1310414 SYSTEM DESIGN 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING SYSTEM DESIGN

1310414310414 SYSTEM DESIGNSYSTEM DESIGN

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

SYSTEM DESIGNSYSTEM DESIGNSYSTEM DESIGNSYSTEM DESIGN


SYSTEM DESIGNSYSTEM DESIGN

Adapts the logical structure of the Analysis Model to the Adapts the logical structure of the Analysis Model to the implementation environment and prepares for implementationimplementation environment and prepares for implementation

Adapts the logical structure of the Analysis Model to the Adapts the logical structure of the Analysis Model to the implementation environment and prepares for implementationimplementation environment and prepares for implementation

– consider the impact of nonfunctional requirements

– consider system-wide design issues

– consider the implementation environment

– fully specifying each class including all attributes and operations

– decompose implementation work into more manageable pieces –> subsystems

– capture the major interfaces between subsystems

When to transition to system design?– when minimal changes will be required to transform the Analysis

Model into the Design Model

6


IMPORTANCE OF DESIGNIMPORTANCE OF DESIGN

Why not go straight to implementation?Why not go straight to implementation?

we need to consider the impact of nonfunctional requirements

the system must be adapted to the implementation environment

analysis model is not sufficiently formal so we need to:– refine analysis classes

– determine operations

– determine how classes should communicate

we want to validate the analysis results

How well do the Analysis Model and the Requirements Model describe the system? What is not yet clear?


DESIGN GOALSDESIGN GOALS

WhatWhat qualitiesqualities of the system should of the system should the developersthe developers optimizeoptimize ((focus onfocus on)?)?

WhatWhat qualitiesqualities of the system should of the system should the developersthe developers optimizeoptimize ((focus onfocus on)?)?

qualities derived mainly from nonfunctional requirements

selected qualities guide the decisions made by developers, especially when trade-offs are needed

usually only a small subset of the nonfunctional requirements can be considered simultaneously

need to prioritize design goals and possibly develop trade-offs against each other as well as against managerial

goals

Examples: space vs. speed; delivery time vs. functionality, etc.

6.2


SYSTEM-WIDE DESIGN ISSUESSYSTEM-WIDE DESIGN ISSUES

data management — How is persistent data handled? files? relational DBMS? object-oriented DBMS?

access control — How is access control specified and realized? global access table? access control list? capability?

control flow — How is processing initiated and controlled? procedure-driven? event-driven? threaded?

boundary conditions — How are system start-up, system shutdown and exceptions handled?

specify system administration use cases for start-up, shutdown

specify an exceptional handling mechanism for errors

6.4.76.4.66.4.5 6.4.8


IMPLEMENTATION ENVIRONMENTIMPLEMENTATION ENVIRONMENT

What hardware/software will the system run on?– hardware (limitations) –system software– distribution

What programming language will be used?– OO, non-OO –memory management

What existing software do we need to use?– DBMS – network facilities– UIMS – legacy systems

What development people/organizations will be involved?– distributed location – team competencies

Need to consider theNeed to consider the technical and managerial technical and managerial constraintsconstraints under which the system should be builtunder which the system should be built

Need to consider theNeed to consider the technical and managerial technical and managerial constraintsconstraints under which the system should be builtunder which the system should be built

6.4.4


??

IMPLEMENTATION ENVIRONMENT (cont’d)IMPLEMENTATION ENVIRONMENT (cont’d)

General design strategy:General design strategy:localizelocalize andand encapsulateencapsulate implementation environmentimplementation environment

General design strategy:General design strategy:localizelocalize andand encapsulateencapsulate implementation environmentimplementation environment

to accomplish this, we create “bridge” classes that represent occurrences of components in the implementation environment

FileManager

NT Unix Mac-OS

application system classes that require file access

often need to define additional classes to deal with the implementation environment

bridge class


Increments

Inception Elaboration Construction Transition

LIFE CYCLE ROLELIFE CYCLE ROLE

PhasesCore Workflows

Requirements

Analysis

Design

Implementation

Testing

iter.#1

iter.#2

— — — — —iter.#n-1

iter.#n

Iter

atio

n


ARTIFACTS & WORKERSARTIFACTS & WORKERS

Use-CaseEngineer

Use-CaseRealization—Design

responsible for

Architect

DesignModel

ArchitectureDescription

ComponentEngineer

DesignSubsystem

InterfacesDesignClass

DeploymentModel

responsible forresponsible for


UP — SYSTEM DESIGN ACTIVITIESUP — SYSTEM DESIGN ACTIVITIES

Use-CaseEngineer

Architect

ComponentEngineer

