Software design cs 406 software engineering i fall 2001 l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 123

Software Design CS 406 Software Engineering I Fall 2001 PowerPoint PPT Presentation

Software Design CS 406 Software Engineering I Fall 2001 Aditya P. Mathur Last update: October 2, 2001 Organization Part I: Design principles and process Part II: OO Design Part III:Design Patterns Part IV: Special topics Learning Objectives

Download Presentation

Software Design CS 406 Software Engineering I Fall 2001

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software design cs 406 software engineering i fall 2001 l.jpg

Software DesignCS 406 Software Engineering IFall 2001

Aditya P. Mathur

Last update: October 2, 2001


Organization l.jpg

Organization

Part I: Design principles and process

Part II:OO Design

Part III:Design Patterns

Part IV:Special topics

Software Design


Learning objectives l.jpg

Learning Objectives

  • To learn notations for representing a design.

  • To understand and be able to apply the basic principles of software design. (GRASP patterns).

  • To learn techniques and tools for Object-Oriented Design.

  • Interaction diagrams

  • Class diagrams

  • State diagrams

Software Design


Models during the design phase l.jpg

Class model

Object behavior model

Design state model

Models during the Design Phase

Static structure

diagrams

Interaction Diagrams: Collaboration diagrams

Sequence diagrams

Contracts for

methods and operations

State diagrams

for classes

Software Design


A collaboration diagram l.jpg

1: message2()

message1()

2: message3()

A collaboration diagram

:classAinstance

:classBinstance

message1() is sent to an instance of class A.

message2() and message3() are sent, in that

order, by an instance of class A to an instance of

class B.

One diagram for each system event.

Software Design


A sequence diagram l.jpg

:classAinstance

:classBinstance

message1()

message2()

message3()

Focus of control,

activation box, optional

A sequence diagram

May be used for multiple events.

Software Design


Collaboration diagram makepayment l.jpg

direction of message

first internal message

1: makePayment(cashTendered)

makePayment(cashTendered)

:POST

:Sale

first message

1.1: create(cashTendered)

link line

instance of a class

parameter

Collaboration diagram:makepayment()

:Payment

Note: Post is Register in the

second edition of Larman.

Software Design


Making collaboration diagrams l.jpg

Making collaboration diagrams

  • Design a system of interacting objects to fulfill the tasks....this is the tough part of design!

  • One diagram for each system operation in the current development cycle, e.g. for makepayment().

  • If the diagram gets complex, split into smaller diagrams.

Software Design


Classes and objects l.jpg

:Sale

s1:Sale

Sale

class

object or instance

named object

Classes and Objects

Software Design


Links l.jpg

msg1()

addPayment(cashTendered)

link line

Links

:Post

:Sale

Link illustrates client/server relationship.

Software Design


Messages l.jpg

msg1()

1: message1()

2: message2()

3: message3()

:Post

:Sale

all messages flow on the same link

Messages

Software Design


Parameters l.jpg

msg1()

1: addPayment(amount:Money)

:Post

:Sale

parameters shown within parentheses;

types may also be shown

Parameters

Software Design


Return values l.jpg

return value type

msg1()

:Post

:Sale

return value name

Return values

1: tot:=total(): int

Software Design


Messages to self or this l.jpg

Messages to “self” or “this”

msg1()

:Post

1: clear()

Software Design


Iteration l.jpg

msg1()

1*: li = nextLineItem: SalesLineItem

:Post

:Sale

Iteration

iteration, no recurrence values

Software Design


Iteration with recurrence l.jpg

1*: [i:= 1..10] li = nextLineItem: SalesLineItem

:Post

:Sale

Iteration with recurrence

msg1()

iteration clause

Software Design


Iteration clause multiple messages l.jpg

msg1()

1*: [i:= 1..10] msg2()

:A

:myB: B

2*: [i:= 1..10] msg3()

:myC: C

Iteration clause: Multiple messages

msg1()

{

for i:= 1 to 10

{

myB.msg2();

myC.meg3();

}

}

equal iteration clauses

Software Design


Creation l.jpg

msg1()

1: create(cashier)

:Post

:Sale

<<create>>

1: make(cashier)

Creation

new created instance

create message with optional parameter for

initialization. Note that use of the name

create is a UML convention.

Software Design


Languages and create l.jpg

Languages and create

C++

Automatic allocation, or new() operator followed by constructor call.

Java

new() operator followed by a constructor call.

Software Design


Message sequence numbering l.jpg

first message not numbered

second

third (nested)

msg1()

1: msg2()

1.1: msg3()

