Architectural Design

Architectural Design
Objectives: Architectural Design

Understand the purpose of Architectural Design and where
in the lifecycle it is performed
Explain what Design and Implementation Mechanisms are
and how they map from Analysis Mechanisms
Understand what subsystems and interfaces are and what
role they play in the architecture
Describe the process for identifying interfaces, classes and
subsystems
or
OOAD Using the UML - Architectural Design, v 4.0

Copyright 1994-1998 Rational Software, all rights reserved

So Where Are We?
Architect
Architectural
Analysis
Architectural Design Overview
Architectural Describe
Design Concurrency
Describe
Distribution
Review the Architecture

Reviewer
Architecture
Glossary
Supplementary
Specifications
Use-Case
Analysis
Subsystem
Design
Designer
Use-Case
Design
Review the
Design
Architecture Document
Design
Guidelines
Design
Guidelines
Architectural
Design
Design
Reviewer
Class
Design
Analysis Classes
Database
Design
Database
Designer


Design Model
Architectural Design Topics
Key Concepts
Design and Implementation Mechanisms
Design Classes and Subsystems
Reuse Opportunities
Refined Architectural Layers and Partitions
Architectural Design Checkpoints

Design Model
4
Key Concepts
Reuse Opportunities

Page 1
1
The 4+1 View Architecture Model
Review of Key Terms

What is a class?
Logical View
Analysts/Designers
Structure
A description of a set of objects that share the same

responsibilities, relationships, operations, attributes, and
semantics.
Implementation View
End-user
Functionality
Class Name
Programmers
Software management
What is a package?
Use-Case View
Process View
A general purpose mechanism for organizing elements into

groups
A model element which can contain other model elements
Deployment View
System engineering
System topology
Delivery, installation
communication
System integrators
Performance
Scalability
Throughput
Package Name


Global Packages
Package Visibility
PackageA
Certain packages are used by all other packages

These packages are marked global
Class A1
Class A2
Foundation
Class A3
Only public classes

can be referenced
outside of the
owning package
PackageB
Classes
Class B1
Class B2
global
Public visibility

Private visibility

Key Concepts
Reuse Opportunities
Client
Analysis
Design
Implementation
Class
Mechanism
Mechanism
Mechanism
(Conceptual)
(Concrete)
(Actual)
Legacy Data
Course
11
Persistency
RDBMS
Persistency
OODBMS
JDBC to Ingres
New Data
Student
RegistrationController

10
Distribution
Analysis

Remote Method
Invocation (RMI)
Design
12
ObjectStore
Java 1.1 from Sun

Implementation
Page 2
2
Example: Remote Method Invocation (RMI)
Common Object Request Broker Architecture (CORBA)

C++
Jav
a
IDL
IDL
Ada
Cobol
C++
Jav
a
IDL
Client
IDL
IDL
IDL
IDL
Ada
Cobol
IDL
Server
IDL
IDL
Naming
Lookup(serverURL)
Remote
client
ORB
InvokeOp()
InvokeOp()
RemoteObject
RemoteStub
ClassA
ProxyClientB
ProxyServerB
RemoteSkeleton
ClassB
RMI Transport
Object Request Broker

13

Key Concepts
Reuse Opportunities

DesignClass
DesignClass
DesignClass
DesignClass
<<subsystem>>
Subsystem

Example: Design Classes
<<boundary>>
MaintainScheduleForm
16
Example: Design Classes (cont.)
<<boundary>>
MainForm
0..1
<<boundary>>
0..1
0..1
MainProfessorForm
<<boundary>>
<<boundary>>
(from Professor Interface)
ReportCardForm
(from Student Interface)
1
1
0..1
<<boundary>>
CloseRegistrationForm
<<boundary>>
MainStudentForm
In design, the one

application becomes
three applications, each
with its own forms ...
0..1 <<boundary>>
LogonForm
1
1 1 1
<<subsystem>>
Subsystem
<<subsystem>>
Subsystem
15
In analysis, we had one

application with many
different forms
14
(from Registrar Interface)
<<boundary>>
SubmitGradesForm
0..1
<<boundary>>
SelectCoursesForm
0..1
0..1
<<boundary>>
<<boundary>>
SelectCoursesForm
SubmitGradesForm
(from Professor Interface)(from Professor Interface)
<<boundary>>
MaintainProfessorForm
0..1
0..*
<<boundary>>
MaintainStudentForm
<<boundary>>
ReportCardForm

17
0..*
0..1
<<boundary>>
<<boundary>>
<<boundary>>
MaintainStudentForm
(from Registrar Interface) (from Registrar Interface) (from Registrar Interface)
0..1

0..1
<<boundary>>
MainRegistrarForm
0..1

18
Page 3
3
Interfaces and Subsystems
Subsystem Usage
Subsystems can be used to partition the system into parts
which can be independently:
InterfaceI1
<<subsystem>>
Subsystem A
MyPackage
W()
X()
Class A1
Class A2
W()
X()
<<Interface>>
InterfaceI2
Subsystems can also be used to:
<<subsystem>>
Subsystem B
AnotherPackage
Y()
Z()

ordered, configured, or delivered

developed, as long as the interfaces remain unchanged
deployed across a set of distributed computational nodes
changed without breaking other parts of the systems
Class B1
Class B2
Class B3
W()
Y()
X()
Z()
partition the system into units which can provide restricted

security over key resources
represent existing products or external systems in the design
(e.g. components)
Subsystems raise the level of abstraction
19

Packages Vs. Subsystems
Client Class
PackageB
Look at object collaborations