ArchitecturalDesign

DesignUse Cases

DesignClasses

DesignSubsystems


USE-CASE DESIGNUSE-CASE DESIGN

Identify the participating design classes– analysis classes that participate in the use case

– additional classes to handle any special requirements of analysis use case (e.g., design goals)

– any other classes needed to implement the use case(e.g., to accommodate the implementation environment)

preserve traceability: use-case realization–design use-case realization–analysis use case

Specify:

– class diagrams show participating classes

identify active classesa thread or process shown with a thicker border

– implementation requirements collect the nonfunctional requirements that will be handled during implementation


CLASS DESIGNCLASS DESIGN

Design classesDesign classes are classes whose specifications have been are classes whose specifications have been completed to such a degree that they completed to such a degree that they can be implementedcan be implemented..

Design classesDesign classes are classes whose specifications have been are classes whose specifications have been completed to such a degree that they completed to such a degree that they can be implementedcan be implemented..

7.4

design classes come from two places:

1. the problem domain refine analysis classes by adding implementation details may require analysis classes to be divided into two or more

detailed design classes

2. the solution domain utility class libraries, reusable components, component

frameworks (DCOM, CORBA, Enterprise JavaBeans, etc.) provides the technical tools to implement a system


For boundary classes we need to consider– specific user interface technologies used

in Visual Basic need design classes:(1) stereotyped as «form» (2) representing “controls”

For entity classes we need to consider– specific data management technologies used

design classes that encapsulate a relational database

For control classes we need to consider– distribution issues –> do we need a separate design class at each

node?– performance issues –> do we merge with boundary/entity class?– transaction issues –> do we need to incorporate transaction

management technology?

CLASS DESIGN — SOLUTION DOMAINCLASS DESIGN — SOLUTION DOMAIN


CLASS DESIGN — ACTIVITIESCLASS DESIGN — ACTIVITIES

complete the specification by identifying/specifying:– missing attributes, associations and operations

not all messages become operations (e.g., actors, boundary classes)

not all operations appear in interaction diagrams

– type signatures and visibility of attributes and operations

– constraints on operations –> invariants; preconditions; postconditions

– exceptions –> values that operations should not accept

select reusable components by identifying and adapting:– class libraries –> conversion/“glue” classes and operations may be

needed

– generic design mechanisms for handling nonfunctional requirements persistence; object distribution; security; transaction

management; error handling, etc.

7.4


CLASS DESIGN — ACTIVITIES (cont’d)CLASS DESIGN — ACTIVITIES (cont’d)

restructure the design model– realize associations –> often realized as variables that provide

references among objects refine multiplicities, role names, association classes, qualified roles,

navigability of associations; consider programming language support

– increase reuse by use of inheritance/delegation

optimize the design model– revise access paths to speed up access –> add new associations

– collapse classes –> classes with few attributes and little behavior

– cache expensive computations –> use derived attributes

– delay expensive computations –> e.g., image display

Describe using the syntax of the programming language.


WELL-FORMED DESIGN CLASSESWELL-FORMED DESIGN CLASSES

completeness and sufficiency a class should do what users of the class expect – no more and no

less

primitiveness a class should always make available the simplest and smallest

possible set of operations

high cohesion a class should model a single abstract concept and should have

operations that support the intent of the class

low coupling a class should be associated with just enough other classes to

allow it to realize its responsibilities


GENERIC DESIGN MECHANISMSGENERIC DESIGN MECHANISMS

Well-tried waysWell-tried ways to handleto handle common requirementscommon requirementsWell-tried waysWell-tried ways to handleto handle common requirementscommon requirements

design pattern – a named, well-understood solution to a commonproblem in context described in literary form

– help novices to learn by example to behave more like experts

– pattern catalog documents particular designs that are useful in a certain context

framework – a reusable “chunk” of architecture– describes how a collection of objects work together to implement the

structural part of, usually, several design patterns

– usually define generic classes that describe the collaborations between the objects and which will be sub-classed (specialized) when the framework is applied to a problem

WhatWhat

HowHow

7.4.6


DESIGN PATTERN: DESIGN PATTERN: SINGLETONSINGLETON — MOTIVATION — MOTIVATION

Problem: It is important for some classes to have exactly one instance. How to ensure that a class has only one instance and that the instance is easily accessible?

e.g., although there can be many printers in a system, there should be only one print spooler

A global variable can make an object accessible, but how to prohibit instantiation of multiple instances?

Solution: Make the singleton class itself responsible for– keeping track of its sole instance

– ensuring that no other instance can be created, and

– providing a way to access the instance