2.1: msg5()

2: msg4()

fifth (nested)

fourth

Message sequence numbering

:classA

:classB

:classC

Software Design


Conditional message l.jpg

msg1()

1*: [new sale] create()

1.1: create()

conditional message with test

Conditional message

:Post

:Sale

:SalesLineItem

Software Design


Mutually exclusive conditional messages l.jpg

Unconditional after

either msg2 or msg4

1a and 1b are mutually

exclusive

:ClassE

2: msg6()

1a: [test_1] msg2()

msg1()

:ClassA

:ClassB

1b: [nottest_1] msg4()

1a.1: msg3()

1b.1: msg5()

:ClassD

:ClassC

Mutually exclusive conditional messages

Software Design


Collections l.jpg

sales:Sale

A multiobject or a collection of instances,

e.g. a List of Sales.

Collections

Software Design


Messages to multiobjects l.jpg

Message sent to a

Multiobject.

msg1()

1*: s:=size(): int

:Sale

:SalesLineItem

The two *’s imply iteration over all elements.

Messages to Multiobjects

*

Software Design


Messages to multiobjects and an element 1 l.jpg

Message sent to an

element.

msg1()

1: el:=create()

:Sale

sl:SalesLineItem

:SalesLineItem

2: addElement(el)

Message sent to a

collection.

Messages to multiobjects and an element [1]

Software Design


Design guidelines l.jpg

Design Guidelines

  • OO system consists of interacting objects.

  • How does one determine the assignment of responsibilities to various objects?

  • There is no unique assignment and hence “good” and “poor” designs, “beautiful” and “ugly” designs, “efficient” and “inefficient” designs.

  • Design guidelines assist in the derivation of a good design.

Software Design


Grasp patterns l.jpg

GRASP Patterns

  • GRASP:

    General Responsibility Assignment Software Patterns

  • These are best considered as design guidelines and principles. These could also be considered as “thought patterns” useful in software design.

Software Design


Guidelines and principles l.jpg

Guidelines and principles

  • We first consider three useful guidelines:

  • Expert

  • Creator

  • Controller

and two widely applicable principles:

  • High cohesion

  • Low coupling

Software Design


Pos partial domain model l.jpg

Product

Catalog

Payment

Item

Manager

Customer

POS

Store

Cashier

Sale

date

time

address

name

amount

Product

Specification

Sales LineItem

description

price

itemID

quantity

POS: Partial Domain Model

Contains

1

1…*

1

Used-by

*

1

Describes

1..*

*

Contained-in

Stocks

1

1

*

1

Houses

Captured-on

*

Started-by

1

1

Paid-by

1

1

1

1

1

Initiated-by

1

1

Records-sale-on

1

Software Design


Expert l.jpg

Expert

  • Question:

    How does one assign responsibilities ?

  • Answer:

    Assign a responsibility to an information expert, i.e. to a class that has the information needed to fulfill that responsibility.

Software Design


Expert example 1 l.jpg

Sale

date

time

Contains

1…*

Product

Specification

Sales LineItem

Described by

*

description

price

UPC

quantity

Expert: Example [1]

In POS, some class needs to know the grand total of a sale.

Who should be responsible for knowing the grand total of a sale ?

Software Design


Expert example 2 l.jpg

Expert: Example [2]

  • From the model, identify the class that contains the information needed to obtain the grand total.

  • Information needed to obtain the grand total:

    • Knowledge of all SaleItems

    • Sum of their subtotals

  • Only a Sale object possesses this knowledge.

  • Sale being the information expert, we assign this responsibility to Sale.

Software Design


Partial collaboration diagram 1 l.jpg

1: t:=getTotal()

Sale

New method added to

the Sale class. The class itself is

derived from the domain model.

date

time

getTotal

Partial collaboration diagram [1]

:Sale

Software Design


Expert example 3 l.jpg

Expert: Example [3]

  • What information is needed to determine subtotal?

  • We need:

    • Quantity of each SalesLineItem and its price.

    • Quantity is available with SalesLineItem and price with ProductSpecification.

  • Hence SalesLineItem is assigned the responsibility to compute the subtotal.

Software Design


Partial collaboration diagram 2 l.jpg

1: t:=total()

1*: st=getSubtotal()

:Sale

*

Sale

:SalesLineItem

date

time

2.1: p:=getPrice()

SalesLineItem

ProductSpecification

:ProductSpecification

getTotal()

quantity

description

price

itemID

getSubtotal()

getPrice()

Partial collaboration diagram [2]

Software Design


Summary example 4 l.jpg

