Phase 4 - Design II - dynamic modeling

• Tasks
• Tips

Collaboration diagrams in phase 2 are elaborated to sequence diagrams such that the new classes and data structures are taken into account, along with detailed description of the system's internal functionality. Application logic is explicated by modelling state diagrams.

Note that the descriptions and models in phases 0-2 are typically not complete - especially concerning dynamic behaviour and exception handling. In addition, class diagram in phase 3 might contain inconsistencies or missing details that should be fixed using the additional information in sequence and state diagrams.

Tasks

1. Design one or more sequence diagrams per each collaboration diagrams modeled in phase 2. Sequence diagrams should model the normal functionality of the system, as wella as the most essential exceptions and alternate flows (with large sequence diagrams some details can be omitted). Remember to note the implemented associations in phase 3 - especially with the domain classes.
   
2. Depending on the system: model the user interface logic based on Horrock's method or explicate the functionality of a nontrivial (=more than 2 states) domain- or controller class with a state diagram. Partition to substates if necessary.
   
3. Finalize the tasks in phases 1-3 and ensure that the models are consistent: domain descriptions, use case diagram, use case descriptions, data dictionary, analysis and design class diagrams.. Node: analysis class diagram is still kept in "analysis level" - association implementations, , collections classes, or detailed user interface or control classes will not be updated - only new domain-based attributes and domain classes found in design phase. Collaboration diagrams and CRC cards do not need to be updated.
   

Tips

• Example process for modeling sequence diagrams:
• 1. Choose a use case and its associated collaboration diagram.
     
  2. Express objects as rectangles, use variable names if necessary to separate multiple objects of same class. Mark actors with "stick-men" (if tthe UML editor supports the notation).
  3. Add objects for domain classes modeled earlier, as well as detailed boundary and control classes (related to current use case) modeled in phase 3, as well as existing container classes.
     
  4. Based on the using textual use case description and collaboration diagram, consider what kind of messages between objects and actors must be relayed to accomplish the specified functionality. Pay attention the the message ordering and conditions for sending messages.
  5. Mark the messages with arrows and name them with descriptive terms (using verbs). The message must be an operation of the receiving class. If the operation does not yet exist in the class diagram, add it. Use existing methods if possible. Messages should be augmented with essential parameters - object references or values passed to receiving object. Simple return messages do not need to be marked, unless the return value is used later (e.g. object reference variable that is used to call another object).
  6. First, describe the main scenario. Exceptions and alternative flows are can be described either in the same or separate diagrams (referred from the original diagram), depending on diagram size. Loops and conditionals can be described as UML 2.0-fragments or simplified UML 1.4-style notation ([condition] in message name for conditional structured, * a repeat symbol).
  7. Check that the intended behaviour specified in use case is traceble in sequence diagram.
  8. Check that all objects in sequence diagram belong to a class specified in class diagram. Are all classes known - is it possible for a controller object to call a domain object?
     
  9. Update class diagram with required changes noted during designing the sequence diagrams. Check that all the messages in sequence diagrams match the operations in class diagram.
• About creating state diagrams, see Lecture 13. Horrock's method is described in Lecture 14.
  
• When checking the models consider the following:
• • Do the sequence diagrams cover all the functionality described in the most essential use cases, including the most common exceptions?
  • Do the objects know what they are supposed to based on interaction diagrams? Do the classes contain such attributes that the corresponding objects need - if not, can a required reference be asked from another object? Check attribute values that are added or retrieved run-time, reference attributes...
    
  • Are all necessary associations described in detail in the design class diagram?
  • Is the functionality expressed in sequence diagrams presented as methods in design class diagram?
  • Is the control responsibility distributed adequetely - i.e. are the operations defined in "right" classes such that passing values back and forth between objects is minimized?
  • Are names used consistently? E.g. object's type in sequence diagram = class name in class diagram; message name in sequence diagram = operation in classs diagram
  • Check that analysis class diagram is updated (e.g. if new domain classes or domain-related attributes are found during the design phase, they should be updated to analysis model)
    
  • Ensure that the definitions in data dictionary are still correct