Unit- 3

Design Engineering

and

Creating an Architectural Design

 Introduction
•Design is the place where quality is fostered
in software engineering. Design provides us with
representations of software that can be assessed for
quality. Design is the only way that we can accurately
translate a customer's requirements into a
finished software product or system.
•Architectural design is a process for identifying the
sub-systems making up a system and the framework
for sub-system control and communication. The
output of this design process is a description of
the software architecture. Architectural design is an
early stage of the system design process.
 Five Notable Design Quotes
• "Questions about whether design is necessary or affordable are quite beside
the point; design is inevitable. The alternative to good design is bad design,
[rather than] no design at all." Douglas Martin
• "You can use an eraser on the drafting table or a sledge hammer on the
construction site." Frank Lloyd Wright
• "The public is more familiar with bad design than good design. If is, in effect,
conditioned to prefer bad design, because that is what it lives with; the new
[design] becomes threatening, the old reassuring." Paul Rand
• "A common mistake that people make when trying to design something
completely foolproof was to underestimate the ingenuity of complete fools."
Douglas Adams
• "Every now and then go away, have a little relaxation, for when you come
back to your work your judgment will be surer. Go some distance away
because then the work appears smaller and more of it can be taken in at a
glance and a lack of harmony and proportion is more readily seen."
Leonardo DaVinci
3
 Purpose of Design
• Design is where customer requirements, business needs, and
technical considerations all come together in the formulation of
a product or system
• The design model provides detail about the software data
structures, architecture, interfaces, and components
• The design model can be assessed for quality and be improved
before code is generated and tests are conducted
– Does the design contain errors, inconsistencies, or
omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints,
schedule, and cost that have been established?

4
 Purpose of Design (continued)
• A designer must practice diversification and convergence
– The designer selects from design components, component
solutions, and knowledge available through catalogs, textbooks,
and experience
– The designer then chooses the elements from this collection that
meet the requirements defined by requirements engineering and
analysis modeling
– Convergence occurs as alternatives are considered and rejected
until one particular configuration of components is chosen
• Software design is an iterative process through which requirements
are translated into a blueprint for constructing the software
– Design begins at a high level of abstraction that can be directly
traced back to the data, functional, and behavioral requirements
– As design iteration occurs, subsequent refinement leads to design
representations at much lower levels of abstraction
5
 From Analysis Model to
Design Model
• Each element of the analysis model provides information
that is necessary to create the four design models

– The data/class design transforms analysis classes into

design classes along with the data structures required
to implement the software
– The architectural design defines the relationship
between major structural elements of the software;
architectural styles and design patterns help achieve
the requirements defined for the system
– The interface design describes how the software
communicates with systems that interoperate with it
and with humans that use it
– The component-level design transforms structural
elements of the software architecture into a
procedural description of software components

(More on next slide) 6

 From Analysis Model to
Design Model (continued)
Component-level Design

(Class-based model, Flow-oriented model

Behavioral model)

Interface Design

(Scenario-based model, Flow-oriented model

Behavioral model)

Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model, Behavioral model) 7

 Task Set for Software Design
1) Examine the information domain model and design appropriate
data structures for data objects and their attributes
2) Using the analysis model, select an architectural style (and design
patterns) that are appropriate for the software
3) Partition the analysis model into design subsystems and allocate
these subsystems within the architecture
a) Design the subsystem interfaces
b) Allocate analysis classes or functions to each subsystem
4) Create a set of design classes or components
a) Translate each analysis class description into a design class
b) Check each design class against design criteria; consider
inheritance issues
c) Define methods associated with each design class
d) Evaluate and select design patterns for a design class or
subsystem
8
(More on next slide)
 Task Set for Software Design
(continued)
5) Design any interface required with external systems or
devices
6) Design the user interface
7) Conduct component-level design
a) Specify all algorithms at a relatively low level of
abstraction
b) Refine the interface of each component
c) Define component-level data structures
d) Review each component and correct all errors
uncovered
8) Develop a deployment model
▪ Show a physical layout of the system, revealing which
components will be located where in the physical9
 Design Quality

A good design is elegant and simple

- but elegance is in the eye of the
beholder.
 Quality's Role
• The importance of design is quality
• Design is the place where quality is fostered
– Provides representations of software that can be
assessed for quality
– Accurately translates a customer's requirements into a
finished software product or system
– Serves as the foundation for all software engineering
activities that follow
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test
– Cannot be assessed for quality later in the software
process when time is short and most of the budget has
been spent
• The quality of the design is assessed through a series of
formal technical reviews or design walkthroughs
11
 Goals of a Good Design