Responsibility

Class

Sale

Knows sale total

SalesLineItem

Knows line item subtotal.

ProductSpecification

Knows the price of a product

Summary: Example [4]

Software Design


Expert discussion l.jpg

Expert: Discussion

  • Expert guideline used often.

  • Fulfillment of a responsibility often requires interaction amongst several objects (3 in our example). There are many semi-expertswho collaborate in performing a task.

  • Use of the Expert guideline allows us to retain encapsulation of information.

  • It often leads to “lightweight” classes collaborating to fulfill a responsibility.

Software Design


Expert disadvantages l.jpg

Expert: Disadvantages

  • On some occasions the Expert guideline might not suggest a desirable solution.

  • Example: Who should save Sale in a database ?

  • As all the information to be saved is in the Sale class, it should be responsible for saving the information.

  • This implies that the Sale class must know about handling databases. Adding database related methods to sale class will make it in-cohesive.

  • It also violates the “separation of concerns” principle.

Software Design


Expert benefits l.jpg

Expert: Benefits

  • Objects use their own information to fulfill tasks, hence encapsulation is maintained.

  • This leads to low coupling.

  • Behavior is distributed across cohesive and lightweight classes.

Software Design


Creator 1 l.jpg

Creator [1]

  • Question:

    Who should be responsible for creating an instance of a class ?

  • Answer:

    Assign to B the responsibility to create an object of class A if the following is true:

Software Design


Creator 2 l.jpg

Creator [2]

  • B aggregates objects of type A.

  • B contains objects of type A.

  • B records instances of objects of type A.

  • B closely uses objects of type A.

  • B has the data passed to A when A is created.

Implication: B is an expert in the creation of A.

Software Design


Creator example 1 l.jpg

Sale

date

time

Contains

1…*

Product

Specification

Sales LineItem

Described by

*

description

price

itemID

quantity

Creator: Example [1]

Who should be responsible

for creating a SalesLineItem?

Software Design


Creator example 2 l.jpg

Creator: Example [2]

  • Salecontains many SalesLineItem objects.

  • This implies that Sale is a good candidate for creating a SalesLineItem.

  • This leads to the following collaboration diagram.

Software Design


Sequence diagram for the creation of saleslineitem l.jpg

:POST

:Sale

makeLineItem(quantity)

create(quantity)

:SalesLineItem

Sequence diagram for the creation of SalesLineItem

Software Design


Partial collaboration diagram l.jpg

makeLineItem(quantity)

1: create(quantity)

Sale

date

time

makeLineItem()

total()

New method added to

the Sale class.

Partial collaboration diagram

:Sale

:SalesLineItem

Software Design


Creator discussion l.jpg

Creator: Discussion

  • Creator guides the assignment of responsibility of creating objects.

  • Creator suggests that the enclosing container or aggregate class is a good candidate for the creation of the object contained.

Software Design


Controller 1 l.jpg

Controller [1]

  • Question:

    Who should be responsible for handling system events ?

Recall that a system event is a high level event, an external event, generated by a system actor.

  • Answer:

    Assign a responsibility to handle a system event to a controller.

Software Design


Controller 2 l.jpg

Controller [2]

  • A controller is a non-user interface object that handles system events. Here is a list of controllers:

  • Façade controller: Represents the overall system, device, or business.

  • Use case controller: Represents an artificial handler of all events of a use case.

Software Design


Controller 3 l.jpg

Controller [3]

  • window, applet, view, document do not qualify as controllers. They typically receive system events and delegate them to a controller.

  • System event examples:

  • Pressing the “end of sale” button.

  • Request Spell Check.

  • Request Engine Start.

Software Design


System operations l.jpg

System operations

System

endSale()

enterItem()

makePayment()

During system behavior analysis, system operations are assigned to the class System. It does not imply that the class named System performs these during design. Instead, during design, a controller class is assigned to perform these operations.

Software Design


Controller example 1 l.jpg

enterItem(upc,quantity)

:???

Controller: Example (1)

Which object should be

responsible for handling the enterItem()

system event message ?

Software Design


Controller example 152 l.jpg

enterItem(upc,quantity)

enterItem(upc,quantity)

enterItem(upc,quantity)

enterItem(upc,quantity)

:Store

:Cashier

:BuyItemsHandler

:POST

Controller: Example [1]

Represents the overall system

Represents overall business

Represents a real world

actor

Represents an artificial

handler

Software Design


Controller example 2 l.jpg

System

POST

…...

endSale()

enterItem()

makePayment()

endSale()

enterItem()

makePayment()

