Behavioral Modeling with UML 2.0

Behavioral Modeling with UML 2.0
PowerPoint Presentation derived from Dennis, Wixom & Tegarden Systems Analysis and Design John Wiley & Sons, Inc.. and from IBM/Rational Course on UML 2.0 Most slides Copyright 2001 © John Wiley & Sons. Others © IBM/Rational.

Objectives Understand the rules and style guidelines for sequence and communication diagrams and behavioral state machines. Understand the processes used to create sequence and communication diagrams and behavioral state machines. Be able to create sequence and communication diagrams and behavioral state machines. Understand the relationship between the behavioral models and the structural and functional models.

Key Ideas Behavioral models describe the internal dynamic aspects of an information system that supports business processes in an organization Key UML behavioral models are: sequence diagrams, collaboration diagrams, and statechart diagrams

CONTEXT: UML DIAGRAMS

The Thirteen (13) UML 2.0 Diagrams
Using UML 2.0 for Model Driven Development The Thirteen (13) UML 2.0 Diagrams Structural Diagrams Class Deployment Composite Structure Package Component Object Behavioral Diagrams Use Case Activity State Machine Timing Interaction Overview Sequence Communication

Using UML 2.0 for Model Driven Development
UML 2.0 Diagrams CoffeeMachine Customer MakeTea TeaMaking << include >> MakeCoffee Use Case Diagram : Hardware Controller Customer FromUser :: Coin ( 10 ) Coffee FillWater WaterOK FillCoffee CoffeeOK HeatWater Warm ToUser CupOfCoffee Here’s a sneak preview of what’s coming up later. You can see that they all have symbols containing text, joined by lines in various styles Sequence Diagram Interaction Overview Diagram

UML 2.0 Diagrams CoffeeMachine Customer Controller Hardware CM Cust Ctrl Hw Class Diagram Statechart Diagram MakingCoffee WaterOK FillCoffee WaterForCoffee / ^ ; Coffee HeatWater P1 FromUser ToUser Ctrl : Controller P2 P3 Hw Hardware P4 WaterOK , Warm CoffeeOK FillWater HeatWater FillCoffee CustbiCtrl Here are two more Only significant one here is the Architecture diagram , more precisely called the Composite Structure diagram, which has a containing frame which is a significant part of the diagram – representing the boundary with the outside world UML 2.0 has 13 diagram types (versus 9 in UML 1.x), and the ones we will look provide the core modelling concepts, and are implemented in Tau Architecture Diagram (Composite Structure)

UML 2.0 Diagrams Activity Diagram Package Diagram Here are two more Only significant one here is the Architecture diagram , more precisely called the Composite Structure diagram, which has a containing frame which is a significant part of the diagram – representing the boundary with the outside world UML 2.0 has 13 diagram types (versus 9 in UML 1.x), and the ones we will look provide the core modelling concepts, and are implemented in Tau Deployment Diagram Component Diagram

When to Use Which Diagram?
Using UML 2.0 for Model Driven Development When to Use Which Diagram? UML is not a method or a process, it is a visual language The different diagrams are like “tools” in a “tool-box”, each with a different intended use [Things to add: typical sequences of diagram use, e.g. UC->SD|AD|Text, CD, StD, etc. -overview of diagram navigation actually allowed in TAU G2 Students always ask for this sort of “usage roadmap”.] Use Case Diagram Architecture Diagram Sequence Diagram Statechart Diagram Class Diagram

CONTEXT: PROCESS MODELS

How Does UML Fit Into a Process?
Using UML 2.0 for Model Driven Development How Does UML Fit Into a Process? UML is the communication language used during the Analysis and Design Phases – aids communication between stakeholders and developers Using UML a complete, accurate and fully consistent description of the system can be created Using UML allows mistakes and errors to be easily identified. The process of looping through the system, removing errors is absolutely essential and unavoidable, and is described as iteration. Iteration occurs within all phases As we saw in the previous lecture, UML is a language that aids communication and understanding between the various stakeholders in the system. Effective communication allows people to determine whether someone has made a mistake, or, alternatively, if there is something inherently wrong with the system to be computerised. Using UML, a complete, accurate and fully consistent description of the system can be created. This is an essential requirement in software system creation as a computer will only perform the functions it is programmed to carry out. If there are errors in the system description, then this will ultimately be transmitted in the final software system. Using UML allows mistakes and system errors to be easily identified. This will mean that the system definition will change. As this may impact on other parts of the system, it is therefore necessary to revisit the entire system description. This process of looping though the system, removing errors is absolutely essential and unavoidable, and is described as Iteration. Iteration is only possible when there is effective communication between the stakeholders. And this demonstrates how UML is integral to the software development process.