• The design must implement all of the explicit
requirements contained in the analysis model
– It must also accommodate all of the implicit
requirements desired by the customer
• The design must be a readable and understandable guide
for those who generate code, and for those who test and
support the software
• The design should provide a complete picture of the
software, addressing the data, functional, and behavioral
domains from an implementation perspective
"Writing a clever piece of code that works is one thing; designing something
that can support a long-lasting business is quite another."
12
 Design Quality Guidelines
1) A design should exhibit an architecture that
a) Has been created using recognizable architectural
styles or patterns
b) Is composed of components that exhibit good design
characteristics
c) Can be implemented in an evolutionary fashion,
thereby facilitating implementation and testing
2) A design should be modular; that is, the software should
be logically partitioned into elements or subsystems
3) A design should contain distinct representations of data,
architecture, interfaces, and components
4) A design should lead to data structures that are
appropriate for the classes to be implemented and are
drawn from recognizable data patterns

13
 Quality Guidelines (continued)
5) A design should lead to components that exhibit
independent functional characteristics
6) A design should lead to interfaces that reduce the
complexity of connections between components and
with the external environment
7) A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis
8) A design should be represented using a notation that
effectively communicates its meaning

"Quality isn't something you lay on top of subjects and objects

like tinsel on a Christmas tree."
14
Design Concepts
 Design Concepts
• Abstraction
– Procedural abstraction – a sequence of instructions that have a specific
and limited function
– Data abstraction – a named collection of data that describes a data
object
• Architecture
– The overall structure of the software and the ways in which the
structure provides conceptual integrity for a system
– Consists of components, connectors, and the relationship between
them
• Patterns
– A design structure that solves a particular design problem within a
specific context
– It provides a description that enables a designer to determine whether
the pattern is applicable, whether the pattern can be reused, and
whether the pattern can serve as a guide for developing similar
patterns 16
 Design Concepts (continued)
• Modularity
– Separately named and addressable components (i.e., modules) that are
integrated to satisfy requirements (divide and conquer principle)
– Makes software intellectually manageable so as to grasp the control
paths, span of reference, number of variables, and overall complexity
• Information hiding
– The designing of modules so that the algorithms and local data
contained within them are inaccessible to other modules
– This enforces access constraints to both procedural (i.e.,
implementation) detail and local data structures
• Functional independence
– Modules that have a "single-minded" function and an aversion to
excessive interaction with other modules
– High cohesion – a module performs only a single task
– Low coupling – a module has the lowest amount of connection needed
with other modules
17
 Design Concepts (continued)
• Stepwise refinement
– Development of a program by successively refining levels of procedure
detail
– Complements abstraction, which enables a designer to specify procedure
and data and yet suppress low-level details
• Refactoring
– A reorganization technique that simplifies the design (or internal code
structure) of a component without changing its function or external
behavior
– Removes redundancy, unused design elements, inefficient or
unnecessary algorithms, poorly constructed or inappropriate data
structures, or any other design failures
• Design classes
– Refines the analysis classes by providing design detail that will enable the
classes to be implemented
– Creates a new set of design classes that implement a software
infrastructure to support the business solution
18
 Types of Design Classes
• User interface classes – define all abstractions necessary for human-
computer interaction (usually via metaphors of real-world objects)
• Business domain classes – refined from analysis classes; identify
attributes and services (methods) that are required to implement some
element of the business domain
• Process classes – implement business abstractions required to fully
manage the business domain classes
• Persistent classes – represent data stores (e.g., a database) that will
persist beyond the execution of the software
• System classes – implement software management and control functions
that enable the system to operate and communicate within its computing
environment and the outside world

19
 Characteristics of a Well-Formed
Design Class
• Complete and sufficient
– Contains the complete encapsulation of all attributes and methods that exist for
the class
– Contains only those methods that are sufficient to achieve the intent of the class
• Primitiveness
– Each method of a class focuses on accomplishing one service for the class
• High cohesion
– The class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities
• Low coupling
– Collaboration of the class with other classes is kept to an acceptable minimum
– Each class should have limited knowledge of other classes in other subsystems

20
The Design Model
Component-level Design

Interface Design

Architectural Design

Data/Class Design
 Dimensions of the Design Model
High

Analysis model
Abstraction Dimension

