Architectural Design
Slide Set - 10
Organized & Presented By:
Software Engineering Team CSED
TIET, Patiala
Chapter 10
Architectural Design
- Introduction
- Data design
- Software architectural styles
- Architectural design process
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Introduction
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
4
Example -Architectural Design
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
5
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
6
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
7
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
8
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Fun ction function
uses
homeowner peers
uses
uses
sensors sensors
9
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"
11
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
12
Software Architectural Styles
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
14
(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 15
System Remote Procedure Call
Data Flow Style
Validate Sort Update Report
16
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) 17
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
18
(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
19
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
20
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) 21
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
22
Data-Centered Style
Client A Client B Client C
Shared Data
Client D Client E Client F
23
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
24
(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
25
Virtual Machine Style
Program
Program Data
Instructions
Interpretation Program
Engine Internal State
26
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
27
Independent Component Style
Client A Client B
Server
Client C Client D
Peer W Peer X
Peer Y Peer Z
28
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
29
(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
30
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
32
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 consumes I/F I/F
Depends on
"Sub"ordinate systems
33
(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
34
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
35
Example Archetypes in Humanity
• Addict/Gambler • Lover/Devotee • Seeker/Wanderer
• Amateur • Martyr • Servant/Slave
• Beggar • Mediator • Storyteller
• Clown • Mentor/Teacher • Student
• Companion • Messiah/Savior
• Trickster/Thief
• Damsel in distress • Monk/Nun
• Destroyer • Mother • Vampire
• Detective • Mystic/Hermit • Victim
• Don Juan • Networker • Virgin
• Drunk • Pioneer • Visionary/Prophet
• Engineer • Poet • Warrior/Soldier
• Father • Priest/Minister
• Gossip • Prince
• Guide
• Prostitute
• Healer
• Hero • Queen
• Judge • Rebel/Pirate
• King • Saboteur
• Knight • Samaritan
• Liberator/Rescuer • Scribe/Journalist
36
(Source: [Link]
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 Component)
37
Archetypes – their attributes
38
Archetypes – their methods
39
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
40
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
41
Software Architecture Patterns
Software Architecture…
- Captures the gross structure of a system
- How it is composed of interacting parts
- How the interactions take place
- Key properties of the parts
- Provides a way of analysing systems at a high
level of abstraction !
- Illuminates top-level design decisions
Software Architecture Patterns
• Architectural pattern are software patterns that offer well-
established solutions to architectural problems in software
engineering.
• It gives description of the elements and relation type
together with a set of constraints on how they may be used.
• An architectural pattern expresses a fundamental structural
organization schema for a software system, which consists
of subsystems, their responsibilities and interrelations.
• In comparison to design patterns, architectural patterns are
larger in scale.
Typical architectural patterns (styles)
- How can I integrate multiple applications so that they
work together and can exchange information?
Integration styles for (enterprise) messaging
File Transfer
Shared Database
Remote Procedure
Messaging
Pipes and filters
The Pipes and Filters architectural pattern [style]
provides a structure for systems that process a
stream of data.
Each processing step is encapsulated in a filter
component.
Data is passed through pipes between adjacent
filters.
Recombining filters allows you to build families of
related systems.
Example: apache cacoon’s pipes & xslt filters
Tiered architecture (layering)
2 - tier architecture (traditional client-server)
A two-way interaction in a client/server environment,
in which the user interface is stored in the client and
the data are stored in the server. The application logic
can be in either the client or the server.
3 tier architecture
Model-view-controller (1)
The MVC paradigm is a way of breaking an
application, or even just a piece of an
application's interface, into three parts:
➢ the model, the view, and the controller.
MVC was originally developed to map the
traditional input, processing, output roles into
the GUI realm:
Input → Processing → Output
Controller → Model → View
Model-view-controller (2)
The pattern isolates business logic from input and
presentation, permitting independent development,
testing and maintenance of each.
