software architecture

Software Architecture

Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245

Introduction to Software Architecture
Basic Idea about Software Architecture
Software Architecture is the way of decomposing complex system into many sub problems or subsystem.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding
Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471.
These include definitions of system, stakeholder, architect, architecture, architectural views and architectural
viewpoints.
IEEE 1471 defines the following key terms:
• System is a set of components that accomplishes a specific function or set of functions.
• ‘Architecture is the fundamental organization of a system embodied in its components, their
relationships to each other, and to the environment, and the principles guiding its design and
evolution’.
• Architectural Description is a set of products that document the architecture.
• Architectural View is a representation of a particular system or part of a system from a
particular perspective.
• Architectural Viewpoint is a template that describes how to create and use an architectural
view. A viewpoint includes a name, stakeholders, concerns addressed by the viewpoint, and
the modeling and analytic conventions.
Design:
“There are two ways of constructing a software design:
One way is to make it so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies.” - C.A.R. Hoare
What Is Design?
♦ Requirements specification was about the WHAT the system will do
♦ Design is about the HOW the system will perform its functions
 provides the overall decomposition of the system
 allows splitting the work among a team of developers
 also lays down the groundwork for achieving non-functional requirements
(Performance, maintainability, reusability, etc.)
 takes target technology into account (e.g., kind of middleware, database
design, etc.)
Software Development Activities
• Requirements Elicitation
• Requirements Analysis (e.g., Structured Analysis, OO Analysis)
• analyzing requirements and working towards a conceptual model without taking
the target implementation technology into account
• Useful if the conceptual gap between requirements and implementation is large



• Part of requirements engineering (but may produce more than what is going to be
part of the requirement spec)
• Design
• coming up with solution models taking the target implementation technology into account.
• Implementation
• Test
• ...
Levels of Design
• Architectural design (also: high-level design)
• Architecture - the overall structure: main modules and their connections
• Design that covers the main use-cases of the system
• addresses the main non-functional requirements (e.g., throughput, reliability)
• hard to change
• Detailed design (also: low-level design)
• the inner structure of the main modules
• may take the target programming language into account
• detailed enough to be implemented in the programming language
Analogy: Architecture of Buildings


We all live in them



(We think) We know how they are built



Design (blueprints)



Construction




Requirements

Use

This is similar (though not identical) to how we build software.

Architectures in Context
Fundamental Understanding


Architecture is a set of principal design decisions about a software system



Three fundamental understandings of software architecture, the recognition of which helps situate
architecture with respect to the software engineering:


Every application has an architecture





Every application has at least one architect



Architecture is not a phase of development

Wrong View: Architecture as a Phase


Treating architecture as a phase denies its foundational role in software development



More than “high-level design”



Architecture is also represented, e.g., by object code, source code, …

Architecture-Centric Design


Traditional design phase suggests translating the requirements into algorithms, so a
programmer can implement them



Architecture-centric design


stakeholder issues



decision about use of COTS component



overarching style and structure



package and primary class structure



deployment issues



post implementation/deployment issues

Context of Software Architecture


Requirements



Design



Implementation



Analysis and Testing



Evolution



Development Process



The fig shows how all context fits together
(Frameworks and the implementation activity in the context of development.
Activities are shown in left column; artifacts are in the central column; notes are on the right.)



Chapter 1: Basic Concepts
Terminology
The major constituent elements of architectures are, including components, connectors and configuration.
Two important types of potentially deep architectural knowledge-architectural patterns and styles – are then
defined and examined.
Architecture
Definition: A software system’s architecture is the set of principal design decisions made about the system.
Put another way, software architecture is the blueprint for a software system’s construction and evolution.
The notion of design decision is central to software architecture and to all of the concepts based on it. For
example,
Some architecture are anchored on the idea of the reference architecture, defined as follows.
Definition: Reference architecture is the set of principal design decisions that are simultaneously applicable
to multiple related systems, typically within an application domain, with explicitly defined points of
variation.
Design decisions encompass every aspect of the system under development, including:


Design decision related to system Structure-for example, “The architectural elements should be
organized and composed exactly like this…”



Design decision related to functional Behavior-for example, “Data processing, storage, and visualization
will be performed in strict sequence.”



Design decision related to system Interaction-for example, ”Communication among all system
elements will occur only using event notifications.”



Design decision related to system’s Non-functional properties-for example, “The system’s
dependability will be ensured by replicated processing modules.”



Design decision related to system’s implementation-for example, ”the user interface components will
be built using the Java Swing toolkit.”

What is “Principal”?


“Principal” implies a degree of importance that grants a design decision “architectural status”


It implies that not all design decisions are architectural






That is, they do not necessarily impact a system’s architecture

How one defines “principal” will depend on what the stakeholders define as the system goals

Other Definitions of Software Architecture


Perry and Wolf




Software Architecture = { Elements, Form, Rationale }
what
how
why
Shaw and Garlan


Software architecture [is a level of design that] involves



interactions among those elements,



patterns that guide their composition, and




the description of elements from which systems are built,

Constraints on these patterns.

Kruchten


Software architecture deals with the design and implementation of the highlevel structure of software.



Architecture deals with abstraction, decomposition, composition, style, and aesthetics.










A software architecture is defined as follows:
Software architecture- A model that describes the structure of a software system in
terms of computational components, the relationships among components, and the
constraints for assembling the components.
That is, a software architecture can be defined in terms of the following elements:
software architecture = {components, relationships, constraints}
These elements are defined as follows:
Components- Components are the computational elements which collectively constitute
architecture. Software architecture is typically decomposed into subsystems, which in
turn may be decomposed into modules. Further decomposition is also possible. (For
example in an object-oriented design, modules may be decomposed into classes.)
Examples of components include clients, services, and persistent stores.
Relationships- Relationships are the logical connections between architectural
components. Examples of abstract component relationships include dependency,







aggregation, and composition. Examples of concrete component relationships include
client-server protocols and database protocols.
Constraints- Constraints provide conditions and restrictions for component
relationships. They connect the architecture to system requirements. Examples of
constraints include restrictions on parameters types for communication protocols and
high availability requirements for fault tolerance.
The architecture components and their interrelationships define the architectural
structure.

Software Architecture’s Elements


A software system’s architecture typically is not (and should not be) a uniform monolith



A software system’s architecture should be a composition and interplay of different elements



Data, also referred as information or state




Processing

Interaction

Software architectures have 3 types of elements
 – Components
 – Connectors
 – Configuration

Components:


Elements that encapsulate processing and data in a system’s architecture are referred to as software
components



Definition


A software component is an architectural entity that





restricts access to that subset via an explicitly defined interface




encapsulates a subset of the system’s functionality and/or data

has explicitly defined dependencies on its required execution context

Components typically provide application-specific services.

Put another way, a software component is a locus of computation and state in a system.





A component can be as simple as a single operation or as complex as an entire system, depending on
the architecture, the perspective taken by the designers, and the need of the given system.



The key aspect of any component is that it can be “seen” by its users, whether human or software,
from the outside only, and via the interface it has chosen to make public.



Software components are thus embodiments of the software engineering principles of encapsulation,
abstraction, and modularity.



In turn, this has a number of positive implications on a component’s composability, reusability, and
evolvability.



Components are often targeted at be the processing and data capture needs of a particular
application; that is, they are said to be application-specific.



Sometimes components are designed to address the needs of multiple applications or problem
domain. For example, web servers are an integral part of any Web-based system; one will probably
download, install, and configure an existing Web server rather than develop one’s own.



Finally, certain software components are utilities that are needed and can be reused across numerous
applications, without regard for the specific application characteristics or domain. Common examples
of reusable utility components are math libraries and GUI toolkits, such as Java’s Swing toolkit.

Connector:


Another fundamentals aspect of software systems is interaction among the system’s building blocks.



Software connectors are the architectural abstraction tasked with managing component interaction.



Definition


A software connector is an architectural element tasked with effecting and regulating
interaction among components.



In traditional desktop software system, connectors usually have manifest themselves as simple
procedure calla or shared data access.



Simple connectors are usually restricted to enabling the interaction of pairs of components.



However, as software system has become more complex, so have connectors, with their own separate
identities, roles, and bodies of implantation-level code, as well as ability to simultaneously service
many different components.



Connectors typically provide application-independent interaction facilities.





Examples:


Procedure call connectors



Shared memory connectors



Message passing connectors



Streaming connectors



Distribution connectors



Wrapper/adaptor connectors

Configuration:


Components and connectors are composed in a specific way in a given system’s architecture to
accomplish that system’s objective. That composition represents the system’s configuration, also
referred as topology



Definition




An architectural configuration, or topology, is a set of specific associations between the
components and connectors of a software system’s architecture

A configuration may be represented as a graph wherein nodes represent components and connectors,
and whose edges represent their associations.

Architectural Styles


Definition


An Architectural Style is a named collection of architectural design decisions that (1) are
applicable in a given development context, (2) constrain architectural design decisions that
are specific to a particular system within that context, and (3) elicit beneficial qualities in each
resulting system.



Architectural styles classify architecture in terms of the use of form, techniques, materials, time period,
region and other stylistic influences.



It overlaps with, and emerges from the study of the evolution and history of architecture. In
architectural history, the study of Gothic architecture, for instance, would include all aspects of the
cultural context that went into the design and construction of these structures.





Hence, architectural style is a way of classifying architecture that gives emphasis to characteristic
features of design, leading to a terminology such as Gothic "style".

Architectural Pattern


Definition


An Architectural Pattern is a named collection of architectural design decisions that are
applicable to a recurring design problem parameterized to account for different software
development contexts in which that problem appears.



Architectural styles provide general design decisions that both constrain and may need to be refined
into additional, usually more specific design decisions in order to be applied to a system.



In contrast, an architectural pattern provides a set of specific design decisions that have been
identified as effective for organizing certain classes of software systems or, more typically, specific
subsystems.



A "pattern" has been defined as: "an idea that has been useful in one practical context and will
probably be useful in others" [Analysis Patterns - Reusable Object Models].



What’s the difference between an architectural style, an architectural pattern, and a system
metaphor?




An architectural style is a central, organizing concept for a system.
An architectural pattern describes a coarse-grained solution at the level of subsystems or
modules and their relationships.
A system metaphor is more conceptual and it relates more to a real-world concept over a
software engineering concept.

Models


A software system’s architecture is captured in an architectural model using a particular modeling
notation.



Definition


An architectural model is an artifact that captures some or all of the design decisions that
comprise a system’s architecture. Architectural modeling is the reification and
documentation of those design decisions.





Architectural models are used as the foundation for most other activities in architecture-based
software development processes, such as analysis, system implementation, deployment, and
adaptation.

Processes


Software architecture is not software engineering life cycle phase that follows requirements elicitation
and precedes low-level design and system implementation. In that sense, software architecture helps
to anchor the processes associated with different development activities, as follows,


Architectural design



Architecture modeling and visualization



Architecture-driven system analysis



Architecture-driven system implementation



Architecture-driven system deployment, runtime redeployment, and mobility



Architecture-based design for non-functional properties, including security and trust



architectural adaptation

Stakeholders


Architects: The software architect role is responsible for the software architecture, which includes the
key technical decisions that constrain the overall design and implementation for the project.



Developers: A software developer is a person or organization concerned with facets of the software
development process.



Testers: If releasing a relatively bug-free product is important then having a team of software testers is
key.



Managers: A Project Manager is responsible for managing the resources of large projects. The Project
Manager is responsible for making sure a project is completed within a certain set of restraints. These
restraints usually involve time, money, people and materials. The project must then be completed to a
certain level of quality.



Customers: who sometime buy software from developer and sell it in market to make profit.



Users: end users who actually use the software.



2. Conventional Architectural styles
Terminology



Software architectures often use idiomatic patterns of system organization.



Patterns and styles of design are pervasive in many engineering disciplines and an established
understanding of the common forms of design is an indication of a mature engineering field.



The shared vocabulary of design idioms and rules for using them are stored in engineering handbooks
and in professional curricula.



A common framework can be developed to compare different architectures.



