6.

6 From Logical Design to Physical Design

up to now: considered logical design

• software architecture,
• interface description,
• software quality issues
starting point of design: OOA model
steps: 1. architectural design
2. implementation design

Vorläufige Version 442 5. Juli 2004, Peter Thiemann

 Architectural Design

• user interface, persistent data management, system interfaces

• deployment

• adaption, extension, and refinement of OOA model

→ OOD model (e.g. in UML): navigation, container classes, etc

• reuse: class libraries, components (Halbfabrikate)

Implementation Design

• tailoring to programming language

• transformations: multiple → single inheritance; elimination of inheritance

Vorläufige Version 443 5. Juli 2004, Peter Thiemann

 6.6.1 Class Libraries

• commercial or part of IDE

• GUI, graphics, data structures and algorithms, data base access,
communication
• organization principles
tree relies on inheritance (one root class); complicated to use
forest loosely coupled classes with shallow inheritance relations
flat independent classes; parameterized; easy to use
• multiple implementations of interface with different features
• class adapters (another design pattern)
• framework: adaptable system of cooperating classes

Vorläufige Version 444 5. Juli 2004, Peter Thiemann

 6.6.2 Components

Component: building block of a software architecture

Features:
• Service
– interface specification
– protocol
• composition
• adaption
• open
Goals:
• binary reuse
• unification of form, function, . . .
• standards

Vorläufige Version 445 5. Juli 2004, Peter Thiemann

 Prefabricated Components

Intention: acceleration of software design and implementation by guing

prefabricated parts
⇒ software factory
GUI Components: • (Swing)
• JavaBeans
• ActiveX
Server Components: COM+, EJB, CORBA (middleware, business
logic)
• independence of language, platform, and location
• distribution and interoperability

Vorläufige Version 446 5. Juli 2004, Peter Thiemann

 Components vs Objects

• Component 6= object
– Component 7→ one or more objects (COM)
– one method implementation per interface
– language independent specification
• Component 6= distributed object
alternatives: in process (DLL), local (IPC), remote (RMI, SOAP,
CORBA)
• Component 6= class
– physical structure vs. logical structure
– inheritance
• interface management (IDL)
• dynamic binding

Vorläufige Version 447 5. Juli 2004, Peter Thiemann

 6.6.3 Architectural Design

Extending the OOA model by

• directions of associations
• comments
• visibility of attributes and operations
• class attributes and operations
• wrappers for legacy / DB systems

Vorläufige Version 448 5. Juli 2004, Peter Thiemann

 Class attributes and operations

• have to be removed with OODB

• → introduce auxiliary class
• → singleton pattern

OOA OOD
Account

Account
*
average
1
AccountC
average

Vorläufige Version 449 5. Juli 2004, Peter Thiemann

 User-defined attribute types

Elementary classes include in OOD model only if multiple uses

OOA
Company Person
address : AddressT address : AddressT

OOD
Company AddressT Person
1 1
street
town
state

Vorläufige Version 450 5. Juli 2004, Peter Thiemann

 Enumeration types
OOA OOD
Polygon Polygon «enumeration»
1 Color
color
red
green
blue

Vorläufige Version 451 5. Juli 2004, Peter Thiemann

 6.6.4 Embedding a relational DB

OO-layer transforms
1. classes → relations
2. associations → secondary keys
3. inheritance → system of relations
4. compound types → base types
5. optimistic → pessimistic transactions
6. OO-access methods → SQL

Vorläufige Version 452 5. Juli 2004, Peter Thiemann

 Classes → relations
Person
Person OID no first name name
no
first name
name

• map attribute type to SQL type create table Person

• add column for object identity ( OID number(8) not null,
(OID, reference/pointer) no number(8) not null,
first_name char(20),
• identify mandatory attributes
name char(20) not null,
• index primary key (no)
);

create secondary index PersonIndex

on Person(name);

Vorläufige Version 453 5. Juli 2004, Peter Thiemann

 Associations → secondary keys

• 1 : m-association:
K1
K1 K2 OID1 A1 A2
A1 1 * A3
A2 A4
K2
OID2 A3 A4 OID1

• n : m-association (n, m > 1):

K1 K1-2
K1 K2 OID1 A1 A2 OID1 OID2
A1 * * A3
A2 A4
K2
OID2 A3 A4

Vorläufige Version 454 5. Juli 2004, Peter Thiemann

 Inheritance → systems of relations

1. one relation per class

• each relation contains primary key
• additional attribute determines subclass
• small schema but information dispersed (efficiency?)
Person Person
Name OID Name Group
27 May Cust.
42 Nolan Emp.

Customer Employee
Customer Employee OID Sales OID Wage
Sales Wage 27 3212 42 4619

Vorläufige Version 455 5. Juli 2004, Peter Thiemann

 2. move superclass attributes to subclasses
Customer Employee
OID Name Sales OID Name Wage
27 May 3212 42 Nolan 4619

• suitable if superclass has few attributes

• 3NF
3. move subclass attributes to superclass
Person
OID Name Group Sales Wage
27 May Cust. 3212 NULL
42 Nolan Emp. NULL 4619

• suitable if few subclasses with few attributes

• violates 3NF
4. one relation / class + relation for inheritance → multiple inheritance

Vorläufige Version 456 5. Juli 2004, Peter Thiemann

 6.6.5 Implementation Design

Elimination of multiple inheritance 1. Aggregation of roles

Vehicle Vehicle
location location
speed speed
move()
1
1..2
Role
Airplane Ship
max. altitude draught move()
move() move()

Seaplane Airplane Ship

max. altitude draught
move() move() move()

Vorläufige Version 457 5. Juli 2004, Peter Thiemann

 2. Flattening heterarchy → hierarchy
Vehicle
location
speed
move()

Airplane Seaplane Ship

max. altitude max. altitude draught
move() draught move()
move()

Vorläufige Version 458 5. Juli 2004, Peter Thiemann

 Elimination of inheritance
• languages w/o inheritance: Ada, C
• transfer all attributes and operations from superclasses into each
“class”
Airplane Seaplane Ship
location location location
speed speed speed
max. altitude max. altitude draught
move() draught move()
move()

Vorläufige Version 459 5. Juli 2004, Peter Thiemann

 Further tailoring to PL

• identifier conventions
• base types
• administrative operations (constructors, destructors, initialization,
management of associations and aggregations, access and update of
attributes)
• container classes
• visibility
• transfer object lifecycles (FSM) to algorithms
viz. the state pattern

Vorläufige Version 460 5. Juli 2004, Peter Thiemann