Transcript Analysis - University of Scranton

Design
Yaodong Bi
Introduction to Design

Purposes of Design
–
–
–
–
Acquire a good understanding of issues regarding
nonfunctional requirements and constraints
Capture requirements for individual subsystems,
interfaces, and classes for implementation
Decompose implementation work into pieces for
different development teams.
Create a seamless abstraction of the system’s
implementation so the implementation fills in the
“meat” with no changes to the structure.
Analysis Model and Design Model
ANALYSIS MODEL
 Conceptual model
 Use three conceptual
stereotypes of classes
 Few layers
 Dynamic, but not on
sequencing
 Fewer Elements
 Define a structure that is used
for shaping the system
DESIGN MODEL
 Physical model
 Use any number of physical
stereotypes of classes
 Many Layers
 Dynamic, focus on
sequencing
 More elements (1:5 ratio)
 Shape the system while trying
to preserve the analysis
structure
Artifacts of Design - Overview








Design model
Design classes
Use-case realization – design
Design subsystems
Interfaces
Architecture description (view of the design model)
Deployment model
Architecture description (view of the deployment
model)
Artifacts – Design Model

Design model
–
–
–
Describe the physical realization of use-cases by
focusing on how functional and nonfunctional
requirements and constraints impact the system
Serve as an abstraction of the system’s
implementation.
Contain design subsystems, design classes, usecase realization-design, interfaces
Artifacts – Design Classes

Design classes
–
–
–
–
–
–
A seamless abstraction of a class in implementation
A design class may be given a stereotype that can be
seamlessly mapped to a construct in the implementation
language (<<form>>, <<class model>>)
The language for coding is used to specify design classes
The visibility of operations and attributes can be mapped to
implementation directly
Methods of a design class have a straightforward mapping to
implementation of the methods
Some requirements may be postponed to implementation as
implementation requirements
Artifacts – Use-Case Realization

Use-case realization – design
–
–
–
–
Describe how a use-case is realized using design classes
and design subsystems
Each use-case realization-design can be traced back to the
use-case realization – analysis
Handle nonfunctional requirements as well as functional
requirements of the use case
Consist of




Class diagrams: participating classes and subsystems
Interaction diagrams (sequence diagram): flow of interactions
between participating objects
Textual flow-of-events description:
Implementation requirements
Artifacts – Design Subsystem

Design subsystems
–
–
–
–
–
–
Subsystems should be loosely coupled and cohesive in each
Separate design concerns
Top two levels of subsystems can be mapped directly back to
packages in analysis model
Represent large-grained components in the system’s
implementation
Represent reused software products
Represent legacy systems
Artifacts - Interfaces

Interfaces
–
–
–
–
Specify the operations provided by design classes
and subsystems
A design class (subsystems) must provide at least
one method for each operation of the interface.
Operations vs. methods: separate the specification
of a function from its implementation
Most interfaces between subsystems are
architectural significant.
Artifacts – Architecture (Design)

Architecture description (view of the design
model)
–
–
–
Subsystems, their interfaces, and dependencies
between them
Key design classes including active classes,
significant design classes.
Use-case realizations – design that realize
important and critical functionality that needs to be
implemented.
Artifacts – Deployment Model

Deployment model
–
–
–
–
–
Describe the physical distribution of the system among
computational nodes
Each node represents a computational resource
Describe how nodes are connected together (internet, intranet,
bus, etc)
May describe multiple configurations including testing and
simulation configuration
Manifest a mapping between the software architecture and the
system (hardware) architecture.
Artifacts – Architecture (Deploy.)

Architecture description (view of the
deployment model)
–
–
All aspects of the deployment model should be
shown in this description.
Include the mappings of components on nodes as
found during implementation.
Activities of Design - Overview

Architectural Design
–

Outline the design and deployment models and their
architecture.
Design Use-Cases
–
Use design classes to realize use-cases and specify
implementation requirements
Activities of Design - Overview

Design Classes
–

Create design classes that fulfill their roles in usecase realizations and the nonfunctional
requirements that apply to them.
Design Subsystems
–
Ensure loose coupling between subsystems and
ensure that they fulfill their purpose in use-case
realization
Architectural Design - Purpose