The Waterfall Process Divides the project into well-defined phases with intermediate milestones Each phase depends on the completion of the previous The final product is not delivered until all phases are finished Works best on small projects Waterfall method has many advantages: it is the most direct way to the objective with the shortest development time and cost possible However, the drawbacks of this method include: little flexibility for scope changes system limitations not being discovered until later in the development cycle clients not being able to see the product until it is completely finished Analysis Design Implementation Test

The Spiral Process The spiral process is an iterative process Recognizes the need to visit requirements analysis/design/implementation/test sequence more than once Several reasons for this: Identification and resolution of risks Review of earlier “prototype” versions by the user to elicit feedback. Spiral model focus: to address risks incrementally in order of priority Rounds follow the waterfall process Analysis Design Testing Implementation

The Iterative and Incremental Process
Using UML 2.0 for Model Driven Development The Iterative and Incremental Process A logical extension to the spiral model, but more formal and rigorous Structured in four phases: Inception, Elaboration, Construction and Transition Inception Elaboration Construction Transition

Requirements Phase Requirements Phase Requirements Analysis Design Implementation Test

Analysis Phase Analysis Phase Requirements Analysis Design Implementation Test

Analysis Phase Analysis Phase Understand the problem domain Create a model describing the problem domain Free from any technical or implementation details Detailed enough to allow simulation on paper or by using a modeling tool Activities: Acquire domain knowledge Perform use case analysis Define the necessary classes and relationships Define the behavior and collaboration between classes Test the resulting model

Deliverables Analysis Phase Use Case Model with detailed use case descriptions Natural language Sequence diagram Activity diagram State Machine diagram Domain Model Class diagram showing domain concepts and their relationships System Interface Class Diagram Interface Classes Signals that compose the interfaces Data types used by the signals

