Architectural Analysis
These slides are derived from IBM/Rational slides from
courses on UML and object-oriented design and analysis.
Copyright to the original slides resides with
IBM/Rational. They are used here, in this course, under
password protection limited to students enrolled in the
course, with permission of the owners, but are not to be
published or further distributed.
What Is Architecture?
• Software architecture encompasses a set
of significant decisions about the
organization of a software system.
– Selection of the structural elements and their
interfaces by which a system is composed
– Behavior as specified in collaborations among
those elements
– Composition of these structural and behavioral
elements into larger subsystems
– Architectural style that guides this
organization
Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational
(derived from Mary Shaw)
Architecture Constrains Design
and Implementation
• Architecture involves a set of strategic
design decisions, rules or patterns that
constrain design and construction.
Code`1
`
Implementation
Design
Architecture
Architecture decisions are the most fundamental decisions, and
changing them will have significant effects.
Software Architecture: The “4+1 View”
Model
Logical View
Implementation View
Analysts/Designers
Programmers
Structure
Software management
Use-Case View
End-user
Functionality
Process View
Deployment View
System engineering
System integrators
System topology, delivery,
Performance, scalability, throughput installation, communication
Analysis and Design Workflow
[Early
Elaboration
Iteration]
[Inception
Iteration
(Optional)]
Define
a
Candidate
Architecture
Perform
Architectural
Synthesis
Analysis
Analyze
Behavior
Refine the
Architecture
Design
Design
Components
(Optional)
Design the
Database
Analysis and Design Activity Overview
Architect
Designer
Software Architect’s Responsibilities
• The Software
Architect
leads and
coordinates
technical
activities and
artifacts.
Implementation Model
Analysis Model
Architect
Deployment Model
Design Model
Reference
Architecture
Software
Architecture
Document
Designer’s Responsibilities
• The designer
must know usecase modeling
techniques,
system
requirements,
and software
design
techniques.
Designer
Package
Use-Case
Realization
Class/Subsystems
Review: Analysis and Design Is Use-Case Driven
• Use cases defined for a system are the
basis for the entire development process.
• Benefits of use cases:
– Concise, simple, and understandable by a wide range
of stakeholders.
– Help synchronize the content of different models.
Check Balance
Customer
Withdraw Money
What Is a Use-Case Realization?
Use-Case Model
Design Model
(Traceability)
Use Case
Use-Case Realization
Sequence
Diagrams
Use Case
Communication Diagrams
Class Diagrams
Analysis and Design in an Iterative
Process
Start of iteration
Use Case A
Scenarios 1 & 2
Use Case B
Scenario 1
Use Case A
Scenario 3
Use-Case
Realization A
Use-Case
Realization A
End of iteration
Iteration n
Use-Case
Realization B
Iteration n + 1
Review
• What is the purpose of the Analysis and
Design Discipline?
• What are the input and output
artifacts?
• Name and briefly describe the 4+1
Views of Architecture.
• What is the difference between
Analysis and Design?
• What is architecture?
ARCHITECTURAL ANALYSIS
KEY CONCEPTS
Architectural Analysis in Context
Architecture
Analysis` Architect
[Early
Elaboration
Iteration]
[Inception
Iteration
(Optional)]
Define a
Candidate
Architecture
Perform
Architectural
Synthesis
Analyze
Behavior
(Optional)
Refine the
Architecture
Design
Components
Design the
Database
Architectural Analysis Overview
Supplementary
Specification
Glossary
Reference
Architecture
Software
Architecture Doc
Vision
Document
Architectural
Analysis
Project-Specific
Guidelines
Design Model
Use-Case Model
Deployment Model
Architectural Analysis Steps
• Key Concepts
• Define the High-Level Organization of
Subsystems
• Identify Analysis mechanisms
• Identify Key Abstractions
• Create Use-Case Realizations
• Checkpoints
Review: What Is a Package?
• A package is a general-purpose mechanism for
organizing elements into groups.
• It is a model element that can contain other
model elements.
UniversityArtifacts
• A package can be used:
– To organize the model under development.
– As a unit of configuration management.
– To cope with complexity.
Package Relationships: Dependency
• Packages can be related to one another using a
dependency relationship.
Dependency relationship
Client Package
• Dependency Implications
Supplier
Package
– Changes to the Supplier package may affect the
Client package.
– The Client package cannot be reused independently
because it depends on the Supplier package.
Package Diagram for 5 Layers
A package diagram shows packages only
Avoiding Circular Dependencies
A
B
A
Hierarchy
should be
acyclic
B
A
C
B
A'
C
Circular dependencies make it impossible
to reuse one package without the other.
Architectural Analysis Steps
• Key Concepts
• Define the High-Level Organization of
Subsystems
• Identify Analysis mechanisms
• Identify Key Abstractions
• Create Use-Case Realizations
• Checkpoints
Patterns and Frameworks
• Pattern
– Provides a common solution to a common
problem in a context
• Analysis/Design pattern
– Provides a solution to a narrowly-scoped
technical problem
– Provides a fragment of a solution, or a piece of
the puzzle
• Framework
– Defines the general approach to solving the
problem
– Provides a skeletal solution, whose
details may be Analysis/Design patterns
What Is a Design Pattern?
• A solution to a common design problem.
– Describes a common design problem
– Describes the solution to the problem
– Discusses the results and trade-offs of applying
the pattern
• Provides the capability to reuse successful
designs.
Template
Parameters
Pattern Name
Parameterized
Collaboration
Structural Aspect
Behavioral Aspect
What Is an Architectural
Pattern?
• An architectural pattern expresses a
fundamental structural organization schema for
software systems. It provides a set of
predefined subsystems, specifies their
responsibilities, and includes rules and guidelines
for organizing the relationships between them –
Buschman et al, “Pattern-Oriented Software Architecture
— A System of Patterns”
– Layers
– Model-view-controller (M-V-C)
– Pipes and filters
– Blackboard
EVOLVING THE ANALYSIS
MODELS INTO DESIGN
MODELS
Factoring
• Creating modules that account for
similarities and differences between
units of interest
• New classes
– Generalization
– Aggregation
• Abstracting
• Refinement
Partitions and Collaborations
• Creating “subsystems” or larger units
• Grouping units that collaborate
• May have collaboration among units or
partitions
• The more messages or contracts
between objects, the more likely they
are in the same partition
Layers
• Consider system environment
information to help evolve the analysis
model
• Model-view-controller (MVC)
architecture
• Separating application logic from user
interface logic
Typical Layering Approach
Specific
functionality
Application Subsystems
Distinct application subsystems that make up an
application — contains the value adding software
developed by the organization.
Business-Specific
Business specific — contains a number of reusable
subsystems specific to the type of business.
Middleware
System Software
General
functionality
Middleware — offers subsystems for utility
classes and platform-independent services for
distributed object computing in heterogeneous
environments and so on.
System software — contains the software for the
actual infrastructure such as operating systems,
interfaces to specific hardware, device drivers, and
so on.
Example: Layers
Application
Layer 7
Provides miscellaneous protocols for common activities
Presentation
Layer 6
Structure information and attaches semantics
Session
Layer 5
Provides dialog control and synchronization facilities
Transport
Layer 4
Breaks messages into packets and guarantees delivery
Network
Layer 3
Selects a route from send to receiver
Data Link
Layer 2
Detects and corrects errors in bit sequences
Physical
Layer 1
Transmits bits: velocity, bit-code, connection, etc.
Architectural Pattern: Layers
Equipment and
customer-specific
code
5
Processes and other
application code
4
Major abstractions,
classes, etc.
3
Application
Application
Framework
Mechanisms,
services
H/W specific code, O/S
specific code, generalpurpose code (for
example, ORB, MQS)
2
Infrastructure
1
Dennis et al. : 5 Layers
1.
2.
3.
4.
5.
Foundation
Problem Domain
Data Management
Human-Computer Interaction
Physical Architecture
Are these in a logical order?
Layering Considerations
• Level of abstraction
– Group elements at the same level of abstraction
• Separation of concerns
– Group like things together
– Separate disparate things
– Application vs. domain model elements
• Resiliency
– Loose coupling
– Concentrate on encapsulating change
– User interface, business rules, and retained data tend
to have a high potential for change
Modeling Architectural Layers
• Architectural layers can be modeled
using stereotyped packages.
• <<layer>> stereotype
<<layer>>
Package Name
What Are Stereotypes?
• Stereotypes define a new model element in
terms of another model element.
• Sometimes you need to introduce new things
that speak the language of your domain and
look like primitive building blocks.
<<stereotype>>
Class
Stereotype
Example: High-Level Organization of the Model
<<layer>>
Application
<<layer>>
Business Services
Architectural Analysis Steps
• Key Concepts
• Define the High-Level Organization of
the model
• Identify Analysis mechanisms
• Identify Key Abstractions
• Create Use-Case Realizations
• Checkpoints
What Are Architectural Mechanisms?
Required
Functionality
Implementation
Environment
“realized by client
classes using”
“constrained by”
Mechanisms
Supplementary
Specification
“responsible for”
Use-Case Model
Architect
COTS Products
Databases
IPC Technology, etc.
Architectural Mechanism Categories
• Analysis mechanisms (conceptual)
• Design mechanisms (concrete)
• Implementation mechanisms (actual)
Why Use Analysis Mechanisms?
Analysis mechanisms are used during analysis to reduce the complexity of
analysis and to improve its consistency by providing designers with a
shorthand representation for complex behavior.
Oh no! I found a group of classes that has
persistent data. How am I supposed to
design these things if I don’t even know
what database we are going to be using?
That is why we have a persistence
analysis mechanism. We don’t know
enough yet, so we can bookmark it
and come back to it later.
Sample Analysis Mechanisms
•
•
•
•
•
•
•
•
•
•
•
Persistency
Communication (IPC and RPC)
Message routing
Distribution
Transaction management
Process control and synchronization (resource
contention)
Information exchange, format conversion
Security
Error detection / handling / reporting
Redundancy
Legacy Interface
Examples of Analysis Mechanism
Characteristics
• Persistency mechanism
Granularity
Volume
Duration
Access mechanism
Access frequency (creation/deletion, update,
read)
– Reliability
–
–
–
–
–
• Inter-process Communication mechanism
–
–
–
–
Latency
Synchronicity
Message size
Protocol
Example: Analysis Mechanism
Characteristics (continued)
• Legacy interface mechanism
–
–
–
–
Latency
Duration
Access mechanism
Access frequency
–
–
–
–
Data granularity
User granularity
Security rules
Privilege types
• Security mechanism
• Others
Describing Analysis Mechanisms
• Collect all analysis
mechanisms in a list
• Draw a map of classes
to analysis mechanisms
• Identify
characteristics of
analysis mechanisms
• Model using
collaborations
Classes
Analysis
Mechanisms
Flight
Aircraft
Mission
Persistency
Communication
Schedule
Parsing
Route
Authentication
Load
Example: Course Registration
Analysis Mechanisms
Persistence
Distribution
Security
Legacy Interface
Architectural Analysis Steps
• Key Concepts
• Define the High-Level Organization of
the model
• Identify Analysis mechanisms
• Identify Key Abstractions
• Create Use-Case Realizations
• Checkpoints
What Are Key Abstractions?
• A key abstraction is a concept, normally
uncovered in Requirements, that the
system must be able to handle
• Sources for key abstractions
 Domain knowledge
 Requirements
 Glossary
 Domain Model, or the Business
Model (if one exists)
Defining Key Abstractions
• Define analysis classes
• Model analysis classes and
relationships on class diagrams
– Include a brief description of
an analysis class
• Map analysis classes to
necessary analysis
mechanisms
Example: Key Abstractions
Professor
Student
Schedule
CourseCatalog
CourseOffering
Course
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
Review: What is a Use-Case Realization?
Use-Case Model
Design Model
Use Case
Use-Case Realization
Sequence
Diagrams
Use Case
Communication Diagrams
Class Diagrams
The Value of Use-Case Realizations
• Provides traceability from Analysis and Design back
to Requirements
• The Architect creates the Use-Case Realization
Requirements
(Use-Case Model)
Use Case
Analysis & Design
(Design Model)
Use-Case
realization
Architectural Analysis Steps
 Key Concepts
 Define the High-Level Organization of the
model
 Identify Analysis mechanisms
 Identify Key Abstractions
 Create Use-Case Realizations
 Checkpoints
• General
Checkpoints
– Is the package partitioning and
layering done in a logically
consistent way?
– Have the necessary analysis
mechanisms been identified?
• Packages
– Have we provided a
comprehensive picture of the
services of the packages in
upper-level layers?
Checkpoints (continued)
• Classes
– Have the key entity classes and
their relationships been identified
and accurately modeled?
– Does the name of each class
clearly reflect the role it plays?
– Are the key abstractions/classes
and their relationships consistent
with the Business Model, Domain
Model, Requirements, Glossary,
etc.?
Review: Architectural Analysis
• What is the purpose of Architectural
Analysis?
• What is a package?
• What is a layered architecture? Give
examples of typical layers.
• What are analysis mechanisms? Give
examples.
• What key abstractions are identified during
Architectural Analysis? Why are they
identified here?
Building Package Diagrams
1. Set the context
2. Cluster classes together based on
shared relationships
3. Model clustered classes as a package
4. Identify dependency relationships
among packages
5. Place dependency relationships
between packages
DESIGN STRATEGIES
Custom Development
• Allows for meeting highly specialized
requirements
• Allows flexibility and creativity in
solving problems
• Easier to change components
• Builds personnel skills
• May tax firm’s resources
• May add significant risk
Packaged Software
Software already written
May be more efficient
May be more thoroughly tested and proven
May range from components to tools to whole
enterprise systems
• Must accept functionality provided
• May require change in how the firm does
business
• May require significant “customization” or
“workarounds”
•
•
•
•
System Integration
• The process of combining packages,
legacy systems, and new software
• Key challenge is integrating data
• Write data in the same format
• Revise existing data formats
• Develop “object wrappers”
Outsourcing
Hire external firm to create system
May have more skills
May extend existing resources
Never outsource what you don’t
understand
• Carefully choose vendor
• Prepare contract and payment style
carefully
•
•
•
•
Selecting a Design Strategy
•
•
•
•
•
Business need
In-house experience
Project skills
Project management
Time frame
Selecting a Design Strategy
Use Custom
Development when…
Use a Packaged System
when…
Use Outsourcing when…
Business Need
The business need is
unique
The business need is
common
The business need is not
core to the business
In-house Experience
In-house functional and
technical experience
exists
In-house functional
experience exists
In-house functional or
technical experience does
not exist
Project Skills
There is a desire to build
in-house skills
The skills are not strategic
The decision to outsource
is a strategic decision
Project Management
The project has a highly
skilled project manager
and a proven
methodology
The project has a project
manager who can
coordinate vendor’s
efforts
The project has a highly
skilled project manager
at the level of the
organization that
matches the scope of the
outsourcing deal
Time frame
The time frame is flexible
The time frame is short
The time frame is short
or flexible
DEVELOPING THE ACTUAL
DESIGN
The Alternative Matrix
• Combines several feasibility analyses
into one grid
• Revisits technical, economic, and
organizational feasibility
Request for Proposals
• Description of the system you propose
to be built
• Vendors, developers, service providers
respond with proposals including how
they will address needs as well as
stating cost and time requirements.
Summary
• Verifying and Validating the Analysis
Models
• Evolving the Analysis Models into Design
Models
• Packages and Package Diagrams
• Design Strategies
• Developing the Actual Design
®
IBM Software Group
Mastering Object-Oriented Analysis and Design with
UML 2.0
Module 7: Identify Design Elements
Objectives: Identify Design
Elements
• Define the purpose of Identify Design
Elements and demonstrate where in the
lifecycle it is performed
• Analyze interactions of analysis classes
and identify Design Model elements
– Design classes
– Subsystems
– Subsystem interfaces
Identify Design Elements in Context
[Early
Elaborati
on
Iteration]
Define a
Candidate
Architecture
[Inception
Iteration
(Optional)]
Perform
Architect
ural
Synthesis
Analyze
Behavior
Identify Design
ElementsArchitect
(Opti
onal)
Refine
the
Archite
cture
Design
Compo
nents
Design
the
Databa
se
Identify Design Elements Overview
Supplementary
Specifications
Software
Architecture
Document
Project Specific
Guidelines
Identify
Design
Elements
Design Model
Analysis Model
Identify Design Elements Steps
• Identify classes and subsystems
• Identify subsystem interfaces
• Update the organization of the Design
Model
• Checkpoints
Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Identify reuse opportunities
 Update the organization of the Design Model
 Checkpoints
Analysis Classes
From Analysis Classes to Design
Analysis Classes
Design Elements
Elements
<<boundary>>
<<control>>
<<subsystem>>
Subsystem
<<entity>>
<<boundary>>
<<subsystem>>
Subsystem
Many-to-Many Mapping
Identifying Design Classes
• An analysis class maps directly
to a design class if:
– It is a simple class
– It represents a single logical abstraction
• More complex analysis classes may
– Split into multiple classes
– Become a package
– Become a subsystem (discussed later)
– Any combination …
Review: Class and Package
• What is a class?
– A description of a set of objects that share
the same responsibilities, relationships,
Name
operations, attributes, and Class
semantics
• What is a package?
– A general purpose mechanism for organizing
elements into groups
– A model element which can contain other model
elements
Package
Name
Group Design Classes in Packages
• You can base your packaging criteria on
a number of different factors,
including:
– Configuration units
– Allocation of resources among development
Package C
teams
– Reflect the user types
Package B
– Represent the existing products
Package A
and services the system uses
Packaging Tips: Boundary
Classes
If it is unlikely the system interface
If it is likely the system interface will
undergo considerable changes
Boundary classes placed in
separate packages
will undergo considerable changes
Boundary classes packaged
with functionally related classes
Packaging Tips: Functionally
Related Classes
• Criteria for determining if classes are
functionally related:
– Changes in one class' behavior and/or structure
necessitate changes in another class
– Removal of one class impacts the other class
– Two objects interact with a large number of
messages or have a complex intercommunication
– A boundary class can be functionally related to a
particular entity class if the function of the
boundary class is to present the entity class
– Two classes interact with, or are affected by
changes in the same actor
Packaging Tips: Functionally Related Classes (continued)
 Criteria for determining if classes are functionally
related (continued):
 Two classes have relationships between each other
 One class creates instances of another class
 Criteria for determining when two classes should NOT
be placed in the same package:
 Two classes that are related to different actors should not be
placed in the same package
 An optional and a mandatory class should not be placed in
the same package
Package Dependencies: Package Element
PackageA
Visibility
A
+ Class A1
+ Class A2
+ Class A3
B
Only public classes
can be referenced
outside of the owning
package
PackageB
Public visibility
+ Class B1
- Class B2
Private visibility
OO Principle: Encapsulation
Package Coupling: Tips
• Packages should not
be cross-coupled
• Packages in lower
layers should not be
dependent upon
packages in upper
layers
• In general,
dependencies should
not skip layers
A
Upper
Layer
X
A
X
Lower
Layer
B
B
C
X = Coupling violation
X
Example: Registration Package
MainStudentForm
1
MainRegistrarForm
1
0..1
<<boundary>>
RegisterForCoursesForm
0..1
<<boundary>>
CloseRegistrationForm
1
1
<<control>>
RegistrationController
1
<<control>>
CloseRegistrationController
Example: University Artifacts Package:
Generalization
<<entity>>
Student
<<entity>>
FulltimeStudent
<<entity>>
ParttimeStudent
<<entity>>
ScheduleOfferingInfo
<<entity>>
PrimaryScheduleOfferingInfo
Example: University Artifacts
Package: Associations
<<entity>>
Student
<<entity>>
Schedule
1
0..*
0..*
0..*
primaryCourses
alternateCourses
0..2
0..4
<<entity>> instructor
<<entity>>
Professor
CourseOffering
0..1
0..*
0..*
1
CourseOfferingList
<<entity>>
Course
0..*
1
0..*
0..*
Prerequisites
Example: External System
Interfaces Package
<<Interface>>
IBillingSystem
<<Interface>>
ICourseCatalogSystem
Review: Subsystems and
Interfaces
• Realizes one or more interfaces that
define its
behavior
<<interface>>
Interface Name
Interface
<<subsystem>>
Subsystem Name
Realization (Canonical form)
Interface Name
<<subsystem>>
Subsystem Name
Realization (Elided form)
Subsystem
•
Subsystems and Interfaces
Subsystems : (continued)
– Completely encapsulate behavior
– Represent an independent capability with clear
interfaces (potential for reuse)
– Model multiple implementation variants
<<subsystem>>
SubsystemA
ClassA1
<<Interface>>
InterfaceK
W()
ClassA2
X()
<<subsystem>>
SubsystemB
X()
W()
ClassB1
W()
Y()
ClassB2
X()
ClassB3
Z()
Packages versus Subsystems
Subsystems
Packages
 Don’t provide
behavior
 Don’t completely
encapsulate their
contents
 May not be easily
replaced
– Provide behavior
– Completely
encapsulate their
contents
Client Class
– Are easily
replaced
Package B
ClassB1
ClassB2
<<subsystem>>
Subsystem A
Encapsulation is the key!
Subsystem Usage
• Subsystems can be used to partition the system into parts
that can be independently:
– 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
• Subsystems can also be used to:
– 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.
Identifying Subsystems Hints
• 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.
• Look at volatility.
Candidate Subsystems
• Analysis classes which may evolve into subsystems:
– Classes providing complex services and/or utilities
– Boundary classes (user interfaces and external
system interfaces)
• Existing products or external systems in the design
(e.g., components):
<<subsystem>>
Subsystem A
– Communication software
– Database access support
<<subsystem>>
Subsystem B
– Types and data structures
– Common utilities
<<subsystem>>
Subsystem C
– Application-specific products
Identifying Subsystems
“Superman
Class”
<<control>>
ClassA
X()
W()
<<Interface>>
<<subsystem>>
SubsystemA
InterfaceK
X()
W()
ClassA1
X()
ClassA2
W()
Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Identify reuse opportunities
 Update the organization of the Design Model
 Checkpoints
Identifying Interfaces
• Purpose
– To identify the interfaces of the
subsystems based on their responsibilities
• Steps
– Identify a set of candidate interfaces for
all subsystems.
– Look for similarities between interfaces.
– Define interface dependencies.
– Map the interfaces to subsystems.
– Define the behavior specified by the
interfaces.
– Package the interfaces.
Stable, well-defined interfaces are key to a stable,
resilient architecture.
Interface Guidelines
• Interface name
– Reflects role in system
• Interface description
– Conveys responsibilities
• Operation definition
– Name should reflect operation result
– Describes what operation does, all
parameters and result
• Interface documentation
– Package supporting info: sequence and
state diagrams, test plans, etc.
Example: Design Subsystems and
Analysis
Design
Interfaces
<<boundary>>
BillingSystem
<<subsystem>>
Billing System
//submit bill()
IBillingSystem
submitBill(forTuition : Double, forStude
<<boundary>>
CourseCatalogSystem
<<subsystem>>
Course Catalog System
//get course offerings()
ICourseCatalogSystem
getCourseOfferings(forSemester : Semester, forStudent : S
initialize()
All other analysis classes map directly to design classes.
Example: Analysis-Class-To-DesignElement Map
Analysis Class
Design Element
CourseCatalogSystem
CourseCatalogSystem Subsystem
BillingSystem
BillingSystem Subsystem
All other analysis classes map
directly to design classes
Modeling Convention: Subsystems and
Interfaces
<<subsystem>>
CourseCatalogSystem
ICourseCatalogSystem
+ initialize ()
+ getCourseOfferings ()
Interfaces start with an “I”
<<interface>>
<<subsystem>>
ICourseCatalogSystem
CourseCatalogSystem
+ getCourseOfferings ()
+ initialize ()
+ initialize ()
+ getCourseOfferings ()
Example: Subsystem Context:
RegistrationController
CourseCatalogSystem
Required interface
<<control>>
<<control>>
CloseRegistrationController
defined
+ // is registration open?()
+ // close registration()
0..1
+courseCatalog
1
<<Interface>>
ICourseCatalogSystem
+ getCurrentSchedule()
+ deleteCurrentSchedule()
+ submitSchedule()
+ saveSchedule()
+ getCourseOfferings()
+ setSession()
+ <<class>> new()
+ getStudent()
+ getCourseOfferings ( for Semester: Semester )
+ initialize ()
Provided
interface
defined
CourseOfferingList
<<subsystem>>
CourseCatalogSystem
+ initialize ()
+ getCourseOfferings ()
+ new()
+ add()
Example: Subsystem Context: Billing
System
<<control>>
CloseRegistrationController
+ // is registration open?()
+ // close registration()
0..1
+ Biller
1
<<Interface>>
1
IBillingSystem
<<entity>>
Student
+ submitBill(forStudent : Student, forTuition : double)
<<subsystem>>
BillingSystem
+ submitBill(forStudent : Student, forTuition : double)
Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Identify reuse opportunities
 Update the organization of the Design Model
 Checkpoints
Identification of Reuse
Opportunities
• Purpose
– To identify where existing
subsystems and/or
components can be reused
based on their interfaces.
• Steps
– Look for similar interfaces
– Modify new interfaces to
improve the fit
– Replace candidate interfaces
with existing interfaces
– Map the candidate subsystem
to existing components
Possible Reuse Opportunities
• 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
Reuse Opportunities Internal to
System
?
Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Identify reuse opportunities
 Update the organization of the Design Model
 Checkpoints
ClassB
ClassA
Y()
Z() Y()
Z()
ClassC
ClassD
Y()
Z() Y()
Z()
ClassC
ClassE
Y()
Z() Y()
Z()
Review: Typical Layering Approach
Specific
functionality
Application
Business-Specific
General
functionality
Distinct application subsystems that make up
an application — contains the value adding
software developed by the organization.
Business specific — contains a number of
reusable subsystems specific to the type of
business.
Middleware
Middleware — offers subsystems for utility classes
and platform-independent services for distributed
object computing in heterogeneous environments
and so on.
System Software
System software — contains the software for the
actual infrastructure such as operating systems,
interfaces to specific hardware, device drivers,
and so on.
Layering Considerations
• Visibility
– Dependencies only within current layer and below
• Volatility
– Upper layers affected by requirements changes
– Lower layers affected by environment changes
• Generality
– More abstract model elements in lower layers
• Number of layers
– Small system: 3-4 layers
– Complex system: 5-7 layers
Goal is to reduce coupling and to ease maintenance effort.
Layer 1
Layer 2
Layer 3
Design Elements and the
Architecture
Example: Architectural Layers
<<layer>>
Application
<<layer>>
Business
Services
<<layer>>
Middleware
Base Reuse
global
Necessary because the
Application Layer must
have access to the core
distribution mechanisms
provided with Java RMI.
Partitioning Considerations
•
•
•
•
•
•
Coupling and cohesion
User organization
Competency and/or skill areas
System distribution
Secrecy
Variability
Try to avoid cyclic dependencies.
Example: Partitioning
A
Package A
B
Package B
Example: Application Layer
<<layer>>
Application
Registration
Example: Application Layer Context
<<layer>>
Application
<<layer>>
Application
Registration
<<layer>>
Business
Services
<<layer>>
Business Services
External System
Interfaces
Security
University Artifacts
Secure Interfaces
GUI Framework
Example: Business Services Layer
<<layer>>
Business Services
<<subsystem>>
BillingSystem
<<subsystem>>
CourseCatalogSystem
External System
Interfaces
Security
ObjectStore
Support
GUI
Framework
University
Artifacts
<<subsystem>>
Security
Manager
Secure
Interfaces
Example: Business Services Layer
<<layer>>
Context
Business Services
<<subsystem>>
BillingSystem
<<subsystem>>
CourseCatalogSystem
External System
Interfaces
Security
ObjectStore
Support
GUI
Framework
University
Artifacts
<<layer>>
Middleware
com.odi
java.sql
<<subsystem>>
Security
Manager
Secure
Interfaces
<<layer>>
Business
Services
<<layer>>
Middleware
Example: Middleware Layer
<<layer>>
Middleware
com.odi
Map
java.sql
DriverManager
Session
(from com.odi) (from com.odi)
Transaction
Database
(from com.odi) (from com.odi)
Connection
(from com.odi)
(from com.odi)
Statement
ResultSet
(from com.odi)
(from com.odi)
Identify Design Elements Steps
 Identify classes and subsystems
 Identify subsystem interfaces
 Identify reuse opportunities
 Update the organization of the Design Model
 Checkpoints
Checkpoints
• General
– Does it provide a comprehensive
picture of the services of different
packages?
– Can you find similar structural
solutions that can be used more
widely in the problem domain?
• Layers
– Are there more than seven layers?
• Subsystems
– Is subsystem partitioning done in a
logically consistent way across the
entire model?
Checkpoints (continued)
• Packages
– Are the names of the packages
descriptive?
– Does the package description
match with the responsibilities
of contained classes?
– Do the package dependencies correspond to the
relationships between the contained classes?
– Do the classes contained in a package belong there
according to the criteria for the package division?
– Are there classes or collaborations of classes within
a package that can be separated into an independent
package?
– Is the ratio between the number of packages and
the number of classes appropriate?
Checkpoints (continued)
• Classes
– Does the name of each class clearly
reflect the role it plays?
– Is the class cohesive (i.e., are all parts
functionally coupled)?
– Are all class elements needed by the
use-case realizations?
– Do the role names of the aggregations and
associations accurately describe the
relationship?
– Are the multiplicities of the relationships
correct?
Review: Identify Design Elements
• What is the purpose of Identify Design
Elements?
• What is an interface?
• What is a subsystem? How does it
differ from a package?
• What is a subsystem used for, and how
do you identify them?
• What are some layering and partitioning
considerations?