DESIGN PATTERN: DESIGN PATTERN: SINGLETONSINGLETON

IntentEnsure a class only has one instance and provide a global point of access to it.

Solution1. Declare the constructor(s) as protected.2. Declare a class attribute “self” to hold a reference (pointer) to the single instance

when it is created.3. Declare a class operation “instance” that creates and returns the single instance

if the self pointer is NULL; otherwise it returns the previously created instance.4. Declare a protected destructor that sets the “self” pointer to NULL.5. Declare other operations and attributes as needed normally.6. Clients access the singleton by calling the class instance operation to get a

reference to the single instance and then using it to call other operations.7. Clients must not store this instance reference.

Consequences Ensures that only one instance of the class can ever be created. Access to the sole instance is strictly controlled by the object itself. Reduces the number of global names (i.e., global variables)defined in a system.


DESIGN PATTERN: DESIGN PATTERN: PROXYPROXY — MOTIVATION — MOTIVATION

Problem: Sometimes we want to defer the full cost of creating and initializing an object until we actually need to use it

– e.g., in a document editor that can embed graphical objects in a document, objects like large raster images can be expensive to create

– but, opening a document should be fast avoid creating expensive objects at once when the document is opened (also, usually not all objects are visible at the same time anyway)

expensive objects should be created on demand

Solution: Use another object, an image proxy, that acts as a stand-in for the real image

– the proxy acts just like the image, instantiates it when needed and forwards request to it after creating it

aTextDocument

imageanImageProxy

fileNameanImage

data

in memory on disk


DESIGN PATTERN: DESIGN PATTERN: PROXYPROXY

IntentProvide a surrogate or placeholder for another object to control access to it.

Solution1. Create an abstract Subject class that defines the complete public interface of a

class, but does not implement it.2. Derive a RealSubject class from Subject and implement the public interface as

needed to perform all required behaviour.3. Derive a Proxy that creates the RealSubject and passes all requests to it.

Consequences Proxy is extremely good for patching inflexible OO designs in a well-controlled

manner, often adding flexibility to the design. Proxys can be used to distribute objects to different object spaces or across

networks. Proxy can enhance RealSubject’s behaviour—particularly important when used

to encapsulate third party libraries.


DESIGN PATTERN: DESIGN PATTERN: BRIDGEBRIDGE — MOTIVATION — MOTIVATION

Problem: When an abstraction can have several possible implementations, inheritance is usually used to handle this. However, this binds an implementation to an abstraction permanently making it difficult to modify, extend and reuse abstractions and implementations independently.

e.g., implementation of a portable Window abstraction in a user interface toolkit

Window

MSWindow MacWindow

Window

MSWindow MacWindow

MSWindow MacWindow

IconWindow


DESIGN PATTERN: DESIGN PATTERN: BRIDGEBRIDGE

IntentDecouple an abstraction from its implementation so that the two can vary independently.

Solution1. Create an Implementor class that defines a public interface.2. Create subclasses of the Implementor class to implement each operation as needed.3. Create an Abstraction class that maintains an association to the Implementor class

and provides a set of methods to invoke those operations.4. For each RefinedAbstraction class that needs to use an Implementor subclass,

subclass the RefinedAbstraction from the Abstraction.

Consequences Avoids permanent bindings between an abstraction and its implementation. Both abstractions and implementations are extendable via subclassing. Changes to the implementation have little or not impact on clients. Hides implementation of an abstraction from clients. Allows sharing an implementation among multiple objects and hiding that fact from

clients.


DESIGN PATTERNS FOR PERSISTENT (RDBMS) DATADESIGN PATTERNS FOR PERSISTENT (RDBMS) DATA

issues to consider for mapping classes/objects to a RDBMS:– how to create and assign OIDS

– inheritance usually not supported in a relational DBMS

– class structure table structure

– type system mismatches (programming language DBMS)

Volatile memory

Persistent memory


ASSIGNING AND CREATING OIDSASSIGNING AND CREATING OIDS

Assigning– add an OID attribute (column) to each table that represents a class– the OID is the primary key of the table– this OID should have no meaning in the application domain;

it is strictly for internal system use

Creating1. Do a MAX() on the primary key column and add one

2. Maintain a key-values table(a) Single row/single column (b) multi-row/two column

3. Use HIGH/LOW method (two part OID) HIGH value obtained from a single source when a new OID is

needed LOW value assigned by the application for that session and

incremented for each new OID required

MAX Class MAX

... ...

One row per table


MAPPING CLASSESMAPPING CLASSES

Concerns– Classes do not have keys; tables do not have the same identity

