Software Design CS 406 Software Engineering I Fall 2001

Software DesignCS 406 Software Engineering I

Fall 2001

Aditya P. Mathur

Last update: October 2, 2001

October 2, 2001 Software Design 2

Organization

Part I: Design principles and process

Part II: OO DesignPart III: Design PatternsPart IV: Special topics

Learning Objectives

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

To learn notations for representing a design.

Models during the Design Phase

Class model Object behavior model

Design state model

Interaction Diagrams: Collaboration diagrams

Sequence diagrams

Contracts formethods and operations

Static structure diagrams

State diagrams for classes

A collaboration diagram

:classAinstance

2: message3()

1: message2()

message1()

:classBinstance

message1() is sent to an instance of class A.message2() and message3() are sent, in thatorder, by an instance of class A to an instance ofclass B.

One diagram for each system event.

A sequence diagram

message1()

:classAinstance :classBinstance

message2()

message3()

May be used for multiple events.

Focus of control, activation box, optional

Collaboration diagram: makepayment()

:POST :Sale

makePayment(cashTendered) 1: makePayment(cashTendered)

:Payment

1.1: create(cashTendered)

direction of message first internal message

parameter

instance of a classlink line

first message

Note: Post is Register in thesecond edition of Larman.

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.

Classes and Objects

object or instance

s1:Sale

named object

link line

msg1()

addPayment(cashTendered)

Link illustrates client/server relationship.

Messages

:Post :Sale

all messages flow on the same link

msg1()

3: message3()2: message2()1: message1()

Parameters

parameters shown within parentheses;types may also be shown

:Post :Sale

msg1()

1: addPayment(amount:Money)

Return values

return value name

:Post :Sale

msg1()

1: tot:=total(): int

return value type

Messages to “self” or “this”

msg1()

1: clear()

Iteration

:Post :Sale

msg1()

iteration, no recurrence values

1*: li = nextLineItem: SalesLineItem

Iteration with recurrence

msg1()

:Post :Sale

iteration clause

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

Iteration clause: Multiple messages

msg1()

equal iteration clauses

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

:A :myB: B

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