Design model

Data/Class Architectural Interface Component-level Deployment-level

Low Elements Elements Elements Elements Elements

Process Dimension (Progression)

 Introduction
• The design model can be viewed in two different dimensions
– (Horizontally) The process dimension indicates the evolution of the parts
of the design model as each design task is executed
– (Vertically) The abstraction dimension represents the level of detail as
each element of the analysis model is transformed into the design model
and then iteratively refined
• Elements of the design model use many of the same UML diagrams
used in the analysis model
– The diagrams are refined and elaborated as part of the design
– More implementation-specific detail is provided
– Emphasis is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture

23
 Introduction (continued)
• Design model elements are not always developed in a sequential
fashion
– Preliminary architectural design sets the stage
– It is followed by interface design and component-level design, which
often occur in parallel
• The design model has the following layered elements
– Data/class design
– Architectural design
Component-level Design
– Interface design
– Component-level design
Interface Design
• A fifth element that follows all of
the others is deployment-level design Architectural Design

Data/Class Design

24
 Design Elements
• Data/class design
– Creates a model of data and objects that is represented at a high level of
abstraction
• Architectural design
– Depicts the overall layout of the software
• Interface design
– Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
– Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
– Describes the internal detail of each software component by way of data
structure definitions, algorithms, and interface specifications
• Deployment-level design elements
– Indicates how software functionality and subsystems will be allocated within
the physical computing environment that will support the software

25
 Pattern-based Software Design
• Mature engineering disciplines make use of thousands of design patterns for such
things as buildings, highways, electrical circuits, factories, weapon systems, vehicles,
and computers
• Design patterns also serve a purpose in software engineering
• Architectural patterns
– Define the overall structure of software
– Indicate the relationships among subsystems and software components
– Define the rules for specifying relationships among software elements
• Design patterns
– Address a specific element of the design such as an aggregation of components or solve
some design problem, relationships among components, or the mechanisms for effecting
inter-component communication
– Consist of creational, structural, and behavioral patterns
• Coding patterns
– Describe language-specific patterns that implement an algorithmic or data structure
element of a component, a specific interface protocol, or a mechanism for communication
among components

26
☺
 Architectural Design
- Introduction
- Data design
- Software architectural styles
- Architectural design process
- Assessing alternative architectural designs
 Introduction
Architectural design is a process for identifying
the sub-systems making up a system and the
framework for sub-system control and
communication. The output of this design process is
a description of the software architecture.
Architectural design is an early stage of the system
design process. It represents the link between
specification and design processes and is often
carried out in parallel with some specification
activities. It involves identifying major system
components and their communications.
 Definitions
• The software architecture of a program or computing system is the structure
or structures of the system which comprise
– The software components
– The externally visible properties of those components
– The relationships among the components
• Software architectural design represents the structure of the data and
program components that are required to build a computer-based system
• An architectural design model is transferable
– It can be applied to the design of other systems
– It represents a set of abstractions that enable software engineers to describe
architecture in predictable ways
 Architectural Design Process
• Basic Steps
– Creation of the data design
– Derivation of one or more representations of the architectural structure of the
system
– Analysis of alternative architectural styles to choose the one best suited to
customer requirements and quality attributes
– Elaboration of the architecture based on the selected architectural style
• A database designer creates the data architecture for a system to represent
the data components
• A system architect selects an appropriate architectural style derived during
system engineering and software requirements analysis
 Emphasis on Software Components

• A software architecture enables a software engineer to

– Analyze the effectiveness of the design in meeting its stated
requirements
– Consider architectural alternatives at a stage when making design
changes is still relatively easy
– Reduce the risks associated with the construction of the software
• Focus is placed on the software component
– A program module
– An object-oriented class
– A database
– Middleware
 Importance of Software Architecture
• Representations of software architecture are an enabler for
communication between all stakeholders interested in the development of
a computer-based system
• The software architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows and, as
important, on the ultimate success of the system as an operational entity
• The software architecture constitutes a relatively small, intellectually
graspable model of how the system is structured and how its components
work together
Software Architecture Diagram
Data Design
 Purpose of Data Design
• Data design translates data objects defined as part of the analysis model
into
– Data structures at the software component level
– A possible database architecture at the application level
• It focuses on the representation of data structures that are directly
accessed by one or more software components
• The challenge is to store and retrieve the data in such way that useful
information can be extracted from the data environment
• "Data quality is the difference between a data warehouse and a data
garbage dump"
 Data Design Principles
