6 12 From%20Logical%20Design%20to%20Physical%20Design

8/14/2019 6 12 From%20Logical%20Design%20to%20Physical%20Design

http://slidepdf.com/reader/full/6-12-from20logical20design20to20physical20design 1/19

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

Vorlaufige 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




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




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




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




Components vs Objects

• Component = object

– Component → one or more objects (COM)

– one method implementation per interface– language independent specification

• Component = distributed object

alternatives: in process (DLL), local (IPC), remote (RMI, SOAP,

CORBA)

• Component = class

– physical structure vs. logical structure

– inheritance

• interface management (IDL)

• dynamic binding




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




Class attributes and operations

• have to be removed with OODB

• → introduce auxiliary class

• → singleton pattern

OOD

*

1AccountC

average

Account

average

OOA

Account




User-defined attribute types

Elementary classes include in OOD model only if multiple uses

OOD

OOA

11street

town

PersonAddressT

Personaddress : AddressT

Companyaddress : AddressT

Company

state




Enumeration types

OOA OOD

1Polygon

color

Polygon

redgreen

blue

«enumeration»Color




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 types5. optimistic → pessimistic transactions

6. OO-access methods → SQL




Classes → relations

Person OID

no

first name

no name

Person

first name

name

• map attribute type to SQL type

• add column for object identity

(OID, reference/pointer)

• identify mandatory attributes

• index

create table Person

( OID number(8) not null,

no number(8) not null,

first_name char(20),name char(20) not null,

primary key (no)

);

create secondary index PersonIndexon Person(name);




Associations → secondary keys

• 1 : m -association:

K1

K2

*1

K1

A1

A2

K2

A3

OID1

OID2 A3 A4 OID1

A2A1

A4

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

K1-2

OID1K2

A3

A4

*

A1 A2OID1

K1

*A1

A2

K1

A4A3OID2

K2

OID2




Inheritance → systems of relations

1. one relation per class

• each relation contains primary key

• additional attribute determines subclass

• small schema but information dispersed (efficiency?)

Employee

42 4619Customer Employee

Sales Wage

OID

OID Sales

Person

Customer

27

42

Name Name Group

May

Nolan

Cust.

Emp.

27 3212

Person

OID Wage




6.6.5 Implementation Design

Elimination of multiple inheritance 1. Aggregation of roles

move()

move()max. altitude

Airplane

move()draught

Ship

Vehicle

location

speed

Role

1

1..2

Vehicle

move()

location

speed

move()

draughtShip

Seaplane

move()

move()

max. altitudeAirplane




2. Flattening heterarchy → hierarchy

max. altitude

Seaplane

move()

draughtmove()

max. altitude

Airplane

Vehicle

move()

location

speed

move()

draught

Ship




Elimination of inheritance

• languages w/o inheritance: Ada, C

• transfer all attributes and operations from superclasses into each

“class”SeaplaneAirplane Ship

move()

move()

move()draught

max. altitudemax. altitude

speed

location location location

speed speed

draught




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


6 12 From%20Logical%20Design%20to%20Physical%20Design

Documents

Transcript of 6 12 From%20Logical%20Design%20to%20Physical%20Design