msg1(){

for i:= 1 to 10{myB.msg2();myC.meg3();}

Creation

:Post :Sale

create message with optional parameter forinitialization. Note that use of the name create is a UML convention.

msg1()

1: create(cashier)

new created instance

<<create>>1: make(cashier)

Languages and create

Language Meaning of create()

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

new() operator followed by a constructor call.

Message sequence numbering

:classA :classB

msg1()

first message not numbered

1: msg2()

:classC2: msg4()

second

1.1: msg3()

third (nested)

2.1: msg5()

fourthfifth (nested)

Conditional message

:Post :Sale

msg1()

conditional message with test

1*: [new sale] create()

:SalesLineItem

1.1: create()

Mutually exclusive conditional messages

1a and 1b are mutually exclusive

:ClassA :ClassB

:ClassC:ClassD

:ClassE

msg1() 1a: [test_1] msg2()

1b: [not test_1] msg4() 1a.1: msg3()

1b.1: msg5()

2: msg6()

Unconditional aftereither msg2 or msg4

Collections

sales:Sale

A multiobject or a collection of instances,e.g. a List of Sales.

Messages to Multiobjects

msg1()

1*: s:=size(): int

Message sent to a Multiobject.

:Sale :SalesLineItem*

The two *’s imply iteration over all elements.

Messages to multiobjects and an element [1]

msg1()

1: el:=create()

Message sent to anelement.

:SalesLineItem

sl:SalesLineItem

2: addElement(el)

Message sent to acollection.

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.

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.

Guidelines and principles

We first consider three useful guidelines:

Expert

and two widely applicable principles: High cohesion Low coupling

Controller

Creator

POS: Partial Domain Model

datetime

Sales LineItem

quantity

Product Specification

descriptionpriceitemID

Contains

addressname

CashierCustomerPayment

amount

Manager

Product Catalog

Used-by1*

Stocks

Houses1

Contained-in1..*

Captured-on

11Started-by

11Paid-by 1

1Initiated-by

Describes1*

Records-sale-on1

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.

Expert: Example [1]

datetime

Sales LineItem

quantity

descriptionpriceUPC

Contains1…*

Described by*

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 ?

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.

Partial collaboration diagram [1]

:Sale1: t:=getTotal()

New method added to the Sale class. The class itself is derived from the domain model.

datetime

getTotal

Expert: Example [3]

What information is needed to determine subtotal ?

Hence SalesLineItem is assigned the responsibility to compute the subtotal.

We need: Quantity of each SalesLineItem and its price. Quantity is available with SalesLineItem and

price with ProductSpecification.

Partial collaboration diagram [2]

:Sale1: t:=total()

datetime

getTotal()

SalesLineItem

quantity

getSubtotal()

:ProductSpecification

2.1: p:=getPrice()

ProductSpecification

getPrice()

:SalesLineItem

1*: st=getSubtotal()

Summary: Example [4]

Class Responsibility

Sale Knows sale total

SalesLineItem Knows line item subtotal.

ProductSpecification Knows the price of a product

Expert: Discussion

Expert guideline used often.

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

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

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

Expert: Disadvantages

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

Example: Who should save Sale in a database ?

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

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

It also violates the “separation of concerns” principle.

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.

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:

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.

Creator: Example [1]

datetime

Sales LineItem

quantity

Contains1…*

Described by*

Who should be responsiblefor creating a SalesLineItem ?

Creator: Example [2]

Sale contains many SalesLineItem objects.

This leads to the following collaboration diagram.

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

Sequence diagram for the creation of SalesLineItem

:SalesLineItem

makeLineItem(quantity)

create(quantity)

:POST :Sale

Partial collaboration diagram

:Sale makeLineItem(quantity)

datetime

makeLineItem()total()

:SalesLineItem

New method added to the Sale class.

1: create(quantity)

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.

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.

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.

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.

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.

Controller: Example (1)

Which object should be responsible for handling the enterItem()system event message ?

enterItem(upc,quantity)

Controller: Example [1]

:Store

:Cashier

:BuyItemsHandler

:POSTRepresents the overall system

Represents overall business

Represents a real worldactor

Represents an artificialhandler

Controller: Example [2]

System

During design the system operations, identified during analysis, are assigned to one or more of controller classes.

…...

System operationsdiscovered duringanalysis

Allocation of systemoperations during design

Controller: Discussion [1]

Controllers must be chosen to handle incoming events.

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.

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

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.

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.

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.

Avoiding bloated controller

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

Role controllers Use case controllers

ReservationAgent

Scheduler

FareAnalyst

MakeAReservationHandler

ManageSchdulesHandler

ManageFaresHandler

An airline reservation system may contain the following controllers:

Presentation (Interface) Layer [1]

Avoid using presentation layer to handle system events.

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.

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

Object Store

Sample GUI for Point of Sale Terminal

Cash 4

Make Payment10End Sale9Enter Item8

Balance 7

Description 6

Quantity 5

Total 3

Price 2

Sample course of events

Actor System

Customer arrives at thePOST checkout with itemsto purchase.

For each item, the Cashierenters the UPC in 1 of Window 1. The quantity of this item is optionally entered in 5.

2 Adds information on the item to the current sales transaction.Description and price of the itemare displayed in 2 and 6 ofWindow 1.

Sample course of events(2)

Actor System

Completion of item entry is indicated by the Cashier to POSTby pressing widget 9.

4 Computes and displays thesale total in 3.

.......6

Presentation layer [2]

Controller

:SaleJFrame

1: enterItem(upc,quantity)

Quantity

Balance

Enter Item End Sale Make Payment

Object Store x_

onEnterItem()

1.1: makeLineItem(upc,quantity)

System eventmessage

Presses button

Cashier

Presentation layer

Domain layer

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.

Presentation layer: undesirable coupling [4]

:SaleJFrame

Quantity

Balance

Object Store

onEnterItem()

1: makeLineItem(upc,quantity)

Presses button

Cashier

Presentation layer

Domain layer

Business logic embedded inpresentation layer.

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.

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.

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.

Low coupling: Example (1)

Payment POST Sale

Consider the following partial conceptual model:

What class should be responsible forcreating an instance of Payment ?

Low coupling: Example [1]

makePayment()

1: create():POST

p:Payment

2: addPayment(p)

One solution is to let POST create an instanceof Payment and pass a reference this Payment to Sale. This solution is suggested as POST records a Payment.

Low coupling: Example [3]

makePayment()

1: makePayment():POST :Sale

p:Payment

Another solution is to let Sale create aninstance of Payment.

1.1: create()

Which of the two solutions is preferable from the point of viewof coupling?

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.

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!

High cohesion

Question: How to keep design complexity manageable.

Answer:Assign responsibilities while maintaining high cohesion.

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.

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.

Interaction diagrams and system events

We now consider two use cases and their associated events:

Buy items• enterItem• endSale• makePayment

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

Start up• startUp

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.

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.

System events

endSale()

makePayment()

startUp

enterItem()

We select the POST class to handle systemevents.

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:

Partial collaboration diagram: enterItem()

1: [new sale] create()

Post-condition: If a new sale, Sale was created (instance creation).

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!

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.

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: SystemCross reference: Use cases: Buy itemsExceptions: If the UPC is not valid, indicate

that it was an error.

Collaboration diagram: enterItem (2)

Pre-condition:UPC is known to the system.

Post-conditions:

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

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

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

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

Collaboration diagram (1)

:POSTenterItem(upc,quantity)

Collaboration diagram begins by “some object” sending an enterItem() message to an instance of POST.

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.

A container SalesLineItem must be created by Sale.

Collaboration diagram

:POSTenterItem(upc,quantity)

Display of the item description and its price is ignored for now.

:Sale1: [new sale] create()

:SalesLineItem

1.1: create()by controller

by creator

an empty collection thatwill eventually hold

instances of SalesLineItem

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

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.

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.

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.

The enterItem() collaboration diagram

enterItem(upc,qty)

1: [new sale] create()

: :SalesLineItem

1.1: create()

by expert :ProductCatalog

2: spec:=specification(upc)

: :SalesLineItem

2.1: spec:=find(upc)

3: makeLineItem(spec,qty)

3.2: add(s))

