REFERENCE MODELS

&
REFERENCE ARCHITECTURES
 A reference model is a division of functionality
together with data flow between the pieces. A reference
model is a standard decomposition of a known problem
into parts that cooperatively solve the problem.
 A reference architecture is a reference model mapped
onto software elements (that cooperatively implement
the functionality defined in the reference model) and
the data flows between them. Whereas a reference
model divides the functionality, A reference
architecture is the mapping of that functionality onto a
system decomposition.
 Reference models, architectural patterns, and reference
architectures are not architectures; they are useful
concepts that capture elements of an architecture. Each
is the outcome of early design decisions.

 A software architect must design a system that provides

concurrency, portability, modifiability, usability,
security, and the like, and that reflects consideration of
the tradeoffs among these needs.
 1) Communication among stakeholders :

Software architecture represents a common abstraction

of a system that most if not all of the system’s
stakeholders can use as a basis for mutual
understanding, negotiation, consensus and
communication.
 2) Early design decisions:

Software architecture manifests the earliest design

decisions about a system with respect to the system's
remaining development, its deployment, and its
maintenance life. It is the earliest point at which design
decisions governing the system to be built can be
analyzed.
 3) Transferable abstraction of a system:

Software architecture model is transferable across

systems. It can be applied to other systems exhibiting
similar quality attribute and functional attribute and
functional requirements and can promote large-scale
re-use.
 Software architecture represents a system’s earliest set
of design decisions. These early decisions are the most
difficult to get correct and the hardest to change later in
the development process, and they have the most far-
reaching effects.
 The architecture defines constraints on
implementation :

This means that the implementation must be divided

into the prescribed elements, the elements must interact
with each other in the prescribed fashion, and each
element must fulfill its responsibility to the others as
dictated by the architecture.
 The architecture dictates organizational structure :

The normal method for dividing up the labor in a large

system is to assign different groups different portions of
the system to construct. This is called the work breakdown
structure of a system.
 The architecture inhibits or enables a system’s
quality attributes :

Whether a system will be able to exhibit its desired (or

required) quality attributes is substantially determined by
its architecture.
However, the architecture alone cannot guarantee
functionality or quality.
 Decisions at all stages of the life cycle—from high-
level design to coding
And
Implementation—affect system quality. Quality is not
completely a function of architectural design.

 To ensure quality, a good architecture is necessary, but

not sufficient.
 Software systems change over their lifetimes.
 Every architecture partitions possible changes into
three categories: local, nonlocal, and architectural.
 A local change can be accomplished by modifying a
single element.
 A nonlocal change requires multiple element
modifications but leaves the underlying architectural
approach intact.
 Architecture helps in evolutionary prototyping .
 The system is executable early in the product's life
cycle. Its fidelity increases as prototype parts are
replaced by complete versions of the software.
 A special case of having the system executable early is
that potential performance problems can be identified
early in the product’s life cycle.
 Cost and schedule estimates are an important
management tool to enable the manager to acquire the
necessary resources and to understand whether a
project is in trouble.
 The earlier in the life cycle re-use is applied, the greater
the benefit that can be achieved. While code reuse is
beneficial, re-use at the architectural level provides
tremendous leverage for systems with similar
requirements.
 A software product line or family is a set of software-
intensive systems sharing a common, managed set of
features that satisfy the specific needs of a particular
market segment or mission and that are developed
from a common set of core assets in a prescribed
way.
 Whereas earlier software paradigms focused on
programming as the prime activity, with progress
measured in lines of code, architecture-based
development often focuses on composing or
assembling elements that are likely to have been
developed separately, even independently, from each
other
 We wish to minimize the design complexity of the
system we are building. Advantages to this approach
include enhanced re-use more regular and simpler
designs that are more easily understood and
communicated, more capable analysis, shorter selection
time and greater interoperability.
 An architecture embodies design decisions about how
elements interact that, while reflected in each element's
implementation, can be localized and written just once.
Templates can be used to capture in one place the inter-
element interaction mechanisms.
 The architecture, including a description of how
elements interact to carry out the required behavior, can
serve as the introduction to the system for new project
members.
 Architectural structures can by and large be divided
into three groups, depending on the broad nature of the
elements they show.
 Here the elements are modules, which are units of
implementation.
 Modules represent a code-based way of considering the
system.
 They are assigned areas of functional responsibility.
 There is less emphasis on how the resulting software
manifests itself at runtime.
 Module structures allow us to answer questions such
as
1. What is the primary functional responsibility
assigned to each module?
2. What other software elements is a module allowed to
use?
3. What other software does it actually use?
4. What modules are related to other modules by
generalization or specialization (i.e., inheritance)
relationships?
 Here the elements are runtime components (which are
the principal units of computation) and connectors
(which are the communication vehicles among
components).
Component-and-connector structures help answer
questions such as
1. What are the major executing components and how do
they interact?
2. What are the major shared data stores?
3. Which parts of the system are replicated?
4. How does data progress through the system?
5. What parts of the system can run in parallel?
6. How can the system's structure change as it executes?
 Allocation structures show the relationship between the
software elements and the elements in one or more
external environments in which the software is created
and executed.
They answer questions such as
1. What processor does each software element execute
on?
2. In what files is each element stored during
development, testing, and system building?
3. What is the assignment of software elements to
development teams?
 Module-based structures include the following
structures.

 Decomposition: The units are modules related to each

other by the "is a submodule of " relation, showing how
larger modules are decomposed into smaller ones
recursively until they are small enough to be easily
understood.
 Uses: The units are related by the uses relation. One
unit uses another if the correctness of the first requires
the presence of a correct version (as opposed to a stub)
of the second.

 Layered: Layers are often designed as abstractions

(virtual machines) that hide implementation specifics
below from the layers above, engendering portability.

 Class or generalization: The class structure allows us

to reason about re-use and the incremental addition of
functionality.
 Component-and-connector structures include the
following structures.

 Process or communicating processes: The units here

are processes or threads that are connected with each
other by communication, synchronization, and/or
exclusion operations.
 Concurrency: The concurrency structure is used early
in design to identify the requirements for managing the
issues associated with concurrent execution.

 Shared data or repository: This structure comprises

components and connectors that create, store, and
access persistent data.

 Client-server: This is useful for separation of concerns

(supporting modifiability), for physical distribution,
and for load balancing (supporting runtime
performance).
Allocation structures include the following structures:

 Deployment: This view allows an engineer to reason

about performance, data integrity, availability, and
security.
 Implementation: This is critical for the management of
development activities and builds processes.
 Work assignment: This structure assigns responsibility
for implementing and integrating the modules to the
appropriate development teams.
 Each of these structures provides a different
perspective and design handle on a system, and each is
valid and useful in its own right.
 In general, mappings between structures are many to
many.
 Individual structures bring with them the power to
manipulate one or more quality attributes. They
represent a powerful separation-of concerns approach
for creating the architecture.
 Development: This view shows the organization of
software modules, libraries, subsystems, and units of
development. It is an allocation view, mapping
software to the development environment.

 Physical :This view maps other elements onto

processing and communication nodes and is also an
allocation view
 Logical :The elements are "key abstractions," which are
manifested in the object-oriented world as objects or
object classes. This is a module view.

 Process: This view addresses concurrency and

distribution of functionality. It is a component-and
connector view.
ANY QUERY
??????