1

1. Introduction2. System design3. Object design4. Testing and Metrics5. Design Patterns

2

Goal

CRCcards

Classmodelling

Dynamicmodelling

Use cases

Analysis domain

OOA

Design

Design domain

OOD

ImplementationDomain

code

code

OOP

3

The design pyramid

Subsystem design

Class and object design

Message design

Responsi-bility design

Use casesDynamic modeling

Attributes, operations,collaborations CRC-cards

Static modeling

Attributes, operations, collaborationsCRC-cards

4

Unified Approach

System design

Object design

• goal : to represent the software architecture (from implementation perspective !)• translate conceptual (OOA) architecture into architecture for implementation

Goal :• find complete description of objects

• data structures for attributes ?• Algorithms for operations

• describe interaction between objects• complete message model between objects• define interfaces between classes• determine visibility of methods

5

Process

1. Partition the analysis model into subsystems2. Find concurrency and allocate subsystems3. Design user interface4. Design data management5. Design task management6. Resource management7. Communication between subsystems

6

Partition into subsystems

Analysis model

Cohesive set of classes

• strong relations within set• aggregation, subtype …• collaboration, message passing, …

• characterized by common responsibility = set of “services”

Su

bsystem

Goal : to identify subsystems

7

Partition into subsystems

Subsystem A

• strong collaboration, “communication” within subsystem• communication to other subsystems limited to a few classes

a:A

b:B c:C

aa:Ad:D

Subsystem B

Communicationclass

8

Partition into subsystems

Subsystem

• well defined interface to the outside (rest of the system)• limited set of communication classes• number of subsystems low -> hierarchy of subsystems

Subsystem 1

Subsystem 1.1 Subsystem 1.2

High level responsibility“services”

More specific responsibilitysubset of “services”

9

Partition into subsystems

Communication between subsystems

Client-server

Peer-to-peer

A serviceSubsystem A

Services ofsubsystem A

Subsystem B

Services ofsubsystem B

A serviceSubsystem A

Services ofsubsystem A

Subsystem B

Services ofsubsystem BB service

10

Partition into subsystems Architectural Style : Layering

• partition into subsystems with different levels of abstraction• usually : level of abstraction <-> visibility to end-user• minimize coupling between layers (functional independence)

Example I : 3-tier business architecture

Persistent data layer (database)

Business Logic Layer

Presentation Layer User interface

Business rules(e.g. reorder policy)

Persistent storageof data

11

Partition into subsystems

Example II : 4-tier architecture

Persistent data layer (database)

Application Layer

Presentation Layer

Data Formatting

Example III : TCP/IP stack

Application Layer

Transport Layer

Internet Layer

Host-to-Network Layer

Visib

ility to en

d-u

ser

Layering

12

ConcurrencySubsystem allocation

Dynamic models

Objects simultaneously active ?

no Single threaded, software can be mapped on 1 processor

yes Concurrency, allocation of tasks• on 1 processor, different processes/threads• more processors, different computers, …Criteria : performance, overhead, cost, ...

Different threads of control

Different tasks to be executed simultaneously

Goal : to identify different tasks in the system

13

User interface

Scenario’s, use-cases, actors

Goal : to provide user friendly access to the system

anActor

Use Case

Use Case

scenario

scenario

Command hierarchy

Menu bar (tool palette)

Menu windows

Implementation :• graphical libraries (e.g. Java Swing)• GUI-builders

Repeat until all scenario’s implemented

14

Data management Goal : • manage application critical data• storage/retrieval of objects

e.g. system settings

DataBase Management System used for storage/retrieval• add attributes and store/retrieve methods to objects• provide server class for storage/retrieval

DBMS

aClass

+storeInDB()+retrieveFromDB()

DBMS

aClass

+storeInDB()+retrieveFromDB()

ServerClass

+storeInDB()+retrieveFrom DB()

15

Task management

Goal : coordinate tasks Only if concurrency detected

(1) Describe task characteristics• initiator identified (external event, clock driven)• priority• criticality

(2) Identify coordinating task(3) Add attributes/operations to allow coordination

16

Resource management

Goal : resolve resource conflicts

• I/O device• processor• ...

External resources

“abstractions” • database• object• ...

Possible control mechanism

resource

GuardianObject

resource

GuardianObject

resource

GuardianObject

Gatekeeper• control access• resolve conflicts

17

Subsystem communication

Goal : formalize collaboration between subsystems