It consists of computational components (components and interactions between these components
connectors. Examples of components are clients, servers, filters, layers and databases. Examples of
connectors are procedure call, events broadcast, database protocols, and pipes.



A topological layout of these components indicating their runtime interrelationship.

A Partial List of Common Architecture Styles






Dataflow Systems -- Batch sequential, Pipes and filters.
Call-and-return systems -- Main program and subroutines, OO systems, Hierarchical layers.
Independent components -- Communicating processes, Event Systems.
Virtual Machines -- Interpreters, Rule-based systems.
Data-centered systems (repositories) -- Databases, Hypertext system, Blackboards.

Pipes and Filters






Each component has a set of inputs and outputs.
A component reads a stream of data on its input and produces a stream of data on its outputs.
Input is transformed both locally and incrementally so that output begins before input is consumed (a
parallel system).
Components are called filters.
Connectors serve as conduits for the information streams and are termed pipes.








Invariant traits include the condition that filters must be independent entities, and they must not
know the identity of upstream or downstream filters. They may specify input format and guarantee
what appears on output, but they may not know which components appear at the ends of those pipes.
Common specializations include pipelines which restrict topologies to linear sequences of filters, and
bounded pipes which restrict the amount of data in pipes at one time.
A degenerate version occurs when each filter processes all of its input as a single entity. This is a batch
sequential system. In these systems pipes no longer provide a stream of data.



The best-known example of pipe-and-filter architectures are UNIX shell programs. Components are
represented as UNIX processes and pipes are created through the file system.
UNIX Shell: cat input.txt | grep “text” | sort > output.txt



Other examples include compilers (The consecutive filters perform lexical analysis, parsing, semantic
analysis, and code generation.), signal-processing systems, parallel programming, functional
programming, and distributed systems.

Advantages to pipe-and-filter systems include:






easy understanding of the system's behavior as the composition of filters
they support reuse
easy to maintain and enhance
they support specialized analysis (throughput deadlock analysis)
and they support concurrent execution

Disadvantages to pipe-and-filter systems include:





they often lead to batch organization of processing
poor for interactive applications
can be difficult to maintain synchronization between two related but separate streams
May force lowest common denominator on data transmission, resulting in added work for each filter
to parse input and format output data which can, in turn, affect performance and increase complexity
of the filters.

Event-Based, Implicit Invocation


Instead of invoking a procedure directly, a component announces (broadcasts) one or more events.
Other components in the system can register interest in an event by associating a procedure with it.
The system invokes all events which have registered with it.





Event announcement ``implicitly'' causes the invocation of procedures in other models. This style
originates in constraint satisfaction, daemons, and packet-switched networks.



Architectural components are modules whose interface provides both a collection of procedures and a
set of events. Procedures may be called normally or be registered with events in the system.



Implicit invocation systems are used in:
 programming environments to integrate tools
 database management systems to ensure consistency constraints
 user interfaces to separate data from representation
For example, tools such as editors and variable monitors register for a debugger’s breakpoint events.
When a debugger stops at a breakpoint, it announces an event that allows the system to automatically
invoke methods in those registered tools. These methods might scroll an editor to the appropriate
source line or redisplay the value of monitored variables.
In this scheme, the debugger simply announces an event, but does not know what other tools (if any)
are concerned with that event, or what they will do when that event is announced.





Advantages of Implicit invocation to systems include:


Implicit invocation facilitates reuse by allowing any component to register for events,



And eases system evolution by allowing components to be replaced without affecting the interfaces of
other components in the system.

Disadvantages of Implicit invocation to systems include:


The primary disadvantage to implicit invocation is that the components relinquish control over the
computation performed by the system.



A component cannot assume that other components will respond to its requests and does not know
what order events will be processed.





In systems with a shared repository of data the performance and accuracy of the resource manager
can become critical.



Reasoning about correctness can be difficult because the meaning of a procedure that announces
events will depend on the context in which it was invoked.

Layered Systems


A layered system is organized hierarchically with each layer providing service to the layer above it and
serving as a client to the layer below.



In some systems inner layers are hidden from all except the adjacent outer layer.



Connectors are defined by the protocols that determine how layers will interact.



Constraints include limiting interactions to adjacent layers.



The best known example of this style appears in layered communication protocols OSI-ISO (Open
Systems Interconnection - International Standards Organization) communication system. Lower levels
describe hardware connections and higher levels describe application.
Eg. UNIX OS

Advantages of Layered system include:


Layered systems support designs based on increasing levels of abstraction.



Complex problems may be partitioned into a series of steps.



Enhancement is supported through limiting the number of other layers with which communication
occurs.

Disadvantages of Layered system include:


Disadvantages include the difficulty in structuring some systems in a layered fashion.





Performance considerations may not be well served by layered systems especially when high level
functions require close coupling to low level implementations.



It may be difficult to find the right level of abstraction especially if existing systems cross several
layers.

Repositories:


In a repository style there are two quite distinct kinds of components:
 A central data structure represents the current state, and a collection of independent components
operate on the central data store.
 Interactions between the repository and its external components can vary significantly between
systems.
 The choice of control discipline leads to major subcategories. If the types of transactions in an input
stream of transactions trigger selection of processes to execute, the repository can be a traditional
database. If the current state of the central data structure is the main trigger of selecting processes to
execute, the repository can be a blackboard.
 In Repository architecture the data is passive.
 Blackboard architecture has quasi-active data, which informs the clients interested in changes. The
Blackboard architecture style is similar to the Observer design pattern (Gamma et al., 1995).
Advantages of Repositories include:
 Clients are independent from each other. Thus, a client can be changed, without affecting the others.
Also further clients can be added.
 This advantage pales if the architecture is changed in such a way that clients are coupled closely (thus
deviating from the recommended architecture style), for example in order to improve the performance
of the system.
Eg.

Interpreters



Interpreters create a virtual machine in software.
There are generally four components to an interpreter; these are the program being interpreted, the
state of the program, the state of the interpreter, and the interpreter itself.





They are commonly used to narrow the gap between the computing engine in hardware and the
semantics of a program.
 Programming languages can be thought of as providing a virtual language machine. Examples include
Pascal, Java, and BASIC.

Process Control
 This architecture style is based on control loops.
 This system organization is not widely recognized in the software community.
 Unlike object-oriented or functional designs, which are characterized by the kinds of components that
appear, control-loop designs are characterized both by the kinds of components involved and the
special relations that must hold among them.
 Process-Control paradigms
 Continuous processes of many kinds convert input materials to products with specific properties by
performing operations on the inputs and on intermediate products.
 Some useful definitions:
 Process variable: properties of the process that can be measured; several specific kinds are often
distinguished.
 Controlled Variable: Process variable whose value the system is intended to control.
 Input variable: process variable that measures an input to the process.
 Manipulated variable: Process variable whose value can be changed by the controller.
 Set point: the desired value for a controlled variable.
 Open-loop system: System in which information about process variables is not used to adjust the
system.
 Closed-loop system: System in which information about process variables is used to manipulate a
process variable to compensate for variations in process variables and operating conditions.



Ch.3 Designing Architectures
3.1 Terminology:
The chapter focus on question that “how architectures are created.” In analogy of building architectures, is not fully
adequate basis for creating a fifty-story building that successfully houses business, provides the base for a television
broadcast tower, and which effectively integrates with a city’s electrical ,water ,data, and wastewater infrastructures.
The small matter of design stands between raw materials and tools and realization of the vision. The design of a
skyscraper is the product of a cadre of architects and engineers who labor to meet all the goals for the building while
simultaneously satisfying all the constraints placed upon it, and upon them.
The outcome of such study is a set of approaches and techniques for designing that can be described, taught, applied,
evaluated, and refined. Examination of existing design helps identify good strategies for tackling various kinds of
problem and helps develop a sense for associated costs and qualities.
3.2The Design Process
The goal of this chapter is to set forth a variety of approaches for helping the student learn how to design software
system. The typical assumption of software design is that the process can proceed in the general manner of
architectural design or engineering design, which can be summarized as consisting of the following four stages.
1. Feasibity stage: Identifying a set feasible concept.
2. Preliminary design stage: Selection and development of the best concept.
3. Detailed design stage: development of engineering descriptions of the concept.
4. Planning stage: evaluating and altering the concept to suit the requirements of production, distribution,
consumption and product retirement.
“Designing begins (stage 1) by the taking –in of information. From this a set of alternative arrangements for the design
as a whole is quickly derived. Stage 2 is to select one of these alternatives for further development. When this design has
reached the point of satisfying the chief designer the work is split up for detailed design many people working in
parallel(stage 3 and 4)”.
The viewpoint represented by this process so pervades the software development world that it is hard to realize that the
use of this process represents a choice-that, indeed, other approaches are possible. This is an important recognition
because the standard approach does not always work. Even in those situations where it does work, it may not yield the
best result. At a minimum, designers must be aware of some of the conditions under which the traditional approach is
likely to be insufficient.



Conditions under which this process may not work:


If the designer is unable to produce a set of feasible concepts, progress stops.



As problems and products increase in size and complexity, the probability that any one individual can
successfully perform the first steps decreases.



The standard approach does not directly address the situation where system design is at stake, i.e. when
relationship between a set of products is at issue.



As complexity increases or the experience of the designer is not sufficient, alternative approaches to the
design process must be adopted.

Alternative Design Strategies


Standard
o



Cyclic
o



Independent alternatives are explored in parallel

Adaptive (“lay tracks as you go”)
o



Process can revert to an earlier stage

Parallel
o



Linear model described above

The next design strategy of the design activity is decided at the end of a given stage

Incremental
o

Each stage of development is treated as a task of incrementally improving the existing design

3.3 Architectural conception
The standard approach to architectural and engineering design says that the first major step consists of identifying a
feasible set of “alternative arrangements for the design as a whole,” choosing one of those arrangements, and then
proceeding to refine and elaborate it.
Way to identify set of viable arrangements-or even one viable arrangement.
1)”Apply the fundamental design tools of software engineering: abstraction and modularity.”
2) “Inspiration” Creative inspiration is needed; to be sure, it is not a reliable magic wand to be blithely waved
over
complex design challenge. A more effective strategy is to minimize and isolate those parts of a design for which creative
inspiration is required, and to apply more prosaic and predictable techniques elsewhere.


3) A common, effective, and appropriate answer to the question of how to identify a feasible set of “alternative
arrangement for the design as a whole” is applying experience.
3.3.1Fundamental Conceptual Tools
The most basic design tools are separation of concerns, abstraction, modularity, and other “first principles of software
engineering “such as anticipation of change and design for generality.
Abstraction and the Simple Machines


What concepts should be chosen at the outset of a design task?


One technique: Search for a “simple machine” that serves as an abstraction of a potential system
that will perform the required task



For instance, what kind of simple machine makes a software system embedded in a fax machine?


At core, it is basically just a little state machine.



Simple machines provide a plausible first conception of how an application might be built.



Every application domain has its common simple machines.

Simple Machines:
Domain
Graphics

Word processing
Process control
Income Tax Software

Web pages
Scientific computing
Banking

Simple Machines
Pixel arrays
Transformation matrices
Widgets
Abstract depiction graphs
Structured documents
Layouts
Finite state machines
Hypertext
Spreadsheets
Form templates
Hypertext
Composite documents
Matrices
Mathematical functions
Spreadsheets
Databases
Transactions



Choosing the Level and Terms of Discourse


Any attempt to use abstraction as a tool must choose a level of discourse, and once that is chosen, must choose
the terms of discourse.



Alternative 1: initial level of discourse is one of the applications as a whole (step-wise refinement).



Alternative 2: work, initially, at a level lower than that of the whole application.




Once several such sub-problems are solved they can be composed together to form an overall solution

Alternative 3: work, initially, at a level above that of the desired application.


E.g. handling simple application input with a general parser.

Separation of Concerns


Separation of concerns is the subdivision of a problem into (hopefully) independent parts.



The difficulties arise when the issues are either actually or apparently intertwined.



Separations of concerns frequently involves many tradeoffs



Total independence of concepts may not be possible.



Key example from software architecture: separation of components (computation) from connectors
(communication)

3.3.2 The Grand Tool: Refined Experience


Experience must be reflected upon and refined.



Experience can be a masterful teacher, however, and can provide the guidance necessary to wield the basic
tools in an effective fashion.



Raw experience by itself,though,does not provide the mature guidance



The lessons from prior work include not only the lessons of successes, but also the lessons arising from failure.



Learn from success and failure of other engineers


Literature



Conferences



Experience can provide that initial feasible set of “alternative arrangements for the design as a whole”.



Similarly, communication between development team members is enhanced: when others have experience with
the same or similar preexisting systems, it is easier to describe use of or modifications to an established
approach, as compared to conveying a completely new concept.



Limitation: Innovation is certainly inhibited by mindlessly following one’s standard approach.



3.4 Refined Experience in action: Styles and architectural patterns
 The distilled architectural wisdom that has arisen from a vast body experience comes in many shapes and
flavors.
 Styles are designed to capture knowledge of effective design for achieving specified goals within a particular
application context.
 Patterns and styles can be characterized for large problem as well as small.

Following figure for a summary of the main types architectural styles and patterns.
(Domain knowledge versus scope in showing the relationship between styles and pattern).



The horizontal axis of above figure refers to the scop of applicability of the body of knowledge-the domain of
discourse.



For instance,design pattern are focused on the programmingof object-oriented solutions to program design
problems.



Such patterns are inapplicable to enterprise-level system design,which is other end of thye horizontal axis.



The vertical axis reflects the amount of domain knowledge represented by the body of knowledge.



Program design patterns are shown at the shallow end of this scale,reflecting that they are very generally
applicable and are not restricted to use within a particular application domain.





At the other end of the scale are domain-specific software architecture.



Such styles are applicable to the design of very large applications and concomitantly encode substantial
knowledge about the design of applications within a domain.



The diagram has fuzzy boundaries, however, and should only be taken as a rough guide.



Programming languages exist at many levels of abstraction;applications range from very simple to extraordinary
complex.

3.4.1 Domain-specific software architectures


A DSSA is an assemblage (or combination)of software components
o

A referance architecture for an application domain, and

o

A library of software components for that architecture containing reusable chunks of domain expertise,

o

A method of choosing and configuration components to work within an instance of the referamce
architecture.



Since DSSAs are specialized for a particular domain they are only of value if one exists for the domain wherein
the engineer is tasked with building a new application.



DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for
developing a new architectural design.



The difficultywith DSSAs is that they are specialised for a particular domain and so are only of value if one exists
for the domain wherein the engineer is charged with building a new application.

