Beruflich Dokumente
Kultur Dokumente
Lecture Outline
Unified Modeling Language (UML) ObjectObject-Oriented Requirements (OOR) System Activities Use Case Diagram Activity Diagram System Sequence Diagram State Machine Diagram Integrating Object-Oriented Models Object2
Object-oriented system requirements are specified and documented through process of building models Modeling process starts with identification of use cases and problem domain classes (things in users work environment) Business events trigger elementary business processes (EBP) that new system must address as use cases Use cases define functional requirements
4
OOR - Models
OO models (or diagrams) to define system requirements are called use case models:
Use case diagram shows 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. Sequence diagram shows inputs and outputs and sequence of messages between an external actor and the system objects during a use case or scenario. The flow of information between the objects is in form of messages
OO models (or diagrams) to define classes of objects and their states are called domain models :
Domain class diagram (see lecture 5) identifies and classifies the objects that will make up the new system along with their properties (or attributes) State machine diagram describes the states and behavior of each 5 object: life of an object in state and transitions
Use case model used to identify and define all elementary business processes that system must support Use cases are identified at two levels:
Overview level (event table and use case diagram of all the use cases) Detailed level (for each use case use case description, activity diagram, sequence diagram)
Use case an activity a system carried out, usually in response to a user request Actor (person, other system, or device that receive services from the system and who actually interact with the system)
Role played by user Outside automation boundary
6
Event decomposition technique (event table) CRUD analysis technique (create, read/report, update, delete) to ensure coverage
7
Graphical UML diagram that summarizes information about actors and use cases Simple diagram shows overview of functional requirements Symbols: use case is symbolized by an oval with the name of the use case inside; stick figure represents an actor (i.e., a role) Two approaches to use case diagrams
By subsystem By actor
8
Use Case Diagram with Automation Boundary and Alternate Actor Notation
10
11
12
A packaged notation is used: a tabbed rectangle that groups similar component together 13
<<Includes>> Relationship
Documents situation in which one use case requires the services of a common subroutine Another use case is developed for this common subroutine A common use case can be reused by multiple use cases E.g., two use cases Create new order and Update order may need to validate the customer account. A common use case may be defined to 14 carry out this function
15
16
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) - steps within a use case A use case may have several alternative internal activities. In the RMO example, for the use case Create new order there are at least two sequences when: A customer creates telephone order through clerk (a clerk interacts with the system), or A customer creates web order (a customer interacts with the system) A particular sequence of activities within a use case is called scenario. It represents a unique path through the use case E.g., two possible scenarios for the RMO use case Create new order: in the first instance, the second actor Order clerk is involved who is actually interfacing with the system
19
20
Activity Diagrams
Used to document workflow of business process activities for each use case or scenario Standard UML 2.0 diagram as seen in Chapter 4 Can support any level of use case description; a supplement to use case descriptions Helpful in developing system sequence diagrams
21
22
23
Interaction diagram a communication diagram or a sequence diagram System sequence diagram (SSD) is type of UML 2.0 interaction diagram Used to model input and output messaging requirements for a use case or scenario Shows sequence of interactions as messages to/from actors and internal objects during flow of activities Emphasis: how the actor interacts with the system by entering input data and receiving output data Object notation instead of class notation is used to show that message is sent to an individual object, not the class System is shown as one object: a black box
24
25
SSD Notation
Lifeline or object lifeline is a vertical dashed line under object or actor to show the sequence of messages over time: from top to bottom Message is labelled on arrows to show messages sent to or received by actor or system, including input data: request operation in the destination object Actor is role interacting with the system with messages Object is the component that interacts with actors and other objects
26
27
SSD Notation
Activation line
28
SSD Lifelines
SSD Messages
Internal events identified by the flow of objects in a scenario Requests from one actor or object to another to do some action Invoke a particular method Input message solid line Return message dashed line Complete syntax:
30
31
Repeating Message
32
Begin with detailed description of use case from fully developed form or activity diagram Identify input messages Describe message from external actor to system using message notation Identify and add any special conditions on input message, including iteration and true/false conditions Identify and add output return messages 33
34
35
SSD of the Web Order Scenario for the Create New Order Use case
36
The relationship of use case diagram, class diagram and sequence diagrams
SSD includes objects from the class diagram and actors from the use 37 case diagram
A complete SSD for the RMO use case Create new order
39
http://www.visualjokes.com
40
SSDs give external view of object behaviour messages passed around but do not show, what an object does when it gets a message There is a need to specify internal logic for each object, i.e., a description of the actions that the objects perform themselves State machine diagram is UML a 2.0 diagram that models object internal behaviour, states and transitions
Complex problem domain classes can be modeled
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 SMD (two main symbols: state and 41 transitions)
State of an object
A condition that occurs during its life when it satisfies some criterion, performs some action, or waits for an event Each state has unique name (e.g., on, working, loading equipment, etc.) and is a semipermanent condition or status (because external events can interrupt them) Action is an activity performed by an object in a particular state 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
42
43
Pseudostate the starting point of a state machine, indicated by a black dot Origin state the original state of an object from which the transition occurs Destination state the state to which an object moves after the completion of a transition Message event the trigger for a transition, which causes the object to leave the origin state Guard condition a true/false test to see whether a transition can fire Action expression a description of the activities performed as part of a transition
44
45
46
47
An SMD 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
48
Review domain class diagram, select important ones, and list all state and exit conditions Begin building state machine diagram fragments for each class Sequence fragments in correct order and review for independent and concurrent paths Expand each transition with message event, guard-condition, and action-expression Review and test each state machine diagram
49
50
51
52
Order Domain Class for RMO RMO States and Exit Transitions
53
54
55
Complete use case diagram is needed to understand total scope of new system Domain model class diagrams should also be as complete as possible for entire system With iterative approach, construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration Development of a new diagram often helps refine and correct previous diagrams
56
57
Readings
For next lecture: Chapter 8 Evaluating Alternatives for Requirements, Environments, and Implementation
58