high-level design with sequence diagrams comp314 (based on original slides by mark hall)

High-Level Design With Sequence Diagrams

COMP314

(based on original slides by Mark Hall)

2007 COMP314 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


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


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


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


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


Sequence Diagram Elements

:SearchPage :SearchResultsPage Catalogue

searchByAuthor()

validateSearchCriteria()

displayResults()method

method calllifeline


Sequence Diagrams

aMailBoxnewMessages

:MessageQueue

add

locateMailBox

:MailSystem

:MailBox

<<create>>


Allocating Behavior (Putting Methods on Classes)…

• Difficult compared to previous modeling tasks

• Factoring out commonality from use cases saves effort when drawing sequence diagrams


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


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


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

CopyMaintain data about copies currently borrowed

Meet requests to borrow and return copies

CollaboratorsResponsibilities

LibraryMember

BookMaintain data about a particular copy of a book

Inform corresponding Book when borrowed or returned

CollaboratorsResponsibilities

Copy


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


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


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


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.

high-level design with sequence diagrams comp314 (based on original slides by mark hall)

Documents