Controller: Example [2]

System operations

discovered during

analysis

Allocation of system

operations during design

During design the system operations, identified during

analysis, are assigned to one or more of controller classes.

Software Design


Controller discussion 1 l.jpg

Controller: Discussion [1]

  • Controllers must be chosen to handle incoming events.

  • Use the same controller class for events of one use case. This allows maintenance of the state of a use case.

  • Do not assign “too much” responsibility to a controller. A controller should delegate to other objects work that needs to be done while coordinating an activity.

Software Design


Controller discussion 2 l.jpg

Controller: Discussion [2]

  • Façade controllers are suitable when there are only a “few” system events.

  • They are also useful when it is not possible to redirect system events to other controllers as, for example, in a message processing system.

  • Selecting a use case controller leads to a different controller for each use case. This controller is not a domain object. For example, for “Buy items” use case one might construct a “BuyItemsHandler” class.

Software Design


Controller discussion 3 l.jpg

Controller: Discussion [3]

  • When an existing controller becomes too large, one may choose a use case controller. This will likely help in maintaining low coupling and high cohesion.

  • Corollary: External interfacing objects should not have the responsibility for handling system events. Instead, these should be handled in the domain layer objects as opposed to being handled in application layer objects.

Software Design


Bloated controller l.jpg

Bloated controller

  • Signs of a bloated controller:

  • There is only one controller receiving all system events.

  • The controller performs all tasks itself without delegating any task to other objects.

  • A controller has many attributes and maintains significant information about the domain.

  • A controller duplicates information found in other objects.

Software Design


Avoiding bloated controller l.jpg

Role controllers

Use case controllers

ReservationAgent

MakeAReservationHandler

Scheduler

ManageSchdulesHandler

FareAnalyst

ManageFaresHandler

Avoiding bloated controller

  • Add more controllers. If necessary, use role-controllers and use-case controllers.

  • An airline reservation system may contain the following controllers:

Software Design


Presentation interface layer 1 l.jpg

Presentation (Interface) Layer [1]

  • Avoid using presentation layer to handle system events.

  • Use of domain layer objects to handle system events is preferred.

  • Example:

    Assume that POS application has a window that displays sale information and captures cashier’s operations. Suppose that a Java applet displays the window. Let us see how the presentation and domain layers can be coupled.

Software Design


Sample gui for point of sale terminal l.jpg

Object Store

UPC

Quantity

5

Price

Description

Total

Balance

Cash

8

1

4

10

9

2

7

6

3

End Sale

Enter Item

Make Payment

Sample GUI for Point of Sale Terminal

_

x

Software Design


Sample course of events l.jpg

Actor

System

1

Customer arrives at the

POST checkout with items

to purchase.

2

For each item, the Cashier

enters the UPC in 1 of

Window 1. The quantity of this

item is optionally entered in 5.

3

Adds information on the item

to the current sales transaction.

Description and price of the item

are displayed in 2 and 6 of

Window 1.

Sample course of events

Software Design


Sample course of events 2 l.jpg

4

Completion of item entry is

indicated by the Cashier to POST

by pressing widget 9.

5

6

Computes and displays the

sale total in 3.

.......

Sample course of events(2)

Actor

System

Software Design


Presentation layer 2 l.jpg

Object Store

_

x

Cashier

UPC

Quantity

Cash

Cash

Balance

Presses button

onEnterItem()

System event

message

Presentation layer

1: enterItem(upc,quantity)

Enter Item

End Sale

Make Payment

1.1: makeLineItem(upc,quantity)

Controller

Domain layer

Presentation layer [2]

:SaleJFrame

:Sale

:POST

Software Design


Presentation layer 3 l.jpg

Presentation layer [3]

  • SaleJFrame passes on the enterItem() message to the domain layer.

  • It does not get involved in the processing of this message.

  • Thus, business processing logic is in a domain object, not in the presentation object.

  • Presentation layer objects have lower opportunity for re-use due to their coupling with the environment.

Software Design


Presentation layer undesirable coupling 4 l.jpg

Object Store

_

x

Cashier

UPC

Quantity

Cash

Cash

Balance

Presses button

onEnterItem()

End Sale

Enter Item

Make Payment

1: makeLineItem(upc,quantity)

:Sale

Presentation layer: undesirable coupling [4]

Business logic embedded in

presentation layer.

:SaleJFrame

Presentation layer

Domain layer

Software Design


Presentation layer 5 l.jpg

Presentation layer [5]

  • Some applications do not have a user interface. They receive messages from an external system. For example, LDAP (Light Weight Directory Protocol) might receive a message from a CGI script.

  • In these cases the messages is encoded in a “stream” or as a CORBA message.