• The systematic analysis principles that are applied to function and
behavior should also be applied to data
• All data structures and the operations to be performed on each one
should be identified
• A mechanism for defining the content of each data object should be
established and used to define both data and the operations applied to it
• Low-level data design decisions should be deferred until late in the design
process
• The representation of a data structure should be known only to those
modules that must make direct use of the data contained within the
structure
• A library of useful data structures and the operations that may be applied
to them should be developed
• A software programming language should support the specification and
realization of abstract data types
Software Architectural Styles
Common Architectural Styles
of American Homes
 Common Architectural Styles
of American Homes
A-Frame Four square Ranch

Bungalow Georgian Split level

Cape Cod Greek Revival Tidewater

Colonial Prairie Style Tudor

Federal Pueblo Victorian

 Software Architectural Style
• The software that is built for computer-based systems exhibit one of
many architectural styles
• Each style describes a system category that encompasses
– A set of component types that perform a function required by the system
– A set of connectors (subroutine call, remote procedure call, data stream,
socket) that enable communication, coordination, and cooperation
among components
– Semantic constraints that define how components can be integrated to
form the system
– A topological layout of the components indicating their runtime
interrelationships

(Source: Bass, Clements, and Kazman. Software Architecture in Practice. Addison-Wesley, 2003)
A Taxonomy of Architectural Styles
Independent Components

Communicating Event Systems

Processes

Implicit Explicit
Client/Server Peer-to-Peer
Invocation Invocation

Data Flow Data-Centered

Batch Sequential Pipe and Repository Blackboard

Filter

Virtual Machine Call and Return

Main Program Object

and Subroutine Layered Oriented
Interpreter Rule-Based
System Remote Procedure Call
 Data Flow Style

Validate Sort Update Report

 Data Flow Style
• Has the goal of modifiability
• Characterized by viewing the system as a series of transformations on
successive pieces of input data
• Data enters the system and then flows through the components one at a
time until they are assigned to output or a data store
• Batch sequential style
– The processing steps are independent components
– Each step runs to completion before the next step begins
• Pipe-and-filter style
– Emphasizes the incremental transformation of data by successive components
– The filters incrementally transform the data (entering and exiting via streams)
– The filters use little contextual information and retain no state between
instantiations
– The pipes are stateless and simply exist to move data between filters

(More on next slide)

 Data Flow Style (continued)
• Advantages
– Has a simplistic design in the limited ways in which the components interact
with the environment
– Consists of no more and no less than the construction of its parts
– Simplifies reuse and maintenance
– Is easily made into a parallel or distributed execution in order to enhance system
performance
• Disadvantages
– Implicitly encourages a batch mentality so interactive applications are difficult to
create in this style
– Ordering of filters can be difficult to maintain so the filters cannot cooperatively
interact to solve a problem
– Exhibits poor performance
• Filters typically force the least common denominator of data representation (usually
ASCII stream)
• Filter may need unlimited buffers if they cannot start producing output until they
receive all of the input
• Each filter operates as a separate process or procedure call, thus incurring overhead in
set-up and take-down time

(More on next slide)

 Data Flow Style (continued)
• Use this style when it makes sense to view your system as one that
produces a well-defined easily identified output
– The output should be a direct result of sequentially transforming a well-
defined easily identified input in a time-independent fashion
 Call-and-Return Style
Main module

Subroutine B
Subroutine A

Subroutine A-1 Subroutine A-2

Application layer Class V Class W

Transport layer

Network layer Class X Class Y

Data layer
Class Z
Physical layer
 Call-and-Return Style
• Has the goal of modifiability and scalability
• Has been the dominant architecture since the start of software
development
• Main program and subroutine style
– Decomposes a program hierarchically into small pieces (i.e., modules)
– Typically has a single thread of control that travels through various components
in the hierarchy
• Remote procedure call style
– Consists of main program and subroutine style of system that is decomposed
into parts that are resident on computers connected via a network
– Strives to increase performance by distributing the computations and taking
advantage of multiple processors
– Incurs a finite communication time between subroutine call and response

(More on next slide)

 Call-and-Return Style (continued)
