Transcript Document
High-Level Design With Sequence Diagrams
COMP314 (based on original slides by Mark Hall)
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 2007 COMP314 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 2007 COMP314 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
on each other to each other”/calling methods • 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 2007 COMP314 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 2007 COMP314 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 2007 COMP314 Software Engineering
method
Sequence Diagram Elements
:SearchPage :SearchResultsPage Catalogue validateSearchCriteria() searchByAuthor() displayResults()
method call lifeline
COMP314 Software Engineering 2007
2007
Sequence Diagrams
aMailBox newMessages :MessageQueue locateMailBox :MailSystem <
Allocating Behavior (Putting Methods on Classes)…
• • Difficult compared to previous modeling tasks Factoring out commonality from use cases saves effort when drawing sequence diagrams 2007 COMP314 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 2007 COMP314 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 2007 COMP314 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 2007 COMP314 Software Engineering
CRC…
• Advantages – – Encourage discussion among developers Promotes thinking about (and understanding) the high-level behaviour of classes LibraryMember
Responsibilities Collaborators
Maintain data about copies currently borrowed Meet requests to borrow and return copies Copy Copy
Responsibilities
Maintain data about a particular copy of a book Inform corresponding Book when borrowed or returned
Collaborators
Book
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 2007 COMP314 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 2007 COMP314 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
with what the software does from the
system
perspective perspective – Specified assigning behavior to classes and showing method calls over time
how
the software does it at a high level by 2007 COMP314 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. 2007 COMP314 Software Engineering