M.Sc Computing Science Software Engineering Lecture 4

1
M.Sc Computing Science Software Engineering
Lecture 4

• Niki Trigoni
• Department of Computer Science
• and Information Systems
• Birkbeck College, University of London
• Email niki_at_dcs.bbk.ac.uk
• Web Page http//www.dcs.bbk.ac.uk/niki

2
Review of lecture 3

• We introduced the Domain Model, the main artifact
  of the Business Modeling discipline.
• The Domain Model is inspired from the artifacts
  of the Requirements discipline (mainly from the
  use cases).
• The Domain Model is a visual representation of
  conceptual classes in the problem domain. It also
  illustrates
• attributes of conceptual classes
• associations between conceptual classes
• The Domain Model is initiated and almost
  completed in the Elaboration phase.
• Working on the Domain Model reduces the gap
  between requirements and solution.

3
Review of lecture 3
Sales LineItem quantity
ProductSpec description price specID
Described-by
1

1..
Contained-in
1
Sale date time
Payment amount
Paid-by
1
1
Conceptual classes Not software classes
Rltp Multiplicity denotes how many objects are
associated with another at a particular moment
Select attributes with simple data types (no
object references, no foreign keys). No
methods
4
Review of lecture 3

• We also introduced Contracts, that reflect state
  changes of objects in the Domain Model.

System
Cashier
makeNewSale()
enterItem(itemID, quantity)
description, total
more items
endSale()
total with taxes
makePayment(amount)
change due, receipt
System Sequence Diagram
5
Overview of lecture 4

• The Design Model
• Representation of the Design Model using UML
  notation
• Collaboration diagrams
• Sequence diagrams
• Introduction to the Object Design
• assigning responsibilities to objects
• responsibilities and methods
• responsibilities and interaction diagrams
• design patterns
• A mini workshop examples of interaction diagrams

6
The Design Model

• Comparing the Design Model to the Domain Model
• they both use the object-oriented paradigm
• the Domain Model describes the problem at hand
  (does the right thing), whereas the Design Model
  designs a good solution for the problem (does
  the thing right)
• the Domain Model provides a static view of
  conceptual classes, whereas the Design Model
  provides both a static and a dynamic view of
  software objects and classes.

The Design Model
7
Interaction diagrams

• Interaction diagrams are the heart of the Design
  Model
• They illustrate how objects interact via messages
  and collaborate to fulfill the requirements
• They provide a dynamic view to the system
• Many design decisions are taken in the process of
  generating interaction diagrams
• gt their creation requires strong design skills
• But, first lets look at the notation!

8
Interaction diagrams

• Two kinds of Interaction diagrams
• Collaboration diagrams
• Sequence diagrams
• Collaboration diagrams illustrate object
  interactions in a graph or network format, where
  objects can be placed anywhere in the diagram.
• Sequence diagrams illustrate object interactions
  in a fence format, in which each new object is
  successively added to the right.

9
Interaction diagrams
Collaboration diagram Sequence
diagram
msg1()
ClassAInstance
ClassAInstance
ClassBInstance
1.msg2()
msg1()
2.msg3()
msg2()
ClassBInstance
msg3()
10
Common interaction diagram notation

• Classes and instances
• class example
• instance examples
• Message expression syntax
• return message (parameterparameterType)
  returnType
• message example
• spec getProductSpec (idItemID) ProductSpec
• (type information can be omitted)

Payment
p1Payment
Payment
11
Collaboration diagram notation

• Message number sequencing
• Message direction
• Creation messages
• Self messages

msg()
2.create()
ClassA
ClassB
1.msg1()
12
Collaboration diagram notation (cont.)

• Nesting of messages
• Conditional messages
• Mutually exclusive conditional paths

msg()
1.msg1()
ClassA
ClassB
1.1 cond1msg2()
2.msg3()
2bnot cond2.msg5()
2acond2.msg4()
ClassC
ClassD
13
Collaboration diagram notation (cont.)

• Iteration or looping
• Iteration over a collection
• Messages to a class, rather than an instance

ClassD
1.2 staticMsg()
msg()
1.msg1()
ClassA
ClassB
1.1 i1..Nmsg2()
2 msg3()

ClassE
ClassC
14
Sequence diagram notation

• Sequence is inferred by order of arrowed lines
  (top-bottom)
• Activation boxes show message nesting
• Returns are illustrated with dotted lines

ClassA
ClassB
msg0()
msg1()
create()
msg2()
ClassC
msg3()
msg4()
msg5()
15
Sequence diagram notation (cont.)

• Conditional messages
• Mutually exclusive conditional messages
• Messages to class objects

ClassA
ClassB
ClassC
msg0()
daySunday msg1()
amountlt10 msg2()
amountgt50 msg3()
16
Sequence diagram notation (cont.)

• Iteration of a message
• Iteration of multiple messages
• Iteration over the items of a Collection object

CollClassInst
ClassAInstance
ClassBInstance
msg0()
i1..N msg1()
msg2()
msg3()
i1..N
17
Overview of lecture 4

