2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
software architecture
1. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Introduction to Software Architecture
Basic Idea about Software Architecture
Software Architecture is the way of decomposing complex system into many sub problems or subsystem.
The Institute of Electrical and Electronic Engineers (IEEE) recently issued a recommended practice regarding
Software Architecture: IEEE 1471. The definitions we provide in this book are closely aligned with IEEE 1471.
These include definitions of system, stakeholder, architect, architecture, architectural views and architectural
viewpoints.
IEEE 1471 defines the following key terms:
• System is a set of components that accomplishes a specific function or set of functions.
• ‘Architecture is the fundamental organization of a system embodied in its components, their
relationships to each other, and to the environment, and the principles guiding its design and
evolution’.
• Architectural Description is a set of products that document the architecture.
• Architectural View is a representation of a particular system or part of a system from a
particular perspective.
• Architectural Viewpoint is a template that describes how to create and use an architectural
view. A viewpoint includes a name, stakeholders, concerns addressed by the viewpoint, and
the modeling and analytic conventions.
Design:
“There are two ways of constructing a software design:
One way is to make it so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies.” - C.A.R. Hoare
What Is Design?
♦ Requirements specification was about the WHAT the system will do
♦ Design is about the HOW the system will perform its functions
provides the overall decomposition of the system
allows splitting the work among a team of developers
also lays down the groundwork for achieving non-functional requirements
(Performance, maintainability, reusability, etc.)
takes target technology into account (e.g., kind of middleware, database
design, etc.)
Software Development Activities
• Requirements Elicitation
• Requirements Analysis (e.g., Structured Analysis, OO Analysis)
• analyzing requirements and working towards a conceptual model without taking
the target implementation technology into account
• Useful if the conceptual gap between requirements and implementation is large
2. 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
Analogy: Architecture of Buildings
We all live in them
(We think) We know how they are built
Design (blueprints)
Construction
Requirements
Use
This is similar (though not identical) to how we build software.
Architectures in Context
Fundamental Understanding
Architecture is a set of principal design decisions about a software system
Three fundamental understandings of software architecture, the recognition of which helps situate
architecture with respect to the software engineering:
Every application has an architecture
3. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Every application has at least one architect
Architecture is not a phase of development
Wrong View: Architecture as a Phase
Treating architecture as a phase denies its foundational role in software development
More than “high-level design”
Architecture is also represented, e.g., by object code, source code, …
Architecture-Centric Design
Traditional design phase suggests translating the requirements into algorithms, so a
programmer can implement them
Architecture-centric design
stakeholder issues
decision about use of COTS component
overarching style and structure
package and primary class structure
deployment issues
post implementation/deployment issues
Context of Software Architecture
Requirements
Design
Implementation
Analysis and Testing
Evolution
Development Process
4. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
The fig shows how all context fits together
(Frameworks and the implementation activity in the context of development.
Activities are shown in left column; artifacts are in the central column; notes are on the right.)
5. 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 Non-functional properties-for example, “The system’s
dependability will be ensured by replicated processing modules.”
Design decision related to system’s implementation-for example, ”the user interface components will
be built using the Java Swing toolkit.”
What is “Principal”?
“Principal” implies a degree of importance that grants a design decision “architectural status”
It implies that not all design decisions are architectural
6. 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
Other Definitions of Software Architecture
Perry and Wolf
Software Architecture = { Elements, Form, Rationale }
what
how
why
Shaw and Garlan
Software architecture [is a level of design that] involves
interactions among those elements,
patterns that guide their composition, and
the description of elements from which systems are built,
Constraints on these patterns.
Kruchten
Software architecture deals with the design and implementation of the highlevel structure of software.
Architecture deals with abstraction, decomposition, composition, style, and aesthetics.
A software architecture is defined as follows:
Software architecture- A model that describes the structure of a software system in
terms of computational components, the relationships among components, and the
constraints for assembling the components.
That is, a software architecture can be defined in terms of the following elements:
software architecture = {components, relationships, constraints}
These elements are defined as follows:
Components- Components are the computational elements which collectively constitute
architecture. Software architecture is typically decomposed into subsystems, which in
turn may be decomposed into modules. Further decomposition is also possible. (For
example in an object-oriented design, modules may be decomposed into classes.)
Examples of components include clients, services, and persistent stores.
Relationships- Relationships are the logical connections between architectural
components. Examples of abstract component relationships include dependency,
7. 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.
Software Architecture’s Elements
A software system’s architecture typically is not (and should not be) a uniform monolith
A software system’s architecture should be a composition and interplay of different elements
Data, also referred as information or state
Processing
Interaction
Software architectures have 3 types of elements
– Components
– Connectors
– Configuration
Components:
Elements that encapsulate processing and data in a system’s architecture are referred to as software
components
Definition
A software component is an architectural entity that
restricts access to that subset via an explicitly defined interface
encapsulates a subset of the system’s functionality and/or data
has explicitly defined dependencies on its required execution context
Components typically provide application-specific services.
Put another way, a software component is a locus of computation and state in a system.
8. 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
A software connector is an architectural element tasked with effecting and regulating
interaction among components.
In traditional desktop software system, connectors usually have manifest themselves as simple
procedure calla or shared data access.
Simple connectors are usually restricted to enabling the interaction of pairs of components.
However, as software system has become more complex, so have connectors, with their own separate
identities, roles, and bodies of implantation-level code, as well as ability to simultaneously service
many different components.
Connectors typically provide application-independent interaction facilities.
9. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Examples:
Procedure call connectors
Shared memory connectors
Message passing connectors
Streaming connectors
Distribution connectors
Wrapper/adaptor connectors
Configuration:
Components and connectors are composed in a specific way in a given system’s architecture to
accomplish that system’s objective. That composition represents the system’s configuration, also
referred as topology
Definition
An architectural configuration, or topology, is a set of specific associations between the
components and connectors of a software system’s architecture
A configuration may be represented as a graph wherein nodes represent components and connectors,
and whose edges represent their associations.
Architectural Styles
Definition
An Architectural Style is a named collection of architectural design decisions that (1) are
applicable in a given development context, (2) constrain architectural design decisions that
are specific to a particular system within that context, and (3) elicit beneficial qualities in each
resulting system.
Architectural styles classify architecture in terms of the use of form, techniques, materials, time period,
region and other stylistic influences.
It overlaps with, and emerges from the study of the evolution and history of architecture. In
architectural history, the study of Gothic architecture, for instance, would include all aspects of the
cultural context that went into the design and construction of these structures.
10. 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
An Architectural Pattern is a named collection of architectural design decisions that are
applicable to a recurring design problem parameterized to account for different software
development contexts in which that problem appears.
Architectural styles provide general design decisions that both constrain and may need to be refined
into additional, usually more specific design decisions in order to be applied to a system.
In contrast, an architectural pattern provides a set of specific design decisions that have been
identified as effective for organizing certain classes of software systems or, more typically, specific
subsystems.
A "pattern" has been defined as: "an idea that has been useful in one practical context and will
probably be useful in others" [Analysis Patterns - Reusable Object Models].
What’s the difference between an architectural style, an architectural pattern, and a system
metaphor?
An architectural style is a central, organizing concept for a system.
An architectural pattern describes a coarse-grained solution at the level of subsystems or
modules and their relationships.
A system metaphor is more conceptual and it relates more to a real-world concept over a
software engineering concept.
Models
A software system’s architecture is captured in an architectural model using a particular modeling
notation.
Definition
An architectural model is an artifact that captures some or all of the design decisions that
comprise a system’s architecture. Architectural modeling is the reification and
documentation of those design decisions.
11. 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
Architecture modeling and visualization
Architecture-driven system analysis
Architecture-driven system implementation
Architecture-driven system deployment, runtime redeployment, and mobility
Architecture-based design for non-functional properties, including security and trust
architectural adaptation
Stakeholders
Architects: The software architect role is responsible for the software architecture, which includes the
key technical decisions that constrain the overall design and implementation for the project.
Developers: A software developer is a person or organization concerned with facets of the software
development process.
Testers: If releasing a relatively bug-free product is important then having a team of software testers is
key.
Managers: A Project Manager is responsible for managing the resources of large projects. The Project
Manager is responsible for making sure a project is completed within a certain set of restraints. These
restraints usually involve time, money, people and materials. The project must then be completed to a
certain level of quality.
Customers: who sometime buy software from developer and sell it in market to make profit.
Users: end users who actually use the software.
12. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
2. Conventional Architectural styles
Terminology
Software architectures often use idiomatic patterns of system organization.
Patterns and styles of design are pervasive in many engineering disciplines and an established
understanding of the common forms of design is an indication of a mature engineering field.
The shared vocabulary of design idioms and rules for using them are stored in engineering handbooks
and in professional curricula.
A common framework can be developed to compare different architectures.
It consists of computational components (components and interactions between these components
connectors. Examples of components are clients, servers, filters, layers and databases. Examples of
connectors are procedure call, events broadcast, database protocols, and pipes.
A topological layout of these components indicating their runtime interrelationship.
A Partial List of Common Architecture Styles
Dataflow Systems -- Batch sequential, Pipes and filters.
Call-and-return systems -- Main program and subroutines, OO systems, Hierarchical layers.
Independent components -- Communicating processes, Event Systems.
Virtual Machines -- Interpreters, Rule-based systems.
Data-centered systems (repositories) -- Databases, Hypertext system, Blackboards.
Pipes and Filters
Each component has a set of inputs and outputs.
A component reads a stream of data on its input and produces a stream of data on its outputs.
Input is transformed both locally and incrementally so that output begins before input is consumed (a
parallel system).
Components are called filters.
Connectors serve as conduits for the information streams and are termed pipes.
13. 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.
Advantages to pipe-and-filter systems include:
easy understanding of the system's behavior as the composition of filters
they support reuse
easy to maintain and enhance
they support specialized analysis (throughput deadlock analysis)
and they support concurrent execution
Disadvantages to pipe-and-filter systems include:
they often lead to batch organization of processing
poor for interactive applications
can be difficult to maintain synchronization between two related but separate streams
May force lowest common denominator on data transmission, resulting in added work for each filter
to parse input and format output data which can, in turn, affect performance and increase complexity
of the filters.
Event-Based, Implicit Invocation
Instead of invoking a procedure directly, a component announces (broadcasts) one or more events.
Other components in the system can register interest in an event by associating a procedure with it.
The system invokes all events which have registered with it.
14. 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 systems are used in:
programming environments to integrate tools
database management systems to ensure consistency constraints
user interfaces to separate data from representation
For example, tools such as editors and variable monitors register for a debugger’s breakpoint events.
When a debugger stops at a breakpoint, it announces an event that allows the system to automatically
invoke methods in those registered tools. These methods might scroll an editor to the appropriate
source line or redisplay the value of monitored variables.
In this scheme, the debugger simply announces an event, but does not know what other tools (if any)
are concerned with that event, or what they will do when that event is announced.
Advantages of Implicit invocation to systems include:
Implicit invocation facilitates reuse by allowing any component to register for events,
And eases system evolution by allowing components to be replaced without affecting the interfaces of
other components in the system.
Disadvantages of Implicit invocation to systems include:
The primary disadvantage to implicit invocation is that the components relinquish control over the
computation performed by the system.
A component cannot assume that other components will respond to its requests and does not know
what order events will be processed.
15. 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.
Constraints include limiting interactions to adjacent layers.
The best known example of this style appears in layered communication protocols OSI-ISO (Open
Systems Interconnection - International Standards Organization) communication system. Lower levels
describe hardware connections and higher levels describe application.
Eg. UNIX OS
Advantages of Layered system include:
Layered systems support designs based on increasing levels of abstraction.
Complex problems may be partitioned into a series of steps.
Enhancement is supported through limiting the number of other layers with which communication
occurs.
Disadvantages of Layered system include:
Disadvantages include the difficulty in structuring some systems in a layered fashion.
16. 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:
In a repository style there are two quite distinct kinds of components:
A central data structure represents the current state, and a collection of independent components
operate on the central data store.
Interactions between the repository and its external components can vary significantly between
systems.
The choice of control discipline leads to major subcategories. If the types of transactions in an input
stream of transactions trigger selection of processes to execute, the repository can be a traditional
database. If the current state of the central data structure is the main trigger of selecting processes to
execute, the repository can be a blackboard.
In Repository architecture the data is passive.
Blackboard architecture has quasi-active data, which informs the clients interested in changes. The
Blackboard architecture style is similar to the Observer design pattern (Gamma et al., 1995).
Advantages of Repositories include:
Clients are independent from each other. Thus, a client can be changed, without affecting the others.
Also further clients can be added.
This advantage pales if the architecture is changed in such a way that clients are coupled closely (thus
deviating from the recommended architecture style), for example in order to improve the performance
of the system.
Eg.
Interpreters
Interpreters create a virtual machine in software.
There are generally four components to an interpreter; these are the program being interpreted, the
state of the program, the state of the interpreter, and the interpreter itself.
17. 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.
18. 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.
3.2The Design Process
The goal of this chapter is to set forth a variety of approaches for helping the student learn how to design software
system. The typical assumption of software design is that the process can proceed in the general manner of
architectural design or engineering design, which can be summarized as consisting of the following four stages.
1. Feasibity stage: Identifying a set feasible concept.
2. Preliminary design stage: Selection and development of the best concept.
3. Detailed design stage: development of engineering descriptions of the concept.
4. Planning stage: evaluating and altering the concept to suit the requirements of production, distribution,
consumption and product retirement.
“Designing begins (stage 1) by the taking –in of information. From this a set of alternative arrangements for the design
as a whole is quickly derived. Stage 2 is to select one of these alternatives for further development. When this design has
reached the point of satisfying the chief designer the work is split up for detailed design many people working in
parallel(stage 3 and 4)”.
The viewpoint represented by this process so pervades the software development world that it is hard to realize that the
use of this process represents a choice-that, indeed, other approaches are possible. This is an important recognition
because the standard approach does not always work. Even in those situations where it does work, it may not yield the
best result. At a minimum, designers must be aware of some of the conditions under which the traditional approach is
likely to be insufficient.
19. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Conditions under which this process may not work:
If the designer is unable to produce a set of feasible concepts, progress stops.
As problems and products increase in size and complexity, the probability that any one individual can
successfully perform the first steps decreases.
The standard approach does not directly address the situation where system design is at stake, i.e. when
relationship between a set of products is at issue.
As complexity increases or the experience of the designer is not sufficient, alternative approaches to the
design process must be adopted.
Alternative Design Strategies
Standard
o
Cyclic
o
Independent alternatives are explored in parallel
Adaptive (“lay tracks as you go”)
o
Process can revert to an earlier stage
Parallel
o
Linear model described above
The next design strategy of the design activity is decided at the end of a given stage
Incremental
o
Each stage of development is treated as a task of incrementally improving the existing design
3.3 Architectural conception
The standard approach to architectural and engineering design says that the first major step consists of identifying a
feasible set of “alternative arrangements for the design as a whole,” choosing one of those arrangements, and then
proceeding to refine and elaborate it.
Way to identify set of viable arrangements-or even one viable arrangement.
1)”Apply the fundamental design tools of software engineering: abstraction and modularity.”
2) “Inspiration” Creative inspiration is needed; to be sure, it is not a reliable magic wand to be blithely waved
over
complex design challenge. A more effective strategy is to minimize and isolate those parts of a design for which creative
inspiration is required, and to apply more prosaic and predictable techniques elsewhere.
20. 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.
3.3.1Fundamental Conceptual Tools
The most basic design tools are separation of concerns, abstraction, modularity, and other “first principles of software
engineering “such as anticipation of change and design for generality.
Abstraction and the Simple Machines
What concepts should be chosen at the outset of a design task?
One technique: Search for a “simple machine” that serves as an abstraction of a potential system
that will perform the required task
For instance, what kind of simple machine makes a software system embedded in a fax machine?
At core, it is basically just a little state machine.
Simple machines provide a plausible first conception of how an application might be built.
Every application domain has its common simple machines.
Simple Machines:
Domain
Graphics
Word processing
Process control
Income Tax Software
Web pages
Scientific computing
Banking
Simple Machines
Pixel arrays
Transformation matrices
Widgets
Abstract depiction graphs
Structured documents
Layouts
Finite state machines
Hypertext
Spreadsheets
Form templates
Hypertext
Composite documents
Matrices
Mathematical functions
Spreadsheets
Databases
Transactions
21. 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
Alternative 3: work, initially, at a level above that of the desired application.
E.g. handling simple application input with a general parser.
Separation of Concerns
Separation of concerns is the subdivision of a problem into (hopefully) independent parts.
The difficulties arise when the issues are either actually or apparently intertwined.
Separations of concerns frequently involves many tradeoffs
Total independence of concepts may not be possible.
Key example from software architecture: separation of components (computation) from connectors
(communication)
3.3.2 The Grand Tool: Refined Experience
Experience must be reflected upon and refined.
Experience can be a masterful teacher, however, and can provide the guidance necessary to wield the basic
tools in an effective fashion.
Raw experience by itself,though,does not provide the mature guidance
The lessons from prior work include not only the lessons of successes, but also the lessons arising from failure.
Learn from success and failure of other engineers
Literature
Conferences
Experience can provide that initial feasible set of “alternative arrangements for the design as a whole”.
Similarly, communication between development team members is enhanced: when others have experience with
the same or similar preexisting systems, it is easier to describe use of or modifications to an established
approach, as compared to conveying a completely new concept.
Limitation: Innovation is certainly inhibited by mindlessly following one’s standard approach.
22. 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.
23. 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.
3.4.1 Domain-specific software architectures
A DSSA is an assemblage (or combination)of software components
o
A referance architecture for an application domain, and
o
A library of software components for that architecture containing reusable chunks of domain expertise,
o
A method of choosing and configuration components to work within an instance of the referamce
architecture.
Since DSSAs are specialized for a particular domain they are only of value if one exists for the domain wherein
the engineer is tasked with building a new application.
DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for
developing a new architectural design.
The difficultywith DSSAs is that they are specialised for a particular domain and so are only of value if one exists
for the domain wherein the engineer is charged with building a new application.
3.4.2 Architectural Patterns
An architectural pattern is a set of architectural design decisions that are applicable to a recurring design
problem, and parameterized to account for different software development contexts in which that problem
appears.
Architectural patterns are similar to DSSAs but applied “at a lower level” and within a much narrower scope.
Definition: An Architectural Pattern is a named collection of architectural design decisions that are applicable
to a recurring design problem parameterized to account for different software development contexts
in which that problem appears.
In this sections below,we sketch three very simple examples:State-logic-display,model-view-controller,and
sense-compute-control.
State-Logic-Display(aka. Three-Tier)
This example is commonly employed in business applications where there is a data store behind a set of
business logic rules, and that business logic is accessed by user interfacecomponents.This pattern,also known as
24. 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
Model-View-Controller(for Graphical User Interfaces)
Objective: Separation between information(M), presentation(V) and user interaction(C).
This pattern has been a dominent influencein the design of graphical user interfaces.
When a model object value changes, a notification is sent to the view and to the controller.
When handling input from the user the windowing system sends the user event to the controller.
Thus, the view can update itself and the controller can modify the view if its logic so requires.
If a change is required, the controller updates the model object.
The simple idea shown in figure,
The model component encapsulates the information used by the application;
the view component encapsulates the information chosen and necessary for graphical depiction of the
information;
the controller component encapsulates the logic neccesary to maintain consistency between the model
and the view,and to handle inputs from the user as they relate to tha depiction.
25. 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.
The basic idea is illustrated in figure,
A computer is embedded in some application;
sensors from various devisec are connected to the computer and may be simpled to determine their
value.
Also attached to the computer are hardware actuators.
By sending a signal to such devices the computer may,for example,open a vlue.lower flaps,or turn off a
light, and hence control the system.
3.4.3 Introduction to Styles
An architectural style is a named collection of architectural design decisions …
A primary way of characterizing lessons from experience in software system design
Reflect less domain specificity than architectural patterns
Useful in determining everything from subroutine structure to top-level application structure
Many styles exist and we will discuss them in detail in the next lecture
Definitions of Architectural Style
Definition. An architectural style is a named collection of architectural design decisions that
26. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
constrain architectural design decisions that are specific to a particular system within that context
are applicable in a given development context
elicit beneficial qualities in each resulting system.
Recurring organizational patterns & idioms
Established, shared understanding of common design forms
Mark of mature engineering field.
Shaw & Garlan
Abstraction of recurring composition & interaction characteristics in a set of architectures
Medvidovic & Taylor
Basic Properties of Styles
A vocabulary of design elements
Component and connector types; data elements
e.g., pipes, filters, objects, servers
A set of configuration rules
Topological constraints that determine allowed compositions of elements
e.g., a component may be connected to at most two other components
A semantic interpretation
Compositions of design elements have well-defined meanings
Possible analyses of systems built in a style
Benefits of Using Styles
Design reuse
o
Code reuse
o
Well-understood solutions applied to new problems
Shared implementations of invariant aspects of a style
Understandability of system organization
o
A phrase such as “client-server” conveys a lot of information
27. Software Architecture
Interoperability
o
Style-specific analyses
o
Supported by style standardization
Enabled by the constrained design space
Visualizations
o
Style-specific depictions matching engineers’ mental models
Some Common Styles
Traditional, language-influenced styles
o
o
Main program and subroutines
Object-oriented
Layered
o
o
Virtual machines
Client-server
Data-flow styles
o
o
Batch sequential
Pipe and filter
Shared memory
o
o
Blackboard
Rule based
Interpreter
o
o
Interpreter
Mobile code
Implicit invocation
o
o
Event-based
Publish-subscribe
Peer-to-peer
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
28. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
“Derived” styles
o
C2
o
CORBA
Traditional Language-Influenced Styles
The two styles considered here reflect the program styles that result from the traditional use of programming lamguages
such C,C++,Java,and Pascal.
Main program and Subroutines.
The main program and subroutine style should be instantly familiar to anyone who has programmed in a
language such C,Fortran,Pascal, or Basic.
The components are the main program and the various subroutines(procedures);the connectors between the
components are procedure calls.
Main
program
Procedure Call
Call
Subroutines
Procedure Call
Procedure Call
Subroutines
Subroutines
Object-Oriented
Components are objects
o Data and associated operations
Connectors are messages and method invocations
Style invariants
o Objects are responsible for their internal representation integrity
o Internal representation is hidden from other objects
Advantages
o Malleable object internals
o System decomposition into sets of interacting agents
Disadvantages
o Objects must know identities of servers
29. 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
Shared State (Shared memory styles)
The essence of shared state styles is that multiple components have access to the same data store, and
communicate through that data store.
Blackboard
Two kinds of components
Central data structure — blackboard
Components operating on the blackboard
System control is entirely driven by the blackboard state
Examples
Speech recognition
Planner component for RADRSAT-1 satellite
30. 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
31. 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.
32. 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.
What is a Software Connector?
Architectural element that models
o Interactions among components
o Rules that govern those interactions
Simple interactions
o Procedure calls
o Shared variable access
Complex & semantically rich interactions
o Client-server protocols
o Database access protocols
o Asynchronous event multicast
Each connector provides
o Interaction duct(s)
o Transfer of control and/or data
Where are Connectors in Software Systems?
33. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Reasons for Treating Connectors Independently
Connector Component
o Components provide application-specific functionality
o Connectors provide application-independent interaction mechanisms
Interaction abstraction and/or parameterization
Specification of complex interactions
o Binary vs. N-ary
o Asymmetric vs. Symmetric
o Interaction protocols
Localization of interaction definition
Extra-component system (interaction) information
Component independence.
Component interaction flexibility.
Benefits of First-Class Connectors
Separate computation from interaction
Minimize component interdependencies
Support software evolution
o At component-, connector-, & system-level
Potential for supporting dynamism
Facilitate heterogeneity
Become points of distribution
Aid system analysis & testing
Connector Foundation
The underlying, elementary building blocks of every connector are the primitives for managing the flow
of control (that is, changing the processor program counter) and flow of data (that is, performing
memory access) in a system.
These primitives give enough conceptual power to build sophisticated and complex connectors. In
addition to these primitives, every connector maintains one or more channels, also referred to as
ducts, which are used to link the interacting components and support the flow of data and control
between them.
Simple connectors, such as module linkers, provide their service simply by forming duct between
components.
Very complex connectors can also have an internal architecture that includes computation and
information storage.
For example, a load balancing connector would execute an algorithm for switching incoming traffic
among a set of components based on the knowledge about the current and past load state of
components.
34. 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)
Connector types and their variation dimensions
Procedure call
Event
Data access
Linkage
Stream
Arbitrator
Adaptor
Distributor
35. 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.
36. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Data Access Connectors
Data access connectors allow components to access maintained by a data store component. Therefore
they provide communication services.
In case there is a difference in the format of the required data and format in which data is stored and
provided, data access connectors may perform translation of the information being accecced, that is
conversion.
The data can be stored either persistently data access include query mechanism, such as SQL for
database access, example of transient data access include heap and stack memory access and
information caching. Eg.JDBC
37. 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.
38. 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.
39. 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.
40. 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).
Event-Based Data Distribution Connectors
• Event-based utilizes 4 of the 6 connectors:
o Event
o Data access
o Stream
o Distributor
• These connectors send and receive data via asynchronous notification called events
• An example is a middle ware that performs publish-subscribe architectural style and involves some
producer of information alerting subscribers ---events, which then kicks- off the accessing of various
data. The accessed data is then packaged and streamlined for distribution by the distributor to the
subscribers.
Grid-based Distribution Connector
• Grid-based utilizes 4 of the 6 connectors:
o Procedure call
o Data access
41. 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.
Client Server-based Distribution Connector
• Client server-based utilizes the same 4 connectors as Grid :
o Procedure call
o Data access
o Stream
o Distributor
• These connectors allow seamless distribution of data between client and server system using Remote
Procedure Call (RPC).
• This middle-ware is very much like the grid-based distribution connector, except the customer of
service and the provider of service operates in a much more seamless manner (as if the service and
data are “local”).
Peer-to-Peer-based Distribution Connector
• P2P-based utilizes the 4 connectors :
o Arbitrator
o Data access
o Stream
o Distributor
• These connectors differ from the previous 3 in that it is invoked via arbitration, which involves control
flow redirection among distributed, peer resources. Arbitrators can negotiate various issues such as
timing, scheduling, or protocols.
• Once a peer is invoked via arbitration then the collection of data may also be through the peers in a
distributed environment (also via arbitration). Data is then organized and package in chunks for
transmission to other peers. Other peers are located via arbitration and the data is distributed to them.
42. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Chapter 5: Modeling
Introduction
Every software system has architecture, whether it is a “good” architecture or not.
Recall that we have characterized architecture as the set of principal design decisions made about a system.
Once design decisions have been made, they can be recorded.
Design decisions are captured in models; the process of creating models is called modeling.
Definitions:
An architectural model is an artifact that captures some or all of the design decisions that
comprise a system’s architecture
Architectural modeling is the reification and documentation of those design decisions
Without a model, architecture is inscrutable. Modeling notations can be rich and ambiguous (for example,
natural language), highly formal (such as the Rapide notation), semantically weak (such as Power-Point diagrams),
or semantically formal. Several notations can be combined to describe architecture - for example, a UML class
diagram can be annotated with natural language.
(Note: This chapter deals with basic architectural concepts and design decisions that need to be modelled, as
well as modeling views, viewpoints, and visualizations. Other section covers various modeling notations: natural
language (3.1); informal graphical styles (3.2); Unified Modeling Language (3.3); early Architecture Description
Languages (3.4) – Darwin (3.4.1), Rapide (3.4.2), and Wright (3.4.3); domain-specific and style-specific
Architecture Description Languages (3.5) – Koala (3.5.1), Weaves (3.5.2), and AADL (3.5.3); extensible
Architecture Description Languages (3.6) – Acme (3.6.1), ADML (3.6.2), and xADL (3.6.3); User Requirements
Notation (3.7); and Dialog Flow Notation (3.8). )
Throughout the chapter, we also discuss how architecture modeling notations are used to capture design decisions.
Definition:
An architectural modeling notation is a language or means of capturing design decisions.
5.1 Modeling Concepts
In this chapter, we discuss a broad spectrum of kinds of things that can be modeled in architecture, and then how
various notations can be selected and used to facilitate this modeling.
5.1.1 Stakeholder-Driven Modeling
One of the most critical decisions that architects and other stakeholders will make in developing architecture is to
choose:
43. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
1. What architectural decisions and concepts should be modeled,
2. At what level of detail, and
3. With how much rigor or formality.
These decisions should be based on costs and benefits. Architects should balance the benefits of having certain models
in certain forms or notations with the cost of creating and maintaining those models. Thus, the choice of what to model,
and at what level of detail, will be stakeholder driven.
Figure shows five concerns about the system identified by stakeholders.
In this particular case, Concerns 1 is of great importance,
and will be considered and modeled deeply.
Concerns 2 and 4 are less important and will be modeled shallowly.
Modeling is an activity, and as such it is often governed by a process.
The basic activities behind stakeholder-driven modeling are to:
1. Identify relevant aspects of the software to model.
2. Roughly categorize them in terms of importance.
3. Identify the goals of modeling for each aspect (communication, bug finding, quality analysis, generation of other
artifacts, and so on).
4. Select modeling notations that will model the selected aspects at appropriate levels of depth to achieve the
modeling goals.
5. Create the models.
6. Use the models in manner consistent with the modeling goals.
Although the steps outlined above are in rough chronological order, they can be incorporated into an iterative process.
5.1.2 Basic Architectural Concepts
Components – Components are the architectural building blocks that encapsulate a subsets of system's
functionality and data, and restrict access to them via an explicitly defined interfaces.
Connectors - Connectors are the architectural building blocks that effect regulate interactions among
components.
Interfaces - points at which components and connectors interact with the outside world.
Configurations - specific associations between the components and connectors in the system.
44. 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 .
5.1.3 Elements of the Architectural Style
“Architectural style is a collection of design decisions that are applicable in a given development context, constrain
design decisions within that context, and elicit beneficial qualities in the resulting system.”
Explicitly modeling the architectural style can be helpful for a number of reasons.
1. It reduces confusion about what is and is not allowed in the architecture.
2. It can help to reduce architectural drift and erosion.
3. It makes it easier to distinguish whether a specific design decision in architecture was made to conform to a
stylistic constraint or for some other reason.
4. It can help to guide the evolution of the architecture.
5. Style represent a single place capture cross-cutting concerns and rational for an architecture.
The kinds of design decisions found in an architectural style are generally more abstract or general than those found in
architecture. Some kind of design decisions that might be captured in a style model include:
Specific elements - particular components, interfaces and connectors to be used in a particular way in specific
situations. Modeling templates or base models can be thus created.
Component, connector, and interface types - kinds of elements permitted, required, or prohibited in the
architecture.
Interaction constraints - temporal (call one before another), topological (can be invoked only by components
belonging to a certain layer), protocol (one or a group) constraints on interaction between Components and
connectors.
Behavioral constraints - from simple rules to complete finite state automata of the system.
Concurrency constraints - rules for concurrency, synchronization, access to shared resources.
45. Software Architecture
5.1.4
5.1.5
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Static and Dynamic Aspects
Static aspects are easier to model as they do not include changes over time.
Typical models of static system aspects might include component/connector topologies, assignments of
components and connectors to processing elements or host and network configurations, or mappings of
architectural elements to code or binary artifacts.
Dynamic aspects of a system are harder to represent. This includes interaction models, data flow models, and
behavioral models.
In cases when the system is usually stable but might have to change behavior if one of the components fails,
both the static and dynamic models might be needed.
Modeling dynamic aspects of a system can be done using static modeling (for example, interaction diagrams).
Dynamic models can be employed to visualize the behavior of a running system, and are updated on-the-fly.
Functional and Non-Functional Aspects
Architecture can capture both functional and non-functional aspects of a system.
Functional aspects relate to what a system does.
Non-functional aspects relate to how a system performs its functions.
Functional aspects of a system can be described using declarative, subject-verb sentences:
Eg: “The system prints medical records”.
Non-functional aspects of a system can be described by adding adverbs to these sentences.
Eg: “The system prints medical records quickly and confidentially.”
Architectural models tend to be functional, but like rationale it is often important to capture non-functional
decisions even if they cannot be automatically or deterministically interpreted or analyzed.
Functional (what a system does) and non-functional (constraints on what a system does) aspects of the system
can be captured through modeling. Functional aspects are easier to model as they are complete.
Most modeling notations are designed to capture primarily functional aspects. Non-functional aspects are often
captured less
rigorously, as they are qualitative and subjective.
5.2 Ambiguity, Accuracy, and Precision
Architectures are abstractions of systems. They capture information about some aspect of the system and leave out
other aspects.
Three key concepts can be used to characterize architectural models: ambiguity, accuracy, and precision.
5.2.1 Ambiguity
Definition: A model is ambiguous if it is open to more than one interpretation
Because conflicting interpretations of a model may lead to misunderstandings, bugs, and errors, it is generally
desirable to eliminate ambiguity in design.
46. 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.
5.2.2 Accuracy and Precision
Many conceptions of accuracy and precision, including dictionary definition, conflate the two terms. Here, we will adopt
an interpretation that more clearly delineates them.
Definition: A model is accurate if it is correct, conforms to fact, or deviates from correctness within
acceptable limits.
Definition: A model is precise if it is sharply exact or delimited.
Accuracy deals with correctness, while precision deals with exactness.
In architectural terms, a model is accurate if it conveys correct information about the modeled system.
A model is precise if it conveys a lot of detailed information about the modeled system.
5.3 Complex Modeling: Mixed Content and Multiple views
Architectural models are complex artifacts. They attempt to capture all the design decisions about a system that are
important to a wide variety of stakeholders. There can be multiple or different aspects of same concern captured
simultaneously. Some basics about views and viewpoints are as follows.
47. 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
o
The model would be too big, complex, and confusing
So, we create several coordinated models, each capturing a subset of the design decisions
o
Generally, the subset is organized around a particular concern or other selection criteria
We call the subset-model a ‘view’ and the concern (or criteria) a ‘viewpoint’
Definitions
•
•
•
A view is a set of design decisions related by a common concern (or set of concerns).
A viewpoint is the perspective from which a view is taken.
A view (what you see) is an instance of a viewpoint (filter) for a specific system .
A viewpoint is a filter for information, and a view is what you see when you look at a system through that filter.
Viewpoints provide a way to limit presented information to a cognitively manageable subset of the architecture,
display related concepts simultaneously, can be tailored to the needs of specific stakeholders, can be used to
display the same data at various levels of abstraction.
Listed below are several traditional viewpoints frequently used in modeling:
1. Logical - logical (often software) entities in the system and how they are interconnected.
2. Physical - physical (often hardware) entities in the system and how they are interconnected.
3. Deployment - how logical entities are mapped onto physical entities.
4. Concurrency - how concurrency and threading are managed in the system
5. Behavioral - expected behavior of the system or its parts.
The use of views and viewpoints in modeling is important for several reasons:
1.
2.
3.
4.
They provide a way to limit presented information to a cognitively manageable subset of the architecture.
They display related concepts simultaneously.
They can be tailored to the needs of specific stakeholders.
They can be used to display the same data at various levels of abstraction.
5.3.2 Consistency among Views
Views can contain overlapping and related design decisions
o
Views are consistent if the design decisions they contain are compatible
o
There is the possibility that the views can thus become inconsistent with one another
Views are inconsistent if two views assert design decisions that cannot simultaneously be true
Inconsistency is usually but not always indicative of problems
o
Temporary inconsistencies are a natural part of exploratory design
48. Software Architecture
o
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
Inconsistencies cannot always be fixed.
The following inconsistencies may exist among views:
Direct inconsistencies - two views assert directly contradictory propositions, automatically detectable.
E.g., “The system runs on two hosts” and “the system runs on three hosts.”
Refinement inconsistencies - two views at different levels of detail assert contradictory propositions; can be
automatically detected with appropriate consistency rules.
Static versus dynamic aspect inconsistencies - view of a static aspect conflicts with a view of the dynamic aspect
of the system, harder to automatically detect, depending on how explicit the dynamic aspect's specification is.
Dynamic aspect inconsistencies - two views of dynamic aspects of the system conflict, often extremely difficult
to detect automatically as it requires extensive state exploration or simulations.
Functional versus non-functional aspect inconsistencies - non-functional property prescribed by a
nonfunctional view is not met by the design expressed in functional views; the most difficult to detect because
of the general and abstract nature of non-functional properties.
5.4 Specific Modeling Techniques
This section evaluate different modeling techniques for software architecture
Generic approaches
1. Natural language
2. PowerPoint-style modeling
3. UML, the Unified Modeling Language
Early architecture description languages
1. Darwin
2. Rapide
3. Wright
Domain- and style-specific languages
1. Koala
2. Weaves
3. AADL
Extensible architecture description languages
1. Acme
2. ADML
3. xADL
5.4.1 Generic Techniques
These techniques are often used to describe software architecture in whole or in part, although they were not
specifically developed or adopted for this purpose, they tend to be flexible but have few semantics.
Natural Language
Natural (human) languages, such as English, are expressive, but ambiguous, non-formal, and non-rigorous.
They cannot be effectively processed and understood by machines, and so can only be inspected by humans.
Natural languages are easily accessible to stakeholders and can be handled using common word-processing
tools.
Due to the abstract and qualitative nature of non-functional requirements, natural languages are best in
capturing those.
Sometimes, a restricted form of a language is used instead of a pure language.
49. 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.
Informal Graphical PowerPoint-style Modeling
Informal Power-Point-style modeling allows for creation of decorative diagrams of interconnected shapes.
They are easily accessible to stakeholders, assuming the tools for their manipulation are available.
The slide nature of these presentations limits the diagram size, which ensures suitable abstraction.
Advantages
o Can be aesthetically pleasing
o Size limitations (e.g., one slide, one page) generally constrain complexity of diagrams
o Extremely flexible due to large symbolic vocabulary
Disadvantages
o Ambiguous, non-rigorous, non-formal
But often treated otherwise
o Cannot be effectively processed or analyzed by machines/software.
The Unified Modeling language (and its Cousins)
13 loosely-interconnected notations called diagrams that capture static and dynamic aspects of softwareintensive systems
UML (Booch, Rumbaugh, and Jacobson 2005) combines concepts from earlier notations: Booch diagrams, OMT,
OOSE, and Statecharts.
UML provides a wide variety of modeling constructs and viewpoints.
There are many tools that provide varying degrees of support for UML (from diagram construction to generation
of code from UML models).
UML is an extensive notation that traditionally employs graphical symbols with textual annotations to represent
the system from thirteen different viewpoints (as of UML 2.0).
Early versions of UML focused on detailed design modeling. UML 2.0 has added support for higher-level
architectural constructs.
Advantages
Support for a diverse array of viewpoints focused on many common software engineering concerns.
Ubiquity improves comprehensibility.
Extensive documentation and tool support from many vendors.
Disadvantages
Needs customization through profiles to reduce ambiguity.
Difficult to assess consistency among views.
Difficult to capture foreign concepts or views.
50. Software Architecture
Notes compiled by Prof. Suresh Mestry
Mobile No:8097404245
5.4.2 Early Architecture Description Languages
There is no single definition of what constitutes an architecture description language.
The uncertainty regarding this issue hinges on disagreement on what should and should not be included in the
concept of software architecture.
Looking at architecture as a set of principal design decisions about a system, there are several languages that
fall into the category of ADLs.
The early ADLs did not go past the research project stage and are not used in practice.
However, they are an important part of architectural modeling development.
A brief feature overview is provided below for three early ADLs: Darwin, Rapide, and Wright.
Darwin
Darwin is a General-purpose architecture description language for specifying the structure of system composed
from components that communicate through explicit interfaces.
Darwin has a canonical textual representation in which components and their interconnections are described.
It is general purpose language with graphical and textual visualizations focused on structural modeling of
systems.
Darwin is a declarative language that describes systems as collections of components interacting via explicit
interfaces.
The notion of a software connector is not present, but a component that facilitates interactions can be
considered a connector.
Darwin components expose a set of provide and required services, sometimes called ports.
Advantages
Simple, straightforward mechanism for modeling structural dependencies
Interesting way to specify repeated elements through programmatic constructs
Can be modeled in pi-calculus for formal analysis
Can specify hierarchical (i.e., composite) structures
Disadvantages
Limited usefulness beyond simple structural modeling
No notion of explicit connectors
Although components can act as connectors.
Eg:
component DataStore{
provide values;
}
component Calculation{
require values;
provide calculationService;
}
component UserInterface{
require calculationService;
require values;
Rapide
Rapide is a language that focuses on modeling systems that consist of components communicating via events.
Procedure calls are supported by using two events: one for the call and one for the return value.
Events in Rapide are combined into partially-ordered sets.
51. 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.
5.4.3 Domain- and Style –Specific ADLs
Domain- and style specific ADLs are important for several reasons.
First, their scope is better tailored to stakeholder needs since they target particular group of stakeholder, rather
than system and software developer in general.
52. 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.
AADL-The Architecture Analysis & Design Language
AADL was initially created to model avionics systems.
The notation is not specifically bound to that domain, however, and can be used in embedded and real-time
system modeling.
AADL is a textual language that can be expressed graphically and is accompanied by a UML profile to capture
the information in several ways.
53. 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
5.4.4 Extensible ADLs
Modeling involves a trade-off between being able to describe a variety of systems, and taking advantage of
semantically powerful features of more specialized languages, such as being able to automate model analysis
and code generation.
One way to resolve this is to use a combination of several languages to describe the system.
This entails keeping models in sync, which requires knowledge of multiple notations. This approach might also
result in inability to describe certain concerns in any of the notations.
Another way to deal with the trade-off is to use extensible ADLs that strive to combine the flexibility of generic
languages with precision and analyzability of semantically rich languages.
Extensible ADLs normally support the common architectural constructs (such as components and connectors)
and allow the user to extend the syntax to support user-defined constructs [1].
Below three extensible ADLs are presented: Acme, ADML, and xADL.
ACME
It is early general purpose ADL with support for extensibility through properties
Acme provides a set of seven constructs: connectors, components, ports (interfaces on components), roles
(interfaces on connectors), attachments (links), systems (configurations), and representations (inner
architectures for components and connectors).
Acme allows describing static aspects of the system natively, as well as dynamic and non-functional aspects
through the use of properties.
Advantages
Structural specification capabilities similar to Darwin
Simple property structure allows for arbitrary decoration of existing elements
Tool support with AcmeStudio
Disadvantages
No way to add new views
54. 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.
Architectural Description Markup Language (ADML)
ADML is a language based on XML with its syntax derived from Acme.
Semantically ADML is nearly identical to Acme, with the exception of meta-properties, which allow for
specification of the properties and property types that should be present on particular elements.
ADML's syntax is defined using an XML DTD.
Advantages
o XML parsers and tools readily available.
o Added some ability to reason about types of properties with meta-properties.
Disadvantages
o Properties are still name-value pairs.
o Did not take advantage of XML extension mechanisms.
Extensible XML-based ADL (xADL)
xADL [22] is an XML-based domain-neutral extensible ADL that fully leverages XML's extensibility mechanisms to
extend the language.
The syntax of xADL is defined by XML Schemas.
xADL models are well-formed XML documents.
Extensibility is achieved through defining derived data types in separate schemas, thus allowing data types
declared in one schema to be extended in a different schema.
Advantages
u Growing set of generically useful modules available already
u Tool support in ArchStudio environment
u Users can add their own modules via well-defined extensibility mechanisms
Disadvantages
u Extensibility mechanisms can be complex and increase learning curve
u Heavy reliance on tools