Software Architecture.ppt

 Is this an architecture?
◦ Assuming (as many definitions do) that architecture is a set
of components (of which we have four) and connections
among them (also present), this diagram seems to fill the
bill.
◦ However, even if we accept the most primitive definition,
what can we not tell from the diagram?

 What is the nature of the elements?
 What is the significance of their separation?
 Do they run on separate processors?
 Do they run at separate times?
 Do the elements consist of processes, programs, or both?
 Do they represent ways in which the project labor will be
divided, or do they convey a sense of runtime separation?
 Are they objects, tasks, functions, processes, distributed
programs, or something else?

 What are the responsibilities of the elements?
 What is it they do?
 What is their function in the system?

 What is the significance of the connections?
 Do the connections mean that the elements
◦ communicate with each other,
◦ control each other,
◦ send data to each other,
◦ use each other, invoke each other,
◦ synchronize with each other,
◦ share some information-hiding secret with each other,
◦ or some combination of these or other relations?
 What are the mechanisms for the communication?
 What information flows across the mechanisms, whatever
they may be?

 What is the significance of the layout?
◦ Why is A on a separate level?
◦ Does it call the other three elements, and are the others not
allowed to call it?
◦ Does it contain the other three in an implementation unit sense?
 Or is there simply no room to put all four elements on the
same row in the diagram?

 The software architecture of a program or computing system
is the structure or structures of the system, which comprise
software elements, the externally visible properties of those
elements, and the relationships among them.

 architecture defines software elements. The architecture embodies
information about how the elements relate to each other.
 This means that it specifically omits certain information about
elements that does not pertain to their interaction.
◦ Thus, an architecture is foremost an abstraction of a system that
suppresses details of elements that do not affect how they use, are used
by, relate to, or interact with other elements.
 In nearly all modern systems, elements interact with each other by
means of interfaces that partition details about an element into
public and private parts.
◦ Architecture is concerned with the public side of this division; private
details—those having to do solely with internal implementation—are not
architectural.

 the definition makes clear that systems can and do comprise
more than one structure and that no one structure can
irrefutably claim to be the architecture.
◦ For example, all nontrivial projects are partitioned into implementation
units; these units are given specific responsibilities and are frequently the
basis of work assignments for programming teams. This type of element
comprises programs and data that software in other implementation units
can call or access, and programs and data that are private.
 In large projects, these elements are almost certainly
subdivided for assignment to sub-teams.
◦ This is one kind of structure often used to describe a system.
◦ It is very static in that it focuses on the way the system's functionality is
divided up and assigned to implementation teams.

 Other structures are much more focused on the
way the elements interact with each other at
runtime to carry out the system's function.
◦ Suppose the system is to be built as a set of parallel
processes.
◦ The processes that will exist at runtime, the programs in
the various implementation units described previously that
are strung together sequentially to form each process,
◦ and the synchronization relations among the processes
form another kind of structure often used to describe a
system.

 Are any of these structures alone the architecture?
◦ No, although they all convey architectural information. The architecture
consists of these structures as well as many others.
 This example shows that since architecture can comprise more
than
 one kind of structure,
 there is more than one kind of element (e.g., implementation unit and
processes),
 more than one kind of interaction among elements (e.g., subdivision and
synchronization),
 and even more than one context (e.g., development time versus runtime).
 By intention, the definition does not specify what the
architectural elements and relationships are.
◦ Is a software element an object?
◦ A process?
◦ A library?
◦ A database?
◦ A commercial product?
◦ It can be any of these things and more.

 Third, the definition implies that every
computing system with software has a
software architecture because every system
can be shown to comprise elements and the
relations among them.

 An architectural pattern is a description of element and
relation types together with a set of constraints on how they
may be used.
 A pattern can be thought of as a set of constraints on
◦ an architecture
◦ on the element types and their patterns of interaction
◦ and these constraints define a set or family of architectures that satisfy
them.
 For example, client-server is a common architectural pattern.
◦ Client and server are two element types, and their coordination is
described in terms of the protocol that the server uses to communicate
with each of its clients.

 One of the most useful aspects of patterns is that they exhibit
known quality attributes. This is why the architect chooses a
particular pattern and not one at random.
 Some patterns represent known solutions to performance
problems, others lend themselves well to high-security
systems, still others have been used successfully in high-
availability systems. Choosing an architectural pattern is
often the architect's first major design choice.
 The term architectural style has also been widely used to
describe the same concept.

 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.
◦ Arising from experience, reference models are a characteristic of
mature domains.

 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. The
mapping may be, but by no means necessarily is, one
to one.
◦ A software element may implement part of a function
or several functions.

 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.1) The architecture defines constraints on