property as classes– Table data types do not match the classes in the object model– Complex classes can reference other complex classes and collections– Not all class attributes are persistent (e.g., a Total attribute)

Solution– Create a table for each persistent class with a column that contains

the OID– For each attribute represented as a base database type, create a

column in the table naming it the same as the class attribute– If an attribute contains a collection, use the design pattern

Representing Collections in a Relational Database– If an attribute contains any other value, use the design pattern

Foreign-Key Reference


MAPPING INHERITANCE HIERARCHIESMAPPING INHERITANCE HIERARCHIES

1. Design Pattern: One Inheritance Tree One Table

Person

namephoneNumber

Employee

startDate

Customer

customerIDpreferences

name phoneNumberOID customerID preferences startDate classType

Chan 9234-8756123 NULL NULL 6/11/02 Employee

Hui 2367-9823345 6677543 ABC NULL Customer

Mak 2546-8723836 NULL NULL 8/12/99 Employee

Person

...


MAPPING INHERITANCE HIERARCHIES (cont’d)MAPPING INHERITANCE HIERARCHIES (cont’d)

2. Design Pattern: One Inheritance Path One Table

Person

namephoneNumber

Employee

startDate

Customer


name phoneNumberOID customerID preferences

Hui 2367-9823345 6677543 ABC

Customer

......

startDate

6/11/02

8/12/99

name phoneNumberOID

Chan 9234-8756123

Mak 2546-8723836

Employee


MAPPING INHERITANCE HIERARCHIES (cont’d)MAPPING INHERITANCE HIERARCHIES (cont’d)

3. Design Pattern: One Class One Table

Person

namephoneNumber

Employee

startDate

Customer


...

Person

name phoneNumberOID

Chan 9234-8756123

Hui 2367-9823345

Mak 2546-8723836

...

customerID preferences

6677543 ABC

OID

345

Customer

...

startDate

6/11/02

8/12/99

OID

123

836

Employee


MAPPING ASSOCIATIONSMAPPING ASSOCIATIONS

Concerns– A variety of associations exist between classes in an object model

including: 1 to 1; 1 to many; many to many; ternary; etc.

– The association may represent containment, related properties or have special meaning

Solution– Merge 1 to 1 associations with no special meaning into one of the

tables(if it has a special meaning, create a table based on the class derived from the association)

– For 1 to many associations with no special meaning, use the design pattern Foreign Key Reference

– For many to many associations use the design pattern Association Table


MAPPING ASSOCIATIONS (cont’d)MAPPING ASSOCIATIONS (cont’d)

1. Design Pattern: Foreign Key Association

Employee

namephoneNumberstartDate

Project

namedescriptionlocation

AssignedTo

...

startDate

6/11/02

8/12/99

name phoneNumberOID

Chan 9234-8756123

Mak 2546-8723836

Employee

1 *

...

name descriptionOID

ABC Accounting1256

Project

SIT Billing1258

EAT Data mining1266

UUC Ordering1389

MAN Web services2390

location

Aberdeen

Central

Mongkok

Tsuen Wan

Shatin

foreign key

empOID

123

123

836

123

837

Project


...

Part

descriptionOID

widgets45

bolts78

fasteners65

washers34

pipe88

part#

123

243

338

227

105...

name locationOID

Reliable Wanchai835

Ho Ho Sai Kung886

Supplier

The Best Wong Tai Sin542

So Good Mongkok101

supplier#

12385

34127

66398

93245

Supplier

supplier#namelocation

Part

part#description

* *Supplies


2. Design Pattern: Association Table

foreign key

...

OID

90

92

93

96

99

SOID

835

835

886

101

101

POID

123

338

123

227

123

Supplies

foreign key



2. Design Pattern: Association Table

...

Course

OID

668

634

654

772

name

OO Prog

Data Struct

Software

Languages

Algorithms825

courseID

151

171

211

252

271...

nameOID

Cheng150

Wong157

Student

Lam162

Kwok171

student#

0127689

0177523

0188319

0143256

Student

student#name

Course

courseIDname

* *

EnrolledIn

grade

...

OID

312

415

322

245

599

SOID

150

171

162

150

162

COID

151

151

171

211

211

EnrolledIn

grade

A-

B

C+

A

B-

foreign keyforeign key


MAPPING COLLECTIONSMAPPING COLLECTIONS

Concerns– a table cannot contain a multi-valued attribute (i.e., a collection)

– a collection may convey additional information besides the relationships between objects

Solution– represent each collection using the design pattern Association

Table

Documents

1310414 SYSTEM DESIGN 310414 SOFTWARE ENGINEERING 310414 SOFTWARE ENGINEERING SYSTEM DESIGN