SlideShare uma empresa Scribd logo
1 de 89
Baixar para ler offline
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
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
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
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.)
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
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,
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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
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
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
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
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
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
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.
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?
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.
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
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.
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
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.
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.
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.
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
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.
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:
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture
software architecture

Mais conteúdo relacionado

Mais procurados

Software Architecture and Design
Software Architecture and DesignSoftware Architecture and Design
Software Architecture and DesignRa'Fat Al-Msie'deen
 
Architecture vs Design
Architecture vs DesignArchitecture vs Design
Architecture vs DesignLuc Trudeau
 
Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Sudarshan Dhondaley
 
Software architecture
Software architectureSoftware architecture
Software architecturenazn
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Sudarshan Dhondaley
 
Software Engineering - chp5- software architecture
Software Engineering - chp5- software architectureSoftware Engineering - chp5- software architecture
Software Engineering - chp5- software architectureLilia Sfaxi
 
Architecture Design
Architecture DesignArchitecture Design
Architecture DesignSaqib Raza
 
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Dhivyaa C.R
 
Software architecture model
Software architecture modelSoftware architecture model
Software architecture modelEmmanuel Fuchs
 
Software Architecture: views and viewpoints
Software Architecture: views and viewpointsSoftware Architecture: views and viewpoints
Software Architecture: views and viewpointsHenry Muccini
 
Software Architecture Design for Begginers
Software Architecture Design for BegginersSoftware Architecture Design for Begginers
Software Architecture Design for BegginersChinh Ngo Nguyen
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)IIUI
 
Software Architecture Patterns
Software Architecture PatternsSoftware Architecture Patterns
Software Architecture PatternsAssaf Gannon
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principlessaurabhshertukde
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineeringRupesh Vaishnav
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9Ian Sommerville
 

Mais procurados (20)

Software Architecture and Design
Software Architecture and DesignSoftware Architecture and Design
Software Architecture and Design
 
Software design
Software designSoftware design
Software design
 
Architecture vs Design
Architecture vs DesignArchitecture vs Design
Architecture vs Design
 
Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5Designing and documenting software architecture unit 5
Designing and documenting software architecture unit 5
 
Software architecture
Software architectureSoftware architecture
Software architecture
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2
 
Software Engineering - chp5- software architecture
Software Engineering - chp5- software architectureSoftware Engineering - chp5- software architecture
Software Engineering - chp5- software architecture
 
Architecture Design
Architecture DesignArchitecture Design
Architecture Design
 
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
 
Software architecture model
Software architecture modelSoftware architecture model
Software architecture model
 
Software Architecture
Software ArchitectureSoftware Architecture
Software Architecture
 
Unit1
Unit1Unit1
Unit1
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
 
Software Architecture: views and viewpoints
Software Architecture: views and viewpointsSoftware Architecture: views and viewpoints
Software Architecture: views and viewpoints
 
Software Architecture Design for Begginers
Software Architecture Design for BegginersSoftware Architecture Design for Begginers
Software Architecture Design for Begginers
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)
 
Software Architecture Patterns
Software Architecture PatternsSoftware Architecture Patterns
Software Architecture Patterns
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principles
 
Software design, software engineering
Software design, software engineeringSoftware design, software engineering
Software design, software engineering
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9
 

Semelhante a software architecture

Software Architecture
Software Architecture Software Architecture
Software Architecture ssuser9d62d6
 
Unit_4_Software_Design.pptx
Unit_4_Software_Design.pptxUnit_4_Software_Design.pptx
Unit_4_Software_Design.pptxtaxegap762
 
Lecture-2-Architectural_Concepts.pdf
Lecture-2-Architectural_Concepts.pdfLecture-2-Architectural_Concepts.pdf
Lecture-2-Architectural_Concepts.pdfAkilaGamage2
 
Arch06 1
Arch06 1Arch06 1
Arch06 1nazn
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxKarthigaiSelviS3
 
Software architecture in practice unit1 1
Software architecture in practice unit1 1Software architecture in practice unit1 1
Software architecture in practice unit1 1sush-sushma
 
Software architecture in practice unit1 1
Software architecture in practice unit1 1Software architecture in practice unit1 1
Software architecture in practice unit1 1sush-sushma
 
Software architecture simplified
Software architecture simplifiedSoftware architecture simplified
Software architecture simplifiedPrasad Chitta
 
Software Architecture
Software ArchitectureSoftware Architecture
Software ArchitectureVikas Dhyani
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxMahmoudZidan53
 