implementation
◦ An implementation exhibits an architecture if it conforms to
the structural design decisions described by the
architecture.
◦ 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.

 Not only does architecture prescribe the structure of the
system being developed, but that structure becomes
engraved in the structure of the development project .
◦ 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.
◦ Because the system architecture includes the highest-level
decomposition of the system,
◦ it is typically used as the basis for the work breakdown structure, which
in turn dictates units of planning, scheduling, and budget; inter-team
communication channels; configuration control and file system
organization; integration and test plans and procedures

 Whether a system will be able to exhibit its
desired (or required) quality attributes is
substantially determined by its architecture.
◦ If your system requires high performance, you need
to manage the time-based behavior of elements
and the frequency and volume of inter-element
communication.

◦ If modifiability is important, you need to assign responsibilities to
elements such that changes to the system do not have far-reaching
consequences.
◦ If your system must be highly secure, you need to manage and protect
inter-element communication and which elements are allowed to access
which information.
◦ If you believe scalability will be needed in your system, you have to
carefully localize the use of resources to facilitate the introduction of
higher-capacity replacements.
◦ If you want the elements of your system to be re-usable in other systems,
you need to restrict inter-element coupling so that when you extract an
element it does not come out with too many attachments to its current
environment to be useful.

 The software development community is
coming to grips with the fact that roughly 80
percent of a typical software system's cost
occurs after initial deployment.
◦ Many if not most programmers and designers never
work on new development—they work under the
constraints of the existing body of code. Software
systems change over their lifetimes; they do so often
and often with difficulty.

 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.
◦ An architectural change affects the fundamental ways in
which the elements interact with each other—the pattern of
the architecture—and will probably require changes all over
the system.

 Deciding when changes are essential,
◦ determining which change paths have the least risk,
◦ assessing the consequences of proposed changes,
◦ and arbitrating sequences and priorities for requested changes all
require broad insight into relationships, performance, and
behaviors of system software elements.
 These are in the job description for an architect.
 Reasoning about the architecture can provide the
insight necessary to make decisions about
proposed changes.

 Once an architecture has been defined, it can be
analyzed and prototyped as a skeletal system. This
aids the development process in two ways.
◦ 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.
◦ These prototype parts can be a lower-fidelity version of
the final functionality, or they can be surrogates that
consume and produce data at the appropriate rates.
◦ 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.
 Cost estimations based on an understanding
of the system pieces are, inherently, more
accurate than those based on overall system
knowledge.

 As we have said, the organizational structure of a
project is based on its architecture.
◦ Each team will be able to make more accurate estimates for
its piece than a project manager will and will feel more
ownership in making the estimates come true.
 Second, the initial definition of an architecture
means that the requirements for a system have
been reviewed and, in some sense, validated.
◦ The more knowledge about the scope of a system, the more
accurate the estimates.

 The earlier in the life cycle re-use is applied, the greater the
benefit that can be achieved.
 While code re-use is beneficial, re-use at the architectural
level provides tremendous leverage for systems with similar
requirements.
◦ Not only code can be re-used but so can the requirements that led to the
architecture in the first place, as well as the experience of building the re-
used architecture.
◦ When architectural decisions can be re-used across multiple systems, all
of the early decision consequences we just described are also transferred.

 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.
 Chief among these core assets is the architecture that was designed
to handle the needs of the entire family.
◦ Product line architects choose an architecture (or a family of closely related
architectures) that will serve all envisioned members of the product line by making
design decisions that apply across the family early and by making other decisions
that apply only to individual members late.
◦ The architecture defines what is fixed for all members of the product line and what is
variable. Software product lines represent a powerful approach to multi-system
development that shows order-of-magnitude payoffs in time to market, cost,
productivity, and product quality.

 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.
 This composition is possible because the
architecture defines the elements that can be
incorporated into the system.

 One key aspect of architecture is its organization of element
structure, interfaces, and operating concepts. The most significant
principle of this organization is interchangeability.
 Commercial off-the-shelf components, subsystems, and compatible
communications interfaces all depend on the principle of
interchangeability. However, there is much about software
development through composition that remains unresolved.
 When the components that are candidates for importation and re-
use are distinct subsystems that have been built with conflicting
architectural assumptions, unanticipated complications can increase
the effort required to integrate their functions.
◦ David Garlan and his colleagues coined the term architectural mismatch to describe
this situation

 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.
◦ This reinforces our point that one of the important uses of
software architecture is to support and encourage
communication among the various stakeholders. The
architecture is a common reference point.

Software Architecture.ppt

Recommended

More Related Content

Similar to Software Architecture.ppt (20)

Recently uploaded (20)

Software Architecture.ppt

Editor's Notes