Software architecture
Software Development Process
The software architecture of a system comprises its
software components, their external properties, and
their relationships with one another. The term also
refers to documentation of a system's software architecture.
Documenting software architecture facilitates communication
between stakeholders, documents early decisions about
high-level design, and allows reuse of design components
and patterns between projects.
Background
The field of computer science has come across problems
associated with complexity since its formation. Earlier
problems of complexity were solved by developers by
choosing the right data structures, developing algorithms,
and by applying the concept of separation of concerns.
Although the term “software architecture” is relatively
new to the industry, the fundamental principles of the
field have been applied sporadically by software engineering
pioneers since mid s. Early attempts to capture and
explain software architecture of a system were imprecise
and disorganized - often characterized by a set of box-and-line
diagrams. During the ’s there was a concentrated effort
to define and codify fundamental aspects of the discipline.
Initial sets of design patterns, styles, best practices,
description languages, and formal logic were developed
during that time.
The software architecture discipline is centered on
the idea of reducing complexity through abstraction
and separation of concerns. To date there is still no
agreement on the precise definition of the term “software
architecture”.
As a maturing discipline with no clear rules on the
right way to architect a system the action of architecting
is still a composition of art and science. The “art”
aspect of software architecture is due to the fact that
a commercial software system supports some aspect of
a business or a mission. How a system supports key business
drivers is described via scenarios as non-functional
requirements of a system, also known as quality attributes,
determine how a system will behave. Every system is
unique due to the nature of the business drivers it
supports, as such the degree of quality attributes exhibited
by a system such as fault-tolerance, backward compatibility,
extensibility, reliability, maintainability, availability,
security, usability, and such other –ilities will vary
with each implementation.
To bring a software architecture user's perspective
into the software architecture, it can be said that
software architecture gives the direction to take steps
and do the tasks involved in each such user's speciality
area and interest e.g. the stake holders of software
systems, the software developer, the software system
operational support group, the software maintenance
specialists, the deployer, the tester and also the business
end user. In this sense software architecture is really
the amalgamation of the multiple perspectives a system
always embodies. The fact that those several different
perspectives can be put together into a software architecture
stands as the vindication of the need and justification
of creation of software architecture before the software
development in a project attains maturity.
History
The origins of software architecture as a concept was
first identified in the research work of Edsger Dijkstra
in and David Parnas in the early ’s. The scientists
emphasized that the structure of a software system matters
and getting the structure right is critical. The study
of the field increased in popularity since the early
s with research work concentrating on architectural
styles (patterns), architecture description languages,
architecture documentation, and formal methods. Many
research institutions such as Carnegie Mellon University
and University of California, Irvine are doing a lot
of research in the field of software architecture. Mary
Shaw and David Garlan of Carnegie Mellon wrote a book
titled Software Architecture: Perspectives on an Emerging
Discipline in , which brought forward the concepts in
Software Architecture, such as components, connectors,
styles and so on. UCI's Institute for Software Research's
efforts in software architecture research is directed
primarily in architectural styles, architecture description
languages, and dynamic architectures.
ANSI/IEEE -: Recommended Practice for Architecture Description
of Software-Intensive Systems is the first formal standard
in the area of software architecture, and was recently
adopted by ISO as ISO/IEC DIS .
Describing architectures
Architecture description languages
Architecture description languages (ADLs) are used to
describe a Software Architecture. Several different
ADLs have been developed by different organizations,
including Wright (developed by Carnegie Mellon), Acme
(developed by Carnegie Mellon), xADL (developed by UCI),
Darwin (developed by Imperial College London), DAOP-ADL
(developed by University of Malaga). Common elements
of an ADL are component, connector and configuration.
Views
Software architecture is commonly organized in views,
which are analogous to the different types of blueprints
made in building architecture. Within the ontology established
by ANSI/IEEE -,
views are instances of viewpoints, where a viewpoint
exists to describe the architecture in question from
the perspective of a given set of stakeholders and their
concerns.
Some possible views (actually, viewpoints in the ontology)
are:
Functional/logic view
Code view
Development/structural view
Concurrency/process/thread view
Physical/deployment view
User action/feedback view
Several languages for describing software architectures
have been devised, but no consensus has yet been reached
on which symbol-set and view-system should be adopted.
Some believe that UML will establish a standard for
software architecture views. Others believe that effective
development of software relies on understanding unique
constraints of each problem, and so universal notations
are doomed because each provides a notational bias that
necessarily makes the notation useless or dangerous
for some set of tasks. They point to the proliferation
of programming languages and a succession of failed
attempts to impose a single 'universal language' on
programmers, as proof that software thrives on diversity
and not on standards.
From
Wikipedia
