Meltem Özturan

Transcription

1 Meltem Özturan 1

2 2

3 Modeling System Requirements Object Oriented Approach to Requirements OOA considers an IS as a set of objects that work together to carry out the function. OO analysis involves two steps: 1. Defining the set of objects that will make up the system and describing the interactions or communications among the various objects. 2. Describing the internal processes that go on within each object to respond to messages from other objects, and to initiate messages to other objects UML notation is used for modeling system requirements in OOA Class diagrams, Use case diagrams, Interaction diagrams and statechart diagrams are the diagrams used in OO analysis 3

4 4

5 Modeling System Requirements Class diagram identifies and classifies the objects that will make up the new system along with their properties (or attributes) Use case diagram is a diagram to show the various user roles and how they will use the system. It is an extension of the event table. It is a convenient way to document the function that the system must support. Interaction diagrams The collaborative diagram shows which object should collaborate to realize a given business function. It shows also the interaction or messages, that are sent between the objects to carry out this function. The sequence diagram shows sequence of messages between objects during a use case. It is another view of the same information contained in the collaboration diagram. Statechart diagram describes the states and behavior of each object The following formula helps so remember the relation of these diagrams: OO Requirements = Event Table + Class Diagram + Use Case Diagrams + Interaction Diagrams (collaboration and/or sequence diagrams) + Statechart Diagram 5

6 Class Diagram 6

7 Class Diagram Class diagram provides definition of structural components of the system The classes identified in the class diagram provide the structure for the database As far as the OO programming also consists of object classes, the class diagram defines the structure of the computer program that will be eventually created Class diagram specifies not only problem domain related classes but also implementation classes - additional classes in a class diagram needed for physical implementation (e.g. user interface classes which include such classes as windows for input screens and output report classes) 7

8 Use Case Diagram 8

9 Use Case Diagram The Use Cases and Actors In the OOA, use case is a single use or function performed by the system for those who use the system; it describes the activity the system carries out in response to an event (or a situation where the system is used for some purpose) There are two concepts in the OOA: (1) A person is involved, and (2) The person uses the system In UML, the person involved is called an actor (always outside of the automation boundaries of the system) 9

10 Use Case Diagram The Use Case Diagram A use case diagram is a graphical model that summarizes the information about the actors and use cases During the use case analysis all of the uses of the system should be identified The uses derive from the events in the event table A use case diagram can be defined as a functional description of the entire system, which identifies functions to be supported by the new system 10