When is the Analysis Phase Finished?
Using UML 2.0 for Model Driven Development Analysis Phase When is the Analysis Phase Finished? When the Use Cases describe the functional aspects of the System to build When the Conceptual Model expresses the major components of the problem domain When the system interface is well defined When developers feel comfortable estimating the time it will take to develop each use case In practice most of the time during the requirements analysis is usually spent designing the use cases, using these as a means to investigate the intended behavior of the system. It is impossible to completely cover the entire set of behaviors in the requirements analysis. Finding the right trade-off between the completeness of the use cases and the time and effort spent in requirements analysis is an important aspect of this phase. A recommended practice from [32] is that the use cases should cover `approximately 80% of the primary scenarios along with a representative selection of the secondary ones'. The use case model (as well as the other models) will be further extended and refined during the elaboration phase so it is important to force the requirements analysis phase to a completion when a sufficient level of understanding has been reached. 27

Behavioral Models

Behavioral Models Systems have static &dynamic characteristics
Structural models describe the static aspects of the system Behavioral models describe the dynamics and interactions of the system and its components Behavioral models describe how the classes described in the structural models interact in support of the use cases.

Interaction Diagrams

Interaction Diagram Components
Objects an instantiation of a class Operations the behaviors of an instance of a class Messages information sent to objects to tell them to execute one of their behaviors

Kinds of Interaction Diagrams
Sequence Diagrams Communication Diagrams Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Sequence Diagrams Model the behavior of use cases by describing the way groups of objects interact to complete the task. Show sequences of messages (“interactions”) between instances in the system Each diagram depicts a possible set of messages only (a ”scenario”) – not all possible messages Are read left to right and descending Emphasize time ordering

System Level Sequence Diagrams
Describe the interaction between the Actors and the System Remember: Black box Define the System Interface Can be used as System Level Test Cases

Sequence Diagram Syntax

Sequence Diagram – elements
Using UML 2.0 for Model Driven Development Analysis Phase Sequence Diagram – elements OrderCoffee - Basic OrderCoffee Associated Use Case Lifeline Message name Use Case Reference The "interaction OrderCoffee" part of the diagram is TAU specific, as is the page numbering. Message line TAU specific The interaction name and page numbering is Tau specific

Analysis Phase Lifelines A Lifeline consists of a rectangle that identifies the connectable element (such as a part or component) and a vertical line indicating its time of existence Lifeline of unknown Class Lifeline of an Anonymous Object Lifeline of an Object of a known class

More Sequence Diagram Syntax

Sample Sequence Diagram

Analysis Phase Object Communication Messages are labeled with the name of the message (operation or signal) and its argument values. Message parameters can be a data type, a variable or a constant. For correctness the variables and constants must be declared To make the interaction more general use data types or variables as parameters Data type Variable Value

Analysis Phase Referencing To avoid unnecessary duplication it is possible to reuse already existing Sequence Diagrams The name is the Use Case name, not the Sequence Diagram name. A Use Case encapsulates zero or more Sequence, or other types of diagrams

Steps to Build Sequence Diagrams (Dennis)
Set the context Identify which objects will participate Set the lifeline for each object Lay out the messages from top to bottom of the diagram based on the order in which they are sent Add execution occurrence to each object‘s lifeline Validate the sequence diagram

Steps to System Level Sequence Diagrams (alternate view)
Using UML 2.0 for Model Driven Development Analysis Phase Steps to System Level Sequence Diagrams (alternate view) Select a Use Case to model Select a scenario: Basic: positive and straightforward behavior Alternative Exception Add lifelines for the System and each involved Actor Add interactions between the Actors and the System using arrows Name the arrows using message names and parameters Keep it simple, no need to provide all parameters at this point

Sequence Diagram Guidelines
Using UML 2.0 for Model Driven Development Analysis Phase Sequence Diagram Guidelines Keep the diagram simple If it is too complex, perhaps it should be broken down into separate diagrams Don’t capture all the scenarios in one diagram One diagram per scenario Tool tip: using right-click update model on the SD message will automatically create a signal definition in the receiving class definition

InterACTION OVERVIEW DIAGRAMS

Interaction Overview Diagrams
Using UML 2.0 for Model Driven Development Analysis Phase Interaction Overview Diagrams A specialized activity diagram that shows how sequence diagrams can be put together Allow you to construct a “roadmap” of sequence diagrams and navigate easily among them

Interaction Overview Diagram Guidelines
Using UML 2.0 for Model Driven Development Analysis Phase Interaction Overview Diagram Guidelines Keep the diagram simple If it is too complex, perhaps it should be broken down into separate diagrams Show how different Sequence Diagrams interconnect with each other Tool tip: using right-click update model on the SD message will automatically create a signal definition in the receiving class definition

COMMUNICATION DIAGRAMS

What Is a Communication Diagram?
Essentials of Visual Modeling w/ UML Instructor Notes What Is a Communication Diagram? A communication diagram emphasizes the organization of the objects that participate in an interaction. The communication diagram shows: The objects participating in the interaction. Links between the objects. Messages passed between the objects. Unlike sequence diagrams, communication diagrams emphasize the organization of the objects. Sequence diagrams, on the other hand, emphasize the time ordering of the messages. A communication diagram shows how objects interact to perform the behavior of a particular use case or a part of a use case. Like sequence diagrams, communication diagrams are used by designers to define and clarify the roles of the objects that perform a particular flow of events of a use case. They are the primary source of information used to determine class responsibilities and interfaces. Because of the communication diagram’s format, they tend to be better suited for analysis activities. Specifically, they tend to be better suited to depict simpler interactions of a smaller number of objects. As the number of objects and messages grows, the diagram becomes increasingly hard to read. It is also difficult to show additional descriptive information like timing, decision points, or other unstructured information that can be easily added to the notes in a sequence diagram. Communication Diagrams

Example: Communication Diagram
Essentials of Visual Modeling w/ UML Instructor Notes Example: Communication Diagram Provide a preview of a communication diagram for the students. Explain how communication diagrams allow you to see the communication patterns among the objects. Normally, boundary classes are on the “edge,” interfacing with actors. Control classes are toward the middle, managing communication. Entity classes are on the “bottom” where all of the persistent data lives. 5: display course offerings( ) 6: display blank schedule( ) 1: create schedule( ) : Course Catalog : RegisterForCoursesForm : Student 2: get course offerings( ) You can have objects and actor instances in communication diagrams, together with links and messages describing how they are related and how they interact. The diagram describes what takes place in the participating objects, in terms of how the objects communicate by sending messages to one another. You can make a communication diagram for each variant of a use case's flow of events. The above example shows the communication of objects to support the Register for Courses use case, Create a Schedule sub-flow. It is the “communication diagram equivalent” of the sequence diagram shown earlier. 4: get course offerings( ) 3: get course offerings(forSemester) : RegistrationController : CourseCatalogSystem

Communication Diagrams Contents: Objects
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagrams Contents: Objects Explain objects on a communication diagram. Make sure the students understand that this is an object diagram and not a class diagram. How do you know that these are objects and not classes? (The names are underlined.) Note: You don’t have to show the boundary, control, and entity stereotypes on a communication diagram, but they can help you see communication patterns quicker. : RegisterForCoursesForm Objects An object is represented by an object symbol, showing the name of the object and its class underlined, separated by a colon. objectname : classname You can use objects in communication diagrams in the following ways: An object's class can be unspecified. Normally, you create a communication diagram with objects first and specify their classes later. The objects can be anonymous. However, you should name them if you want to discriminate different objects of the same class. : RegistrationController SWTSU Catalog : CourseCatalogSystem

Communication Diagram Contents: Actors
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagram Contents: Actors Explain actors on a communication diagram. : RegisterForCoursesForm : Student : Course Catalog Actors Normally an actor instance occurs in the communication diagram as the invoker of the interaction. If you have several actor instances in the same diagram, try to keep them in the periphery of the diagram. Don’t show the interaction between actors in a communication diagram because actors are, by definition, external to the system. : RegistrationController SWTSU Catalog : CourseCatalogSystem

Communication Diagram Contents: Links and Messages
Essentials of Visual Modeling w/ UML Instructor Notes Communication Diagram Contents: Links and Messages Explain links and messages on a communication diagram. Point out that these are the same messages that were seen on the sequence diagram. Notice, however, that you have to follow the numbers to figure out the sequence. This diagram is more effective at pointing out the relationships between the objects. Messages 5: display course offerings( ) 6: display blank schedule( ) Links 1: create schedule( ) : Course Catalog : RegisterForCoursesForm : Student 2: get course offerings( ) A link is a relationship between objects across which messages can be sent. In communication diagrams, a link is shown as a solid line between two objects. An object interacts with or navigates to other objects through its links to these objects. A link can be an instance of an association. Or, it can be anonymous, meaning that its association is unspecified. Message flows are attached to links. A message is a communication between objects that conveys information with the expectation that activity will ensue. In communication diagrams, a message is shown as a labeled arrow placed near a link. That is, the link is used to transport or otherwise implement the delivery of the message to the target object. The arrow points along the link in the direction of the target object (the one that receives the message). The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often used in communication diagrams because they are the only way to describe the relative sequencing of messages. 4: get course offerings( ) 3: get course offerings(forSemester) : RegistrationController : CourseCatalogSystem

Sequence and Communication Diagram Similarities
Essentials of Visual Modeling w/ UML Instructor Notes Sequence and Communication Diagram Similarities Show the students the similarities between sequence and communication diagrams. Go back and point to the semantic similarities between the two diagrams. Semantically equivalent Can convert one diagram to the other without losing any information Model the dynamic aspects of a system Model a use-case scenario Because they both derive the same information from the UML’s metamodel; sequence diagrams and communication diagrams are semantically equivalent. As a result, you can take a diagram in one form and convert it to the other without any loss of information.

Sequence and Communication Diagram Differences
Essentials of Visual Modeling w/ UML Instructor Notes Sequence and Communication Diagram Differences Show the students the differences between the two diagrams. The use of sequence versus communication diagrams is a personal choice. This course does not recommend one over the other, but describes the advantages of each. For brainstorming, some find the communication diagram easier, a closer visual representation of CRC cards. The students should use the diagram they like best. However, you may want to recommend that they ultimately create the communication diagram to find relationships between the associated classes. Note: RUP recommends that communication diagrams be used in analysis and that sequence diagrams be used in design. Sequence diagrams Communication diagrams Show the explicit sequence of messages Show execution occurrence Better for visualizing overall flow Better for real-time specifications and for complex scenarios Show relationships in addition to interactions Better for visualizing patterns of communication Better for visualizing all of the effects on a given object Easier to use for brainstorming sessions Sequence and communication diagrams express similar information, but show it in different ways. Communication diagrams emphasize the structural communication of a society of objects and show a clearer picture of the pattern of relationships and control that exist among the objects participating in a use case. Communication diagrams also show more structural information, such as the relationships among objects. Communication diagrams are better for understanding all the effects of a given object and for procedural design. Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and complex scenarios. A sequence diagram includes chronological sequences but does not include object relationships. Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative sequence. On sequence diagrams, the time dimension is easier to read, the operations and parameters are easier to present, and the larger number of objects are easier to manage than in communication diagrams. Both sequence and communication diagrams allow you to capture semantics of the use-case flow of events. They help identify objects, classes, interactions, and responsibilities, as well as validate the architecture.

ACTIVITY DIAGRAMS

Analysis Phase Activity Diagrams Activity diagrams describe the workflow behavior of a system Activity diagrams can show activities that are conditional or parallel. Activity Diagrams are useful for: analyzing a use case by describing what actions need to take place and when they should occur describing a complicated sequential algorithm modeling applications with parallel processes modeling bussiness workflow

Activity Diagram - elements
Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram - elements Object Node Initial Node Action Node Join Fork Activity Final Decision Node Guard

Activity Diagram Symbols - 1
Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 1 Initial node Starting point for invocing other activities. An activity may have several starting points. Action/Activity An action is an executable unit. Can also refer to a new activity diagram.

Action States and Activity States
Using UML 2.0 for Model Driven Development Analysis Phase Action States and Activity States Each state in an activity diagrams is either: an action state describes an atomic action the outgoing transitions are implicitly triggered by the completion of the action in the state or an activity state describes an enduring activity which can be interrupted invokes an activity graph the activity state is not exited until the final state of the nested graph is reached.

Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 2 Object node Represents an instance of a clasifier, usually a class Used to show input to or output from an action. An object flow shows objects being generated or used by actions or activities in activity diagrams

Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 3 Decision node A decision node is a control node that chooses between outgoing flows. Each branch has its own guard condition “Else” may be defined for at most one outgoing transition Fork/Join symbol Divides a flow into multiple concurrent flows. Flows can be split and synchronized again.

Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 4 Connector symbol Label and Join Accept event symbol Represents an input action. Send signal symbol Represents an output action. Accept time event symbol Represents a timeout situation. To set a timer, use textual syntax in an action node

Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 5 Activity final symbol Aborts all flows in the containing activity. Flow final symbol Destroys all tokens that arrive at it, but has no effect on other flows. Text symbol Comment symbol: unconnected or unselected it looks almost like a text symbol.

Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Symbols - 6 Activity Partition (Swim lanes) Swim lanes visually group the action states. They have no semantics but are often used to show a relation between activities, for example activities performed by a person, business unit etc. Swimlanes can also contain other swimlanes. You can also indicate that a swimlane represents a certain part or that it represents an external entity.

Activity Diagram – Swimlane Example
Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram – Swimlane Example Transitions can take place from one swim lane to another

Activity Diagram – Example
Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram – Example Card Inserted System prompts for PIN Customer enters PIN Log invalid PIN Validate PIN Select transaction type Prompt PIN invalid [PIN invalid] [PIN valid] Reject card [NbrOfAttempts < 3] for amount for currency [Withdrawal] [Foreign currency transaction] Customer enters amount enters currency Guard: Follow this path, only if the text in the brackets [ ] evaluates to true.

Activity Diagram Guidelines
Using UML 2.0 for Model Driven Development Analysis Phase Activity Diagram Guidelines Keep the diagram simple The focus is easy communication. Don’t be too formal Swimlanes should only represent the Actors and the System All required Object Nodes should be part of the Conceptual Model Revise the Model if necessary Try to capture all the scenarios of the Use Case in one diagram But be careful not to overload the diagram. If necessary use more than one per Use Case Emphasize the collaborative and parallel aspects of the behavior

Drawing Activity Diagram
Using UML 2.0 for Model Driven Development Analysis Phase Drawing Activity Diagram Remember, this is an iterative process Select a Use Case to model Look at all scenarios: Basic: positive and straightforward behavior Alternative Exception Find the Use Case participants Find the main activities Internal and Intermediate activities will be defined in later phases Find the Decision Criteria that defines the transition between activities Find the Input and the Output for the activities Determine which activities are parallel/concurrent and which ones are sequential Exercise 8

Assignment Build Activity Diagram
Using UML 2.0 for Model Driven Development Analysis Phase Assignment Build Activity Diagram Identify the participating candidates and draw the associated swim lane Identify and define activities Identify and define transitions between those activities Add the necessary decision nodes that are necessary to understand the use case If pertinent, add the Object Nodes and Flows

Behavioral State Machines

Analysis Phase State Machine Diagram A state machine diagram specifies the dynamic behavior of an element in a reactive, event-driven way Specifies a finite number of states of an element and how transitions between states are performed in response to events Typically not used for all objects Just for complex ones Since te entire ”system” may be represented by a class or a set of systems it too may have its own statemachine diagram.

State Machine Diagram Usage
Using UML 2.0 for Model Driven Development Analysis Phase State Machine Diagram Usage To elaborate use case specifications To specify high-level system behavior during analysis Capture significant events that can act on an object

System Level State Machine Diagram
Using UML 2.0 for Model Driven Development Analysis Phase System Level State Machine Diagram Defining a System Level State Machine that includes all Use Cases would be unrealistic Too many system states Too many possible transitions Instead, a System Level State Machine should be created to show only some aspects of the functionality Each of these State Machines could be used to do partial simulation of the System On paper Using a UML tool Tool tip: using right-click update model on the SD message will automatically create a signal definition in the receiving class definition

Components of State Machines
States values of an object’s attributes at a point in time Events change the values of the object’s attributes Transitions movement of an object from one state to another Actions atomic, non-decomposable processes Activities non-atomic, decomposable processes

State Machine Syntax

State Machine Diagram - elements
Using UML 2.0 for Model Driven Development Analysis Phase State Machine Diagram - elements Initial state Transition Self transition State Final state

Sample State Machine

Analysis Phase Transition (1) event-name ( parameter-list ) [ guard-condition] / action-expression; Event-name Parameter-list TAU specific The action language in transitions is Tau specific Action-expression MBJ: Any action language usage is TAU specific, including for example assignment. Guard-condition

Analysis Phase Transition (2) event-name ( parameter-list ) [ guard-condition] / action-expression; incoming-signal-name / signal-output; Warm / ^FillWater; incoming-signal-name ( parameter-list ) / operation-call; Coin(faceValue) / Amount = AddCoin ( Amount , faceValue ); The variable that will contain the parameter value, must be declared and visible within the scope of the state machine

Analysis Phase Transition (3) event-name ( parameter-list ) [ guard-condition] / action-expression; [ guard-condition] / signal-output ( parameters-list ); [Amount >= drinkCost] / ^theMessage(“Please make your drink selection”); incoming-signal-name [guard-condition] / signal-output; Tea [Amount < drinkCost] / ^GetTeaBag;

Steps to Build a State Machine
Set the context Identify the initial, final, and stable states of the object Determine the order in which the object will pass through the stable states Identify the events, actions, and guard conditions associated with the transitions Validate the behavioral state machine

State Machine Diagram Guidelines
Using UML 2.0 for Model Driven Development Analysis Phase State Machine Diagram Guidelines Keep the diagram simple If it is too complex, perhaps it should be broken down into separate diagrams Try to capture all the scenarios of a Use Case in one diagram One diagram per Use Case Tool tip: using right-click update model on the SD message will automatically create a signal definition in the receiving class definition

Drawing State Machine Diagrams
Using UML 2.0 for Model Driven Development Analysis Phase Drawing State Machine Diagrams Find the Classes or Use Cases that are important enough to justify a behavior analysis Find the main states Internal and Intermediate states will be defined later in the Design phase Find the required transitions to fulfill all the Actors’ requests As for the Sequence Diagram, name the incoming request and answers in a natural language. Message names will be defined/refined later. Do not define sub-state machine Keep it simple Simply give the short description of the internal state behavior Tool tip: using right-click update model on the SD message will automatically create a signal definition in the receiving class definition

CRUD Analysis

CRUD Analysis Labels object interaction in 4 possible ways
Create Read Update Delete Matrix representation of objects and interactions Most useful as a system-wide representation Identify complex objects Catch omissions Group closely related classes

Sample CRUD Matrix

Behavioral Modeling with UML 2.0

Similar presentations

Presentation on theme: "Behavioral Modeling with UML 2.0"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Behavioral Modeling with UML 2.0

Similar presentations

Presentation on theme: "Behavioral Modeling with UML 2.0"— Presentation transcript:

Similar presentations

About project

Feedback