• Object-oriented or abstract data type system
– Emphasizes the bundling of data and how to manipulate and access data
– Keeps the internal data representation hidden and allows access to the object only
through provided operations
– Permits inheritance and polymorphism
• Layered system
– Assigns components to layers in order to control inter-component interaction
– Only allows a layer to communicate with its immediate neighbor
– Assigns core functionality such as hardware interfacing or system kernel operations to
the lowest layer
– Builds each successive layer on its predecessor, hiding the lower layer and providing
services for the upper layer
– Is compromised by layer bridging that skips one or more layers to improve runtime
performance
• Use this style when the order of computation is fixed, when interfaces are specific,
and when components can make no useful progress while awaiting the results of
request to other components
 Data-Centered Style
Client A Client B Client C

Shared Data

Client D Client E Client F

 Data-Centered Style (continued)
• Has the goal of integrating the data
• Refers to systems in which the access and update of a widely accessed data
store occur
• A client runs on an independent thread of control
• The shared data may be a passive repository or an active blackboard
– A blackboard notifies subscriber clients when changes occur in data of interest
• At its heart is a centralized data store that communicates with a number of
clients
• Clients are relatively independent of each other so they can be added,
removed, or changed in functionality
• The data store is independent of the clients

(More on next slide)

 Data-Centered Style (continued)
• Use this style when a central issue is the storage, representation,
management, and retrieval of a large amount of related persistent data
• Note that this style becomes client/server if the clients are modeled as
independent processes
Virtual Machine Style

Program
Program Data
Instructions

Interpretation Program
Engine Internal State
 Virtual Machine Style
• Has the goal of portability
• Software systems in this style simulate some functionality that is not
native to the hardware and/or software on which it is implemented
– Can simulate and test hardware platforms that have not yet been built
– Can simulate "disaster modes" as in flight simulators or safety-critical systems
that would be too complex, costly, or dangerous to test with the real system
• Examples include interpreters, rule-based systems, and command
language processors
• Interpreters
– Add flexibility through the ability to interrupt and query the program and
introduce modifications at runtime
– Incur a performance cost because of the additional computation involved in
execution
• Use this style when you have developed a program or some form of
computation but have no make of machine to directly run it on
Independent Component Style
Client A Client B

Server

Client C Client D

Peer W Peer X

Peer Y Peer Z
 Independent Component Style
• Consists of a number of independent processes that communicate
through messages
• Has the goal of modifiability by decoupling various portions of the
computation
• Sends data between processes but the processes do not directly control
each other
• Event systems style
– Individual components announce data that they wish to share (publish) with
their environment
– The other components may register an interest in this class of data (subscribe)
– Makes use of a message component that manages communication among the
other components
– Components publish information by sending it to the message manager
– When the data appears, the subscriber is invoked and receives the data
– Decouples component implementation from knowing the names and
locations of other components

(More on next slide)

 Independent Component Style
(continued)
• Communicating processes style
– These are classic multi-processing systems
– Well-know subtypes are client/server and peer-to-peer
– The goal is to achieve scalability
– A server exists to provide data and/or services to one or more clients
– The client originates a call to the server which services the request
• Use this style when
– Your system has a graphical user interface
– Your system runs on a multiprocessor platform
– Your system can be structured as a set of loosely coupled components
– Performance tuning by reallocating work among processes is important
– Message passing is sufficient as an interaction mechanism among
components
 Heterogeneous Styles
• Systems are seldom built from a single architectural style
• Three kinds of heterogeneity
– Locationally heterogeneous
• The drawing of the architecture reveals different styles in different areas (e.g., a
branch of a call-and-return system may have a shared repository)
– Hierarchically heterogeneous
• A component of one style, when decomposed, is structured according to the rules
of a different style
– Simultaneously heterogeneous
• Two or more architectural styles may both be appropriate descriptions for the style
used by a computer-based system
Architectural Design Process
 Architectural Design Steps

1) Represent the system in context

2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system

"A doctor can bury his mistakes, but an architect can only advise
his client to plant vines." Frank Lloyd Wright
 1. Represent the System in Context
"Super"ordinate systems

Used by
I/F I/F I/F
Uses

Target system
Produces or
Produces or consumes Peers
Actors I/F I/F
consumes
Depends on

"Sub"ordinate systems

(More on next slide)

 1. Represent the System in Context
(continued)
• Use an architectural context diagram (ACD) that shows
– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from/by other systems
• An ACD models the manner in which software interacts with entities external to
its boundaries
• An ACD identifies systems that interoperate with the target system
– Super-ordinate systems
• Use target system as part of some higher level processing scheme
– Sub-ordinate systems
• Used by target system and provide necessary data or processing
– Peer-level systems
• Interact on a peer-to-peer basis with target system to produce or consume data
– Actors
• People or devices that interact with target system to produce or consume data
 2. Define Archetypes