11 Use Case Diagram Automation Boundary and Organization The boundary line drawn around the entire set of use cases is the automated system boundary or the automation boundary (it denotes the boundary between the environment, where the actors reside, and the internal functions of the automated system. Two ways to organize the use cases: By subsystems By including all use cases that involve a specific actor Includes Relationships Very often, one use case can use the services of another case The relationship between these cases is denoted by the connecting line with the arrow. 11

12 Use Case Diagram Scenarios A use case only shows that an actor interacts with the system to carry out a business activity There may be a whole series of individual steps to accomplish the use case (these steps are described with a narrative called a flow of activities) The flow of activities is a general description of the steps within a use case. In most cases, we need to extend the description to even more detail A use case may have several alternative sequences of internal activities. A particular sequence of activities within a use case is called scenario. It represents a unique path through the use case. 12

13 Use Case Diagram The Use Case Diagram Compared to Structured Techniques Similarities Objective of the use case diagram, like context diagram, is to provide an overview of the system (including actors and the functions they perform) and defines the scope of the system and individual use cases appear more like a DFD fragment in that they identify an individual function that the system must support Differences The use case diagram begins by defining the automation boundary while in DFD development this boundary is often not defined until the entire process has been detailed In a DFD an external agent is always the original source or destination of the information and may not necessarily be the one interacting with the system; In a use case diagram, an actor is the one who actually interacts with the system whether or not that actor is the original source of information 13

14 Use Case Diagram Development of a Use Case Diagram First approach: start with an event table and analyze each event to determine: How the system is used to support the event The actors who initiate the event Other use cases that will need to be invoked Generally, each event will become a use case Second approach: start by identifying all the actors who use the system Build a list of actors based on the event table by looking at the Trigger and Source columns Instead of listing the actors by their names, it is better to identify the specific roles that these people play (e.g. clerk, doctor etc.). The same person may play various role; it is important to identify every possible role that will use the system. Once the actors and use cases are identified next step is to develop a flow of activities as the starting point for identifying the various scenarios. 14

15 Interaction Diagrams Sequence & Collaboration Diagrams Two types of diagrams describe flow of information and interactions between objects, but each has a slightly different focus: A sequence diagram focuses more on the details of the messages A collaboration diagram emphasizes the objects that interact together to support a use case During system development, both types or either type of diagram may be used Those who prefer a bottom-up approach develop a sequence diagram first (a sequence diagram shows information flow within a single use case or a single scenario) Those who prefer a top-down approach develop a collaboration diagram first to get an overview of the objects that collaborate to carry out the use case 15

16 Interaction Diagrams - Sequence Diagram 16

17 Interaction Diagram - Sequence Diagram Sequence Diagram To develop a sequence diagram we use both the class diagram and the flow of events for each scenario Sequence Diagrams shows the sequence of interactions between objects that occur during the flow of events in a single scenario or use case Four basic symbols are used on a sequence diagram: The actor symbol (a stickman) The object symbol (a rectangle with the name underlined) The lifeline symbol (a dashed line or a narrow vertical rectangle) The message symbol (a directional arrow with a message descriptor) 17

18 Interaction Diagrams - Sequence Diagram Actors and Objects The stick figures represent the actor of the use case being described The objects are the internal things involved in the use case and are depicted with the rectangles Objects in the OOA create a hierarchy: object class particular object (unidentified or anonymous) - specific (identified) object Objects in the Sequence Diagram: Object class (i.e. a set of objects that have the same characteristics) is represented by a rectangle with the name of the class inside A particular object (i.e. a particular instance of an object) is also represented by a rectangle, but the text inside is underlined with the name of the class inside The same thing may play a role of both actor and an object. 18

19 Interaction Diagrams - Sequence Diagram Lifelines During the period that a scenario is active, the actors and objects are also active. The time period of this active life is represented by a dash line (the lifeline) beneath each actor and object. Lifeline is the vertical line under an object or an actor on a sequence diagram to show the duration of the actor or object within the scenario (time flows from top to bottom, i.e. the messages higher up on the lifeline occur before those below). But creation and destruction of the actor or object is not important for the scenario If it is important to note the creation or destruction of an object, then the long narrow rectangle (called activation lifeline) can be used Activation lifeline is the narrow vertical rectangle to emphasize that an object is active only during part of a scenario 19

20 Interaction Diagrams - Sequence Diagram Messages In the OOA the internal events occur as a response to the messages sent between objects and actors or other objects. A message is a request from one actor or object to another to do some action (in a sequence diagram, actors are like objects because they also perform some function when they receive a message) Messages invoke particular methods Receiving object responds by executing methods Message names are just simple description of the action A message symbol on the diagram includes two parts (1) The directional arrow (2) Message descriptor The syntax for the message description is : [true/false condition] return-value := message-name (parameter list) The true/false condition is a test of whether the message can be sent In some cases, the extended name of the message is used which includes a possible return value from the method and the list of input variables needed by the method. 20

21 Interaction Diagrams - Sequence Diagram Steps in creating a sequence diagram 1. Identify all the objects and actors that are involved in the scenario (they are only actors have been identified in the use case diagram and objects from the classes that are identified in the class diagram) 2. Based on the flow of activities, identify each message that will be required to carry out the scenario along with both source object (or actor) for the message and the destination object (or actor) 3. Determine whether each message is always sent or sent only under certain conditions 4. Sequence the messages correctly and attach them to the appropriate lifelines of actors and objects 5. Add the formal syntax on the messages for conditions, message names and passed parameters 6. Add response messages and communications 21

22 Interaction Diagrams - Collaboration Diagram 22

23 Interaction Diagrams - Collaboration Diagram Collaboration Diagram Objective is to quickly get an overview of all the objects that collaborate to support a given scenario Uses similar symbols as in a sequence diagram (actor, object and message) but there is no lifeline Instead of lifeline, each message is numbered (to indicate the order of the messages) Syntax of the message descriptor in a collaborative diagram is: [true/false condition] sequence-number: return-value := message-name (parameter list) Link is connecting line between two objects or actors (shows that two items share a message one sends, another receives) 23

24 Interaction Diagrams - Collaboration Diagram Notes on Collaboration Diagrams A collaboration diagram can t easily describe information about concurrent messages (or messages that are initiated at the same time) Does not indicate information about creation or deletion of objects within the scenario Often drawn without messages simply to identify the collaborating actors and objects (in this case, another sequence diagram is developed to show the detailed information about the interactions and messages within the scenario) 24

25 Statechart Diagram 25

26 Statechart Diagram The final information needs to be specified is internal logic for each object (it is a description of the actions that the objects perform themselves) In the OOA how an object performs its action is called object behaviour Sequence diagrams give external view of object behavior shows messages passed around but they do not show, what an object does when it gets a message The purpose of a statechart diagram is to describe the internal workings of the object. Each class in the class diagram for a system has its own unique statechart diagram. Relationship between the sequence diagrams and the statecharts can be tabulated; -each column is labelled with the name of a class -each row is for one sequence diagram -X s in the cells show which classes are involved in which sequence diagram -A statechart diagram for a class is based on the entire column for that class. -Every cell with X provides information about the messages to and from the class 26

27 Statechart Diagram Life cycle of an object Each object is an instance of a class, and comes into existence in some manner During its existence it is in certain states and makes transitions from state to state These states and the changes an object makes from state to state are shown in a statechart diagram (two main symbols on the statechart diagram include states and transitions) 27

28 Statechart Diagram Object States A state for an object is a condition during its lifetime when it Satisfies some criteria Performs some action Waits for an event Each unique state has a unique name States are described as semipermanent conditions because external events can interrupt them An object stays in a state until some event causes it to move to another state Quiescent (i.e. Nothing happening) Active (i.e. Performing some action) Action is an activity performed by an object in a particular state Objects in the real world behave in more complex way than being in one state at a time concurrent states 28

29 Statechart Diagram States A state is represented by a rectangle with rounded corners (with the name of the state inside) Any actions that must be performed during the period of the state are placed below the state name in the rectangle In the diagram, the beginning and ending of the statechart are indicated by two darkened circles where the initial state is called a pseudostate (the entry point maybe prior to the creation of the object itself) and the final state indicates the exit from the statechart (frequently denotes the removal of the object from the system) Composite states thus lower-level statecharts can be used for concurrent states 29

30 Statechart Diagram Object Transitions A transition is a component of a statechart that shows the movement from one state to the next one States are semipermanent conditions (transitions interrupt them and cause them to end) Transitions are considered to be short in duration and cannot be interrupted. Once started, a transition runs to completion by taking the object to the new state (called destination state) Internal transition is a special kind of transition that occurs within a state and does not cause the object to leave the state. 30

31 Statechart Diagram Object Transitions A transition is represented by an arrow from an origin state (i.e. the state before transition) to a destination state and is labeled with a string to describe the components of the transition The transition label consists of three components: transition-name (parameters, ) [guard-condition] / action-expression -The transition-name is the name of a message event that triggers the transition and causes the object to leave the origin state. -The parameter list identifies any parameters that the message is to pass to the object -Guard-condition is a true/false test to see whether a transition can be taken (first the trigger must occur and then the guard must also be true!). The guard-condition is on the receiving side of the message (it can be received, but transition takes place only if the guard-condition is true) -Action-expression is the statement on a transition to describe the action to be performed (executes when the transition fires; can be a compound series of steps) 31

32 Statechart Diagram Messages, Transitions, and Actions Sequence diagrams and statecharts are related because both show messages Transition names in statechart correspond to message names in the sequence diagram (usually both of them use same name and parameter list) Objects in statecharts receive and send messages (messages are normally sent as a part of action statement which, in turn, is a part of transition or state) To represent the messages, dot notation is used: first object or class is named, then dot is added and then the name of the message Two statements within the action expression are separated by a semicolon Usually, same name and parameter list for a message and a transition is used 32

33 Statechart Diagram Messages, Transitions, and Actions Completion transition : A transition with no trigger event so that it is taken when the origin state completes its actions Decision pseudostate : A diamond on a statechart to represent a decision point on a path Path : A valid sequence of transitions and states through a statechart Concurrent behavior : Object can do multiple things in parallel and statechart diagram represents concurrent behavior with multiple paths Thread : Each separate path of concurrent behavior Synchronization pseudostate : A vertical bar denoting a point where transition can split into multiple threads Two types of output transitions : - OR condition (one or another path may be taken, but not both!) - AND condition (both paths are taken simultaneously) 33

34 Statechart Diagram Statechart Diagram Development 1.Review the class diagram and select classes that will require the statecharts 2.Identify all the input messages across all sequence diagrams for the selected class (the use cases and scenarios provide the basis for identifying messages into and out of a class). Assume that each message will be the trigger for a transition. 3.For each selected class, make a list of all the states you can identify. Note that each transition requires at least one origin and one destination state. 4.Build statechart fragments (a portion of the path in a statechart) and sequence the fragments in the correct order. Each statechart fragment consists of either a state-transition-state sequence or a transition-state-transition sequence. 34

35 Statechart Diagram Statechart Diagram Development 5. Review the paths and look for independent, concurrent paths. When an item can be in two states, there are two possibilities: either the two states are on independent paths, or one state should be a composite state and the two states should be nested. 6. Expand each transition with the appropriate message event, guard-condition, and action-expression Include with each state appropriate internal transitions and action-expressions. Ensure that every output message identified from the sequence diagram is somewhere within an action-expression for a state or transition. 35

36 Statechart Diagram Statechart Diagram Development 7. Review and test each statechart Make sure your states are states of being Follow the life cycle of an object from creation to deletion Be sure your diagram covers all normal and exception conditions Make sure you ve included all relevant transitions Review all possible messages and make sure they are handled somewhere in the statechart Review all possible actions and activities (processes) and make sure they are included correctly in the statechart Look again for concurrent behavior (multiple threads) and possibility of nested paths (complex states) 36