sl:SalesLineItem

3.1 create(spec,qty)

Collaboration diagram: endSale (1)

Name: endSale()

Responsibilities: Record the end of sale and display sale total.

Type: SystemCross reference: Use cases: Buy itemsExceptions: If a sale is not underway,

indicate that it was an error.

Collaboration diagram: endSale (2)

Pre-condition: UPC is known to the system.

Post-conditions: Sale.isComplete was set to true (attribute modification).

Who should be responsible for receiving the endSale message?

We continue to use POST as the controller.

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.

Collaboration diagram: endSale()

endSale()

1: saleComplete()

by controllerby expert

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!!

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.

The Sale total collaboration diagram

:Saletot:=total()

:sli:SalesLineItem

: :SalesLineItem

by expert

2: st:=subtotal()

prodSpec: Productspecification

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

by expert

Sale--total(){ total:=0; for each SalesLineItem.sli

tot:=tot+sli.subtotal();return tot;}

Collaboration diagram: makePayment (1)

Name: makePayment(amount:float)

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

Type: SystemCross reference: Use cases: Buy itemsExceptions: If a sale is not complete,

indicate an error.

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

Who should be responsible for receiving the endSale message?

We continue to use POST as the controller.

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 Payment which leads to lower coupling in POST.

The makePayment collaboration diagram

:POST1: makePayment(cashTendered)

by controller

:Payment

1.1create(cashTendered)

by Creator, low coupling

makePayment(cashTendered)

Balance computation collaboration diagram

:Sale1: amt:=amount()

:Paymentbal:=balance()

2 t=total()Sale is responsible for knowing thebalance. It needs visibility intoPayment to ask for cash tendered. AsSale created Payment it has visibility into it.

