Transcript Software Engineering II-

Why Architecture?
The architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:
(1) analyze the effectiveness of the design in meeting its stated
requirements,
(2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and
(3) reduce the risks associated with the construction of the
software.
Why is Architecture Important?
• Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in the
development of a computer-based system.
• The 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.
• Architecture “constitutes a relatively small, intellectually graspable
model of how the system is structured and how its components work
together”.
Why is Architecture Important?
• It is important to start reasoning about the system as early as
possible
• The architectural specification helps us see a match between
the requirements a certain set of constraints before identifying
concrete solutions
Architecture definition
Perry, Wolf:
• Elements
• processing elements (data transformer)
• data elements (data)
• connecting elements (glue that holds pieces together)
• Form
• weighted properties and relationships
• constraints for choice of elements and placement
• Rationale
• motivation for choices
Architecture vs design
Architecture – concerned with the selection of architectural
elements, their interactions, and the constraints on those elements
and interactions to provide a framework in which to satisfy the
requirements and serve as basis for the design
Design - concerned with the modularization and detailed
interfaces and procedures, and the data types needed to support the
architecture and to satisfy the requirements
Uses for Architectural specification
• Prescribe the architectural constraints to the desired level
(specify the constraints and their generalization level instead of
specific solutions)
• Separate aesthetics from engineering (load-bearing vs
decoration)
• Express different aspects of the architecture in an appropriate
manner
• Perform dependency and consistency analysis (requirements,
architecture, design must be consistent, their interdependencies
specified)
Architectural style
• Architecture can be thought of as a formal arrangement of
architectural elements; a specific architecture
• Style – less constrained, less complete; a template architecture
Architectural erosion and drift
• Evolution and customization – major contributors to software
cost
• Due to problems with architecture:
• erosion – violations of architectural constraints, leads to
disasters
• drift – lack of coherence and clarity of form, leads to
inadaptability
Taxonomy of styles
Shaw and Garlan[‘96] define architecture in terms of design elements
and the constraints on the elements, but differ from Perry and Wolf in that
the elements are:
• components and connectors, described in some idiom specific manner.
Idioms are represented as topologies of the component/connector
vocabulary, along with constraints on how the topologies can be arranged.
Shaw and Garlan have developed a taxonomy based on
case studies of actual systems. The eventual goal is to
develop a handbook for the selection and application of
appropriate styles.
Shaw & Garlan Taxonomy
Common Architectural Styles
Data Flow style:
• Batch Sequential - each step runs to completion; old style data
processing architecture
• Pipes and Filters - linked stream transformers
Each filter is a stand-alone process that incrementally transforms its
input streams into output streams.
Call and Return style:
• Main program and subroutines - traditional functional decomposition,
a controlling main program determines flow of control
• Hierarchical layers - well defined interfaces and information
hiding (e.g., kernels, shells)
Object-oriented systems - abstract data types with inheritance;
objects only interact through defined interfaces
Common Architectural Styles
Independent Components style:
• Communicating processes - asynchronous message passing
• Event systems - implicit invocation; rather than invoking a procedure
directly, a component generates a request for service event that is
broadcast
Virtual Machines style:
• Interpreters - input driven state machine
• Rule-based systems - rule based interpreter
Data-centered systems:
• Transactional Database Systems - central data repository/query driven
• Blackboards - central shared representation/opportunistic execution
Common Architectural Styles
Distributed Processes and Client/Servers
Processes connected by a specific communication topology
(ring, star, etc.) along with protocols for communication.
Servers don't know their clients beforehand, while clients can
dynamically chose among servers. Client-server interactions can be
• direct - where the client activates the server directly (for example by
calling the server as a procedure)
• polled - where the client indicates that it would like a service and
the server periodically checks to see if any client requests are pending.
• interrupt driven - where the server is dormant, and the client
generates an event that eventually activates the server.
Common Architectural Styles
Model, View, Controller
Typical paradigm of user interface design. The underlying element is
modeled by some object. Various representations of this object are
presented through views. Alterations of the state of the object are
achieved through controllers.
State Transition Systems
• Standard design of many reactive systems.
Process Control Systems
• Dynamic control via feedback loops.
Heterogeneous
Process control architecture
Inputs
(monitor
pressure &
temperature)
Control
Equations
Control
Feedback
Outputs
(set control
valves and
pumping rates)
Combining styles
Systems are not usually developed according to a single,
consistent idiom. Variations may occur at different levels
of refinement/abstraction.
Reference Architectures
Architectural idioms need not be constrained to usage
within system development. They can also serve
as tools for the analysis of system design. For example,
a natural language processing system viewed through the
interpreter and blackboard idioms.
4+1 View of Architecture
• Organizes a description of software architecture using five
concurrent views.
• Architects capture their design decisions in four views and
use the fifth to illustrate and validate the other four.
The 4 Views
 The logical view describes the design's object model when an
object-oriented design method is used. To design an application
that is very data-driven, you can use an alternative approach to
develop some other form of logical view, such as an
entity-relationship diagram. [Use UML Class Diagram]
 The process view describes the design's concurrency and
synchronization aspects. [Use UML Collaboration Diagram/
Sequence Diagram]
 The development view describes the software's static organization
in its development environment. [Use UML Component Diagram]
 The physical view describes the mapping of the software onto the
hardware and reflects its distributed aspect. [No UML Counterpart]
Logical View
Process View
Development View
Physical View
Some architecture description languages
• C2ADL (UCI, http://www.isr.uci.edu/architecture/ )
• xArch (UCI)
• xADL (UCI)
• ACME (CMU, http://www-2.cs.cmu.edu/~acme/ )
• Wright (CMU)
• adapting UML
• adapting other formal languages (e.g. Z)
Architectural Styles
Each style describes a system category that encompasses: (1) a set of components
(e.g., a database, computational modules) that perform a function required by a
system, (2) a set of connectors that enable “communication, coordination and
cooperation” among components, (3) constraints that define how components can
be integrated to form the system, and (4) semantic models that enable a designer
to understand the overall properties of a system by analyzing the known
properties of its constituent parts.
•
•
•
•
•
Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures
Data-Centered Architecture
Data Flow Architecture
Call and Return Architecture
Layered Architecture
Architectural Patterns
•
Concurrency—applications must handle multiple tasks in a
manner that simulates parallelism
•
•
•
Persistence—Data persists if it survives past the execution
of the process that created it. Two patterns are common:
•
•
•
operating system process management pattern
task scheduler pattern
a database management system pattern that applies the
storage and retrieval capability of a DBMS to the application
architecture
an application level persistence pattern that builds persistence
features into the application architecture
Distribution— the manner in which systems or components
within systems communicate with one another in a
distributed environment
•
A broker acts as a ‘middle-man’ between the client component
and a server component.
Place of architecture
• It is important to start reasoning about the system
as early as possible
• The architectural specification helps us see a match
between the requirements a certain set of
constraints before identifying concrete solutions