• list requests between subsystemsset of requests for 1 subsystem = subsystem contract(s)

• for each contract, fill in table

• if complex : make collaboration diagram on subsystem level

Contract Type Collaborators Classes Operations Message format

name

Client-serverpeer-to-peer

Communicatingsubsystems Classes needed

to provide requestedservice

Class operations neededto provide requested service

Arguments passedfor operation

18

Package Diagrams

= group of (closely) collaborating classes subsystem

Diagram shows :• packages

• dependencies

aPackage

A B

A is dependent on B ifchange to (element of) B implies change to (element of) A

Goal : minimize dependencies !

19

Package Diagrams

Hierarchy of packages

In javadependency implies dependency on public method of public class of the package !

aPackage

A B

CGlobal packages

A

B

C

C E

A

B

C

C E

{g lobal}

20

Package Diagrams

Generalization

A{abstract}

B C

Packages B and Coffer at least the interface ofpackage A

Design rules• minimize dependencies• avoid “dependency”-cycles

Maintenance !

21

Deployment Diagrams

Goalshow relation between (physical)hardware and software

• Important in distributed systems• Show hardware where object/component is running

Diagram elements

Node “computational unit”(processor, computer, sensor, ...)

aNode

22

Deployment Diagrams

Connection Physical communication paths

Node A Node BTCP/IP

Node C

TCP/IP

Components Physical modules of code packages

aComponent

short

ClassA

ClassB

+ contained classes

aCom ponent

InterfaceC

+ interfacesoffered

23

Deployment Diagrams

Dependencies•Logical communication paths between components and interfaces•Similar to dependencies in package diagrams

Database

A

Application

B

C

D

UI

E

F

H TTP

H TTP

24

Case IIICourses, Students and Professors

System Design Partitioning into subsystems

Classical 3-tier architecture

Persistent data layer (database)

Business Logic Layer

Presentation Layer

Responsibility

Storage of Courses, User info, ...

GUI user interaction

Manipulate data

25

Case IIICourses, Students and Professors

System Design

Components needed

• user interface• task management• data management• resource management

no concurrency

small applicationresource guarded by OS

UIData

Management + Administration

26

Case IIICourses, Students and Professors

System Design Package diagram

DataManagement

DatabaseFacade

Database

Course

User

ProfessorStudent Adm inistrator

Passw ord

IDNum ber

1

1

1

teaches

1

*

*follows

*m anages

1

*

M enu

1

?

DataManagement

Administration

UI

27

Case IIICourses, Students and Professors

System Design

Course

User

ProfessorStudent Adm inistrator

Passw ord

IDNum ber

1

1

1

teaches

1

*

*follows

*m anages

1

*

M enu

1

Generic utilities

utilities

Package diagram

Service user requests

user

28

Case IIICourses, Students and Professors

System Design

Package diagram

UI

DataManagement

DatabaseFacade

Database

utilitiesuser

Administration

29

Goal

= to specify• object attribute types -> data structures• method functioning -> algorithms• connection between objects

Based on• OOA models (requirements, CRC, …)• OOD system design

30

Object description

Protocol description

Implementation description

• = interface of the object• list of messages and associated operations performed by the object• e.g. : see Java-documentation

External “PUBLIC”Service User

Internal “PRIVATE”Service Supplier

• information on how message is handled • internal data structure of the object• details on methods

• usually hidden !

31

AlgorithmsData structures

• problem specific• large catalogues of algorithms and data structures exist• design algorithms and data structures strongly coupled !• use class diagram for hints for data structures !

Typical operations

• data manipulation• computational operations• monitoring operations

32

Testing

Goal

• verify that specifications have been incorporated in design• completely• accurately

• verify correctness of design• logical, algorithmic errors• object/subsystem interfacing errors

(message format)

Techiniquesnon-execution based testing

• inspection• walkthrough

usually no representative from client

33

Metrics

Size

Cost

Duration

Effort

Quality

Fundamental unknowns

# modules

fault statisticsmodule cohesion and coupling

metrics

