09.10.2015 object oriented analysis & design & uml (unified modeling language)1 part v:...

20.04.23 Object Oriented Analysis & Design & UML (Unified Modeling Language) 1

Part V: Design

The Design WorkflowDesign ClassesRefining Analysis Relationships


Content The Design Workflow Design Classes Refining Analysis Relationships

The Design Workflow


Unified Process - Overview

Design is much more consentrated in Elaboration and Construction phases


Design Model

The design model contains exactly one design system that contains many design subsystems


From Analysis to Design

there is a simple one-to-one «trace» relationship between the analysis system and the design system

the design model is based on the analysis model, can be considered to be

just a refinement and elaboration of analysis model


Design Workflow

Artefacts Design subsystems Design classes Design Interfaces Use case realizations for design


Analysis Class-Design Class

An analysis class may be resolved into one or more interfaces or design classes.

analysis classes are a high-level conceptual view of the classes

in the system.

In physical modeling (design): conceptual classes are implemented as

one or more design classes and/or interfaces


Tracing Analysis to Design

Each analysis class can be traced to multiple design classes/interfaces


10

The Design Classes

What are Design Classes? Classes with completed definition Detailed so that ready to implement Sources of design classes

Problem domain via refinement of analysis classes

Solution domain Utility classes

Time, Date, String, collections, … Middleware

Communications, database,.. Component frameworks

DCOM, CORBA, Enterprise JavaBeans GUI Framework

Window, Form, Button, Menu, …


Translating Analysis Classes into Design Classes

Refine analysis class into one or more design classes

if classes become too large design level abstraction is more detailed add newly found attributes

to make the class complete for implementation new implementation level attributes

Broke large analysis classes into two or more classes

Good design classes must be Small Self-contained Cohesive units


Anatomy of Design Class Specify how the class

will fulfill its responsibilities Complete list of attributes

Fully specify with visibility, name, type, Default values (if there are any)

Complete set of methods visibility, name, parameter list, type, return value


Example: BankAccount


BankAccount

namenumberbalance

deposit()withdraw()calculateInterest()

BankAccount

-name: String-number: String-balance: double = 0

+BankAccount(name:String,number:String)+deposit(m:double) : void+withdraw(m:double) : boolean+calculateInterest() : double+getName() : String+setName(n:String) : void+getAddress(): String+setAddress(a:String) : voidgetBalance() : double+BankAccount(n:String, a:String, m:double)

Analysis Design

constructor

«trace»

15

Refining analysis relationships

Inheritance In analysis

use inheritance to implement “is a” relationships

In design use inheritance to reuse code as well

Inheritance is Strongest for coupling

Changes to parent classes have a large impact on classes in the hierarchy

Encapsulation is weak in class hierarchy Child classes can access to base’s attributes!

Inflexible Fixed at run-time You cannot change it as done in aggregation


Aggregation instead of Inheritance (?)

subclass always represents “is kind of” not “is role played by”


Employee

Manager Programmer

john:Programmer

«instance»

Manager Programmer

«instantiate»

Employee

:Manager :Programmer

john:Programmer

«instantiate» «instantiate»

Job

0..* 0..*

john: changes the role by just changing link

between role and :Programmer

Multiple Inheritance Some OO Languages do not allow

Languages do not support: Java, C# Language supports : C++

Overlap between the classes causes unforeseen interactions

“is kind of” and substitutability principles must apply common parents cause

Multiple occurrence of the same features


Person

Staff Student

Assistant

Aggregation Whole-part relationship A lose relationship Whole does not own the parts

Parts Created and destructed any time are not dependent on the whole

Example: Computer system and the peripherals


Aggregation Rules The aggregate can exist

independent from its parts The parts can exist

independent from the aggregate The aggregate is incomplete

If the parts are missing The same parts

can be shared by multiple aggregates


Composition A whole-part relationship Strong type of relationship The life cycle of the parts depend on the

whole Parts

can be created only after the whole is created

destructed by default when the whole is destructed

Example: Tree and its leaves


Composition Rules The parts

belong to only one composite cannot exist without the composite

The composite creates and destroys the parts


Aggregation vs Composition

Aggregation a Computer may be attched to

0 or more Printers

at any time a Printer is connected to 0 or more Computers

over time a computer may use a given Printer

the printer exist even if there are no Computers attached

the Printer is independent from the Computer


Tree

1 0..*Leaf

Composition a Tree might have

0 or many Leaves at a time over time a computer may use a given

Printer Tree still exist even if it has no Leaves

at all the Leaves cannot exist without the

Tree the Leaves are dependent on the Tree

Computer

0..* 1

Monitor

Printer

Speakers

Keyboard

1 0..*

1 0..1

1 1

How to Refine Analysis Relationships?

Add multiplicities and role names to associations if they were absent

Decide which of the side is whole and which side is the part

Look at the whole side If it is exactly 1:

You may apply the composition Otherwise

You must set it as aggregation Add navigability from the whole to the part

Design associations must be unidirectional! Decide how to implement

the multiplicities greater than 1 on both sides


One-to-One Associations

One-to-one associations become composition


Person

1 1Identity

Person

1 1Identity

Analysis

Design

«trace»

Many-to-one Associations

Many on the whole side: Use aggregation

You cannot use composition Reason: the whole cannot be shared in composition!


Computer Printer0..* 1

Computer Printer0..* 1

«trace»

Analysis

Design

One-to-Many Associations There are collection of objects

on the parts side Use collections

to implement If the language does not support

collections Use arrays Implement collections


Implementation of one-to-many

If life-cycle of the parts is dependent on the whole Use aggregation

Otherwise use composition


Computer Monitor1 0..*

Computer Monitor

1 0..*

«trace»

Analysis

Design

Specification of Parts’ Semantics

Property Semantics

{sorted} The collection is sorted to some key: {sorted by name}

{indexed} Individual element is accessed via a key

{set} Dublicates are not allowed in collection

{lifo} Last In First Out characteristics

{queue} A queue with the first element is placed to be taken off first


Student Grade1 0..*

Student Grade

1

«trace»

Analysis

Design

{Ordered} 0..*

Many-to-Many Relationships

commonly used OO languages does not support Many-to-Many relationships

Add new design class between


Resource Task

* *

Resource Allocation1

«trace»

Analysis

Design

*

Task1*


End of Chapter

09.10.2015 object oriented analysis & design & uml (unified modeling language)1 part v:...

Documents

design systemthe design

physical modeling design

analysis system

classesgood design classes

design classesif classes

design classesproblem

elaboration of analysis

designeach analysis