Software Design


Presentation layer 6 l.jpg

Presentation layer [6]

  • In applications with windows, the window might choose who the controller will be.

  • Different windows may collaborate with different controllers.

  • However, in a message handling application, the Command design pattern is useful.

Software Design


Low coupling l.jpg

Low coupling

  • How to achieve low dependency and increased reuse?

  • A class with high coupling is undesirable because:

  • Changes in related classes force local changes.

  • This class is harder to understand in isolation.

  • This class is harder to reuse because its use requires the inclusion of all classes it is dependent upon.

Software Design


Low coupling example 1 l.jpg

Payment

POST

Sale

Low coupling: Example (1)

Consider the following partial conceptual model:

What class should be responsible for

creating an instance of Payment?

Software Design


Low coupling example 170 l.jpg

makePayment()

1: create()

:POST

p:Payment

2: addPayment(p)

:Sale

Low coupling: Example [1]

One solution is to let POST create an instance

of Paymentand pass a reference this Payment to Sale.

This solution is suggested as POST records a Payment.

Software Design


Low coupling example 3 l.jpg

makePayment()

1: makePayment()

:POST

:Sale

1.1: create()

p:Payment

Low coupling: Example [3]

Another solution is to let Salecreate an

instance of Payment.

Which of the two solutions is

preferable from the point of view

of coupling?

Software Design


Low coupling discussion 1 l.jpg

Low coupling: Discussion [1]

  • Encourages assigning a responsibility to keep coupling low.

  • Supports design of relatively independent, hence more reusable, classes.

  • Reusable classes have a positive effect on productivity, i.e. may lead to higher productivity.

  • However, the quest for low coupling to achieve reusability in a future (mythical!) project may lead to increased project cost.

Software Design


Low coupling discussion 2 l.jpg

Low coupling: Discussion [2]

  • It is important for the designer to assess the current level of coupling and attempt to reduce it if it is likely to cause problems.

  • It is important to note that a moderate degree of coupling between classes is normal. After all an OO application is a collection of communicating objects!

Software Design


High cohesion l.jpg

High cohesion

  • Question:

    How to keep design complexity manageable.

  • Answer:

    Assign responsibilities while maintaining high cohesion.

Software Design


High cohesion example 1 l.jpg

High cohesion: Example [1]

  • Creation of a Payment can be assigned to POST as it records a payment in real world. This is suggested by the guidelines associated with Creator.

  • This is acceptable. However, if this logic is applied in several other similar situations, more and more work is likely to be assigned to one class.

  • This might lead to an in-cohesive class.

Software Design


High cohesion example 2 l.jpg

High cohesion: Example [2]

  • For example, if there are 50 system operations, and POST does some work related to each, the POST will be a large incohesive class.

  • In contrast, a design that lets Sale create Payment, supports higher cohesion in POST.

  • This design supports both high cohesion and low coupling and hence is preferred over the first one.

Software Design


Interaction diagrams and system events l.jpg

Interaction diagrams and system events

  • We now consider two use cases and their associated events:

  • Buy items

    • enterItem

    • endSale

    • makePayment

  • Start up

    • startUp

  • For each system event we create a collaboration diagram whose starting message is the system event message. What should be our controller class?

Software Design


Choosing the controller class l.jpg

Choosing the controller class

  • Choices:

    • POST or a new class such as RetailSystem: represents the entire system.

    • Store: represents the business.

    • Cashier: represents a real-world entity.

    • BuyItemsHandler: represents an artificial handler.

  • We select POST as there are only a few system operations.

Software Design


Choosing the controller class79 l.jpg

Choosing the controller class

1.Choices:

POST or a new class such as RetailSystem: represents the entire system.

Store: represents the business.

Cashier: represents a real-world entity.

BuyItemsHandler: represents an artificial handler.

2.We select POST as there are only a few system operations.

Software Design


System events l.jpg

enterItem()

:POST

endSale()

:POST

makePayment()

:POST

startUp

:POST

System events

We select the POST

class to handle system

events.

Software Design


Interaction diagrams and contracts l.jpg

Interaction diagrams and contracts

  • For each contract work through the responsibilities and post-conditions, and design message interactions.

  • Example:

    The enterItem() system operation requires a Sale to be created in its contract.

  • A collaboration diagram that satisfies this state change:

Software Design


Partial collaboration diagram enteritem l.jpg

enterItem(upc,quantity)

1: [new sale] create()