We have ignored the display of balance.

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.

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.

The logging collaboration diagram

1: makePayment(cashTendered)s:Sale

by expert

:Payment

1.1create(cashTendered)

makePayment(cashTendered)

:Store

2:addSale(s)

: completedSales:Sale

2.1:add(s)

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.

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 theinitial domain object.It creates other domain objects.

Name: startUp()

Responsibilities: Initialize the system

Type: SystemPost-conditions:

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

ProductCatalog associated with ProductSpecifications

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

StartUp collaboration diagram (5)

:Store2: create(pc)

by creator

ps:productSpecification

create()

pc:ProductCatalog

1:create()

1.1: loadProdSpec

ProductSpecificationProductSpecification

1.1: create()

Reference to the product

catalog passed to POST.

1.2.1*: create(upc,price,description)

1.2.2*: add(ps)

Connecting presentation and domain layers(1)

:POSTApplet store: Storecreate()

First the applet creates an instance of Store. Store in turn creates an instanceof POST. Then the applet requests Store fora reference to the POST instance.The applet can now send messages directly to POST as in the next diagram.

1: create()

2: p=getPOST():POST

Connecting Presentation layer to the domain layer (2)

onEnterItem()

:PostApplet

Quantity

Balance

Object Store x_

Presses button

Cashier

Domain layer

Presentation layer

1:enterItem(upc,qty)

Connecting Presentation layer to the domain layer (3)

onEnterItem()

:PostApplet

post:POST

Quantity

Balance

Object Store x_

Presses button

Cashier

Domain layer

Presentation layer

1:enterItem(upc,qty)

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

sale:Sale

3: t:=total(): float

Class notation

A class

ClassName

methods

attributes

A class diagram exhibits classes and theirassociations used in an application.

Contrast this with a conceptual model which shows domain concepts and their associations.

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.

CRC cards

Responsibility CollaborationOrder

Check if item in stock

Determine price

Check for valid payment

Dispatch to delivery address

Order line item

Customer

Database interface

class name

Summary

What did we learn?

Design process (in part)

Collaboration diagrams (notation)

Creation of collaboration diagrams using design principles and guidelines

Design principles and guidelines

Software Design CS 406 Software Engineering I Fall 2001

Documents

CS 5150 Software Engineering

CS 4530 & CS 5500 Software Engineering

CS 406/534 Compiler Construction Putting It All Togethercs.lamar.edu/faculty/foreman/Spring2007/4307...1 CS 406/534 Compiler Construction Putting It All Together Prof. Li Xu Dept

CS 5150 1 CS 5150 Software Engineering Lecture 2 Software Processes

CS 406 Fall 98 Software Testing Part III: Test Assessment and Improvement

Software Architecture and Design CS 406 Software Engineering I Fall 2001 Aditya P. Mathur Purdue University Last update: September 25, 2001

Synology 406 Series Server - static.highspeedbackbone.netstatic.highspeedbackbone.net/pdf/Synology-CS-406-Manual.pdf · Synology Server provides diverse backup solutions to back up

CS 501: Software Engineering

Design Patterns CS 406 Software Engineering I Fall 2001 Aditya P. Mathur Purdue University October 30, 2001

MCA Semester-IV CS-406 Database Administration I (MySQL ... MCA Science... · MCA Semester-IV CS-406 Database Administration I (MySQL) ... Communication Protocols, The SQL ... Engine,

Software Testing Sudipto Ghosh CS 406 Fall 99 November 16, 1999

CS 594 Software Engineering

CS 406 Software Testing Fall 98 Part II : Functional Testing Aditya P. Mathur Purdue University Last update: July 19, 1998

CS 552 Software Test

CS 4350: Fundamentals of Software Engineering CS 5500

CS 425 Software Engineering

CS 425/625 Software Engineering Software Requirements

The Boeing Company CC70189.002 Purdue University CS 406/407 Class Project 2000/2001

Purdue University CS 406 - Senior Project

CS 5150 1 CS 5150 Software Engineering Lecture 1 Introduction to Software Engineering