• Archetypes indicate the important abstractions within the problem domain
(i.e., they model information)
• An archetype is a class or pattern that represents a core abstraction that is
critical to the design of an architecture for the target system
• It is also an abstraction from a class of programs with a common structure
and includes class-specific design strategies and a collection of example
program designs and implementations
• Only a relatively small set of archetypes is required in order to design even
relatively complex systems
• The target system architecture is composed of these archetypes
– They represent stable elements of the architecture
– They may be instantiated in different ways based on the behavior of the system
– They can be derived from the analysis class model
• The archetypes and their relationships can be illustrated in a UML class
diagram
 Example Archetypes in Humanity
• Addict/Gambler • Lover/Devotee • Seeker/Wanderer
• Amateur • Martyr • Servant/Slave
• Beggar • Mediator
• Clown • Mentor/Teacher • Storyteller
• Companion • Messiah/Savior • Student
• Damsel in distress • Monk/Nun • Trickster/Thief
• Destroyer • Mother • Vampire
• Detective • Mystic/Hermit
• Victim
• Don Juan • Networker
• Drunk • Pioneer • Virgin
• Engineer • Poet • Visionary/Prophet
• Father • Priest/Minister • Warrior/Soldier
• Gossip • Prince
• Guide
• Prostitute
• Healer
• Hero • Queen
• Judge • Rebel/Pirate
• King • Saboteur
• Knight • Samaritan
• Liberator/Rescuer • Scribe/Journalist

(Source: http://www.myss.com/ThreeArchs.asp)
 Example Archetypes in Software
Architecture
• Node • Moment-Interval
• Detector/Sensor • Role
• Indicator • Description
• Controller • Party, Place, or Thing
• Manager

(Source: Pressman) (Source: Archetypes, Color, and the Domain Neutral Componen
Archetypes – their attributes
Archetypes – their methods
3. Refine the Architecture into Components
• Based on the archetypes, the architectural designer refines the software
architecture into components to illustrate the overall structure and
architectural style of the system
• These components are derived from various sources
– The application domain provides application components, which are the domain
classes in the analysis model that represent entities in the real world
– The infrastructure domain provides design components (i.e., design classes) that
enable application components but have no business connection
• Examples: memory management, communication, database, and task management
– The interfaces in the ACD imply one or more specialized components that
process the data that flow across the interface
• A UML class diagram can represent the classes of the refined architecture
and their relationships
 4. Describe Instantiations of the System
• An actual instantiation of the architecture is developed by applying it to a
specific problem
• This demonstrates that the architectural structure, style and components
are appropriate
• A UML component diagram can be used to represent this instantiation
Assessing Alternative Architectural
Designs
 Various Assessment Approaches
A. Ask a set of questions that provide the designer with an early
assessment of design quality and lay the foundation for more detailed
analysis of the architecture
• Assess the control in an architectural design (see next slide)
• Assess the data in an architectural design (see upcoming slide)
B. Apply the architecture trade-off analysis method
C. Assess the architectural complexity
 Approach A: Questions -- Assessing
Control in an Architectural Design
• How is control managed within the architecture?
• Does a distinct control hierarchy exist, and if so, what is the role of
components within this control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• What is the control topology (i.e., the geometric form that the control
takes)?
• Is control synchronized or do components operate asynchronously?
 Approach A: Questions -- Assessing Data in
an Architectural Design
• How are data communicated between components?
• Is the flow of data continuous, or are data objects passed to the system
sporadically?
• What is the mode of data transfer (i.e., are data passed from one component
to another or are data available globally to be shared among system
components)
• Do data components exist (e.g., a repository or blackboard), and if so, what
is their role?
• How do functional components interact with data components?
• Are data components passive or active (i.e., does the data component
actively interact with other components in the system)?
• How do data and control interact within the system?
 Approach B: Architecture Trade-off
Analysis Method
1) Collect scenarios representing the system from the user's point of view
2) Elicit requirements, constraints, and environment description to be certain all
stakeholder concerns have been addressed
3) Describe the candidate architectural styles that have been chosen to address the
scenarios and requirements
4) Evaluate quality attributes by considering each attribute in isolation (reliability,
performance, security, maintainability, flexibility, testability, portability, reusability,
and interoperability)
5) Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style by making small changes in the architecture
6) Critique the application of the candidate architectural styles (from step #3) using
the sensitivity analysis conducted in step #5

Based on the results of steps 5 and 6, some architecture alternatives may

be eliminated. Others will be modified and represented in more detail until
a target architecture is selected
 Approach C: Assessing Architectural
Complexity
• The overall complexity of a software architecture can be assessed by
considering the dependencies between components within the
architecture
• These dependencies are driven by the information and control flow
within a system
• Three types of dependencies
– Sharing dependency U→→V
• Represents a dependency relationship among consumers who use the same
source or producer
– Flow dependency →U→V→
• Represents a dependency relationship between producers and consumers of
resources
– Constrained dependency U “XOR” V
• Represents constraints on the relative flow of control among a set of activities
such as mutual exclusion between two components
 Summary
• A software architecture provides a uniform, high-level view of the system
to be built
• It depicts
– The structure and organization of the software components
– The properties of the components
– The relationships (i.e., connections) among the components
• Software components include program modules and the various data
representations that are manipulated by the program
• The choice of a software architecture highlights early design decisions
and provides a mechanism for considering the benefits of alternative
architectures
• Data design translates the data objects defined in the analysis model into
data structures that reside in the software

(More on next slide)

 Summary (continued)
• A number of different architectural styles are available that encompass a
set of component types, a set of connectors, semantic constraints, and a
topological layout
• The architectural design process contains four distinct steps
1) Represent the system in context
2) Identify the component archetypes (the top-level abstractions)
3) Identify and refine components within the context of various architectural
styles
4) Formulate a specific instantiation of the architecture
• Once a software architecture has been derived, it is elaborated and then
analyzed against quality criteria