Model Based Software Architectures
Model Based Software ArchitecturesModel Based Software Architectures
Model Based Software ArchitecturesMunazza-Mah-Jabeen
 
Introduction to Modern Software Architecture
Introduction to Modern Software ArchitectureIntroduction to Modern Software Architecture
Introduction to Modern Software ArchitectureJérôme Kehrli
 
Software_Archi-1.ppt
Software_Archi-1.pptSoftware_Archi-1.ppt
Software_Archi-1.pptFaizaZulkifal
 
Object oriented sad-5 part i
Object oriented sad-5 part iObject oriented sad-5 part i
Object oriented sad-5 part iBisrat Girma
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfputtipavan23022023
 

Semelhante a software architecture (20)

SA_UNIT_1.pptx
SA_UNIT_1.pptxSA_UNIT_1.pptx
SA_UNIT_1.pptx
 
Software Architecture
Software Architecture Software Architecture
Software Architecture
 
03 basic concepts
03 basic concepts03 basic concepts
03 basic concepts
 
Sda 1
Sda   1Sda   1
Sda 1
 
Unit_4_Software_Design.pptx
Unit_4_Software_Design.pptxUnit_4_Software_Design.pptx
Unit_4_Software_Design.pptx
 
Lecture-2-Architectural_Concepts.pdf
Lecture-2-Architectural_Concepts.pdfLecture-2-Architectural_Concepts.pdf
Lecture-2-Architectural_Concepts.pdf
 
Arch06 1
Arch06 1Arch06 1
Arch06 1
 
Design Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptxDesign Concepts in Software Engineering-1.pptx
Design Concepts in Software Engineering-1.pptx
 
Software architecture in practice unit1 1
Software architecture in practice unit1 1Software architecture in practice unit1 1
Software architecture in practice unit1 1
 
Software architecture in practice unit1 1
Software architecture in practice unit1 1Software architecture in practice unit1 1
Software architecture in practice unit1 1
 
Software architecture simplified
Software architecture simplifiedSoftware architecture simplified
Software architecture simplified
 
Software Architecture
Software ArchitectureSoftware Architecture
Software Architecture
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
 
Model Based Software Architectures
Model Based Software ArchitecturesModel Based Software Architectures
Model Based Software Architectures
 
Introduction to Modern Software Architecture
Introduction to Modern Software ArchitectureIntroduction to Modern Software Architecture
Introduction to Modern Software Architecture
 
Software_Archi-1.ppt
Software_Archi-1.pptSoftware_Archi-1.ppt
Software_Archi-1.ppt
 
Object oriented sad-5 part i
Object oriented sad-5 part iObject oriented sad-5 part i
Object oriented sad-5 part i
 
Sda 2
Sda   2Sda   2
Sda 2
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
 
DESIGN CONCEPTS
DESIGN CONCEPTSDESIGN CONCEPTS
DESIGN CONCEPTS
 

Último

DLL Catch Up Friday March 22.docx CATCH UP FRIDAYS
DLL Catch Up Friday March 22.docx CATCH UP FRIDAYSDLL Catch Up Friday March 22.docx CATCH UP FRIDAYS
DLL Catch Up Friday March 22.docx CATCH UP FRIDAYSTeacherNicaPrintable
 
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptx
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptxBBA 205 BE UNIT 2 economic systems prof dr kanchan.pptx
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptxProf. Kanchan Kumari
 
ICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfVanessa Camilleri
 
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacyASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacySumit Tiwari
 
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...gdgsurrey
 
Quantitative research methodology and survey design
Quantitative research methodology and survey designQuantitative research methodology and survey design
Quantitative research methodology and survey designBalelaBoru
 
Alamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxAlamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxDhatriParmar
 
Metabolism of lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptx
Metabolism of  lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptxMetabolism of  lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptx
Metabolism of lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptxDr. Santhosh Kumar. N
 
Metabolism , Metabolic Fate& disorders of cholesterol.pptx
Metabolism , Metabolic Fate& disorders of cholesterol.pptxMetabolism , Metabolic Fate& disorders of cholesterol.pptx
Metabolism , Metabolic Fate& disorders of cholesterol.pptxDr. Santhosh Kumar. N
 
The First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfThe First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfdogden2
 
LEAD6001 - Introduction to Advanced Stud
LEAD6001 - Introduction to Advanced StudLEAD6001 - Introduction to Advanced Stud
LEAD6001 - Introduction to Advanced StudDr. Bruce A. Johnson
 
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17Celine George
 
