Architecture and design

By,
Ilakiyaselvan N
 Role of Software Architecture
• Software Architecture of a system is the structure or
structure of the system which comprise software elements,
the externally visible properties of those elements, and the
relationships among them.
Important uses that software architecture descriptions play are:
• Understanding and Communication
• Reuse
• Construction and Evolution
• Analysis
 Architecture Views

• A view describes a structure of the system.

• A view represents the system composed of types of
elements and relationships between them.

Types of views
• Module – Code structures.
• Component and Connector – Runtime structures.
• Allocation – Software & Environment co-structures.
 Components and Connector View

• Components(Data stores)
Client, Server, DB, Application
• Connectors
Bus type, DB Access, Request-Reply, pipe, RPC
 Software Architecture
• Architecture is conceptual.

• Architecture is about fundamental things.

• Architecture exists in some context.

• Architecture is high-level design

• Architecture is overall structure of the system
• Architecture is the structure, including the principles and
guidelines governing their design and evolution over
time
• Architecture is components and connectors
 Global workflow in architecture
design

synthesis architecture
context

evaluation
backlog

evaluation
requirements
results
Elements of a Architectural decision

• Issues: design issues being addressed

• Decision
• Status: e.g., pending, approved
• Assumptions: underlying assumptions
• Alternatives
• Rationale; the why of the decision taken
• Implications: e.g. need for further decisions
 IEEE model for architectural
descriptions
Miss ion

Enviro nmen t Syste m Architecture

Architecture
Sta keh olde r Description Rati onal e

Concern Vi ewpoin t Vi ew

Li brary
Vi ewpoin t Mode l
 Representing System Architecture

Logical View Implementation View

End-user Programmers
Functionality Software management

Use Case View

Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput Communication

Conceptual Physical
 Architectural style
• An architectural style defines a family of
systems in terms of few key patterns
• Set of component types
• Topological layout of components indicating
runtime relationships
• Set of semantic constraints
• Set of connectors that mediate
communication, coordination or cooperation
among components.
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
12
System Remote Procedure Call
• What is the design vocabulary - the types of
components and connectors?
• What are the allowable structural patterns?
• What is the underlying computational model?
• What are the essential invariants of the style?
• What are some common examples of its use?
• What are the advantages and disadvantages of
using that style?
• What are some of the common specializations?
Framework for describing architectural
styles
• problem: type of problem that the style
addresses. Characteristics of the reqs’s guide the
designer in his choice for a particular style.
• context: characteristics of the environment that
constrain the designer, req’s imposed by the
style.
• solution: in terms of components and connectors
(choice not independent), and control structure
(order of execution of components)
• variants
• examples
 LAYERED SYTEM
– 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
 Architecture styles for C & C View
• Pipe and filter
• Shared data style
• Client – server style
 Pipe and Filter

(source)

(pipe) (source) (sink)

Filter Filter Filter
(sink)
• The filter transforms or filters the data it receives
via the pipes with which it is connected. A filter
can have any number of input pipes and any
number of output pipes.
• The pipe is the connector that passes data from
one filter to the next. It is a directional stream of
data, that is usually implemented by a data buffer
to store all data, until the next filter has time to
process it.
• The pump or producer is the data source. It can
be a static text file, or a keyboard input device,
continuously creating new data.
• The sink or consumer is the data target. It can be
a another file, a database, or a computer screen.
 Peer-to-Peer

Similar to client-server style, but each component is both

client and server
Pure peer-to-peer style
• No central server, no central router

Hybrid peer-to-peer style

• Central server keeps information on peers and responds
to requests for that information

Examples
• File sharing applications,
• Communication and collaboration, e.g., Skype
Shared data style: Repository
Repository
Repository
 Model-View-Controller (MVC) style

Controller View
n n

Model

problem: separation of UI from application is desirable due to expected

UI adaptations
context: interactive applications with a flexible UI
solution:
– system model: UI (View and Controller Component(s)) is
decoupled from the application (Model component)
– components: collections of procedures (module)
– connectors: procedure calls
– control structure: single thread
variants: Document-View 25
 Other Familiar Architectures
• Distributed processes: Distributed systems have
developed a number of common organizations for
multi-process systems
• Domain-specific software architectures: architectures
provide an organizational structure tailored to a family
of applications, such as avionics, command and
control, or vehicle management systems.
• State transition systems: These systems are defined in
terms a set of states and a set of named transitions
that move a system from one state to another.
• Process control systems: Systems intended to provide
dynamic control of a physical environment are often
organized as process control systems
 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 27
Layered architecture + repository
Repository architecture
Repository
Repository
 Black board architecture
• Hearsay, speech understanding
• Cryptanalysis
• Threat assessment
• System design
• Curriculum design
• Linux operating system
 Hearsay: knowledge sources (views)
• Acoustics
• Phonetics
• Pronunciation
• Co-articulation
• Syntax
• Semantics
• Pragmatics
• Context
• Spectrographs*
• Phoneme triples*
 Documenting Architecture Design

• System and architecture context

• Description of architecture views
• Across views documentation
- Element catalog
- Architecture rationale
- Behavior
 Evaluating Architectures
ATAM Analysis. .
1. Collect scenarios.
2. Collect requirements or constraints.
3. Describe Architectural views.
4. Attribute – specific analysis.
5. Identify sensitivities and tradeoffs.
System Design
 Design of a system
Design process for software system has two levels:
• Module – Deciding which module(1)
• How modules should be interconnected(1)
• Internal design of the module(2), expands the system
design

1. System design or top-level design

2. Detailed design or logic design
 Design principles
• A design should clearly be verifiable, complete
and traceable.
Designers concern:
• Efficiency
• Simplicity
-Problem Partitioning and hierarchy