Look for optionality
Look to the user interface of the system
Look to the Actors
Look for coupling and cohesion between classes
Look at substitution
Look at distribution
Class B1
<<subsystem>>
A
Class B2
Encapsulation is the key!

21

Subsystem Guidelines
22
Identifying Interfaces
Goals
Purpose
Loose coupling
Portability, plug-and-play compatibility
Insulation from change
Independent evolution
To identify the interfaces of the subsystems based on their

responsibilities
<<subsystem>>
A
Steps
Identify a set of candidate interfaces for all subsystems
Look for similarities between interfaces
Define the operations
Map the interfaces to subsystems
<<subsystem>>
B
Strong Suggestions
Dont expose details
Only depend on other interfaces
Key is encapsulation, abstraction and
simplification
Make the design easier to understand!
Identifying Subsystems Hints
Subsystems provide behavior, packages do not

Subsystems completely encapsulate their contents,
packages do not
Subsystems are easily replaceable

20
23
<<subsystem>>
C
Stable, well-defined interfaces are key to a stable, resilient architecture

24
Page 4
4
Interface Guidelines
Interfaces and Polymorphism
Naming interfaces
Interfaces formalize polymorphism

Interfaces support plug-and-play architectures
Reflect role in system
Describing interfaces
Convey responsibilities
Tube
Defining operations
<<interface>>
Shape
Name should reflect operation result

Describe what operation does, all parameters and result
Pyramid
Draw
Move
Scale
Rotate
Documenting interfaces
Package supporting info: sequence and state diagrams, test
plans, etc.
25

Example: Design Subsystems
ICourseCatalog
(from Business Services)
<<subsystem>>
CourseCatalog
<<subsystem>>
CourseCatalog
(from Business Objects)

ICourseCatalog
27

29
28
Possible Reuse Opportunities
Key Concepts
Reuse Opportunities

(from Business Objects)
<<subsystem>>
CourseCatalog
(from CourseCatalog)

<<subsystem>>
CourseCatalog
(from CourseCatalog)
(from FinanceSystem)
ICourseCatalog
26
Example: Modeling Design Subsystems
<<subsystem>>
FinanceSystem
IFinance
System
Cube
Internal to the system being developed

Recognized commonality across packages and subsystems
External to the system being developed

Commercially available components
Components from a previously developed application
Reverse engineered components

30
Page 5
5
Partitioning Considerations
Key Concepts
Reuse Opportunities

31
Coupling and cohesion

User organization
Competency and/or skill areas
System distribution
Secrecy
Variability

Example: Partitioning
32
Typical Layering Approach

A
Specific
functionality
Package A
Package B
General
functionality
33

Layering Guidelines
34
Example: Architectural Layers
Visibility
<<layer>>
User Interface
Dependencies only within current layer and below
Volatility
<<layer>>
Business Services
Upper layers affected by requirements changes

Lower layers affected by environment changes
<<layer>>
Business Objects
Generality
More abstract model elements in lower layers
<<layer>>
Middleware
Number of layers
Small system: 3 layers
Complex system: 5-7 layers
Goal is to reduce coupling and to ease maintenance effort
35
<<layer>>
System

Base Reuse
36
global
java
global
Page 6
6
Example: User Interface Layer
Example: User Interface Layer: GUI Framework Package

Window
(from java.awt)
The applications need to

retain the current user's
context
View
Student
Interface
Registrar
Interface
Professor
Interface
0..* + open()
0..*+ refresh()
+ close()
+ update()
1
GUI Framework
MainApplicationForm
( from GUI Framework )
LogonForm
0..1 ( from GUI Framework )
+ start( )
+ open( )
0..1
<<interface>>
SecureUser
( from Secure Interfaces )
Secure
Interfaces
(from Security)
+ getUserId( ) : UniqueId
+ getAccess( SecureData ) : SecurityAccess
+ setAccess( SecureData, SecurityAccess)
37

Example: Middleware Layer
Example: User Interface Layer: Main Forms

<<boundary>>
MainApplicationForm
(from GUI Framework)
38
LogonForm
(from GUI Framework)
0..1
Relational
DBMS
OODBMS
<<boundary>>
MainStudentForm
1
<<Interface>>
IPersistent
(from OODBMS)
0..1
0..1
<<boundary>>
<<boundary>>
ReportCardForm
<<boundary>>
MainProfessorForm
<<boundary>>
MainRegistrarForm
1
0..1
0..*
<<boundary>>
<<boundary>>
<<boundary>>
MaintainStudentForm
(from Registrar Interface) (from Registrar Interface)
OODBMSTransaction
(from OODBMS)
0..1
0..1
<<boundary>>
<<boundary>>
SelectCoursesForm
SubmitGradesForm
(from Professor Interface) (from Professor Interface)
0..*
Database
(from OODBMS)
39
RDBMSTransaction
(from RelationalDBMS)
<<utility>>
sql
(from RelationalDBMS)
Objectstore
(from OODBMS)

40
Example: System Layer

Contains
Security
2 packages
<<subsystem>>
Security
Manager
Secure
Interfaces
UserSecurityContext
(from Security Manager)
SecureUser
(from Secure Interfaces)
SecureData
UniqueId
SecurityAccess

41
Page 7
7

Architectural Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architectural Design

Uploaded by

Copyright:

Available Formats

Architectural Design

Objectives: Architectural Design

OOAD Using the UML - Architectural Design, v 4.0

OOAD Using the UML - Architectural Design, v 4.0

So Where Are We?