3.4.2 Architectural Patterns


An architectural pattern is a set of architectural design decisions that are applicable to a recurring design
problem, and parameterized to account for different software development contexts in which that problem
appears.



Architectural patterns are similar to DSSAs but applied “at a lower level” and within a much narrower scope.



Definition: An Architectural Pattern is a named collection of architectural design decisions that are applicable
to a recurring design problem parameterized to account for different software development contexts
in which that problem appears.



In this sections below,we sketch three very simple examples:State-logic-display,model-view-controller,and
sense-compute-control.

State-Logic-Display(aka. Three-Tier)


This example is commonly employed in business applications where there is a data store behind a set of
business logic rules, and that business logic is accessed by user interfacecomponents.This pattern,also known as


state-logic-display,has been popular since itmaps nicely to a distributed implemented in which communication
between the components is by remot procedure call.



Example:


Business applications



Multi-player games



Web-based applications

Model-View-Controller(for Graphical User Interfaces)


Objective: Separation between information(M), presentation(V) and user interaction(C).



This pattern has been a dominent influencein the design of graphical user interfaces.



When a model object value changes, a notification is sent to the view and to the controller.




When handling input from the user the windowing system sends the user event to the controller.




Thus, the view can update itself and the controller can modify the view if its logic so requires.

If a change is required, the controller updates the model object.

The simple idea shown in figure,


The model component encapsulates the information used by the application;



the view component encapsulates the information chosen and necessary for graphical depiction of the
information;



the controller component encapsulates the logic neccesary to maintain consistency between the model
and the view,and to handle inputs from the user as they relate to tha depiction.



Sense-Compute-Control(aka. Sensor-Controller-Actuator)


The sense-compute-control (SCC) pattern is typically used in structuring embedded control applications.



This may range from simple device such as those found in kitchen appliances to sophisticated syatem used in
automotive applications or robotis control.



The basic idea is illustrated in figure,


A computer is embedded in some application;



sensors from various devisec are connected to the computer and may be simpled to determine their
value.



Also attached to the computer are hardware actuators.



By sending a signal to such devices the computer may,for example,open a vlue.lower flaps,or turn off a
light, and hence control the system.

3.4.3 Introduction to Styles


An architectural style is a named collection of architectural design decisions …



A primary way of characterizing lessons from experience in software system design



Reflect less domain specificity than architectural patterns



Useful in determining everything from subroutine structure to top-level application structure



Many styles exist and we will discuss them in detail in the next lecture

Definitions of Architectural Style


Definition. An architectural style is a named collection of architectural design decisions that






constrain architectural design decisions that are specific to a particular system within that context




are applicable in a given development context

elicit beneficial qualities in each resulting system.

Recurring organizational patterns & idioms


Established, shared understanding of common design forms



Mark of mature engineering field.




Shaw & Garlan

Abstraction of recurring composition & interaction characteristics in a set of architectures


Medvidovic & Taylor

Basic Properties of Styles


A vocabulary of design elements
 Component and connector types; data elements
 e.g., pipes, filters, objects, servers



A set of configuration rules
 Topological constraints that determine allowed compositions of elements
 e.g., a component may be connected to at most two other components



A semantic interpretation
 Compositions of design elements have well-defined meanings



Possible analyses of systems built in a style

Benefits of Using Styles


Design reuse
o



Code reuse
o



Well-understood solutions applied to new problems

Shared implementations of invariant aspects of a style

Understandability of system organization
o

A phrase such as “client-server” conveys a lot of information



Interoperability
o



Style-specific analyses
o



Supported by style standardization

Enabled by the constrained design space

Visualizations
o

Style-specific depictions matching engineers’ mental models

Some Common Styles


Traditional, language-influenced styles
o
o



Main program and subroutines
Object-oriented

Layered
o
o



Virtual machines
Client-server

Data-flow styles
o
o



Batch sequential
Pipe and filter

Shared memory
o
o



Blackboard
Rule based

Interpreter
o
o



Interpreter
Mobile code

Implicit invocation
o
o



Event-based
Publish-subscribe

Peer-to-peer





“Derived” styles
o

C2

o

CORBA

Traditional Language-Influenced Styles
The two styles considered here reflect the program styles that result from the traditional use of programming lamguages
such C,C++,Java,and Pascal.
Main program and Subroutines.


The main program and subroutine style should be instantly familiar to anyone who has programmed in a
language such C,Fortran,Pascal, or Basic.



The components are the main program and the various subroutines(procedures);the connectors between the
components are procedure calls.

Main
program

Procedure Call
Call

Subroutines

Procedure Call

Procedure Call

Subroutines

Subroutines

Object-Oriented







Components are objects
o Data and associated operations
Connectors are messages and method invocations
Style invariants
o Objects are responsible for their internal representation integrity
o Internal representation is hidden from other objects
Advantages
o Malleable object internals
o System decomposition into sets of interacting agents
Disadvantages
o Objects must know identities of servers



o Side effects in object method invocations
Layered



Layered styles are as simple and familiar as those above that reflect the traditional use of programming
languages such C or Java.
The essence of a layered style is that architecture is separated into ordered layers, wherein a program within
one layer may obtain services from a layer below it.

Virtual Machines
Refer Interpreter in ch.2
Client-server



The client-server style can be simply understood as a two-layer virtual machine with network
connections.
 That is, the server (component) is a virtual machine below the clients, each of which accesses the
virtual machines interfaces via remote procedure calls or equivalent network access methods
(connector).
 Typically, there are multiple clients that access the same server; the clients are mutually independent.
Dataflow Styles
The two styles presented here can be characterized as dataflow styles. Their essence concerns the movement
of data between independent processing elements.
Batch-sequential
 The batch-sequential style is one of the oldest in the design of computer system.
 It arose in the early days of data processing when the limitations of computing equipment required
that large problems be subdivided into severable components that could communicate by the transfer
of magnetic tapes.
Pipe-and-Filter
Refer ch.2
Shared State (Shared memory styles)
The essence of shared state styles is that multiple components have access to the same data store, and
communicate through that data store.
Blackboard
 Two kinds of components
 Central data structure — blackboard
 Components operating on the blackboard
 System control is entirely driven by the blackboard state
 Examples
 Speech recognition
 Planner component for RADRSAT-1 satellite



Rule-based/Expert System
 A rule-based architecture is a highly specialized type of shared memory architecture.
 The shared memory is a so-called knowledge base, that is, a database that contain facts and
production rules which consist of “if…then” clauses over the set of variables.
 Inference engine parses user input and determines whether it is a fact/rule or a query
 If a fact/rule, add this entry to the knowledge base
 Rules often take if (condition) then {action} form
 Otherwise, query the knowledge base for applicable rules and attempt to resolve the query.
 Components:
 User interface, inference engine, knowledge base
 Connectors:
 Components are tightly interconnected, with direct procedure calls and/or shared memory
 Data Elements:
 Facts and queries
 Pro: can easily modify system behavior through addition or deletion of rules
 Con: as number of rules grows understanding overall system behavior becomes very difficult

Interpreter
 The basic interpreter architectural style involves the execution of commands one at a time.
 Similarly, though typically at a large granularity, the mobile code style involves the execution of one
chunk of code at a time.
 The difference with mobile code is that the place where the commands are executed may vary over
time.
Basic Interpreter
 Interpreter parses and executes input commands, updating the state maintained by the interpreter
 Components: Command interpreter, program/ interpreter state, user interface
 Connectors: Typically very closely bound with direct procedure calls and shared state
 Highly dynamic behavior possible, where the set of commands is dynamically modified.
 Good for end-user programming; supports dynamically changing set of capabilities
 System architecture remains constant while new capabilities can be added
 Examples: Microsoft Excel, Postscript.
Mobile Code
 Mobile code styles enable code to be transmitted to a remote host for interpretation.
 Mobile code may be classified as code on demand, remote evaluation, or mobile agent depending on
where the code is being transmitted, who requested the transmission, and where the program state
resides.
 Data elements become processing comps
 Components:
 “Execution dock”, which handles receipt of code and state; code compiler/interpreter






Connectors:
 Network protocols and elements for packaging code and data for transmission
Data Elements:
 Representations of code as data, program state.

Implicit Invocation
The two styles below are characterized by calls that are invoked indirectly and implicitly as a response to a
notification or an event.
Publish-Subscribe
 Subscribers register/deregister to receive specific messages or specific content.
 Publishers broadcast messages to subscribers either synchronously or asynchronously.
 Components:
Publishers, subscribers, proxies
 Connectors:
Network protocols. Content-based subscription requires sophisticated connectors.
 Data Elements:
Subscriptions, notifications, published information
 Topology:
Subscribers connect to publishers or receive notifications from intermediaries.
Event-Based Style
• Independent components asyn. emit and receive events over event buses
• Components:
Independent, concurrent event generators and/or consumers
• Connectors: Event buses (at least one)
• Data Elements:
Events – data sent as a first-class entity over the event bus.
• Topology: Components communicate with the event buses, not directly to each other.
• Variants: Component communication with the event bus may either be push or pull based.
• Highly scalable, easy to evolve, effective for highly distributed applications.
Peer-to-Peer style
• State and behavior are distributed among peers which can act as either clients or servers.
• Peers: independent components, having their own state and control thread.
• Connectors: Network protocols, often custom.
• Data Elements: Network messages
• Topology: Network (may have redundant connections between peers); can vary arbitrarily and
dynamically
• Supports decentralized computing with flow of control and resources distributed among peers
• Highly robust to node failure
• Scalable in terms of resources and comp. power
• Resource discovery is key concern
• Security – detecting/handling malicious peers.



Chapter 4: Connectors
Introduction
Designing and implementing the functionality and managing the data of modern large, complex, distributed,
multilingual software systems is undoubtedly very difficult. The particular importance in modern systems of
mechanisms for assembling functional components and supporting their interaction, that is, software
connectors, mandates that they be treated and studied separately.
Software connectors perform transfer of control and data among components.
Connectors can also provide services, such as persistence, invocation, messaging, and transactions, that are
largely independent of the interacting components’ functionalities.
What is a Software Connector?
 Architectural element that models
o Interactions among components
o Rules that govern those interactions
 Simple interactions
o Procedure calls
o Shared variable access
 Complex & semantically rich interactions
o Client-server protocols
o Database access protocols
o Asynchronous event multicast
 Each connector provides
o Interaction duct(s)
o Transfer of control and/or data
Where are Connectors in Software Systems?



Reasons for Treating Connectors Independently
 Connector  Component
o Components provide application-specific functionality
o Connectors provide application-independent interaction mechanisms
 Interaction abstraction and/or parameterization
 Specification of complex interactions
o Binary vs. N-ary
o Asymmetric vs. Symmetric
o Interaction protocols
 Localization of interaction definition
 Extra-component system (interaction) information
 Component independence.
 Component interaction flexibility.
Benefits of First-Class Connectors
 Separate computation from interaction
 Minimize component interdependencies
 Support software evolution
o At component-, connector-, & system-level
 Potential for supporting dynamism
 Facilitate heterogeneity
 Become points of distribution
 Aid system analysis & testing
Connector Foundation
 The underlying, elementary building blocks of every connector are the primitives for managing the flow
of control (that is, changing the processor program counter) and flow of data (that is, performing
memory access) in a system.
 These primitives give enough conceptual power to build sophisticated and complex connectors. In
addition to these primitives, every connector maintains one or more channels, also referred to as
ducts, which are used to link the interacting components and support the flow of data and control
between them.
 Simple connectors, such as module linkers, provide their service simply by forming duct between
components.
 Very complex connectors can also have an internal architecture that includes computation and
information storage.
 For example, a load balancing connector would execute an algorithm for switching incoming traffic
among a set of components based on the knowledge about the current and past load state of
components.



Connector Roles
A software connector can provide one or more of four general classes of services: communication,
coordination, conversion, and facilitation.
Communication
 Connectors providing communication services support transmission of data among components.
 Data transfer services are a primary building block of component interaction.
 Components routinely pass messages, exchange data to be processed, and communicate results of
computations.
Coordination
 Connectors providing coordination services support transfer of control among components.
 Components interact by passing the thread of execution to each other.
 Function calls and method invocations are examples of coordination connectors.
 Higher-order connectors, such as signals and load balancing connectors provide richer, more complex
interaction built and coordination services.
Conversion
 Connectors providing conversion services transform the interaction required by one component to that
provided by another.
 Enabling heterogonous components to interact with each other is not a trivial task.
 Conversion services allow components that have not been specifically tailored for each other to
establish and conduct interaction.
Facilitation
 Improve interaction of components that were intended to interoperate
Usually optimizes or streamlines interactions
 Ensure proper performance profiles
Load balancing or scheduling
 Synchronization mechanisms
Monitors (enforce mutex access to resources)

Connector types and their variation dimensions









Procedure call
Event
Data access
Linkage
Stream
Arbitrator
Adaptor
Distributor



Procedure Call
 Procedure call connectors model the flow of control among components through various invocation
techniques. They are thus coordination connectors.
 Additionally, procedure calls perform transfer of data among the interacting components through the
use of parameters and return values. They are thus also communication connectors.
 Examples of procedure call connectors include object-oriented methods, fork and exec in Unix-like