UNIT I Design Thinking and Explore.pptx
UNIT I  Design Thinking and Explore.pptxUNIT I  Design Thinking and Explore.pptx
UNIT I Design Thinking and Explore.pptxGOWSIKRAJA PALANISAMY
 
2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...Sandy Millin
 
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...Marlene Maheu
 
Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024bsellato
 
Research Methodology and Tips on Better Research
Research Methodology and Tips on Better ResearchResearch Methodology and Tips on Better Research
Research Methodology and Tips on Better ResearchRushdi Shams
 
Auchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsAuchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsDhatriParmar
 
Dhavni Theory by Anandvardhana Indian Poetics
Dhavni Theory by Anandvardhana Indian PoeticsDhavni Theory by Anandvardhana Indian Poetics
Dhavni Theory by Anandvardhana Indian PoeticsDhatriParmar
 

Último (20)

ANOVA Parametric test: Biostatics and Research Methodology
ANOVA Parametric test: Biostatics and Research MethodologyANOVA Parametric test: Biostatics and Research Methodology
ANOVA Parametric test: Biostatics and Research Methodology
 
DLL Catch Up Friday March 22.docx CATCH UP FRIDAYS
DLL Catch Up Friday March 22.docx CATCH UP FRIDAYSDLL Catch Up Friday March 22.docx CATCH UP FRIDAYS
DLL Catch Up Friday March 22.docx CATCH UP FRIDAYS
 
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptx
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptxBBA 205 BE UNIT 2 economic systems prof dr kanchan.pptx
BBA 205 BE UNIT 2 economic systems prof dr kanchan.pptx
 
ICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdfICS2208 Lecture4 Intelligent Interface Agents.pdf
ICS2208 Lecture4 Intelligent Interface Agents.pdf
 
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in PharmacyASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
ASTRINGENTS.pdf Pharmacognosy chapter 5 diploma in Pharmacy
 
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...
Certification Study Group - Professional ML Engineer Session 3 (Machine Learn...
 
Quantitative research methodology and survey design
Quantitative research methodology and survey designQuantitative research methodology and survey design
Quantitative research methodology and survey design
 
Alamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptxAlamkara theory by Bhamaha Indian Poetics (1).pptx
Alamkara theory by Bhamaha Indian Poetics (1).pptx
 
Metabolism of lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptx
Metabolism of  lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptxMetabolism of  lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptx
Metabolism of lipoproteins & its disorders(Chylomicron & VLDL & LDL).pptx
 
Metabolism , Metabolic Fate& disorders of cholesterol.pptx
Metabolism , Metabolic Fate& disorders of cholesterol.pptxMetabolism , Metabolic Fate& disorders of cholesterol.pptx
Metabolism , Metabolic Fate& disorders of cholesterol.pptx
 
The First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdfThe First National K12 TUG March 6 2024.pdf
The First National K12 TUG March 6 2024.pdf
 
LEAD6001 - Introduction to Advanced Stud
LEAD6001 - Introduction to Advanced StudLEAD6001 - Introduction to Advanced Stud
LEAD6001 - Introduction to Advanced Stud
 
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17
How to Customise Quotation's Appearance Using PDF Quote Builder in Odoo 17
 
UNIT I Design Thinking and Explore.pptx
UNIT I  Design Thinking and Explore.pptxUNIT I  Design Thinking and Explore.pptx
UNIT I Design Thinking and Explore.pptx
 
2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...2024.03.16 How to write better quality materials for your learners ELTABB San...
2024.03.16 How to write better quality materials for your learners ELTABB San...
 
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
2024 March 11, Telehealth Billing- Current Telehealth CPT Codes & Telehealth ...
 
Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024Awards Presentation 2024 - March 12 2024
Awards Presentation 2024 - March 12 2024
 
Research Methodology and Tips on Better Research
Research Methodology and Tips on Better ResearchResearch Methodology and Tips on Better Research
Research Methodology and Tips on Better Research
 
Auchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian PoeticsAuchitya Theory by Kshemendra Indian Poetics
Auchitya Theory by Kshemendra Indian Poetics
 
Dhavni Theory by Anandvardhana Indian Poetics
Dhavni Theory by Anandvardhana Indian PoeticsDhavni Theory by Anandvardhana Indian Poetics
Dhavni Theory by Anandvardhana Indian Poetics
 

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