High-Level Design With Sequence Diagrams COMP314 (based on original slides by Mark Hall)

2007COMP314 Software Engineering Modeling So Far… Domain modeling (preliminary design) –Behavioural requirements through use cases –Most problem space (conceptual) objects discovered –Static relationships on high-level class diagram Some class attributes identified –Maybe: some dynamic relationships (behaviour) described in functional requirements text

2007COMP314 Software Engineering Interaction Modeling: Moving Towards a Solution… Primary goal: –Allocate behaviour among objects from class diagram –Need to decide which objects are responsible for which bits of behaviour

2007COMP314 Software Engineering Interaction Modeling… Goals of interaction modeling continued: –Show the detailed interactions that occur over time among the objects associated with each use case Objects interact by sending “messages to each other”/calling methods on each other Identify the necessary messages/operations/methods for each unit of behaviour within a use case –Finalize distribution of operations among classes Find appropriate homes for attributes and operations Update static model

2007COMP314 Software Engineering Sequence Diagrams… Represent the major work product of an OO design One sequence diagram for each use case –Basic course + all alternative courses Forms the core of the dynamic model and defines: –Behaviour of the system at run time (ie what the system does) –A high-level view of how the system accomplishes behaviour

2007COMP314 Software Engineering Sequence Diagrams… Four types of elements: –The text for the course of action of the use case appears down the left hand side –Objects along the top Name of object and/or class appears in a box The object’s lifeline (a dotted line) extends from each box down the page –Messages/method calls are arrows between objects –Methods (operations) are rectangles that lie on top of the lifelines Length of rectangle indicates duration of activation

2007COMP314 Software Engineering Sequence Diagram Elements :SearchPage:SearchResultsPageCatalogue searchByAuthor() validateSearchCriteria() displayResults() method method call lifeline

2007COMP314 Software Engineering Sequence Diagrams aMailBox newMessages :MessageQueue add locat Box :MailSystem :MailBox >

2007COMP314 Software Engineering Allocating Behavior (Putting Methods on Classes)… Difficult compared to previous modeling tasks Factoring out commonality from use cases saves effort when drawing sequence diagrams

2007COMP314 Software Engineering Allocating Behavior… Two questions –What are the objects? –Which objects are responsible for which functions Responsibility driven design –A class should have a single “personality”, ie. A strongly related set of behaviours –Think cohesion –Avoid “schizophrenic” classes

2007COMP314 Software Engineering Class Responsibility Collaboration Cards… CRC cards can help you to think in terms of responsibilities Especially helpful for people new to OOA/OOD Not part of the UML Provides a brief, high-level overview of a class On a standard index card for each class, record: –The name of the class, at the top; –The responsibilities of the class, along the left-hand side; –The collaborators of the class, which help to carry out each responsibility, on the right-hand side of the card

2007COMP314 Software Engineering CRC… Responsibility –High level description of the purpose of the class –Avoid description of bits of data and process –Capture the purpose in (at most) a few sentences Collaborators –With each responsibility, indicate which other classes are needed to fulfil it

CRC… Advantages –Encourage discussion among developers –Promotes thinking about (and understanding) the high-level behaviour of classes Copy Maintain data about copies currently borrowed Meet requests to borrow and return copies CollaboratorsResponsibilities LibraryMember Book Maintain data about a particular copy of a book Inform corresponding Book when borrowed or returned CollaboratorsResponsibilities Copy

2007COMP314 Software Engineering Drawing Sequence Diagrams… Copy the text for the use case under consideration onto the left margin of the page –Serves as a reminder of what is to be accomplished –At this point we should have: Validated the use case text with stakeholders/users Refined the use case text to explicitly reference objects from the domain model Reviewed the requirements and preliminary design –Use white space around text to help it line up with associated messages

2007COMP314 Software Engineering Adding Infrastructure… Add methods and attributes to classes as soon as you decide where they go in the context of your sequence diagrams –Keep in mind coupling and cohesion Add “helper” classes and other infrastructure (eg. LibraryMemberControl) to system-level class diagrams –Shifts focus from problem space to solution space –Static model evolves from initial domain model to the final “software blueprint” from which code is written

2007COMP314 Software Engineering Adding Infrastructure Evolution of what the software does to how it does it Through sequence modeling we have –Linked what the software does from the user perspective with what the software does from the system perspective –Specified how the software does it at a high level by assigning behavior to classes and showing method calls over time

2007COMP314 Software Engineering Adding Infrastructure As design evolves more detail is added and implementation becomes more straightforward –Still need to specify how each object’s state changes in response to messages it receives –Still need to specify in detail the control and decision logic for each method in each class. Eg. Structured english/pseudocode, decision tables, decision trees - see Pressman ch. 14, Sommerville ch. 12.