environments, call-back invocation in event-based system, and operating system call.
 Procedure calls are frequently used as the basis for composite connectors, such as remote procedure
call or RPC which also perform facilitation service.

Event
 An event as the instantaneous effect of the termination of the invocation of an operation on an object,
which occurs at that object’s location.
 Event connectors are similar to procedure call connectors in that they affect the flow of control among
components, and thus provide coordination services.in this case, the flow is precipitated by an event.
 Once the event connector learn about the occurrence of an event, it generates messages for all
interested parties and yields control to the components for processing those messages.
 The contents of an event can be structured to contain more information about the event, such as the
time and place of occurrence, and other application-specific data. Events connectors therefore also
provide communication service.
 An example is a windowing application, where GUI inputs serve as the events that activate the system.
 Finally, some events, such as interrupts, page faults, and traps, are triggered by hardware and then
processed by software.



Data Access Connectors
 Data access connectors allow components to access maintained by a data store component. Therefore
they provide communication services.
 In case there is a difference in the format of the required data and format in which data is stored and
provided, data access connectors may perform translation of the information being accecced, that is
conversion.
 The data can be stored either persistently data access include query mechanism, such as SQL for
database access, example of transient data access include heap and stack memory access and
information caching. Eg.JDBC



Linkage Connectors
 Linkage connectors are used to tie the system components together and hold them in such a state
during their operation.
 Linkage connectors enable the establishment of ducts- the channels for communication and
coordination-that are then used by higher-order connectors to enforce interaction semantics.
 In other words, linkage connectors provide facilitation service.
 Once ducts are established, a linkage connector may disappear from the system or remain in place to
assist in the system’s evolution.

Stream connectors
 Streams are used to perform transfer of large amounts of data between autonomous processes. Thus
they provide communication services in a system.
 Streams are also used in client-server system with data transfer protocol to deliver results of
computation.
 Stream can be combined with other connector types such as data access connectors, to provide
composite connectors for performing database and file storage access, and event connectors, to
multiplex the delivery of a large number of events.
 Examples include UNIX pipes, TCP/UDP communication sockets, and proprietary client-server
protocols.



Arbitrator Connectors
 When components are aware of the presence of other components but cannot make assumptions
about their needs and state, arbitrators streamline system operation and resolve any conflicts (thereby
providing facilitation services), and redirect the flow of control (providing coordination services).
 For example, multithreaded systems that require shared memory access use synchronization and
concurrency control to guarantee consistency and atomicity of operations.
 Arbitrators can also provide facilities to negotiate service levels and mediate interaction requiring
guarantees for reliability and atomicity.
 They also provide scheduling and load balancing services.



Adaptor Connectors
 Adaptor connectors provide facilities to support interaction between components that have not been
designed to interoperate.
 Adaptors involve matching communication policies and interaction protocols among components,
thereby providing conversion services.
 These are necessary for interoperation of components in heterogeneous environments, such as
different programming languages or computing platforms.

Distributer Connectors
 Distributer connectors perform the identification of interaction paths and subsequent routing of
communication and coordination information among components along these paths.
 Therefore, they provide facilitation services.
 Distributor connectors never exist by themselves, but provide assistance to other connectors, such as
streams or procedure calls.
 Distributed system exchange information using distributer connectors to direct the data flow.
 Example, Domain Name Service (DNS), routing, switching, and many other network services belong to
this connector type.



Example Connectors
In this section, we illustrate the connector classification discussed above with four composite distribution
connectors that are in wide use today: event-based, grid-based, client-server-based, and peer-to-peer-based
(or p2p-based) connectors. These connectors distribute large amounts of content over a wide area network,
such as the Internet. Several implementations of these connectors are in wide use by a number of research,
industry, and government projects, as well as a large number of individuals around the world.
Distribution connectors can be described as different combinations of six of the connector types defined in the
classification. The exact combinations of the six types dimensions varies across the different distribution
connectors, but in general, each distribution connector performs some form of data access ,involving a
stream-based reading(and packaging) of data, and distribution of the data to end users. Some connectors
classes are invoked via procedure call (for example, client-based), or arbitration (for example, P2P-based).

Event-Based Data Distribution Connectors
• Event-based utilizes 4 of the 6 connectors:
o Event
o Data access
o Stream
o Distributor
• These connectors send and receive data via asynchronous notification called events
• An example is a middle ware that performs publish-subscribe architectural style and involves some
producer of information alerting subscribers ---events, which then kicks- off the accessing of various
data. The accessed data is then packaged and streamlined for distribution by the distributor to the
subscribers.
Grid-based Distribution Connector
• Grid-based utilizes 4 of the 6 connectors:
o Procedure call
o Data access


•
•


o Stream
o Distributor
These connectors move and deliver large amounts of data among software components arranged in a
network (grid) of shared computing and data resources.
This middle-ware is invoked via a named, synchronous procedure call. User authentication and security
functionalities are provided, data-provider & functionality source and destinations are provided,
parameters are passed by values with “keyword equals value”, actual data is packaged and
streamlined, etc. in the grid-network with location & directory services to help distribution.

Client Server-based Distribution Connector
• Client server-based utilizes the same 4 connectors as Grid :
o Procedure call
o Data access
o Stream
o Distributor
• These connectors allow seamless distribution of data between client and server system using Remote
Procedure Call (RPC).
• This middle-ware is very much like the grid-based distribution connector, except the customer of
service and the provider of service operates in a much more seamless manner (as if the service and
data are “local”).
Peer-to-Peer-based Distribution Connector
• P2P-based utilizes the 4 connectors :
o Arbitrator
o Data access
o Stream
o Distributor
• These connectors differ from the previous 3 in that it is invoked via arbitration, which involves control
flow redirection among distributed, peer resources. Arbitrators can negotiate various issues such as
timing, scheduling, or protocols.
• Once a peer is invoked via arbitration then the collection of data may also be through the peers in a
distributed environment (also via arbitration). Data is then organized and package in chunks for
transmission to other peers. Other peers are located via arbitration and the data is distributed to them.



Chapter 5: Modeling
Introduction


Every software system has architecture, whether it is a “good” architecture or not.



Recall that we have characterized architecture as the set of principal design decisions made about a system.



Once design decisions have been made, they can be recorded.



Design decisions are captured in models; the process of creating models is called modeling.

Definitions:


An architectural model is an artifact that captures some or all of the design decisions that
comprise a system’s architecture



Architectural modeling is the reification and documentation of those design decisions

Without a model, architecture is inscrutable. Modeling notations can be rich and ambiguous (for example,
natural language), highly formal (such as the Rapide notation), semantically weak (such as Power-Point diagrams),
or semantically formal. Several notations can be combined to describe architecture - for example, a UML class
diagram can be annotated with natural language.
(Note: This chapter deals with basic architectural concepts and design decisions that need to be modelled, as
well as modeling views, viewpoints, and visualizations. Other section covers various modeling notations: natural
language (3.1); informal graphical styles (3.2); Unified Modeling Language (3.3); early Architecture Description
Languages (3.4) – Darwin (3.4.1), Rapide (3.4.2), and Wright (3.4.3); domain-specific and style-specific
Architecture Description Languages (3.5) – Koala (3.5.1), Weaves (3.5.2), and AADL (3.5.3); extensible
Architecture Description Languages (3.6) – Acme (3.6.1), ADML (3.6.2), and xADL (3.6.3); User Requirements
Notation (3.7); and Dialog Flow Notation (3.8). )

Throughout the chapter, we also discuss how architecture modeling notations are used to capture design decisions.
Definition:


An architectural modeling notation is a language or means of capturing design decisions.

5.1 Modeling Concepts
In this chapter, we discuss a broad spectrum of kinds of things that can be modeled in architecture, and then how
various notations can be selected and used to facilitate this modeling.
5.1.1 Stakeholder-Driven Modeling
One of the most critical decisions that architects and other stakeholders will make in developing architecture is to
choose:



1. What architectural decisions and concepts should be modeled,
2. At what level of detail, and
3. With how much rigor or formality.
These decisions should be based on costs and benefits. Architects should balance the benefits of having certain models
in certain forms or notations with the cost of creating and maintaining those models. Thus, the choice of what to model,
and at what level of detail, will be stakeholder driven.

Figure shows five concerns about the system identified by stakeholders.
In this particular case, Concerns 1 is of great importance,
and will be considered and modeled deeply.
Concerns 2 and 4 are less important and will be modeled shallowly.

 Modeling is an activity, and as such it is often governed by a process.
The basic activities behind stakeholder-driven modeling are to:
1. Identify relevant aspects of the software to model.
2. Roughly categorize them in terms of importance.
3. Identify the goals of modeling for each aspect (communication, bug finding, quality analysis, generation of other
artifacts, and so on).
4. Select modeling notations that will model the selected aspects at appropriate levels of depth to achieve the
modeling goals.
5. Create the models.
6. Use the models in manner consistent with the modeling goals.
Although the steps outlined above are in rough chronological order, they can be incorporated into an iterative process.
5.1.2 Basic Architectural Concepts





Components – Components are the architectural building blocks that encapsulate a subsets of system's
functionality and data, and restrict access to them via an explicitly defined interfaces.
Connectors - Connectors are the architectural building blocks that effect regulate interactions among
components.
Interfaces - points at which components and connectors interact with the outside world.
Configurations - specific associations between the components and connectors in the system.



Rationale – Rational is the information that explains why particular architectural decisions were made ,and what
purpose various elements serve .

5.1.3 Elements of the Architectural Style
“Architectural style is a collection of design decisions that are applicable in a given development context, constrain
design decisions within that context, and elicit beneficial qualities in the resulting system.”
Explicitly modeling the architectural style can be helpful for a number of reasons.
1. It reduces confusion about what is and is not allowed in the architecture.
2. It can help to reduce architectural drift and erosion.
3. It makes it easier to distinguish whether a specific design decision in architecture was made to conform to a
stylistic constraint or for some other reason.
4. It can help to guide the evolution of the architecture.
5. Style represent a single place capture cross-cutting concerns and rational for an architecture.
The kinds of design decisions found in an architectural style are generally more abstract or general than those found in
architecture. Some kind of design decisions that might be captured in a style model include:






Specific elements - particular components, interfaces and connectors to be used in a particular way in specific
situations. Modeling templates or base models can be thus created.
Component, connector, and interface types - kinds of elements permitted, required, or prohibited in the
architecture.
Interaction constraints - temporal (call one before another), topological (can be invoked only by components
belonging to a certain layer), protocol (one or a group) constraints on interaction between Components and
connectors.
Behavioral constraints - from simple rules to complete finite state automata of the system.
Concurrency constraints - rules for concurrency, synchronization, access to shared resources.

5.1.4






5.1.5


Static and Dynamic Aspects
Static aspects are easier to model as they do not include changes over time.
Typical models of static system aspects might include component/connector topologies, assignments of
components and connectors to processing elements or host and network configurations, or mappings of
architectural elements to code or binary artifacts.
Dynamic aspects of a system are harder to represent. This includes interaction models, data flow models, and
behavioral models.
In cases when the system is usually stable but might have to change behavior if one of the components fails,
both the static and dynamic models might be needed.
Modeling dynamic aspects of a system can be done using static modeling (for example, interaction diagrams).
Dynamic models can be employed to visualize the behavior of a running system, and are updated on-the-fly.
Functional and Non-Functional Aspects



Architecture can capture both functional and non-functional aspects of a system.



Functional aspects relate to what a system does.



Non-functional aspects relate to how a system performs its functions.



Functional aspects of a system can be described using declarative, subject-verb sentences:
Eg: “The system prints medical records”.



Non-functional aspects of a system can be described by adding adverbs to these sentences.
Eg: “The system prints medical records quickly and confidentially.”



Architectural models tend to be functional, but like rationale it is often important to capture non-functional
decisions even if they cannot be automatically or deterministically interpreted or analyzed.



Functional (what a system does) and non-functional (constraints on what a system does) aspects of the system
can be captured through modeling. Functional aspects are easier to model as they are complete.
 Most modeling notations are designed to capture primarily functional aspects. Non-functional aspects are often
captured less
rigorously, as they are qualitative and subjective.

5.2 Ambiguity, Accuracy, and Precision
Architectures are abstractions of systems. They capture information about some aspect of the system and leave out
other aspects.
Three key concepts can be used to characterize architectural models: ambiguity, accuracy, and precision.
5.2.1 Ambiguity
Definition: A model is ambiguous if it is open to more than one interpretation
 Because conflicting interpretations of a model may lead to misunderstandings, bugs, and errors, it is generally
desirable to eliminate ambiguity in design.


 Incompleteness is a primary reason for ambiguity in models: When some aspect of a system is left unspecified,
different stakeholders may make different assumptions about hoe the gap should be filled in.
 Architectures are necessarily incomplete: They address principal design decisions about a system, not every
design decision.

5.2.2 Accuracy and Precision
Many conceptions of accuracy and precision, including dictionary definition, conflate the two terms. Here, we will adopt
an interpretation that more clearly delineates them.
Definition: A model is accurate if it is correct, conforms to fact, or deviates from correctness within
acceptable limits.
Definition: A model is precise if it is sharply exact or delimited.


Accuracy deals with correctness, while precision deals with exactness.



In architectural terms, a model is accurate if it conveys correct information about the modeled system.



A model is precise if it conveys a lot of detailed information about the modeled system.