Cyclomatic complexity M(= #binary decisions + 1)

CDM (coupling dependency metric)

34

Metrics : CDM

Module A Module Module

Module Module

The product

change

change

CDM(A)

35

Concept • design of “good” OO-model is difficult

• extendible• maintainable

• BUT : set of good designs have evolved during OO-design practice by experts• cf. Other engineering disciplines (e.g. electronic circuits)

OO-design that is generic (“abstract”),able to solve a entire class of similar problems

Design PatternCatalogs of design patterns exist

Gang-of-Four (GoF) book

36

Concept

“You will find recurring patterns of classes and communicating objectsin many object-oriented systems. These patterns solve specific designproblems and make object-oriented designs more flexible, elegant and ultimately reusable. They help designers reuse succesful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them. “

Gang-of-Four (GoF) book

37

Pattern description

Pattern name

Problem

Solution

Consequences

• two word description, capturing the essence of the pattern• to enlarge “design vocabulary”

• what is the problem to be solved ?

• template how to solve the design problem• in terms of objects and classes• not implementation specific !

• cost and benefits of using the pattern• used to asses trade-off between using different patterns

38

Classification

Creational

Structural

Behavioral

Two generic reuse mechanisms

• solve problems with constructing objects

• how to compose classes or objects

• how to distribute responsibility between objects• how to let objects collaborate

• inheritance (“white-box reuse”)• composition/aggregation (“black-box reuse”)

39

Singleton (Creational)

Pattern name

Problem

Solution

Singleton

• how to make sure that only 1 object of a class can be instantiated ?

• make constructor private !!!!• ensure no default-constructor• Singleton can be responsible for creation of unique instance

Singleton

+getU niqueInstance() : static S ingleton+singletonO peration() :+getS ingletonD ata() :

+uniqueInstance : static S ingleton-singletonD ata : S ingletonD ata

40

Singleton (Creational) Java-example Unique object, holding integer value 23

class Singleton {private int i; // singletonDataprivate static Singleton unique = new Singleton(23);private Singleton(int v) {i=v;}public static Singleton getUniqueElement() {

return unique;}public int getValue() { // getSingletonData

return i;}public void setValue(int v) { // singletonOperation

i=v;}

}

public class SingletonTest {public static void main(String[] a) {

Singleton u = Singleton.getUniqueElement();System.out.println("Element u = "+u.getValue());Singleton v = Singleton.getUniqueElement();v.setValue(40);System.out.println("Element v = "+v.getValue());System.out.println("Element u = "+u.getValue());

}}

41

Facade (Structural)

Pattern name

Problem

Solution

Facade

• how to provide a unique interface to a subsystem ?

Facade

42

Facade (Structural)

Java example

Without façade

A

B

C

Client

class A {private int x;public A(int i) {x=i;}

}class B {

private double d;public B(double i) {d=i;}

}class C {

private char c;public C(char i) {c=i;}

}public class ClientNoFacade {

public static void main(String[] args) {A a = new A(1);B b = new B(2.0);C c = new C('a');

}}

43

Facade (Structural)

Java example

With façade

A

B

C

Client

Facade

class A { private int x;public A(int i) {x=i;}

}class B { private double d;

public B(double i) {d=i;}}class C { private char c;

public C(char i) {c=i;}}class Facade {

static A makeA(int i) {return new A(i);}static B makeB(double i) {return new B(i);}static C makeC(char i) {return new C(i);}

}public class ClientWithFacade {

public static void main(String[] args) {A a = Facade.makeA(1);B b = Facade.makeB(2.0);C c = Facade.makeC('a');

}}

In java : Façade the (only ?) public class in the package !

44

Template Method (Behavorial)

Pattern name

Problem

Solution

Template Method

• how to code a sequence of algorithmic steps without specifying the steps themselves ?• used for Frameworks

AbstractClass

+algorithm () :+operation1() :+operation2() :

ConcreteClass

+operation1() :+operation2() :

• algorithm() (“template method”) specifies in what sequence operations are called• definition of operations given in concrete class

45

Template Method (Behavorial)

Java exampleabstract class ApplicationFramework { int numberOfTimes; public ApplicationFramework(int i) { numberOfTimes=i; executeAlgorithm(); } private void executeAlgorithm() { startUp(); for(int i=0;i<numberOfTimes;i++)

doTask(i); finish(); } abstract void startUp(); abstract void doTask(int i); abstract void finish();}

public class TemplateTest { public static void main(String[ ] args) { SquarePrinter a = new SquarePrinter(10); }}

class SquarePrinter extends ApplicationFramework { public SquarePrinter(int i) {super(i);} public void startUp() { System.out.println("Welcome to square printer !"); } public void doTask(int i) { System.out.println(""+i+" -> "+i*i); } public void finish() { System.out.println("Task is finished !"); }}