Upload
richard-mathews
View
228
Download
1
Tags:
Embed Size (px)
Citation preview
1310414310414 SYSTEM DESIGNSYSTEM DESIGN
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
SYSTEM DESIGNSYSTEM DESIGNSYSTEM DESIGNSYSTEM DESIGN
2310414310414 SYSTEM 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
3310414310414 SYSTEM DESIGNSYSTEM DESIGN
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?
5310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
7310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
8310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
9310414310414 SYSTEM DESIGNSYSTEM DESIGN
??
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
10310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
11310414310414 SYSTEM DESIGNSYSTEM DESIGN
ARTIFACTS & WORKERSARTIFACTS & WORKERS
Use-CaseEngineer
Use-CaseRealization—Design
responsible for
Architect
DesignModel
ArchitectureDescription
ComponentEngineer
DesignSubsystem
InterfacesDesignClass
DeploymentModel
responsible forresponsible for
15310414310414 SYSTEM DESIGNSYSTEM DESIGN
UP — SYSTEM DESIGN ACTIVITIESUP — SYSTEM DESIGN ACTIVITIES
Use-CaseEngineer
Architect
ComponentEngineer
ArchitecturalDesign
DesignUse Cases
DesignClasses
DesignSubsystems
17310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
19310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
20310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
21310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
22310414310414 SYSTEM DESIGNSYSTEM DESIGN
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.
23310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
26310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
27310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
28310414310414 SYSTEM DESIGNSYSTEM DESIGN
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.
30310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
32310414310414 SYSTEM DESIGNSYSTEM DESIGN
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.
34310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
36310414310414 SYSTEM DESIGNSYSTEM DESIGN
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.
38310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
39310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
40310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
41310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
...
42310414310414 SYSTEM DESIGNSYSTEM DESIGN
MAPPING INHERITANCE HIERARCHIES (cont’d)MAPPING INHERITANCE HIERARCHIES (cont’d)
2. Design Pattern: One Inheritance Path One Table
Person
namephoneNumber
Employee
startDate
Customer
customerIDpreferences
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
43310414310414 SYSTEM DESIGNSYSTEM DESIGN
MAPPING INHERITANCE HIERARCHIES (cont’d)MAPPING INHERITANCE HIERARCHIES (cont’d)
3. Design Pattern: One Class One Table
Person
namephoneNumber
Employee
startDate
Customer
customerIDpreferences
...
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
44310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
45310414310414 SYSTEM DESIGNSYSTEM DESIGN
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
46310414310414 SYSTEM DESIGNSYSTEM DESIGN
...
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
MAPPING ASSOCIATIONS (cont’d)MAPPING ASSOCIATIONS (cont’d)
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
47310414310414 SYSTEM DESIGNSYSTEM DESIGN
MAPPING ASSOCIATIONS (cont’d)MAPPING ASSOCIATIONS (cont’d)
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
48310414310414 SYSTEM DESIGNSYSTEM DESIGN
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