Partial collaboration diagram: enterItem()

:POST

:Sale

Post-condition: If a new sale, Sale was

created (instance creation).

Software Design


On the value of post conditions l.jpg

On the value of post-conditions

  • Post-conditions are only an initial estimate of what must be achieved.

  • Thus, treat contracts as a starting point for determining what must be done.

  • New post-conditions might arise during design and old ones might be found redundant.

  • Recall...we are encouraging iterative development!

Software Design


Collaboration diagrams and the conceptual model l.jpg

Collaboration diagrams and the conceptual model

  • Some objects in collaboration diagrams are drawn from the conceptual model.

  • Responsibility assignment depends to some extent upon information in the conceptual model.

  • New concepts might be discovered during design and previously identified concepts might be ignored.

Software Design


Collaboration diagram enteritem 1 l.jpg

Collaboration diagram: enterItem (1)

Name:enterItem

(upc: number, quantity: int)

Responsibilities: Enter sale of an item and

add it to the sale. Display the item description and price.

Type:System

Cross reference:Use cases: Buy items

Exceptions:If the UPC is not valid, indicate that it was an error.

Software Design


Collaboration diagram enteritem 2 l.jpg

Collaboration diagram: enterItem (2)

Pre-condition:UPC is known to the system.

Post-conditions:

  • If a new sale, a Sale was created (instance creation)

  • If a new sale, Sale was associated with the POST (association formed).

  • SalesLineItem.quantity was set to quantity (attribute modification).

  • The SalesLineItem was associated with ProductSpecification based on UPC match (association formed).

Software Design


Collaboration diagram 1 l.jpg

Collaboration diagram (1)

enterItem(upc,quantity)

:POST

Collaboration diagram begins by “some object” sending

an enterItem() message to an instance of POST.

Software Design


Making a new sale l.jpg

Making a new Sale

  • Contract post-conditions related to new Sale:

    • If a new Sale, a Sale was created (instance creation).

    • If a new sale, the new Sale was associated with the POST (association formed).

  • POST can be considered as one that records Thus, POST is a reasonable choice as a creator of Sale. POST will then also have a reference to this instance of Sale.

  • Acontainer SalesLineItem must be created by Sale.

Software Design


Collaboration diagram l.jpg

:SalesLineItem

Collaboration diagram

enterItem(upc,quantity)

1: [new sale] create()

:POST

:Sale

1.1: create()

by controller

by creator

an empty collection that

will eventually hold

instances of SalesLineItem

Display of the item description

and its price is ignored for now.

Software Design


Creating a new saleslineitem 1 l.jpg

Creating a new SalesLineItem (1)

  • More enterItem contract post-conditions:

    • A SalesLineItem was created (instance creation).

    • The SalesLineItem was associated with the Sale (association formed).

    • SalesLineItem.quantity was set to quantity (attribute modification)

    • The SalesLineItem was associated with a ProductSpecification (association formed).

Software Design


Creating a new saleslineitem 2 l.jpg

Creating a new SalesLineItem (2)

  • Sale contains SalesLineItem objects. Hence Sale should create SalesLineItem.

  • SalesLineItem can be associated with Sale by string it in the container of line items.

  • POST must pass the quantity to Sale with the create message.

  • A makeLineItem message is sent to Sale for it to create a SalesLineItem.

Software Design


Finding a product specification l.jpg

Finding a product specification

  • It is necessary to retrieve ProductSpecification based on the UPC of a SalesLineItem.

  • Question:

    Who should have the responsibility for knowing a ProductSpecification ?

  • Expert guidelines suggest that ProductCatalog is a good candidate for this responsibility.

Software Design


Visibility to a productcatalog l.jpg

Visibility to a ProductCatalog

  • Who should send the specification message to the ProductCatalog to ask for a ProductSpecification ?

  • We assume that POST and ProductCatalog were instantiated during the StartUp use case and that the are connected permanently.

  • Thus we let POST send the specification message to ProductCatalog.

  • Note that POST knows how to get to ProductCatalog. We say that POST has “visibility” to ProductCatalog.

Software Design


The enteritem collaboration diagram l.jpg

:

:

:SalesLineItem

:SalesLineItem

The enterItem() collaboration diagram

1: [new sale] create()

enterItem(upc,qty)

3: makeLineItem(spec,qty)

:POST

:Sale

2: spec:=specification(upc)

1.1: create()

3.1 create(spec,qty)

:Product

Catalog

by expert

3.2: add(s))

2.1: spec:=find(upc)

sl:SalesLineItem

Software Design


Collaboration diagram endsale 1 l.jpg