5.3 Complex Modeling: Mixed Content and Multiple views
Architectural models are complex artifacts. They attempt to capture all the design decisions about a system that are
important to a wide variety of stakeholders. There can be multiple or different aspects of same concern captured
simultaneously. Some basics about views and viewpoints are as follows.



5.3.1 Views and Viewpoints


Generally, it is not feasible to capture everything we want to model in a single model or document
o



The model would be too big, complex, and confusing

So, we create several coordinated models, each capturing a subset of the design decisions
o

Generally, the subset is organized around a particular concern or other selection criteria



We call the subset-model a ‘view’ and the concern (or criteria) a ‘viewpoint’



Definitions
•
•
•

A view is a set of design decisions related by a common concern (or set of concerns).
A viewpoint is the perspective from which a view is taken.
A view (what you see) is an instance of a viewpoint (filter) for a specific system .



A viewpoint is a filter for information, and a view is what you see when you look at a system through that filter.



Viewpoints provide a way to limit presented information to a cognitively manageable subset of the architecture,
display related concepts simultaneously, can be tailored to the needs of specific stakeholders, can be used to
display the same data at various levels of abstraction.
Listed below are several traditional viewpoints frequently used in modeling:
1. Logical - logical (often software) entities in the system and how they are interconnected.
2. Physical - physical (often hardware) entities in the system and how they are interconnected.
3. Deployment - how logical entities are mapped onto physical entities.
4. Concurrency - how concurrency and threading are managed in the system
5. Behavioral - expected behavior of the system or its parts.





The use of views and viewpoints in modeling is important for several reasons:
1.
2.
3.
4.

They provide a way to limit presented information to a cognitively manageable subset of the architecture.
They display related concepts simultaneously.
They can be tailored to the needs of specific stakeholders.
They can be used to display the same data at various levels of abstraction.

5.3.2 Consistency among Views
 Views can contain overlapping and related design decisions
o


Views are consistent if the design decisions they contain are compatible
o



There is the possibility that the views can thus become inconsistent with one another

Views are inconsistent if two views assert design decisions that cannot simultaneously be true

Inconsistency is usually but not always indicative of problems
o

Temporary inconsistencies are a natural part of exploratory design

o


Inconsistencies cannot always be fixed.

The following inconsistencies may exist among views:


Direct inconsistencies - two views assert directly contradictory propositions, automatically detectable.
E.g., “The system runs on two hosts” and “the system runs on three hosts.”



Refinement inconsistencies - two views at different levels of detail assert contradictory propositions; can be
automatically detected with appropriate consistency rules.
Static versus dynamic aspect inconsistencies - view of a static aspect conflicts with a view of the dynamic aspect
of the system, harder to automatically detect, depending on how explicit the dynamic aspect's specification is.
Dynamic aspect inconsistencies - two views of dynamic aspects of the system conflict, often extremely difficult
to detect automatically as it requires extensive state exploration or simulations.
Functional versus non-functional aspect inconsistencies - non-functional property prescribed by a
nonfunctional view is not met by the design expressed in functional views; the most difficult to detect because
of the general and abstract nature of non-functional properties.





5.4 Specific Modeling Techniques
This section evaluate different modeling techniques for software architecture
 Generic approaches
1. Natural language
2. PowerPoint-style modeling
3. UML, the Unified Modeling Language
 Early architecture description languages
1. Darwin
2. Rapide
3. Wright
 Domain- and style-specific languages
1. Koala
2. Weaves
3. AADL
 Extensible architecture description languages
1. Acme
2. ADML
3. xADL
5.4.1 Generic Techniques
These techniques are often used to describe software architecture in whole or in part, although they were not
specifically developed or adopted for this purpose, they tend to be flexible but have few semantics.
Natural Language
 Natural (human) languages, such as English, are expressive, but ambiguous, non-formal, and non-rigorous.
 They cannot be effectively processed and understood by machines, and so can only be inspected by humans.
 Natural languages are easily accessible to stakeholders and can be handled using common word-processing
tools.
 Due to the abstract and qualitative nature of non-functional requirements, natural languages are best in
capturing those.
 Sometimes, a restricted form of a language is used instead of a pure language.






This is achieved by users employing a particular dictionary of terms, to avoid ambiguity. Extensive use of this
technique is not effective, as it results in a domain-specific language without the advantages of having a
flexibility of a natural language.
Advantages
 Highly expressive
 Accessible to all stakeholders
 Good for capturing non-rigorous or informal architectural elements like rationale and non-functional
requirements
 Plentiful tools available (word processors and other text editors)
Disadvantages
 Ambiguous, non-rigorous, non-formal
 Often verbose
 Cannot be effectively processed or analyzed by machines/software.

Informal Graphical PowerPoint-style Modeling
 Informal Power-Point-style modeling allows for creation of decorative diagrams of interconnected shapes.
 They are easily accessible to stakeholders, assuming the tools for their manipulation are available.
 The slide nature of these presentations limits the diagram size, which ensures suitable abstraction.
 Advantages
o Can be aesthetically pleasing
o Size limitations (e.g., one slide, one page) generally constrain complexity of diagrams
o Extremely flexible due to large symbolic vocabulary
 Disadvantages
o Ambiguous, non-rigorous, non-formal
 But often treated otherwise
o Cannot be effectively processed or analyzed by machines/software.
The Unified Modeling language (and its Cousins)
 13 loosely-interconnected notations called diagrams that capture static and dynamic aspects of softwareintensive systems
 UML (Booch, Rumbaugh, and Jacobson 2005) combines concepts from earlier notations: Booch diagrams, OMT,
OOSE, and Statecharts.
 UML provides a wide variety of modeling constructs and viewpoints.
 There are many tools that provide varying degrees of support for UML (from diagram construction to generation
of code from UML models).
 UML is an extensive notation that traditionally employs graphical symbols with textual annotations to represent
the system from thirteen different viewpoints (as of UML 2.0).
 Early versions of UML focused on detailed design modeling. UML 2.0 has added support for higher-level
architectural constructs.
 Advantages
 Support for a diverse array of viewpoints focused on many common software engineering concerns.
 Ubiquity improves comprehensibility.
 Extensive documentation and tool support from many vendors.
 Disadvantages
 Needs customization through profiles to reduce ambiguity.
 Difficult to assess consistency among views.
 Difficult to capture foreign concepts or views.



5.4.2 Early Architecture Description Languages
 There is no single definition of what constitutes an architecture description language.
 The uncertainty regarding this issue hinges on disagreement on what should and should not be included in the
concept of software architecture.
 Looking at architecture as a set of principal design decisions about a system, there are several languages that
fall into the category of ADLs.
 The early ADLs did not go past the research project stage and are not used in practice.
 However, they are an important part of architectural modeling development.
 A brief feature overview is provided below for three early ADLs: Darwin, Rapide, and Wright.
Darwin
 Darwin is a General-purpose architecture description language for specifying the structure of system composed
from components that communicate through explicit interfaces.
 Darwin has a canonical textual representation in which components and their interconnections are described.
 It is general purpose language with graphical and textual visualizations focused on structural modeling of
systems.
 Darwin is a declarative language that describes systems as collections of components interacting via explicit
interfaces.
 The notion of a software connector is not present, but a component that facilitates interactions can be
considered a connector.
 Darwin components expose a set of provide and required services, sometimes called ports.
 Advantages
 Simple, straightforward mechanism for modeling structural dependencies
 Interesting way to specify repeated elements through programmatic constructs
 Can be modeled in pi-calculus for formal analysis
 Can specify hierarchical (i.e., composite) structures
 Disadvantages
 Limited usefulness beyond simple structural modeling
 No notion of explicit connectors
 Although components can act as connectors.
