Notes Software Architecture
Notes Software Architecture
Notes Software Architecture
1. Externally visible properties are those assumptions other elements can make of an element,
such as:
its provided services,
performance characteristics,
fault handling,
Shared resource usage, and so on.
3. The definition makes clear that systems can and do comprise more than one structure
4. The architecture defines relationship: Every computing system with software has a
software architecture because every system can be shown to comprise elements and the
relations among them.
Even though every system has architecture, it does not necessarily follow that the
architecture is known to anyone.
Perhaps all of the people who designed the system are long gone, the documentation has
vanished (or was never produced), the source code has been lost (or was never delivered),
and all we have is the executing binary code.
This reveals the difference between the architecture of a system and there presentation of
that architecture.
Unfortunately, an architecture can exist independently of its description or specification,
which raises the importance of architecture documentation.
5. The behavior of each element is part of the architecture in so far as that behavior can be
observed or discerned from the point of view of another element.
Such behavior is what allows elements to interact with each other, which is clearly part of
the architecture.
This is another reason that the box-and-line drawings that are passed off as architectures
are not architectures at all.
They are simply box-and-line drawingsor, to be more charitable, they serve as cues to
provide more information that explains what the elements shown actually do.
Technical context
It gives the customer the opportunity to receive a system (based on the same architecture) in a
more reliable, timely, and economical manner than if built from scratch.
A customer may in fact be willing to relax some of their requirements to gain these economies.
Shrink wrapped software has clearly affected peoples requirements by providing solutions that
are not tailored to any individuals precise needs but are instead inexpensive and (in the best of
all possible worlds) of high quality.
Project context
An architecture prescribes the units of software that must be implemented (or otherwise
obtained) and integrated to form the system.
These units are the basis for the development projects structure.
Teams are formed for individual software units; and the development, test, and integration
activities all revolve around the units.
Business context
A successful system built from architecture can enable a company to establish a foothold in a
particular market segment.
The architecture can provide opportunities for the efficient production and deployment of similar
systems, and the organization may adjust its goals to take advantage of its new found expertise to
plumb the market.
Professional context
The process of system building will affect the architects experience with subsequent.
A system that was successfully built around a particular technical approach will make the
architect more inclined to build systems using the same approach in the future.
Architectures that fail are less likely to be chosen for future projects.
Architectural Structures
A structure is the set of elements itself, as they exist in software or hardware.
Architectural structures can be divided into three groups, depending on the broad nature of
the elements they show.
1. Module
2. Component and Connector
Module
Some structures partition systems into implementation units, which we call modules.
Modules are assigned specific computational responsibilities, and are the basis of work
assignments for programming teams.
In large projects, these elements (modules) are subdivided for assignment to sub-teams.
Component-and-connector Structures
Other structures focus on the way the elements interact with each other at runtime to carry
out the systems functions.
We call runtime structures component-and-connector (C&C) structures.
In our use, a component is always a runtime entity.
Suppose the system is to be built as a set of services.
The services, the infrastructure they interact with, and the synchronization and interaction
relations among them form another kind of structure often used to describe a system.
These services are made up of (compiled from) the programs in the various
implementation units modules.
Allocation Structures
Allocation structures describe the mapping from software structures to the systems
environments
organizational
developmental
installation
Execution
For example
Modules are assigned to teams to develop, and assigned to places in a file structure for
implementation, integration, and testing. Components are deployed onto hardware in
order to execute.
Software architecture is a result of technical, business, and social influences. Its existence in
turn affects the technical, business, and social environments that subsequently influence future
architectures. We call this cycle of influences, from the environment to the architecture and back
to the environment, the Architecture Business Cycle (ABC).
3. The architecture can affect customer requirements for the next system by giving the
customer the opportunity to receive a system (based on the same architecture) in a more
reliable, timely, and economical manner than if the subsequent system were to be built
from scratch.
The customer may be willing to relax some requirements to gain these economies.
Shrink-wrapped software has clearly affected people's requirements by providing
solutions that are not tailored to their precise needs but are instead inexpensive and
(in the best of all possible worlds)of high quality.
4. The process of system building will affect the architect's experience with
subsequent systems by adding to the corporate experience base.
5. A few systems will influence and actually change the software engineering culture,
that is, the technical environment in which system builders operate and learn.
4. Figure illustrated below shows the architect receiving helpful stakeholder "suggestions."
8. The underlying problem, of course, is that each stakeholder has different concerns and goals,
some of which may be contradictory.
ARCHITECTURE ACTIVITIES:
As indicated in the structure of the ABC, architecture activities have comprehensive feedback
relationships with each other.
Creating the Business Case for the System:
1. Creating a business case is broader than simply assessing the market need for a
system. It is an important step in creating and constraining any future requirements
like:
How much should the product cost?
What is its targeted market?
What is its targeted time to market?
Will it needs to interface with other systems?
Are there system limitations that it must work within?
2. These are all questions that must involve the system's architects. They cannot be decided
solely by an architect, but if an architect is not consulted in the creation of the business case, it
may be impossible to achieve the business goals.
Finally, when architecture is created and used, it goes into a maintenance phase.
Constant vigilance is required to ensure that the actual architecture and its representation
remain faithful to each other during this phase.
Although work in this area is comparatively immature; there has been intense activity in recent
years.