Purpose of architectural design
–
Outline the design and deployment models and their
architectures by identify the following




–
Nodes and their network connections
Subsystems and their interfaces
Architecturally significant design classes
Generic design mechanisms that handle common
requirements on persistency, distribution, performance, etc
Various reuse possibilities are considered.
Architectural Design - Deployment

Identify nodes and network configurations
–
–
–
Network configuration has a major impact on the
software architecture. (p234, Fig 9.18)
Three-tier architecture, client/server architecture
Aspects of network configuration




The processing power of each node
The connections and protocols between nodes
Characteristics of the network: bandwidth, availability, etc
Any need for redundant processing power?
Architectural Design - Subsystems

Identify subsystems and their interfaces
–
Identify application subsystems (p235, Fig 9.19)



Identify subsystems in the application-specific and applicationgeneral layers
Analysis packages may be designed as subsystems (p235 Fig
9.20)
A refinement may be needed to accommodate: (p236 Fig 9.21)
–
–
–
–
–
Part of an analysis package can be shared by others (P237 Fig 9.22)
Parts of an analysis package can be realized with reused software
An analysis package does not divide work properly
Legacy systems
Allocation to the nodes of the deployment model (p238 Fig 9.23)
Architectural Design - Subsystems
–
Identify middleware and system-software
subsystems (p238, Fig 9.24, p239, example)


–
–
Identify DBMS’s, operating systems, compiler, GUI kits
Limit the dependency on middleware and system software
Define subsystem dependencies (p241 Fig 9.26)
Identify subsystem interfaces (p242 Fig 9.27&28)


Define operations that are accessible from outside
The operations must be provided by classes or other
subsystems (recursively)
Architectural Design - Classes

Identify architecturally significant design classes
–
Identify design classes from analysis classes



–
Use analysis classes as design classes
Use relationships among analysis classes for relationships
among design classes
A design class that does not participate in any use-case
realization is unnecessary.
Identify active classes (p245 Fig 9.30)


Identify active classes based on performance concern
Identify active classes for inter-node communication
Architectural Design - Classes



Identify active classes based on requirements like deadlock
avoidance, system startup, system termination.
Active classes are outlined by considering how their
objects communicate, synchronize, and share information.
Active objects are allocated to the nodes (p245 Fig 9.30)
–
Processing power and memory of each node
– Connections between nodes, bandwidth, availability, etc

An active object is a candidate for an executable
component for implementation
Architectural Design – Generic mechanism

Identify generic design mechanisms
–
Handle common requirements like:





–
Persistency (relational DBMS or OODBMS) (p247, top)
Transparent object distribution (Java RMI, Corba) (p246)
Security features (encryption techniques)
Error detection and recovery
Transaction management
Identify generic collaborations as patterns for
multiple use cases (p247, bottom, p248 fig 9.32&33)
Design Use Cases – Purpose





Identify participating design classes
Describe design object interactions
Identity participating subsystems and
interfaces
Describe subsystem interactions
Capture implementation requirements
Design Use Cases – Design classes

Identify participating design classes
(p251 Fig 9.35)
–
–
–
Identify design classes that trace back to analysis
classes of the use case
Identify design classes that realize special
requirements of the use case
Use a class diagram to show participating design
classes for each use-case realization
Design Use Cases – Interactions

Describe design object interactions
–
–
Use a sequence diagram to describe how they interact with
each other to realize each use case
Sequence diagram (p252 Fig 9.36)




–
The use case is invoked by an actor
Each design class identified for the use case must participate in
the diagram
Each message may become the name of an operation
Use labels and flow-of-events to complement the diagram
New alternative paths may be added to handle exceptions like
time-out, erroneous inputs, error message from middleware,
system software, etc.
Design Use Cases – Subsystems

Identity participating subsystems and interfaces
–
–
–
–
Design a use case using subsystems (p254 Fig 9.37)
Identify design subsystems that trace back to analysis
packages
Identify the design classes that are used to realize special
requirements of the use case and identify those subsystems
that contain those classes
Use class diagram to identify dependencies between
packages and interfaces of packages (p254 Fig 9.37)
Design Use Cases – Sub. Interactions

Describe subsystem interactions
–
–
–