Collaboration diagram: endSale (1)

Name:endSale()

Responsibilities: Record the end of sale and

display sale total.

Type:System

Cross reference:Use cases: Buy items

Exceptions:If a sale is not underway, indicate that it was an error.

Software Design


Collaboration diagram endsale 2 l.jpg

Collaboration diagram: endSale (2)

Pre-condition:UPC is known to the system.

Post-conditions:

  • Sale.isComplete was set to true (attribute modification).

Software Design


Choosing the controller class97 l.jpg

Choosing the controller class

  • Who should be responsible for receiving the endSale message?

  • We continue to use POST as the controller.

Software Design


Setting the sale iscomplete l.jpg

Setting the Sale.isComplete

  • Who should be responsible for ensuring the post-condition?

  • As Sale knows and maintains the isComplete attribute, it should have the responsibility of setting isComplete.

Software Design


Collaboration diagram endsale l.jpg

Collaboration diagram: endSale()

endSale()

1: saleComplete()

:POST

:Sale

by controller

by expert

Software Design


Display of information l.jpg

Display of information

  • One responsibility in the endSale contract is that the sale total must be displayed.

  • Do not use the domain layer objects to communicate with windows or presentation layer objects.

  • Use the Observer pattern.

  • Note that Sale must know the total before it can be displayed!!

Software Design


Computing the sale total review l.jpg

Computing the sale total-Review

  • Who should be responsible form computing the sale total? Obviously…Sale as it is the expert !

  • What information is required to compute the total ?

    • Sub-totals of all SalesLineItem.

  • Who should be responsible for computing the sub-totals? Obviously…SalesLineItem as it is the expert in this case.

  • Who has the price for each SalesLineItem?…ProductSpecification. Hence SalesLineItem must communicate with ProductSpecification to obtain the price.

Software Design


The sale total collaboration diagram l.jpg

:

:SalesLineItem

The Sale total collaboration diagram

by expert

tot:=total()

2: st:=subtotal()

:Sale

:sli:SalesLineItem

1*: [for each] sli:=next())

by expert

2.1: pr=price()

Sale--total()

{

total:=0;

for each SalesLineItem.sli

tot:=tot+sli.subtotal();

return tot;

}

prodSpec: Product

specification

Software Design


Collaboration diagram makepayment 1 l.jpg

Collaboration diagram: makePayment (1)

Name:makePayment(amount:float)

Responsibilities: Record the payment, compute balance, and print a receipt.

Type:System

Cross reference:Use cases: Buy items

Exceptions:If a sale is not complete, indicate an error.

Software Design


Collaboration diagram makepayment 2 l.jpg

Collaboration diagram: makePayment (2)

Pre-condition:None.

Post-conditions:

  • A Payment was created (instance creation)

  • Payment.tendered is set to amount (attribute modification).

  • The Payment was associated with the Sale (relationship formed).

  • The Sale was associated with the Store to add it to the historical log of completed sales (relationship formed).

Software Design


Choosing the controller class105 l.jpg

Choosing the controller class

  • Who should be responsible for receiving the endSale message?

  • We continue to use POST as the controller.

Software Design


Creating payment l.jpg

Creating Payment

  • Who should be responsible for creating an instance of Payment ?

  • There are two candidates:

    • POST

    • Sale

  • Selecting Sale lightens the workload of Payment.

  • Also POST does not need to know about Paymentwhich leads to lower coupling in POST.

Software Design


The makepayment collaboration diagram l.jpg

The makePayment collaboration diagram

by Creator, low coupling

makePayment(cashTendered)

1: makePayment(cashTendered)

:POST

:Sale

1.1create(cashTendered)

by controller

:Payment

Software Design


Balance computation collaboration diagram l.jpg

Balance computation collaboration diagram

We have ignored the

display of balance.

bal:=balance()

1: amt:=amount()

:Sale

:Payment

Sale is responsible for knowing the

balance. It needs visibility into

Payment to ask for cash tendered. As

Sale created Payment it has visibility

into it.

2 t=total()

Software Design


Logging the sale 1 l.jpg

Logging the Sale (1)

  • Who should be responsible for knowing all the logged sales and doing the logging ?

  • There are two candidates:

    • Store

    • SalesLedger (new idea from basic accounting!)

  • As the design grows Store will become incohesive, hence SalesLedger seems to be a good idea.

Software Design


Logging the sale 2 l.jpg