☺
Building Blocks of UML
 OOAD with UML
Building a Building software
house

Design and OOAD

layout

Blueprint UML

Actual Coding
construction
 A conceptual model of the UML

To understand the UML, you need to form a conceptual

model of the language, and this requires learning
three major elements:
 The UML’s basic building blocks.
 The rules that dictate how these building blocks put
together.
 Some mechanisms that apply throughout the UML.
 Building Blocks of UML
• Things – abstractions that are first class citizen
in a model
• Relationships - tie things together
• Diagrams - group interesting collections of
things
 Things in the UML
There are four kinds of things in the UML:
1.Structural things
2.Behavioral things
3.Grouping things
4.Annotational things
 Structural Things
• Static part of a model, representing elements
that are either conceptual or physical
– Classes
– Interfaces
– Collaborations
– Use cases
– Active classes
– Components
– Nodes
• class
– a class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics
– A class implements one or more interfaces.
• interface
– a collection of operations that specify a service of a class or component
– describes the externally visible behavior of that element
– defines a set of operation specifications but never a set of operation
implementations
– attached to class or component that realizes the interface
• Collaboration
– defines an interaction and is a society of roles and other elements that work
together to provide some cooperative behavior
– Collaborations have structural, as well as behavioral dimensions
– A given class may participate in several collaborations
– therefore represent the implementation of patterns that make up a system
 Class Name

Attributes Figure 2: Interfaces

Operations

Figure 3: Collaborations
Figure 1: Classes
• use case - a description of set of sequence of actions that a system
performs that yields an observable result of value to a particular
actor. A use case is used to structure the behavioral things in a
model. A use case is realized by a collaboration.
• active class - a class whose objects own one or more processes or
threads and therefore can initiate control activity. An active class is
just like a class except that its objects represent elements whose
behavior is concurrent with other elements.
• component - a physical and replaceable part of a system that
conforms to and provides the realization of a set of interfaces.
Represents the physical packaging of otherwise logical elements,
such as classes, interfaces, and collaborations.
• node - a physical element that exists at run time and represents a
computational resource, having at least some memory and, often,
processing capability. A set of components may reside on a node
and may also migrate from node to node.
Figure 3: Use Cases
Figure 4: Active Classes

Figure 5: Components Figure 6: Nodes

 Behavioral Things
• Behavioral things are the dynamic parts of UML
models.
• These are the verbs of a model, representing
behavior over time and space.
• Two primary kinds of behavioral things.
– Interaction (exchange of set of messages among a set of
objects)(includes message, links, action sequence)
– State Machine (specifies the sequences of states an object or an
interaction goes through during its lifetime in response to
events, together with its responses to those events.)(includes
states, transitions, events, activities)
* Shown in the figure 7 and 8
 Grouping Things