Describe how classes’ objects interact with each
other on a subsystem level (p254 Fig 9.38)
Use sequence diagrams
Qualify the message with the interface when a
subsystem provides more than one interface
Capture implementation requirements
–
Capture all requirements that should be handled in
implementation (p255 example)
Design Classes - Purpose








Outline the design classes
Identify operations
Identify attributes
Identify associations and aggregations
Identify generalizations
Describe methods
Describe states
Handling special requirements
Design Classes - Outlining

Outline the design classes
–
–
–
Designing boundary classes depends on the specific interface
technologies in use
Designing persistent entity classes generally imply using a specific
database technology, RDBMS, OODBMS, etc
Designing control classes:



–
Distribution: if the sequence is distributed among several nodes,
separate classes on different nodes may be needed
Performance: control classes may be realized by boundary and/or
entity classes
Transaction: design must encapsulate existing transaction
technologies
Design classes should be assigned trace dependencies to their
corresponding analysis classes
Design Classes - Operations

Identify operations (p258 Fig 9.40)
–
–
–
–
Identify the operations of each design class
Describe those operations in the programming language
Specify the visibility of each operation (public, private, etc)
Important inputs:




The responsibilities of the parent analysis classes
The special requirements of the parent analysis classes
The interfaces that the design class must provide
Roles the class plays in use-case realizations - design
Design Classes - Attributes

Identify attributes
–
–
–
Identify attributes for each design class
Specify the attributes in the programming language
Guidelines:



Consider the attributes of the parent analysis class
If an attribute is complicated, design it as a class
Identify associations and aggregations
–
–
Instances of associations might be used to hold references to
other objects
The number of relationships between classes should be
minimized.
Design Classes - Generalizations

Identify generalizations (p260, Fig 9.41)
–
–

Generalization should be used with the same semantics as
defined in the programming language
If the programming language does not support generalization,
use association and/or aggregation
Describe methods
–
–
–
Methods describe how operations are realized
They can be specified in natural language or pseudocode
They are generally completed during implementation
Design Classes - States

Describe states (p261 Fig 9.42)
–
–

Some objects are state-controlled – their state determines the
behavior when they receive a message
Use statechart diagram to describe state transition
Handling special requirements
–
–
–
Handle any requirements that have not been considered yet.
Handle those requirements using generic design mechanisms
Some requirements may be postponed to implementation as
implementation requirements
Design Subsystems - Purpose



Maintain the subsystem dependencies
Maintain the subsystem interfaces
Maintain the subsystem contents
Subsystems - Dependencies

Maintain the subsystem dependencies
–
–
–
–
Define dependencies when elements of one
subsystem are associated with elements of other
subsystems
Define dependencies when one subsystem uses the
interfaces provided by other subsystems
Interface dependency is better than content/element
dependencies
Minimize the dependencies to other subsystems
and/or interfaces
Subsystems - Interfaces

Maintain the subsystem interfaces
–
The operations of a subsystem’s interface must
support all the roles the subsystem plays in all usecase realizations
Subsystems - Contents

Maintain the subsystem contents
–
–
–
A subsystem must provide a correct realization of
the operations defined in its interfaces
Each interface of the subsystem must be realized by
design classes and/or subsystems (recursively)
(p264, Fig 9.45)
Collaborations among the elements of a subsystem
may be specified to show how the subsystems
interfaces are realized
Summary of Design

Design Model includes
–
–
–
–
Design subsystems and service subsystems and
their dependencies, interfaces, and contents
Design classes, including active classes, and their
operations, attributes, relationships and
implementation requirements
Use-case realization – design
Architectural view of the design model
Summary of Design

Deployment Model includes
–
–
–
Nodes, their characteristics, and connections
Initial mapping of active classes onto nodes
Architectural view of the deployment model
Summary of Design

Connection to Implementation
–
–
Design subsystems and service subsystems will be
implemented by implementation subsystems on a one-to-on
basis
Design classes will be implemented by file components that
contain source


–
–
Multiple classes may be in one single file component
Heavyweight active classes may be mapped to executables
Use-case realizations-design will be used for implementation
planning, each build may implement a set of use-case
realizations
Deployment model and network configurations will be used
when executable components are distributed to nodes.