1 1. introduction 2. system design 3. object design 4. testing and metrics 5. design patterns
TRANSCRIPT
![Page 1: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/1.jpg)
1
1. Introduction2. System design3. Object design4. Testing and Metrics5. Design Patterns
![Page 2: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/2.jpg)
2
Goal
CRCcards
Classmodelling
Dynamicmodelling
Use cases
Analysis domain
OOA
Design
Design domain
OOD
ImplementationDomain
code
code
OOP
![Page 3: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/3.jpg)
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
![Page 4: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/4.jpg)
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
![Page 5: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/5.jpg)
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
![Page 6: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/6.jpg)
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
![Page 7: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/7.jpg)
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
![Page 8: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/8.jpg)
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”
![Page 9: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/9.jpg)
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
![Page 10: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/10.jpg)
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
![Page 11: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/11.jpg)
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
![Page 12: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/12.jpg)
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
![Page 13: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/13.jpg)
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
![Page 14: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/14.jpg)
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()
![Page 15: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/15.jpg)
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
![Page 16: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/16.jpg)
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
![Page 17: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/17.jpg)
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
![Page 18: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/18.jpg)
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 !
![Page 19: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/19.jpg)
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}
![Page 20: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/20.jpg)
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 !
![Page 21: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/21.jpg)
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
![Page 22: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/22.jpg)
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
![Page 23: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/23.jpg)
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
![Page 24: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/24.jpg)
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
![Page 25: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/25.jpg)
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
![Page 26: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/26.jpg)
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
![Page 27: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/27.jpg)
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
![Page 28: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/28.jpg)
28
Case IIICourses, Students and Professors
System Design
Package diagram
UI
DataManagement
DatabaseFacade
Database
utilitiesuser
Administration
![Page 29: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/29.jpg)
29
Goal
= to specify• object attribute types -> data structures• method functioning -> algorithms• connection between objects
Based on• OOA models (requirements, CRC, …)• OOD system design
![Page 30: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/30.jpg)
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 !
![Page 31: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/31.jpg)
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
![Page 32: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/32.jpg)
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
![Page 33: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/33.jpg)
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)
![Page 34: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/34.jpg)
34
Metrics : CDM
Module A Module Module
Module Module
The product
change
change
CDM(A)
![Page 35: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/35.jpg)
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
![Page 36: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/36.jpg)
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
![Page 37: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/37.jpg)
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
![Page 38: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/38.jpg)
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”)
![Page 39: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/39.jpg)
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
![Page 40: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/40.jpg)
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());
}}
![Page 41: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/41.jpg)
41
Facade (Structural)
Pattern name
Problem
Solution
Facade
• how to provide a unique interface to a subsystem ?
Facade
![Page 42: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/42.jpg)
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');
}}
![Page 43: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/43.jpg)
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 !
![Page 44: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/44.jpg)
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
![Page 45: 1 1. Introduction 2. System design 3. Object design 4. Testing and Metrics 5. Design Patterns](https://reader035.vdocuments.net/reader035/viewer/2022081516/56649eb35503460f94bb9c14/html5/thumbnails/45.jpg)
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 !"); }}