• Grouping things are the organizational parts
of UML models. These are the boxes into
which a model can be decomposed.
• There is one primary kind of grouping.
•– Packages(mechanism for organizing elements
into groups) (a package is purely conceptual
meaning that it exists only at development time)
* Shown in the figure 9
 Annotational Things
• Annotational things are the explanatory parts
of UML models. These are the comments you
may apply to describe, illuminate, and remark
about any element in a model.
• There is one primary kind of annotational
things.
– Note (a symbol for rendering constraints and comments
attached to an element or a collection of elements)
* Shown in the figure 10
Figure 7: Messages

Figure 9: Packages

Figure 8: States

Figure 10: Notes

Relationships in the UML
 Relationships in the UML
• There are four kinds of relationships in the UML:
1. Dependency (a semantic relationship between two things in
which a change to one thing may affect the semantics of the other
thing)
2. Association (a structural relationship that describes a set of links, a
link being a connection among objects)
3. Generalization (a specialization / generalization relationship in
which objects of the specialized element (the child) are substitutable
for objects of the generalized element (the parent))
4. Realization (a semantic relationship between classifiers, wherein
one classifier specifies a contract that another classifier guarantees to
carry out) (between interfaces and the classes or components and
between use cases and the collaborations)
 Relationships in the UML

1. Dependencies: rendered as a
dashed line, possibly directed, and
occasionally including a label

2. Associations: rendered as a solid line,

possibly directed, occasionally including a label,
and often containing other adornments, such as
multiplicity and role names

3.Generalizations: rendered as a
solid line with a hollow arrowhead pointing to
the parent

4.Realization: rendered as a cross

between a generalization and a dependency
relationship
 Diagrams in the UML
• graphical presentation of a set of elements,
rendered as a connected graph of vertices
(things) and arcs (relationships).
• a projection into a system
• The same element may appear in all diagrams,
only a few diagrams (the most common case), or
in no diagrams at all (a very rare case)
 Diagrams in the UML
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram Interaction
5. Collaboration diagram diagrams
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
 1. Class Diagram
•A class diagram shows a set of
classes, interfaces, and collaborations
and their relationships.
• Most common diagram found
in modeling object- oriented
systems.
• Address the static design view of a system.
• Class diagrams that include active classes
address the static process view of a system.
 2. Object Diagram
• An object diagram shows a set of objects and
their relationships.
• Object diagrams represent static snapshots of
instances of the things found in class diagrams.
• address the static design view or static process
view of a system as do class diagrams, but from
the perspective of real or prototypical cases.
 3. Use Case Diagram
• A use case diagram shows a set of use cases
and actors (a special kind of class) and their
relationships.
• address the static use case view of a system.
• especially important in organizing and
modeling the behaviors of a system.
 Interaction Diagrams
• Both sequence diagrams and collaboration
diagrams are kinds of interaction diagrams.
• Arc shows an interaction, consisting of a set of
objects and their relationships, including the
messages that may be dispatched among
them.
• Interaction diagrams address the dynamic
view of a system
 4. Sequence Diagram
• A sequence diagram is an interaction diagram
that emphasizes the time-ordering of messages.
 5. Collaboration Diagram
• collaboration diagram is an interaction diagram
that emphasizes the structural organization of
the objects that send and receive messages.
• Note: Sequence diagrams and collaboration
diagrams are isomorphic, meaning that you can
take one and transform it into the other.
 6. Statechart Diagram
• A statechart diagram shows a state machine,
consisting of states, transitions, events and
activities.
• Statechart diagrams address the dynamic view of a
system.
• especially important in modeling the behavior of an
interface, class, or collaboration and emphasize the
event-ordered behavior of an object, which is
especially useful in modeling reactive systems.
 7. Activity Diagram
• An activity diagram is a special kind of a
statechart diagram that shows the flow from
activity to activity within a system.
• Activity diagrams address the dynamic view of
a system.
• They are especially important in modeling the
function of a system and emphasize the flow
of control among objects
 8. Component Diagram
• A component diagram shows the organizations and
dependencies among a set of components.
• Component diagrams address the static
implementation view of a system.
• They are related to class diagrams in that a
component typically maps to one or more classes,
interfaces, or collaborations.
 9. Deployment Diagram
• A deployment diagram shows the configuration of
run-time processing nodes and the components that
live on them.
• Deployment diagrams address the static deployment
view of an architecture.
• They are related to component diagrams in that a
node typically encloses one or more components.