Date: Tue, 14 Jan 1997 22:52:35 GMT Server: NCSA/1.4.2 Content-type: text/html Last-modified: Tue, 04 Jun 1996 21:05:58 GMT Content-length: 9833
This page is a tutorial for students of Computer Science 525 - Software Creation and other individuals wishing to learn the OSA model. Systems Analysis is defined as the study of a specific domain of interacting objects for the purpose of understanding and documenting their essential characteristics. The key words used in this definition are
This document consists of a brief description of model-driven analysis, a discussion of the temporal logic of OSA, and concludes with a summary of the different components of an OSA model instance.
An example of the difference between a model and a method is the problem finding the way to a terminal in an airport. People can either ask a steward the way to a specific terminal and receive step-by-step instructions or look at an airport map. The steward will tell a person to go down the breezeway, turn left at the cafeteria, go down the escalator, and then turn right. However, if a person misread his ticket and arrived at the wrong terminal, then he will have to ask another steward how to get to the correct terminal.
In contrast, if a person looks at the airport map that gives an abstract view of the airport and a reference position with the "You Are Here" arrow, then a person will be able to find his way to his terminal. If he misread the ticket he can recall in his mind where terminal F is in relation to terminal C and will be able find his way.
Both model-driven and method-driven analysis techniques have their merits. This tutorial will contain a hyperlink to the method-driven approach of OSA in the future. However, this tutorial is chiefly concerned with the model-driven approach and will describe that approach in detail.
Time in OSA is defined to be the set of all non-negative integers. Hence, time 0 is when the system first begins operating. The smallest increment of time is 1. Anything occuring in a smaller time increment is considered to be instantaneous. If the data instance at time t is equal to the data instance at time t + 1, then the data instance was not changed during that time increment.
The Object Behavior Model allows the analyst to construct an abstract computation machine called a state net that models the behavior of objects in a particular object set. A state net is a non-deterministic machine that allows multiple threads to be processed. Hence, an object can have one or more states activated at any one time. A thread can change states by passing through transitions. A transition consists of a trigger and an action. Common triggers are switch activations, key presses, mouse clicks, receiving a message, or a change in some conditional value. For example, when a person reaches the age of 13, that person becomes a teenager. This could be a transition between the child state and the teenager state. The trigger would be the condition that person's age is greater than or equal to 13. When a trigger is true, an object can also initiate an action associated with a particular state transition. When a key is pressed the corresponding action to the trigger is that a character is echoed on the screen. Trigger and actions allow objects to be able to react to input and generate output.
The Object Interaction Model allows the analyst to model interaction and communication between objects of various classes. A person can talk to another person, an employee can complain to his or her boss, and a client can request a service or data from a server. All these interactions can be easily modeled in the Object Interaction Model. An interaction between two object sets has a name, a list objects that are sent from the source to the destination and another list of object returned to the sender by the receiver. In its basic form an interaction originates in an action of an object set's state net and influences the triggers of another object set's state net. However, it can also be used as a general high-level communication model in order to keep track of which object sets influence one another.
Large projects modeled in OSA tend to become very large and confusing. In order to combat this problem, High-Level Components have been developed. High-Level Components abstract arbitrarily large portions of information in the OSA diagram. High-Level Components exist for objects, object sets, relationship sets, states, transitions, and interactions. High-Level Components are very useful when a quick overview of a system is needed, or when a clear understanding of the system being modeled can be achieved through further abstraction. If I were to model a kitchen, I would have such High-Level Objects as the oven, the microwave, the refrigerator, the sink, and the cupboards among other things. Within these High-Level Objects, their parts, behaviors, and interactions would be modeled. However, it would be easy to see the main parts of the kitchen along with their primary functions.