Software Architecture (Ch1 - Ch9) Suresh Mistry PDF
Software Architecture (Ch1 - Ch9) Suresh Mistry PDF
Software Architecture (Ch1 - Ch9) Suresh Mistry PDF
Suresh Mestry
Mobile No:8097404245
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.)
1
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
• 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
Requirements
Design (blueprints)
Construction
Use
Architectures in Context
Fundamental Understanding
Three fundamental understandings of software architecture, the recognition of which helps situate
architecture with respect to the software engineering:
2
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Every application has at least one architect
Architecture-Centric Design
Architecture-centric design
stakeholder issues
deployment issues
Requirements
Design
Implementation
Evolution
Development Process
3
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
The fig shows how all context fits together
4
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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 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”
5
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
Kruchten
Software architecture deals with the design and implementation of the high-
6
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
A software system’s architecture typically is not (and should not be) a uniform monolith
Processing
Interaction
Components:
Elements that encapsulate processing and data in a system’s architecture are referred to as software
components
Definition
Put another way, a software component is a locus of computation and state in a system.
7
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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.
8
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Examples:
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
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.
9
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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?
Models
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.
10
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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.
11
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
2. Conventional Architectural styles
Terminology
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.
12
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
13
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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 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.
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.
14
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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
Enhancement is supported through limiting the number of other layers with which communication
occurs.
15
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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:
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.
16
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
17
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
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.
18
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Conditions under which this process may not work:
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.
Standard
Cyclic
Parallel
o 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
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.
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.
19
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
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?
Simple machines provide a plausible first conception of how an application might be built.
Simple Machines:
20
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
Separation of Concerns
The difficulties arise when the issues are either actually or apparently intertwined.
Key example from software architecture: separation of components (computation) from connectors
(communication)
Experience can be a masterful teacher, however, and can provide the guidance necessary to wield the basic
tools in an effective fashion.
The lessons from prior work include not only the lessons of successes, but also the lessons arising from failure.
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.
21
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
22
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
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.
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
23
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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.
Thus, the view can update itself and the controller can modify the view if its logic so requires.
When handling input from the user the windowing system sends the user event to the controller.
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.
24
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
sensors from various devisec are connected to the computer and may be simpled to determine their
value.
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.
Many styles exist and we will discuss them in detail in the next lecture
25
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
are applicable in a given development context
constrain architectural design decisions that are specific to a particular system within that context
A semantic interpretation
Design reuse
Code reuse
26
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Interoperability
Style-specific analyses
Visualizations
o Object-oriented
Layered
o Virtual machines
o Client-server
Data-flow styles
o Batch sequential
Shared memory
o Blackboard
o Rule based
Interpreter
o Interpreter
o Mobile code
Implicit invocation
o Event-based
o Publish-subscribe
Peer-to-peer
27
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
“Derived” styles
o C2
o CORBA
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
Object-Oriented
28
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
29
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
30
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
31
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
32
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
33
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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)
34
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
35
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
36
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
37
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
38
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
39
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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).
40
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
41
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Chapter 5: Modeling
Introduction
Recall that we have characterized architecture as the set of principal design decisions made about a system.
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
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:
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.
One of the most critical decisions that architects and other stakeholders will make in developing architecture is to
choose:
42
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
1. What architectural decisions and concepts should be modeled,
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.
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.
Although the steps outlined above are in rough chronological order, they can be incorporated into an iterative process.
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.
43
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Rationale – Rational is the information that explains why particular architectural decisions were made ,and what
purpose various elements serve .
“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.
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.
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.
44
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
5.1.4 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.
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.
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
Because conflicting interpretations of a model may lead to misunderstandings, bugs, and errors, it is generally
desirable to eliminate ambiguity in design.
45
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
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.
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.
46
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
5.3.1 Views and Viewpoints
Generally, it is not feasible to capture everything we want to model in a single model or document
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. They provide a way to limit presented information to a cognitively manageable subset of the architecture.
2. They display related concepts simultaneously.
3. They can be tailored to the needs of specific stakeholders.
4. They can be used to display the same data at various levels of abstraction.
o There is the possibility that the views can thus become inconsistent with one another
Views are consistent if the design decisions they contain are compatible
o Views are inconsistent if two views assert design decisions that cannot simultaneously be true
47
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
o Inconsistencies cannot always be fixed.
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.
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.
48
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
49
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
50
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
51
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
52
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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
53
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Property specifications can become extremely complex and have entirely separate syntax/semantics of their
own.
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
54
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
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
55
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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;
returns FIFOQueue;
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)
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
56
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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 components\connectors, 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
57
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
58
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
59
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
60
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Note: Architectural Analysis in a Nutshell
61
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
62
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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 Scope – 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
63
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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 Implementation
Decisions 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
64
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
Design
Decisions Software
Library
Database
65
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
OO Class
Design
Design Software
Decisions
Decisions Library
Database
66
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
o Develop glue code Use the middleware
o Leverage parts of the middleware as the basis for
and ignore others a framework
o Hide the middleware in components/connectors
67
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
68
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Requires extremely detailed models including behavioral specifications
More feasible in domain-specific contexts
o Skeletons or interfaces
With detailed structure and interface specifications
o Compositions (e.g., glue code)
With sufficient data about bindings between two elements
Also a third, unbuffered output stream called standard error (‘stderr’) not considered here
Evaluating stdio
Platform support
69
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
o Operates somewhat differently on OSes with no concurrency (e.g., MS-DOS)
Fidelity
o Good support for developing P&F applications, but no restriction that apps have to use this style
Matching assumptions
o 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
Object-oriented
o Distinguished objects (System.in and System.out) for writing to process’ standard streams
Evaluating java.io
Platform support
Fidelity
o Good support for developing P&F applications, but no restriction that apps have to use this style
Matching assumptions
70
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Efficiency
o Very high efficiency mechanisms (memory mapped I/O, channels) not available (but are in java.nio)
16 classes, 3000
lines of code
71
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Evaluating Lightweight C2 Framework
Platform support
Fidelity
o Assists developers with many aspects of C2 but does not enforce these constraints
Matching assumptions
Efficiency
o Lightweight framework; efficiency may depend on threading and queuing policy implemented by
individual elements.
72
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
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.
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.
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.”
Latency is zero
Bandwidth is infinite
73
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Topology doesn’t change
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
Fig.1 Fig.2
74
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Fig. 3
WWW’s Architecture
There are multiple pieces of code that implement the various components of the architecture.
Stylistic constraints of the Web’s architectural style are not apparent in the code
One of the world’s most successful applications is only understood adequately from an architectural vantage
point.
75
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
$ $ orb
http http
http
a
User Agent DNS
b
$ $
http
c Proxy
DNS $
http wais
76
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.
77
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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.1 Akamai
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
78
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
MapReduce
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.
79
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
u Resource: sharing of a single r.
u Collective: coordinating r. usage
Grid GLOBUS (Recovered)
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!
80
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Hybrid Client-Server/P2P:Napster
81
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Overlayed P2P: SKype
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.
82
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Service-Oriented Architectures and web services.
83
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
u Market demands
u Competition
u Strict deadlines
u Limited budgets
84
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
9.3 FPs vs. NFPs – An Example
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
85
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Software Connectors and Efficiency
Carefully select connectors
Use broadcast connectors with caution
Make use of asynchronous interaction whenever possible
Use location/distribution transparency judiciously
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
86
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
9.8 Adaptability
Adaptability is a software system’s ability to satisfy new requirements and adjust to new operating conditions
during its lifetime.
87
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
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
88
Software Architecture Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
References
2. REST Information
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
89