Software Engineering Lecture 4

1
Software EngineeringLecture 4

• Eli Katsiri

2
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

3
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.

4
From requirements and analysis to design
Process Sale
UP Use-case Model
Payment date time
Sale amount
Paid-by
UP Domain Model
1
1
Sale amount getBalance()Money
Payment date Time getTotal()Money
Paid-by
UP Design Model
1
1
5
Realisation (1)

• From Design to Implementation Model
• How to derive class definitions from DCDs
• How to define method bodies from interaction
  diagrams

SalesLineItem quantityInteger getSubtotal()Mon
ey
ProductSpec descriptionText priceMoney itemIDIt
emID
Described-by
1

productSpec
public class SalesLineItem private int
quantity private ProductSpec productSpec publi
c SalesLineItem(ProductSpec spec, int qty)
public Money getSubtotal()
6
Realisation(2)

• From Design to Implementation Model
• How to derive class definitions from DCDs
• How to define method bodies from interaction
  diagrams

2makeLineItem(spec,qty)?
enterItem(id,qty)?
Sale
Register
2.1create(spec,qty)?
1specgetSpecification(id)?
slSalesLine Item
Product Catalog
public void enterItem (ItemID id, int
qty)? ProductSpec spec catalog.getSpecificati
on(id) currentSale.makeLineItem (spec, qty)
7
Realisation (3)

• From Design to Implementation Model
• How to derive class definitions from DCDs
• How to define method bodies from interaction
  diagrams

Register
Sale
1

• isCompleteBoolean
• TimeDateTime

endSale() enterItem(idItemID, qtyInteger) makeNe
wSale() makePayment(cashTendered Money)
currentSale
becomeComplete() makeLineItem() makePayment() ge
tTotal()
public class Register private productCatalog
catalog private Sale currentSale public
Register(ProductCatalog pc) public void
endSale() public void enterItem(itemID id,
int qty) public void makeNewSale() public
void makePayment(Money cashTendered)
8
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!

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
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()?
12
Sequence diagram notation (cont.)?

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

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

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

ClassA
ClassB
ClassC
msg0(int amount)?
alt
calculate()?
amountlt10
calculate()?
else
14
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()?
loop
msg2()?
msg3()?
i1..N
15
Asynchronous call?
public class ClockStarter public void
StartClock() //Clock implements the runnable
interface Thread tnew Thread(new
Clock()) t.start() //asynchronous call to the
run method on clock System.runFinalization()
ClockStarter
ClassC
startClock?
create
Clock
run
runFinalisation?
16
Polymorphism
Payment abstract

• authorise() abstract

Credit Payment
authorise()
authorise()
17
Polymorphism?
Register
Payment abstract
doX?
authorise
DebitPayment
Foo
Bar
CreditPayment
authorise
doX
doA
authorise
doB
18
Collaboration diagram notation

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

msg()?
2.create()?
ClassA
ClassB
1.msg1()?
19
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
20
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
21
Asynchronous invocation?
startClock?
msg()?
3.runFinalisation
ClockStarter
SystemClass
1.create
2. run?
Clock
22
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

23
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

24
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

25
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.

26
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.
27
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.

28
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.

29
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).

30
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).

31
(No Transcript)