Eg:
component DataStore{
provide values;
}
component Calculation{
require values;
provide calculationService;
}
component UserInterface{
require calculationService;
require values;
Rapide




Rapide is a language that focuses on modeling systems that consist of components communicating via events.
Procedure calls are supported by using two events: one for the call and one for the return value.
Events in Rapide are combined into partially-ordered sets.














Components in the system work concurrently.
Rapide’s textual description is similar to Darwin’s, except it also includes behavioral specifications.
Events can be subject to causal relationships. Such relationships exist if:
• both events are generated by the same process;
• process triggered by one event generates the other;
• Process triggered by one event assigns a value to a variable and the process triggered by the other
event reads it;
• one event triggers a connection that generates the other event;
• or events are related transitively (event A precedes C which precedes B).
Rapide provides a single viewpoint and focuses on modeling dynamic aspects of the architecture.
The static aspects are captured by interconnections among components.
Rapide models can be executed to simulate the system's operation.
The result of execution is a graph showing causal and temporal relationships between events present in the
system.
Consistency between multiple models of the same architecture can be checked via manual inspection of
simulator outputs.
Advantages
o Unique and expressive language for describing asynchronously communicating components
o Tool-set supports simulation of models and graphical visualization of event traces
Disadvantages
o No natural or explicit mapping to implemented systems
o High learning curve
o Important tool support is difficult to run on modern machines.

Wright
 Wright language deals with checking component interactions through their interfaces.
 The models include components, connectors, ports, roles (interfaces), attachments, and styles.
 Wright interfaces are based on notation derived from CSP - Communicating Sequential Process - and can be
translated into CSP.
 The resulting model can be analyzed in an automated way (using FDR) to determine compatibility of the
interfaces and to identify deadlocks.
 Wright supports static structural models with behavioral annotations describing component interactions.
 There is no support for non-functional aspects of the architecture.
 Structural, behavioral, and style viewpoints are supported.
 Automated correctness, consistency, and deadlock checks can be performed using a CSP evaluator.
 Advantages
 Structural specification similar to Darwin or Rapide
 Formal interface specifications can be translated automatically into CSP and analyzed with tools
 Can detect subtle problems e.g., deadlock
 Disadvantages
 High learning curve
 No direct mapping to implemented systems
 Addresses a small number of system properties relative to cost of use.
5.4.3 Domain- and Style –Specific ADLs
 Domain- and style specific ADLs are important for several reasons.
 First, their scope is better tailored to stakeholder needs since they target particular group of stakeholder, rather
than system and software developer in general.






Second they are able to leave unnecessary details.
Some architectural languages are created to support a particular architectural style or to model applications
within a particular domain.
Below three such ADLs are presented: Koala notation for modeling products in Philips TV product line, Weaves
notation for a modified pipe-and-filter architectural style , and AADL notation used for embedded and real-time
system modeling .

Koala
 Koala is a language developed by Philips to describe the architecture of consumer electronic devices.
 Koala models include components that communicate via explicit provided and required interfaces.
 It is a Darwin-inspired notation for specifying product lines of embedded consumer-electronics devices.
 Koala combines the concept of portals found in Darwin with constructs that support product-line architectures.
 Thus multiple products can be described with a single model representing a structural viewpoint where
differences are encoded as variation points.
 Advantages
 Advanced product-line features let you specify many systems in a single model
 Direct mapping to implemented systems promotes design and code reuse
 Disadvantages
 Limited to structural specification with additional focus on interfaces
Weaves
 Weaves [18] is an architectural style supported by a graphical modeling notation.
 Weaves can be seen as a variation of pipe-filter systems with three differences:
o Instead of byte streams, weaves deals with object streams.
o Instead of implicit pipes, Weaves connectors are object queues of explicit size.
o Instead of a single input and a single output, Weaves tools allows for multiple inputs and outputs.
 Models allow for components, connectors (queues) and directed interconnections.
 An architectural style and notation for modeling systems of small-grain tool fragments that communicates
through data flows of objects.
 Augmenting Weaves
o Weaves diagrams do not capture the protocol or kinds of data that flow across component boundaries
o This could be rectified through, for example, additional natural language or more formal (e.g., CSP)
protocol specifications
 Advantages
o Extremely optimized notation.
 Even simpler than Darwin diagrams.
o Close mapping to implemented systems.
 Disadvantages
o Addresses structure and data flows only.
AADL-The Architecture Analysis & Design Language
 AADL was initially created to model avionics systems.
 The notation is not specifically bound to that domain, however, and can be used in embedded and real-time
system modeling.
 AADL is a textual language that can be expressed graphically and is accompanied by a UML profile to capture
the information in several ways.









AADL includes constructs that describe both software and hardware components, as well as mapping between
them.
The components available include those for networks, buses, ports, threads, processes, and a large variety of
others.
AADL allows for specification of interfaces for flow of control and data.
There exists limited support for dynamic aspect modeling.
There is also support for some non-functional properties, such as timing, reliability, and safety, although they
cannot be automatically analysed. The models include a high level of detail.
The basic building block of this notation is a component, defined by its category (hardware, software, or
composite), type (how the component interacts with the outside world) and its implementation (an instance of
the component type).
Notation and tool-set for modeling hardware/software systems, particularly embedded and real-time systems



Advantages
o Allows detailed specification of both hardware and software aspects of a system
o Automated analysis tools check interesting end-to-end properties of system



Disadvantages
o Verbose; large amount of detail required to capture even simple systems
o Emerging tool support and UML profile support

5.4.4 Extensible ADLs
 Modeling involves a trade-off between being able to describe a variety of systems, and taking advantage of
semantically powerful features of more specialized languages, such as being able to automate model analysis
and code generation.
 One way to resolve this is to use a combination of several languages to describe the system.
 This entails keeping models in sync, which requires knowledge of multiple notations. This approach might also
result in inability to describe certain concerns in any of the notations.
 Another way to deal with the trade-off is to use extensible ADLs that strive to combine the flexibility of generic
languages with precision and analyzability of semantically rich languages.
 Extensible ADLs normally support the common architectural constructs (such as components and connectors)
and allow the user to extend the syntax to support user-defined constructs [1].
 Below three extensible ADLs are presented: Acme, ADML, and xADL.
ACME
 It is early general purpose ADL with support for extensibility through properties
 Acme provides a set of seven constructs: connectors, components, ports (interfaces on components), roles
(interfaces on connectors), attachments (links), systems (configurations), and representations (inner
architectures for components and connectors).
 Acme allows describing static aspects of the system natively, as well as dynamic and non-functional aspects
through the use of properties.
 Advantages
 Structural specification capabilities similar to Darwin
 Simple property structure allows for arbitrary decoration of existing elements
 Tool support with AcmeStudio
 Disadvantages
 No way to add new views


 Property specifications can become extremely complex and have entirely separate syntax/semantics of their
own.

Architectural Description Markup Language (ADML)







ADML is a language based on XML with its syntax derived from Acme.
Semantically ADML is nearly identical to Acme, with the exception of meta-properties, which allow for
specification of the properties and property types that should be present on particular elements.
ADML's syntax is defined using an XML DTD.
Advantages
o XML parsers and tools readily available.
o Added some ability to reason about types of properties with meta-properties.
Disadvantages
o Properties are still name-value pairs.
o Did not take advantage of XML extension mechanisms.

Extensible XML-based ADL (xADL)









xADL [22] is an XML-based domain-neutral extensible ADL that fully leverages XML's extensibility mechanisms to
extend the language.
The syntax of xADL is defined by XML Schemas.
xADL models are well-formed XML documents.
Extensibility is achieved through defining derived data types in separate schemas, thus allowing data types
declared in one schema to be extended in a different schema.
Advantages
u Growing set of generically useful modules available already
u Tool support in ArchStudio environment
u Users can add their own modules via well-defined extensibility mechanisms
Disadvantages
u Extensibility mechanisms can be complex and increase learning curve
u Heavy reliance on tools



Chapter 6: Analysis
Introduction
Architectural analysis is the activity of discovering important system properties using the system’s architectural models.
 Early, useful answers about relevant architectural aspects
 Available prior to system’s construction
6.1 Concerns Relevant to Architectural Analysis
 Goals of analysis
 Scope of analysis
 Primary architectural concern being analyzed
 Level of formality of architectural models
 Type of analysis
 Level of automation
 System stakeholders interested in analysis
6.2 Architectural Analysis Goals
 The four “C”s
o Completeness
o Consistency
o Compatibility
o Correctness
Completeness
 Completeness is both an external and an internal goal
 It is external with respect to system requirements
o Challenged by the complexity of large systems’ requirements and architectures
o Challenged by the many notations used to capture complex requirements as well as architectures
 It is internal with respect to the architectural intent and modeling notation
o Have all elements been fully modeled in the notation?
o Have all design decisions been properly captured?

Consistency
 Consistency is an internal property of an architectural model
 Ensures that different model elements do not contradict one another
 The goal of analysis is to find following inconsistencies, and then evaluate them
 Dimensions of architectural consistency
o Name
 Component and connector names
 Component service names
 May be non-trivial to establish at the architectural level
o Multiple system elements/services with identical names
o Loose coupling via publish-subscribe or asynchronous event broadcast
o Dynamically adaptable architectures
o Interface







Encompasses name consistency
Also involves parameter lists in component services
A rich spectrum of choices at the architectural level
Example: matching provided and required interfaces
ReqInt: getSubQ(Natural first, Natural last, Boolean remove)
returns FIFOQueue;
ProvInt1: getSubQ(Index first, Index last)
returns FIFOQueue;
ProvInt2: getSubQ(Natural first, Natural last, Boolean remove)
returns Queue;

o

Behavior
 Names and interfaces of interacting components may match, but behaviors need not.
 Example: subtraction
 Subtract (Integer x, Integer y) returns Integer;
o Can we be sure what the subtract operation does?
o If operation is arithmetic then,427-27=27
o And, if operation is computer calendar then, 427(27,april)-27(days)=331(31 march)





Example: QueueClient and QueueServer components
QueueClient
precondition q.size > 0;
postcondition ~q.size = q.size;
QueueServer
precondition q.size > 1;
postcondition ~q.size = q.size - 1;

o Interaction
Names, interfaces, and behaviors of interacting components may match, yet they may still be unable to interact
properly
Example: QueueClient and QueueServer components


o


Refinement
 Architectural models are refined during the design process
 A relationship must be maintained between higher and lower level models
o All elements are preserved in the lower level model
o All design decisions are preserved in the lower-level model
o No new design decisions violate existing design decisions

Compatibility
 Compatibility is an external property of an architectural model
 It is to check the compatibility between new and reused componentsconnectors, reference architecture and
propose architecture.
 Ensures that the architectural model adheres to guidelines and constraints of
o a style
o a reference architecture
o an architectural standard
Correctness
 Correctness is an external property of an architectural model
 Ensures that
o the architectural model fully realizes a system specification





o the system’s implementation fully realizes the architecture
Inclusion of off-the-shelf elements impacts correctness
o System may include structural elements, functionality, and non-functional properties that are not part of
the architecture
o The notion of fulfillment is key to ensuring architectural correctness.

6.3 Scope of Analysis
A software system’s architecture can be analyzed from different perspectives and at different levels. Architects may be
interested in assessing the properties of individual components or connectors, or even their constituent, such as
interfaces or ports.
Components- and Connector-Level Analysis
 This analysis ensures that the given component or connector provides the services expected of it.
 For example, a component’s or connector’s interface can be inspected to make sure that no expected services
are missing.
Subsystem- and system-Level Analysis
 Architects may assess the properties of connector-component compositions at the level of the entire system or
incrementally, by focusing on particular subsystems.
 The most manageable increment is pair-wise conformance, where only two interacting components are
considered at a time, and name, interface, behavior, and interaction conformance are established.
 The next step up is to take a set of components possibly interacting techniques can easily support both these
cases.
 Ensuring desirable properties at the techniques have tried to get a handle on this problem.
 In many real-time systems, a component that computes its results or provides data more quickly and/or
frequently than the system requires will be composed with a (simple) component that introduces the necessary
delays.
Data Exchanged in the System or Subsystem
 Distributed software systems large amounts of data are processed, exchanged, and stored.
 It is important that system’s data is properly modeled, implemented, and exchanged among the structural
elements. This involves assessing the data elements, include the following.
1. The structure of the data, such as typed versus untyped or discrete versus streamed.
2. The flow of the data through the system, such as point-to-point versus broadcast.
3. The properties of data exchanged, such as consistency, security, and latency.
 Example: In the following figure, Producer generating data at 1 mbps and, that data transfer to consumer1 and
comsumer2 at 2Mbps and 500kbps respectively through common connector.so here is the chances of data lost
because data has to wait for long time due to varying in their frequencies.



Architecture at Different Abstraction Levels
 During the architectural design process, architects frequently address the critical system requirements first, and
then both introduce additional elements into the architecture and refine the architecture to include additional
details that are necessary for the architecture’s realization into the final system.
 This may involve the addition and refinement of existing design.
 Example: in following figure, c1, c2, c3, c4 are components interacting through connectors, but this can be
design in more depth by extracting each component with their internal communication.

6.4 Architectural concern being analyzed
Architectural analysis techniques are directed at different facets of a given architecture. Some techniques ensure
structural properties, other focus on the behavior provided by the architectural elements and their composition;
In this section, we focus on each concern individually for ease of exposition and also discuss the relevant characteristics
of each.
Structural Characteristics
The structural characteristics of software architecture include concerns such as the connectivity among an architecture’s
components and connectors, containment of lower-level architectural element into composite higher-level elements,
possible points of network distribution, and a given system’s potential deployment architecture.Thses concerns can help
to determine whether the architecture is well formed.
Behavioral Characteristics
Analyzing architecture’s behavioral characteristics are needed if components and their interaction do not provide
expected behaviors.it has two facets;
1. Considering the internal behaviors of individual components.
2. Considering the architectural structure to assess composite behaviors.
Interaction characteristics
The relevant characteristics of interactions in a given architecture may include the numbers and types of distinct
software connectors, and their values for different connector dimensions.Intraction characteristics can help to establish
whether the architecture will actually be able to fulfill some of its requirements. Analysis of interaction characteristics
may also encompass the interaction protocols for different system components and internal behaviors specified for
different system connectors.



Non-Functional Characteristics
Non-functional characteristics form a critical dimension of almost all software systems. These characteristics typically cut
across multiple components and connectors, which make them particularly difficult to assess.
6.5 Level of Formality of Architectural Models
Architectural models can be classified as follows
 Informal models
o Informal models are typically captured in boxes-and-lines diagrams. Informal models can provide a
useful high-level picture of the system.
o They are amenable to informal and manual analysis, typically by a broad section of stakeholders,
including nontechnical stakeholders such as managers and system customers.
o For example, system managers can use them to determine a project’s overall staffing needs.




Semi-formal models
o Most architectural models used in practice are semiformal.
o A notation that strives to be useful to a large number of system stakeholders, both technical and
nontechnical, will typically try to strike a balance between a high degree of precision and formality on
the one hand, and expressiveness and understandability on the other.
o Example: a semiformal languages such as the UML are amenable both to manual and automated
analysis.
Formal models
o While semiformal modeling notations typically only have a formally defined syntax, formal notations
also have formally defined semantics.
o For example formal notation is wright, which was used to specify the Pipe-connector.

6.6 Types of Analysis
 Static analysis
o Static analysis involves inferring the properties of a software system from one or more of its models,
without actually executing those models.
o A simple example of static analysis is syntactic analysis: determining if the system model adheres to the
syntactic rules of the modeling notation.
o Static analysis can be automated (for eg.compilation) or manual (for eg.inspection).
 Dynamic analysis
o This analysis involves actually executing or simulating the execution of a model of the software system.
o In order to perform dynamic analysis on an architectural model, its semantic underpinning must be
executable or amenable to simulation.
 Scenario-driven analysis
o It can be an instance of both static and dynamic.
o It is used for large and complex software system. For such systems, specific-use cases are identified that
represent the most important or most frequently occurring system usage scenarios, and the analysis is
focus on those.



Note: Architectural Analysis in a Nutshell

6.7 Analysis Techniques
 Inspection- and review-based
 Architectural models studied by human stakeholders for specific properties
 The stakeholders define analysis objective
 Manual techniques
 Can be expensive
 Useful in the case of informal architectural descriptions
 Useful in establishing “soft” system properties
 E.g., scalability or adaptability
 Able to consider multiple stakeholders’ objectives and multiple architectural properties
Inspections and Reviews in a Nutshell
 Analysis Goals – any
 Analysis Scope – any
 Analysis Concern – any, but particularly suited for non-functional properties
 Architectural Models – any, but must be geared to stakeholder needs and analysis objectives
 Analysis Types – mostly static and scenario-based
 Automation Level – manual, human intensive
 Stakeholders – any, except perhaps component vendors
 Example – ATAM
 Stands for architectural trade-off analysis method
 Human-centric process for identifying risks early on in software design



 Focuses specifically on four quality attributes (NFPs)
 Modifiability
 Security
 Performance
 Reliability
 Reveals how well an architecture satisfies quality goals and how those goals trade-off
ATAM Process

 Model-based
 Analysis techniques that manipulate architectural description to discover architectural properties
 Tool-driven, hence potentially less costly
 Typically useful for establishing “hard” architectural properties only
o Unable to capture design intent and rationale
 Usually focus on a single architectural aspect
o E.g., syntactic correctness, deadlock freedom, adherence to a style
 Scalability may be an issue
 Techniques typically used in tandem to provide more complete answers




Model-Based Analysis in a Nutshell
 Analysis Goals – consistency, compatibility, internal correctness
 Analysis Concern – structural, behavioral, interaction, and possibly non-functional properties
 Architectural Models – semi-formal and formal
 Analysis Types – static
 Automation Level – partially and fully automated
 Stakeholders – mostly architects and developers
Eg: Model-Based Analysis in ADLs
 Wright – uses CSP to analyze for deadlocks










Aesop – ensures style-specific constraints
MetaH and UniCon – support schedulability analysis via NFPs such as component criticality and
priority
ADL parsers and compilers – ensure syntactic and semantic correctness
E.g., Rapide’s generation of executable architectural simulations
Architectural constraint enforcement
E.g., Armani or UML’s OCL
Architectural refinement
E.g., SADL and Rapide

 Simulation-based
 Requires producing an executable system model
 Simulation need not exhibit identical behavior to system implementation
 Many low-level system parameters may be unavailable
 It needs to be precise and not necessarily accurate
 Some architectural models may not be amenable to simulation
 Typically require translation to a simulatable language
 Simulation-Based Analysis in a Nutshell
 Analysis Goals – any
 Analysis Concern –behavioral, interaction, and non-functional properties
 Architectural Models – formal
 Analysis Types – dynamic and scenario-based
 Automation Level – fully automated; model mapping may be manual
 Stakeholders – any
 Example – XTEAM
 eXtensible Tool-chain for Evaluation of Architectural Models
 Targeted at mobile and resource-constrained systems
 Combines two underlying ADLs
o xADL and FSP
 Maps architectural description to adevs
o An OTS event simulation engine
 Implements different analyses via ADL extensions and a model interpreter
o Latency, memory utilization, reliability, energy consumption



Chapter 7: Implementation and Deployment
Implementation is the one phase of software development that is not optional. To achieve the goal specified in
software, that architecture must be implemented. In terms of implementation, architecture is both prescriptive and
restrictive. it is prescriptive in the sense that it gives implementers direction on what to produce-how to structure code
modules, how they should be interconnected, and how they should behave. it is restrictive in the sense that its
guidelines-particularly those specified in the architectural style-tell the developers what they may not do: the form of
communication that are prohibited, the kinds of behaviors or system states that are not allowed, and so on.
7.1 Concepts
7.1.1 The Mapping Problem
 Implementation is the one phase of software engineering that is not optional
 Architecture-based development provides a unique twist on the classic problem
o It becomes, in large measure, a mapping activity

Design
Decisions













Implementation
Artifacts

Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems
Common Element Mapping
Components and Connectors
o Partitions of application computation and communication functionality
o Modules, packages, libraries, classes, explicit components/connectors in middleware
Interfaces
o Programming-language level interfaces (e.g., APIs/function or method signatures) are common
o State machines or protocols are harder to map
Configurations
o Interconnections, references, or dependencies between functional partitions
o May be implicit in the implementation
o May be externally specified through a MIL and enabled through middleware
o May involve use of reflection
Design rationale
o Often does not appear directly in implementation
o Retained in comments and other documentation.
Dynamic Properties (e.g., behavior):
o Usually translate to algorithms of some sort
o Mapping strategy depends on how the behaviors are specified and what translations are available
o Some behavioral specifications are more useful for generating analyses or testing plans









Non-Functional Properties
o Extremely difficult to do since non-functional properties are abstract and implementations are concrete
o Achieved through a combination of human-centric strategies like inspections, reviews, focus groups,
user studies, beta testing, and so on
One-Way vs. Round Trip Mapping
Architectures inevitably change after implementation begins
o For maintenance purposes
o Because of time pressures
o Because of new information
Implementations can be a source of new information
o We learn more about the feasibility of our designs when we implement
o We also learn how to optimize them.

7.1.2 Architecture Implementation Frameworks
 Ideal approach: develop architecture based on a known style, select technologies that provide implementation
support for each architectural element
OO CLASS

Design
Decisions

Software
Library

Database






This is rarely easy or trivial
o Few programming languages have explicit support for architecture-level constructs
o Support infrastructure (libraries, operating systems, etc.) also has its own sets of concepts, metaphors,
and rules
To mitigate these mismatches, we leverage an architecture implementation framework
Definition: An architecture implementation framework is a piece of software that acts as a bridge between a
particular architectural style and a set of implementation technologies. It provides key elements of the
architectural style in code, in a way that assists developers in implementing systems that conform to the
prescriptions and constraints of the style.



OO Class

Design
Design
Decisions
Decisions

Software
Library

Database

7.1.3 Evaluating Frameworks
 Can draw out some of the qualitative properties just mentioned
 Platform support
o Target language, operating system, other technologies
 Fidelity
o How much style-specific support is provided by the framework?
 Many frameworks are more general than one target style or focus on a subset of the style rules
o How much enforcement is provided?
 Matching Assumptions
o Styles impose constraints on the target architecture/application
o Frameworks can induce constraints as well
 E.g., startup order, communication patterns …
o To what extent does the framework make too many (or too few) assumptions?
 Efficiency
o Frameworks pervade target applications and can potentially get involved in any interaction
o To what extent does the framework limit its slowdown and provide help to improve efficiency if possible
(consider buffering in stdio)?
 Other quality considerations
o Nearly every other software quality can affect framework evaluation and selection
 Size
 Cost
 Ease of use
 Reliability
 Robustness
 Availability of source code
 Portability
 Long-term maintainability and support



7.1.4 Middleware and Component Models
 This may all sound similar to various kinds of middleware/component frameworks
o CORBA, COM/DCOM, JavaBeans, .NET, Java Message Service (JMS), etc.
 They are closely related
o Both provide developers with services not available in the underlying OS/language
o CORBA provides well-defined interfaces, portability, remote procedure call…
o JavaBeans provides a standardized packaging framework (the bean) with new kinds of introspection and
binding
 Indeed, architecture implementation frameworks are forms of middleware
o There’s a subtle difference in how they emerge and develop
o Middleware generally evolves based on a set of services that the developers want to have available
 E.g., CORBA: Support for language heterogeneity, network transparency, portability
o Frameworks generally evolve based on a particular architectural style that developers want to use
 Why is this important?
 By focusing on services, middleware developers often make other decisions that substantially impact
architecture
 E.g., in supporting network transparency and language heterogeneity, CORBA uses RPC
o But is RPC necessary for these services or is it just an enabling technique?
 In a very real way, middleware induces an architectural style
o CORBA induces the ‘distributed objects’ style
o JMS induces a distributed implicit invocation style
 Understanding these implications is essential for not having major problems when the tail wags the dog!
Resolving Mismatches
 A style is chosen first, but the middleware selected for implementation does not support (or contradicts)
that style
 A middleware is chosen first (or independently) and has undue influence on the architectural style used
 Strategies
o Change or adapt the style
o Change the middleware selected
Use the middleware
o Develop glue code
as the basis for
o Leverage parts of the middleware
a framework
and ignore others
o Hide the middleware in components/connectors
7.1.5 Building a New Framework


Occasionally, you need a new framework
o The architectural style in use is novel
o The architectural style is not novel but it is being implemented on a platform for which no framework
exists


o The architectural style is not novel and frameworks exist for the target platform, but the existing
frameworks are inadequate
 Good framework development is extremely difficult
o Frameworks pervade nearly every aspect of your system
o Making changes to frameworks often means changing the entire system
o A task for experienced developers/architects
 Understand the target style first
o Enumerate all the rules and constraints in concrete terms
o Provide example design patterns and corner cases
 Limit the framework to the rules and constraints of the style
o Do not let a particular target application’s needs creep into the framework
o “Rule of three” for applications
 Choose the framework scope
o A framework does not necessarily have to implement all possible stylistic advantages (e.g., dynamism or
distribution)
 Avoid over-engineering
o Don’t add capabilities simply because they are clever or “cool”, especially if known target applications
won’t use them
o These often add complexity and reduce performance
 Limit overhead for application developers
o Every framework induces some overhead (classes must inherit from framework base classes,
communication mechanisms limited)
o Try to put as little overhead as possible on framework users
 Develop strategies and patterns for legacy systems and components
o Almost every large application will need to include elements that were not built to work with a target
framework
o Develop strategies for incorporating and wrapping these.
o
7.1.6 Concurrency
 Concurrency is one of the most difficult concerns to address in implementation
o Introduction of subtle bugs: deadlock, race conditions…
o Another topic on which there are entire books written
 Concurrency is often an architecture-level concern
o Decisions can be made at the architectural level
o Done carefully, much concurrency management can be embedded into the architecture framework
 Consider our earlier example, or how pipe-and-filter architectures are made concurrent without direct user
involvement
7.1.7 Generative Technologies
 With a sufficiently detailed architectural model, various implementation artifacts can be generated
o Entire system implementations


o
o

 Requires extremely detailed models including behavioral specifications
 More feasible in domain-specific contexts
Skeletons or interfaces
 With detailed structure and interface specifications
Compositions (e.g., glue code)
 With sufficient data about bindings between two elements

7.1.8 Ensuring Architecture-to-Implementation Consistency
 Strategies for maintaining one-way or round-trip mappings
o Create and maintain traceability links from architectural implementation elements
 Explicit links in a database, in architectural models, in code comments can all help with
consistency checking
o Make the architectural model part of the implementation
 When the model changes, the implementation adapts automatically
 May involve “internal generation”
o Generate some or all of the implementation from the architecture.

7.2 Existing Frameworks
1. Different frameworks for pipe-and-filter
Framework #1: stdio


Standard I/O framework used in C programming language



Each process is a filter


Reads input from standard input (aka ‘stdin’)



Writes output to standard output (aka ‘stdout’)
 Also a third, unbuffered output stream called standard error (‘stderr’) not considered here

 Low and high level operations
 getchar(…), putchar(…) move one character at a time
 printf(…) and scanf(…) move and format entire strings


Different implementations may vary in details (buffering strategy, etc.)

Evaluating stdio


Platform support
o

Available with most, if not all, implementations of C programming language

o


Fidelity
o



Good support for developing P&F applications, but no restriction that apps have to use this style

Matching assumptions
o



Operates somewhat differently on OSes with no concurrency (e.g., MS-DOS)

Filters are processes and pipes are implicit. In-process P&F applications might require modifications

Efficiency
o

Whether filters make maximal use of concurrency is partially up to filter implementations and
partially up to the OS

Framework #2: java.io


Standard I/O framework used in Java language



Object-oriented



Can be used for in-process or inter-process P&F applications
o

All stream classes derive from InputStream or OutputStream

o

Distinguished objects (System.in and System.out) for writing to process’ standard streams

o

Additional capabilities (formatting, buffering) provided by creating composite streams (e.g., a
Formatting-Buffered-InputStream)

Evaluating java.io
 Platform support
o

Available with all Java implementations on many platforms

o

Platform-specific differences abstracted away

 Fidelity
o

Good support for developing P&F applications, but no restriction that apps have to use this style

 Matching assumptions
o

Easy to construct intra- and inter-process P&F applications

o

Concurrency can be an issue; many calls are blocking



 Efficiency
o

Users have fine-grained control over, e.g., buffering

o

Very high efficiency mechanisms (memory mapped I/O, channels) not available (but are in java.nio)

2. Different frameworks for the C2 style
Framework #1: Lightweight C2 Framework


16 classes, 3000
lines of code



Components & connectors extend abstract base classes



Concurrency, queuing handled at individual comp/conn level



Messages are request or notification objects



Evaluating Lightweight C2 Framework


Platform support
o



Available with all Java implementations on many platforms

Fidelity
o
o



Assists developers with many aspects of C2 but does not enforce these constraints
Leaves threading and queuing policies up to individual elements

Matching assumptions
o
o



Comp/conn main classes must inherit from distinguished base classes
All messages must be in dictionary form

Efficiency
o

Lightweight framework; efficiency may depend on threading and queuing policy implemented by
individual elements.



Chapter 8: Applied Architectures and Styles
In this chapter, we discussing how a wide variety of important and challenging architectural problem solved, thereby
enhancing the repertoire of insights and styles that a designer possesses to bring to bear on his own problem.
Goals of this chapter are thus to:
 Describe how the concepts from the previous chapters can be used, sometimes in combination, to solve challenging
design problems.
 Highlight key issues in emerging application domains that have architectural implications, or where an architectural
perspective is essential for system development within that domain.
 Show how emerging architectures, such as P2P, can be characterized and understood through the lens of software
architecture.
8.1 Distributed and networked architectures
The phrase “distributed application” is used to denote everything from an application that is simply distributed
across multiple operating system processes all running on the same physical uniprocessor, to integrated applications
that run on multiple computers connected by the internet.
8.1.1

Limitations of the distributed systems viewpoint
A particular design choice the designer made was to attempt to provide the illusion of “location transparency.”
That is, that a developer should not know where the other object is located in order to interact with that
object.(similarly, in Implementation transparency ,developer need not know that choice of programming
language in which that object is implemented.) If such transparency is provided to the developer, all the
concerns and issues associated across a network can be ignored, for those issues will be taken care of by the
underlying CORBA support. But by looking at CORBA API, reveals that, achieving such transparency has not
proved to be fully possible.
The multiple difficulties of attempting to mask the presence of networks and their properties from application
developers was recognized early and become canonized by Peter Deutsch in his short list, as Deutsch and his
colleague James say, “Essentially everyone ,when they first build a distributed application, makes the following
eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning exercises.”
The fallacies are,


The network is reliable



Latency is zero



Bandwidth is infinite



The network is secure



Topology doesn’t change



There is one administrator



Transport cost is zero




The network is homogeneous

8.2 Architectures for the Network-Based Applications
8.2.1

The REpresentational State Transfer Style (REST)
The REST architectural style was used to design the post-1994 World Wide Web (which includes the HTTP/1.1
protocol, the Uniform Resource Identifier specification, and other elements). The goal of that representation
was to begin to indicate the power of software architecture, showing its impact on one of the world’s most
widespread technologies. That presentation also indicated how software architecture is not something you can
necessarily derive by looking at piece of code (for example, the Apache web server).
Application Drivers
Architecture in Action: WWW
Fig.1

Fig.2



Fig. 3

All three ideas (Fig.1, 2, 3) are of WWW
WWW’s Architecture


The application is distributed (actually, decentralized) hypermedia



Architecture of the Web is wholly separate from the code



There is no single piece of code that implements the architecture.



There are multiple pieces of code that implement the various components of the architecture.
u



Stylistic constraints of the Web’s architectural style are not apparent in the code
u



E.g., different Web browsers

The effects of the constraints are evident in the Web

One of the world’s most successful applications is only understood adequately from an architectural vantage
point.



REST Principles


The key abstraction of information is a resource, named by an URL. Any information that can be named can be a
resource.



The representation of a resource is a sequence of bytes, plus representation metadata to describe those bytes.
The particular form of the representation can be negotiated between REST components.



All interactions are context-free: each interaction contains all of the information necessary to understand the
request, independent of any requests that may have preceded it.



Components perform only a small set of well-defined methods on a resource producing a representation to
capture the current or intended state of that resource and transfer that representation between components.
These methods are global to the specific architectural instantiation of REST; for instance, all resources exposed
via HTTP are expected to support each operation identically.



Idempotent operations and representation metadata are encouraged in support of caching and representation
reuse.



The presence of intermediaries is promoted. Filtering or redirection intermediaries may also use both the
metadata and the representations within requests or responses to augment, restrict, or modify requests and
responses in a manner that is transparent to both the user agent and the origin server.
An Instance of REST
Gateway

Proxy
$

b
Proxy
$
http

Client Connector:





http

$
http

c
DNS

orb

DNS

User Agent
$

$

http

http

a

Origin Servers

Client+Cache: $

REST — Data Elements
Resource
u Key information abstraction
Resource ID
Representation
u Data plus metadata

wais
Server Connector:

Server+Cache:

$




















Representation metadata
Resource metadata
Control data
u e.g., specifies action as result of message
REST — Connectors
Modern Web Examples
client
libwww, libwww-perl
server
libwww, Apache API, NSAPI
cache
browser cache, Akamai cache network
resolver bind (DNS lookup library)
tunnel
SOCKS, SSL after HTTP CONNECT
REST — Components
User agent
o e.g., browser
Origin server
o e.g., Apache Server, Microsoft IIS
Proxy
o Selected by client
Gateway
o Squid, CGI, Reverse proxy
o Controlled by server
Derivation of REST
Key choices in this derivation include,
Layered Separation (a theme in the middle portion of diagram) is used to increase efficiencies, enable
independent evolution of elements of the system, and provide robustness;
In order to further improve behavior for Internet-scale requirements, we add layered system constraints. The
layered system style allows architecture to be composed of hierarchical layers by constraining component
behavior such that each component cannot "see" beyond the immediate layer with which they are interacting.
By restricting knowledge of the system to a single layer, we place a bound on the overall system complexity and
promote substrate independence. Layers can be used to encapsulate legacy services and to protect new services
from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary.
Intermediaries can also be used to improve system scalability by enabling load balancing of services across
multiple networks and processors. The primary disadvantage of layered systems is that they add overhead and
latency to the processing of data, reducing user-perceived performance . For a network-based system that
supports cache constraints, this can be offset by the benefits of shared caching at intermediaries. Placing shared
caches at the boundaries of an organizational domain can result in significant performance benefits . Such layers
also allow security policies to be enforced on data crossing the organizational boundary, as is required by
firewalls.






Replication (left side of the diagram) is used to address latency and contention by allowing the reuse of
information; the existence of replication is hidden from clients, of course, as a result of intermediate layers.
One particular form of replication is caching information. Rather than duplicating information sources
irrespective of the particular information actually requested of them, caches may maintain copies of information
that has already been requested or that is anticipated to be requested. Cache can be located on the interface to
a client or server connector in order to save cacheable responses to current interactions so that they can be
reused for later requested interactions. A cache may be used by a client to avoid repetition of network
communication, or by a server to avoid repeating the process of generating a response, with both cases serving
to reduce interaction latency. A cache is typically implemented within the address space of the connector that
uses it.
Limited commonality (right side) addresses the competing needs for universally understood operations with
extensibility. The parts of a distributed application can be made to work together either by demanding that a
common body of a code be used for managing all communications, or through imposition of standards
governing that communication. Clearly the use of standards to govern communication is superior to common
code in an open, heterogeneous application. Innovation is fostered; local specialization may be support,
different hardware platforms used, and so on.

8.3 Commercial Internet-scale applications
8.3.1

Akamai
 Caching to the max
 Akamai's technology – at its core, applied mathematics and algorithms - has transformed the chaos of
the Internet into a predictable, scalable, and secure platform for business and entertainment. The
Akamai EdgePlatform comprises 84,000 servers deployed in 72 countries that continually monitor the


Internet – traffic, trouble spots and overall conditions. We use that information to intelligently optimize
routes and replicate content for faster, more reliable delivery. As Akamai can handle up to 15-20% of
Web traffic on any given day, our view of the Internet is the most comprehensive and dynamic
collected anywhere.

8.3.2

Google


Google distributed file system (GFS)



MapReduce
o

Data selection and reduction

o

All parallelization done automatically



Abstraction layers abound: GFS hides details of data distribution and failure, for instance; MapReduce
hides the intricacies of parallelizing operations;



By designing, from the outset, for living with failure of processing, storage, and network elements, a highly
robust system can be created;



Scale is everything: Google’s business demands that everything be built with scaling issues in mind;



By specializing the design to the problem domain, rather than taking the generic “industry standard”
approach, high performance and very cost-effective solutions can be developed;



By developing a general approach (MapReduce) to the data extraction/reduction problem, a highly reusable
service was created.

8.4 Decentralized applications



8.4.1

Networked applications where there are multiple authorities
In other words
u Computation is distributed
u Parts of the network may behave differently, and vary over time

Shared Resource Computation: The Grid world




Coordinated resource sharing in a distributed environment
u E.g., Folding-at-home
GLOBUS
u A commonly used infrastructure
“Standard architecture”
u Fabric manages low-level resources
u Connectivity: communication and authentication



u Resource: sharing of a single r.
u Collective: coordinating r. usage
Grid GLOBUS (Recovered)

8.4.2










Peer-to-peer styles
Decentralized resource sharing and discovery
o Napster
o Gnutella
P2P that works: Skype
o And BitTorrent
Peer-to-peer style
State and behavior are distributed among peers which can act as either clients or servers.
Peers: independent components, having their own state and control thread.
Connectors: Network protocols, often custom.
Data Elements: Network messages
Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically
Supports decentralized computing with flow of control and resources distributed among peers. Highly robust in
the face of failure of any given node. Scalable in terms of access to resources and computing power. But caution
on the protocol!

Hybrid Client-Server/P2P:Napster

Pure Decentralized P2P:Gnutella (original)




Overlayed P2P: SKype

Insights from Skype


A mixed client-server and peer-to-peer architecture addresses the discovery problem.



Replication and distribution of the directories, in the form of supernodes, addresses the scalability problem and
robustness problem encountered in Napster.



Promotion of ordinary peers to supernodes based upon network and processing capabilities addresses another
aspect of system performance: “not just any peer” is relied upon for important services.



A proprietary protocol employing encryption provides privacy for calls that are relayed through supernode
intermediaries.



Restriction of participants to clients issued by Skype, and making those clients highly resistant to inspection or
modification, prevents malicious clients from entering the network.

Service-Oriented Architectures and web services.




Chapter 9: Designing for Non-Functional Properties
9.1 What Is an NFP?
 A software system’s non-functional property (NFP) is a constraint on the manner in which the system implements
and delivers its functionality
 Example of NFPs
u

Efficiency

u

Complexity

u

Scalability

u

Heterogeneity

u

Adaptability

u

Dependability

9.2 Designing for FPs


Any engineering product is sold based on its functional properties (FPs)
u



TV set, DVD player, stereo, mobile telephone

Providing the desired functionality is often quite challenging
u
u

Competition

u

Strict deadlines

u


Market demands

Limited budgets

However, the system’s success will ultimately rest on its NFPs
u

“This system is too slow!”

u

“It keeps crashing!”

u

“It has so many security holes!”

u

“Every time I change this feature I have to reboot!”

u

“I can’t get it to work with my home theater!”



9.3 FPs vs. NFPs – An Example


Microsoft Word 6.0
u

Released in the 1990s

u

Both for the PC and the Mac

u

Roughly the same functionality

u

It ran fine on the PC and was successful

u

It was extremely slow on the Mac

u

Microsoft “solved” the problem by charging customers for downgrades

u

A lot of bad publicity

9.4 Design Guidelines for Ensuring NFPs


Only guidelines, not laws or rules



Promise but do not guarantee a given NFP



Necessary but not sufficient for a given NFP



Have many caveats and exceptions



Many trade-offs are involved

9.5 Efficiency


Efficiency is a quality that reflects a software system’s ability to meet its performance requirements while
minimizing its usage of the resources in its computing environment
u



Efficiency is a measure of a system’s resource usage economy

What can software architecture say about efficiency?
u

Isn’t efficiency an implementation-level property?

 Efficiency starts at the architectural level!
Software Components and Efficiency






Keep the components “small” whenever possible
Keep component interfaces simple and compact
Allow multiple interfaces to the same functionality
Separate data components from processing components
Separate data from meta-data



Software Connectors and Efficiency
 Carefully select connectors
 Use broadcast connectors with caution
 Make use of asynchronous interaction whenever possible
 Use location/distribution transparency judiciously
Architectural Configurations and Efficiency
 Keep frequently interacting components “close”
 Carefully select and place connectors in the architecture
 Consider the efficiency impact of selected architectural styles and patterns.
9.6 Complexity
 IEEE Definition
u Complexity is the degree to which a software system or one of its components has a design or
implementation that is difficult to understand and verify
 Complexity is a software system’s a property that is directly proportional to the size of the system, number of its
constituent elements, their internal structure, and the number and nature of their interdependencies
Software Components and Complexity
 Separate concerns into different components
 Keep only the functionality inside components
u Interaction goes inside connectors
 Keep components cohesive
 Be aware of the impact of off-the-shelf components on complexity
 Insulate processing components from changes in data format
Software Connectors and Complexity
 Treat connectors explicitly
 Keep only interaction facilities inside connectors
 Separate interaction concerns into different connectors
 Restrict interactions facilitated by each connector
 Be aware of the impact of off-the-shelf connectors on complexity
Architectural Configurations and Complexity
 Eliminate unnecessary dependencies
 Manage all dependencies explicitly
 Use hierarchical (de)composition
9.7 Scalability and Heterogeneity
 Scalability is the capability of a software system to be adapted to meet new requirements of size and scope
 Heterogeneity is the quality of a software system consisting of multiple disparate constituents or functioning in
multiple disparate computing environments
u Heterogeneity is a software system’s ability to consist of multiple disparate constituents or function in
multiple disparate computing environments
u Portability is a software system’s ability to execute on multiple platforms with minimal modifications
and without significant degradation in functional or non-functional characteristics



Software Components and Scalability
 Give each component a single, clearly defined purpose
 Define each component to have a simple, understandable interface
 Do not burden components with interaction responsibilities
 Avoid unnecessary heterogeneity
u Results in architectural mismatch
 Distribute the data sources
 Replicate data when necessary
Software Connectors and Scalability
 Use explicit connectors
 Give each connector a clearly defined responsibility
 Choose the simplest connector suited for the task
 Be aware of differences between direct and indirect dependencies
 Avoid placing application functionality inside connectors
u Application functionality goes inside components
 Leverage explicit connectors to support data scalability
Architectural Configurations and Scalability
 Avoid system bottlenecks
 Make use of parallel processing capabilities
 Place the data sources close to the data consumers
 Try to make distribution transparent
 Use appropriate architectural styles
9.8 Adaptability
 Adaptability is a software system’s ability to satisfy new requirements and adjust to new operating conditions
during its lifetime.
Software Components and Adaptability
 Give each component a single, clearly defined purpose
 Minimize component interdependencies
 Avoid burdening components with interaction responsibilities
 Separate processing from data
 Separate data from metadata
Software Connectors and Adaptability
 Give each connector a clearly defined responsibility
 Make the connectors flexible
 Support connector composability
Architectural Configurations and Adaptability
 Leverage explicit connectors
 Try to make distribution transparent
 Use appropriate architectural styles



9.9 Dependability
 Dependability is a collection of system properties that allows one to rely on a system functioning as required
u Reliability is the probability that a system will perform its intended functionality under specified design
limits, without failure, over a given time period
u Availability is the probability that a system is operational at a particular time
u Robustness is a system’s ability to respond adequately to unanticipated runtime conditions
u Fault-tolerant is a system’s ability to respond gracefully to failures at runtime
u Survivability is a system’s ability to resist, recognize, recover from, and adapt to mission-compromising
threats
u Safety denotes the ability of a software system to avoid failures that will result in (1) loss of life, (2)
injury, (3) significant damage to property, or (4) destruction of property
Software Components and Dependability
 Carefully control external component inter-dependencies
 Provide reflection capabilities in components
 Provide suitable exception handling mechanisms
 Specify the components’ key state invariants
Software Connectors and Dependability
 Employ connectors that strictly control component dependencies
 Provide appropriate component interaction guarantees
 Support dependability techniques via advanced connectors
Architectural Configurations and Dependability
 Avoid single points of failure
 Provide back-ups of critical functionality and data
 Support non-intrusive system health monitoring
 Support dynamic adaptation

References
1. All chapter’s ppts.
http://www.softwarearchitecturebook.com/svn/main/slides/ppt/
2. REST Information
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm


software architecture

More Related Content

What's hot (20)

Similar to software architecture (20)

Recently uploaded (20)

software architecture