• The Design Model
• Representation of the Design Model using UML
  notation
• Collaboration diagrams
• Sequence diagrams
• Introduction to the Object Design
• assigning responsibilities to objects
• responsibilities and methods
• responsibilities and interaction diagrams
• design patterns
• A mini workshop examples of interaction diagrams

18
Main design consideration

• The most important task in the Design Model is to
  assign responsibilities to objects.
• The use cases describe different tasks that must
  be performed in their context. Who is responsible
  for performing these tasks? Are they going to be
  performed by one element (object) or delegated to
  (shared amongst) many elements?
• Responsibilities are obligations of an object in
  terms of its behavior. There are two kinds
• knowing
• doing

19
Object responsibilities

• Doing responsibilities of an object include
• creating an object, doing a calculation,
  initiating action in other objects, coordinating
  activities in other objects
• Knowing responsibilities of an object include
• knowing about private data, about related
  objects, about things it can derive and calculate
• Examples
• A Sale is responsible for creating
  SalesLineItem
• A Sale is responsible for knowing its total

20
Responsibilities and methods

• In general, responsibilities are implemented
  using methods.
• Methods either act alone or collaborate with
  other object methods.
• Depending on its granularity, a responsibility
  may correspond to a single method in a class, or
  it may involve many methods across many classes
  packaged in a subsystem.

21
Responsibilities and interaction diagrams

• How do we assign responsibilities (implemented as
  methods) to objects? Interaction diagrams show
  choices in assigning responsibilities.

Sale
makePayment(cashRcvd)
create(cashRcvd)
Payment
It implies Sale objects have a responsibility to
create Payments. This responsibility is invoked
with a makePayment message and handled with a
corresponding makePayment method.
22
Patterns

• Patterns guide object-oriented developers in the
  creation of software.
• They codify existing tried-and-true knowledge and
  principles the more widely they are used, the
  better.
• They are expressed in a standard format
• Pattern Name
• Solution
• Problem It Solves

23
Pattern Example The Information Expert

• Pattern Name Information Expert
• Solution Assign a responsibility to the
  information expert- the class that has the
  information necessary to fulfill the
  responsibility.
• Problem It Solves What is a general principle
  of assigning responsibility to objects?

24
Why are patterns useful?

• Patterns are very simple to use.
• They are applicable in many contexts in fact,
  the notion of a new pattern could be considered
  an oxymoron.
• If one learns how to apply them properly, s/he
  will generate designs that are easy to
  understand, maintain and reuse.
• By referring to pattern names, designers can
  communicate easily and explain the reasons behind
  their design choices.
• Patterns provide a formal framework for
  generating good designs gt avoid hand-waving.

25
The GRASP patterns

• Information Expert
• Creator
• Low Coupling
• High Cohesion
• Controller
• (They will be covered in detail in the next
  lecture.)

26
Workshop interaction diagrams

• We will produce a set of collaboration and
  sequence diagrams
• Goals of this exercise
• Learn notation practice generating interaction
  diagrams
• Understand how responsibilities are reflected in
  interaction diagrams
• For each of the following scenarios, draw a
  corresponding collaboration and sequence diagram.
  Explain which object is responsible for the tasks
  mentioned in the scenarios.

27
Workshop scenarios

• The system event startSale is first sent to a
  Register object, which clears its state and
  creates a new Sale object.
• The system event newItem(id,quantity) is sent to
  the Register object. Upon receiving this system
  event, the Register object gets the spec of this
  item from a ProductCatalog object. It then asks
  the Sale object to create a new SalesLineItem
  object with this spec and quantity.
• A payment is entered through a Register to a Sale
  object (system event). If the Sales state is
  complete a new Payment object is created.

28
Workshop scenarios

• Like 3, with the following modification. If the
  Sales state is not complete then set it to be
  complete and create a new Payment object.
• A system event asks for the total of a Sale
  object. The Sale evaluates its total by asking
  the SalesLineItem objects to evaluate their
  subtotals. Based on the spec, the SalesLineItem
  identifies which ProductSpec object knows the
  price of the corresponding product. A
  SalesLineItem identifies its subtotal based on
  the quantity and the price of the corresponding
  ProductSpec.
• An Account object receives a message
  evaluateInterest. After checking that its state
  is active, the Account object asks each
  AccountEntry to evaluate its partial interest.
  Every AccountEntry does so by using a static
  method of an InterestCalculator class (and
  passing appropriate parameters).

29
Summary of lecture 4

• Interaction (Collaboration and Sequence) diagrams
  can be used to illustrate object interaction.
• They show who messages are exchanged between
  objects and the order in which they are
  exchanged.
• Interaction diagrams may represent a series of
  notions, like self-messages, create-messages,
  loops, iteration over collections, conditional
  messages, mutually exclusive paths and messages
  to classes.
• The way in which objects interact in these
  diagrams implies how responsibilities are
  assigned to objects - a great design
  consideration.
• Good object designs can be generated by applying
  general design principles (often called
  patterns).