Logging the Sale (2)

  • Consider the following post-condition:

    • The Sale was associated with the Store to add it to the historical log of completed sales.

  • This post-condition needs to change if we decide to use SalesLedger to log the sale.

  • If we decide to use SalesLedger than contracts need to be altered to avoid design divergence.

Software Design


The logging collaboration diagram l.jpg

:

completedSales:Sale

The logging collaboration diagram

makePayment(cashTendered)

1: makePayment(cashTendered)

:POST

s:Sale

2:addSale(s)

1.1create(cashTendered)

by expert

:Store

:Payment

2.1:add(s)

Software Design


Collaboration diagram startup 1 l.jpg

Collaboration diagram: startUp() (1)

  • Most systems have a StartUp() use case.

  • It is recommended that the collaboration diagram for startUp be taken up towards the end.

  • startUp() operation is often dependent on the programming language and the operating system used.

  • A common approach is to create an initial domain object.

Software Design


Collaboration diagram startup 2 l.jpg

Collaboration diagram: startUp() (2)

  • In the initialization method of this initial object, create other problem domain objects.

public class POSTApplet extends Applet

{

public void init ()

{

post = store.getPOST();

}

private Store store = new Store();

private POST post;

private Sale sale;

}

Here, Store is the

initial domain object.

It creates other

domain objects.

Software Design


Collaboration diagram startup 3 l.jpg

Collaboration diagram: startUp() (3)

Name:startUp()

Responsibilities: Initialize the system

Type:System

Post-conditions:

  • Store, POST, ProductCatalog, and ProductSpecifications created (instance creation).

  • ProductCatalog associated with ProductSpecifications

Software Design


Collaboration diagram startup 4 l.jpg

Collaboration diagram: startUp() (4)

  • Post-conditions:

    • Store, POST, ProductCatalog, and ProductSpecifications created (instance creation).

    • ProductCatalog associated with ProductSpecifications

    • Store associated with POST (association formed).

    • POST associated with ProductCatalog (association formed).

Software Design


Startup collaboration diagram 5 l.jpg

ProductSpecification

ProductSpecification

StartUp collaboration diagram (5)

Reference to the product

catalog passed to POST.

create()

2: create(pc)

:Store

:POST

1.1: create()

1:create()

1.2.2*: add(ps)

by creator

pc:ProductCatalog

1.2.1*: create(upc,price,description)

1.1: loadProdSpec

ps:productSpecification

Software Design


Connecting presentation and domain layers 1 l.jpg

Connecting presentation and domain layers(1)

1: create()

2: p=getPOST():POST

create()

:POSTApplet

store: Store

First the applet creates an instance of

Store. Store in turn creates an instance

of POST. Then the applet requests Store for

a reference to the POST instance.The applet

can now send messages directly to POST as

in the next diagram.

Software Design


Connecting presentation layer to the domain layer 2 l.jpg

_

x

End Sale

Enter Item

Make Payment

Connecting Presentation layer to the domain layer (2)

Object Store

Cashier

UPC

Quantity

Cash

Cash

Balance

Presses button

onEnterItem()

Presentation layer

:PostApplet

1:enterItem(upc,qty)

Domain layer

:POST

Software Design


Connecting presentation layer to the domain layer 3 l.jpg

_

x

Enter Item

End Sale

Make Payment

Connecting Presentation layer to the domain layer (3)

Object Store

Cashier

UPC

Quantity

Cash

Cash

Balance

Presses button

onEnterItem()

3: t:=total(): float

Presentation layer

:PostApplet

1:enterItem(upc,qty)

2: [no sale] sale:=getSale():Sale

Domain layer

post:POST

sale:Sale

Software Design


Class notation l.jpg

ClassName

attributes

methods

Class notation

A class diagram exhibits classes and their

associations used in an application.

Contrast this with a conceptual model which

shows domain concepts and their associations.

A class

Software Design


Crc cards l.jpg

CRC cards

  • CRC: Class-responsibility-collaboration cards

  • Instead of using diagrams to show class responsibilities and collaboration, CRC cards are suggested.

  • These are index cards and one for each class.

  • In a team, each person plays the role of one or more classes and holds the corresponding card(s).

  • Helpful in group design efforts.

Software Design


Crc cards122 l.jpg

CRC cards

class name

Responsibility

Order

Collaboration

Order line item

Check if item in stock

Order line item

Determine price

Customer

Check for valid payment

Database interface

Dispatch to delivery address

Software Design


Summary l.jpg

Summary

  • What did we learn?

  • Design process (in part)

  • Collaboration diagrams (notation)

  • Design principles and guidelines

  • Creation of collaboration diagrams using design principles and guidelines

Software Design


  • Login