History:
The notion of Software Architecture (SA) may be related to
precursor work on system decomposition and
system abstraction: the notion of decomposing software
systems into modules has been largely analyzed in the '60s
and '70s (as
reported in [Garlan2001]): in 1968 Dijkstra [Dijkstra68]
considered the problem to structure a computer program, in
1975 a Module Interconnection Language (MIL) has been
presented in [DeRemerKron76] to partition the software
into units
(separately implementable) and to define the relationships
between
parts. The notion of abstraction may be found in [Shaw89]
where Shaw presents its approach to embody abstract
information into classes of components and illustrate
methods for components composition.
Based on these (and many others) previous works, SAs
emerged in the '90s as a discipline to structure complex
software systems, exploiting commonalities in specific
organizations domain (pipeline, client-server, pipe and
filter) and to provide a high-level system description. In
1992, Perry and Wolf [PerryWolf92] propose one of the
earliest definitions of SAs describing them as "a set of
architectural (or, if you will, design) elements that have
a particular form" in which elements are divided into
processing elements, data elements and
connection elements. Garlan and Shaw, in
[GarlanShaw93], suggest that an SA for a specific system
may be captured as ``a collection of computational
components -
or simply components - together with a description of the
interactions between these components - the connectors".
These and other definitions
[DefSA-Boehm95,SADefCarnegie_W] proposed in the '90s
present SAs as a tool to represent the system architecture
by modeling individual components and their interactions
and focusing on the overall organization of a large
software system (the glue) using abstractions of
individual
components.
Initially, the SA description mainly relied on
architectural paradigms (pipelines, layered systems,
client-server organizations) described through informal
box-and-line diagrams. In [GarlanShawBook] (1996) the
authors put in evidence how
this diagrammatic description of SA is ambiguous, not
supported by
tools and without specific criteria for selecting
architectures.
Anyway, they also highlight the practitioners interest in
this new
discipline (also demonstrated by the success of the
[GPT95,Gar95a] workshops on SA). Moreover, SAs where
difficult to be maintained and impossible to be analyzed
and there was no way to check consistency among
requirements, SA and system implementation. However, the
industry recognized the importance of
SA as a mean to create a library of components
(techniques, patterns and so on) reusable in the
development of new software systems.
New languages for describing architectures were needed. An
ideal architectural description language would provide [GarlanShawBook]:
- Composition: it should be possible to
describe systems
as composed of existent libraries of components and
connectors;
- Abstraction: components and connectors
should be described
at a desired level of abstraction hiding unnecessary
details and
putting in evidence important properties;
- Reusability: components, connectors and
whole architectures
should be reused to develop new components, connectors and
system
architectures;
- Analysis: architectural descriptions
should be analyzed.
Existing languages and notations do not have the ability
to point out these (and other) architectural properties
thus the need to develop SA ad hoc tools.
Formalizing Software Architectures
A primary problem in this area is related to the
ability to suitably describe SAs. Tools and architectural
languages have been introduced in order to make rigorous
architectural specifications, avoiding ambiguity and
making possible architecture-based analysis. Architectural
Description Languages (ADLs) [ADL_Neno97,GarlanPerry95]
were born providing a well defined syntax to define
architectural entities. Each one has its own formalism to
represent the topological and dynamic description of an
SA; the Software Architect detects the system components
and connectors, the ports, the interfaces and all that is
needed by
the ADL topological model and group them together in a
graphical (or syntactical) notation reflecting the
architectural rules and constrains. Some of the initially
defined ADLs are Unicon, Aesop, C2, Darwin and FSP,
Wright, Cham and Rapide. We will very briefly summarize
these ADLs giving some references on how to access the
full information:
- Aesop ('94) [Aesop,Aesop_W} is a
system for developing style-oriented architectural
design environments. It provides a generic toolkit and
communication infrastructure that users can customize with
architectural style descriptions and a
set of tools that they would like to use. Aesop helps the
software engineer to exploit design and domain knowledge
when producing domain specific architectures. Rapidly
generate design environments for producing families of
software systems. Store, retrieve, and organize libraries
of "style-aware" architectural design elements and
patterns with the Software Shelf
[Aesop_W].
- Unicon ('95) [UniCon95,Unicon_W] is an
architectural-description
language intended to aid designers in defining SAs in
terms of abstractions that they find useful. An
architecture description in UniCon consists of a set of
components and connectors: each component has an interface
that define
computational rules and constrains. Connectors are
specified by a protocol defining how components may
interact. UniCon support schedulability analysis on
non-functional properties. It only has a predefined set of
types.
UniCon is an implementation constraint ADL, i.e.,
architectural elements (components, connectors, ports,
...) are directly related to their implementations. In
particular, UniCon provides a mechanism to point to source
documents, external to
UniCon, containing the components implementation in
different programming languages.
UniCon is supported by a proactive graphical editor
that prevents errors occurring during the architectural
design. More details may be found in the UniCon Web site [Unicon_W].
- Darwin ('95) [Darwin,Darwin_W] is a
language for describing software structures in terms of
primitive and composite components. Components expose
well-defined interfaces representing a service provided or
required by that component. Programs are constructed by
creating instances of component types and binding
their interfaces together. Connectors in Darwin are the
bindings. Darwin considers such compositions also to be
types and hence encourages hierarchical composition. The
general form of a Darwin program is therefore the tree in
which the root and all intermediate nodes are composite
components; the leaves are
primitive components encapsulating behavioral as opposed
to structural aspects [Darwin_W].
Darwin possesses both a textual and graphical notation and
a process algebra (the Finite State Process (FSP) [FSP_W])
allowing for analysis at the architecture-level.
- The Cham formalism [BerryBoudol:TCS92] was
developed by Berry and Boudol in the field of theoretical
computer science for the principal purpose of defining a
generic computational framework. This formalism based on
molecules and
chemical reactions has been adapted to describe SAs
in [InvWolf:TSE95] ('95). The Cham syntax will be
summarized in Section "Cham" while its use for SA-based
analysis is presented in Section "SA_Analysis".
- Rapide ('95) [Rapide,Rapide_W] is a
general-purpose system description language that allows
modeling of component interfaces and their externally
visible behavior. In Rapide, an architecture is composed
of a number of interfaces and the connections among them.
A complete definition of an interface requires both what
services it offers to other components in the system and
the services required from the rest of the system to
perform the offered services.
Rapide is a language framework consisting of i) a type
language, ii) an executable architecture definition
language, iii) a specification language, and iv) a
concurrent reactive programming language.
Rapide is designed to support component-based development
of large, multi-language systems by utilizing architecture
definitions as the development framework. The main engine
behind the power in Rapide is its model of computation
based on Partially Ordered Sets of Events (posets). Under
this model, a computation is represented as a set of
events generated by the execution of the system. Each
event represents the occurrence of an activity
within a program. Posets provide a formal basis for
constructing early life cycle prototyping tools, allowing
architectural designs to be simulated through automatic
tools.
How Rapide may be used to perform SA analysis is briefly
discussed
in Section "SA_Analysis".
- C2 ('96) [C2,C2_W] is a component- and
message- based architectural style, well suited for
large-scale, heterogeneous and distributed applications. A
C2 architecture is a hierarchical network of concurrent
components linked together by connectors following style
rules. Central to the architectural style is a principle
of limited visibility, or substrate independence: each
component interface can be attached to at most one
connector; a connector may be attached to any number of
other components and connectors; request msgs may only be
sent ``upward" through the architecture while
notifications msgs may only be sent ``downward", i.e., a
component is only aware of services provided by components
``above" it in the hierarchy, and is completely unaware of
services provided by components ``beneath" it.
C2 is scalable (its component may run in different
environment, may be of various granularity and may have
its own thread of control) and flexible with respect to
users, dialogs and tool kits. C2 SADL is the language for
defining architectures built according to the C2 style.
- Wright ('97)[AllenGarlan:TOSEM97] is an
architectural-specification language to support more
direct specification and analysis of architectural
descriptions. Its
specifications are based on the idea that interaction
relationships among components of a software system should
be directly specifiable as protocols. A Wright description
specifies components and connector classes and the system
configuration using instances of classes, defining the
architectural topology as
a list of attachments.
Wright can be used to provide a precise, abstract, meaning
to an architectural specification and to analyze both the
architecture of individual software systems and of
families of systems. work on Wright has focussed on the
concept of explicit connector types, on the use of
automated checking of architectural properties, and on the
formalization of architectural styles.
Wright is an implementation independent language
that do not prescribe a particular relationship between an
architectural description and an implementation. More
information may be get in [Wright_W].
- PADL ('00) [BernardoFSE00](Process Algebra
based Architectural
Description Language) is inspired by Darwin and Wright and
allows abstraction and compositionality mechanisms that
makes it well suited to be used as an ADL. PADL formalizes
the concept of architectural type as a restriction
to the concept of architectural style to make easier the
investigation on properties
which are common to instances of architectural styles. In
architectural types, components behaviors may vary from
architectural instance to architectural instance but the
topology is fixed.
For more details, [Clements96,InPractice_Chap12] present a
survey on ADLs, cataloguing ADLs features in a structured
fashion; in [ADL_Neno97] the authors characterize ADLs
showing what they should have or should be able to do,
presenting a concise classification framework for ADLs.
SA Views
The languages and formalisms presented in the previous
section, differ in many aspects and there is not a
standard notation or specification language to describe
SAs. As a way to cope with many different ADL syntaxes, a
partial solution has been represented by libraries to
support the integration of different ADL technologies
(Acme) [Acme_W]. The main problem occurring in this
approach
is the difficulty to simulate the same information
especially referring to the dynamic aspects of the
description. Inaccuracy or a bad knowledge of the
environment can generate really different results in terms
of system analysis.
More recently, researchers in industry and academia have
integrated the SA description in their software
development processes, e.g. [Applied,InPractice]. They
have understood some SA benefits: SA can play a
significant role in the
development process improving the dependability of large
complex software products, while reducing development
times and costs [GarlanShawBook,Applied]. SA represents
the most promising approach to tackle the problem of
scaling up in software engineering, because, through
suitable abstractions, it provides the way to make large
applications manageable.
Software architects have also learnt some lessons: i)
despite the high-level of abstraction, notably in
industrial contexts, the SA can be too complex to
be described and managed; ii) SA production and
management is, in general, an expensive task.
Therefore the effort is justified if the SA artifacts are
extensively used for multiple purposes. Typical use of SA
is as a high-level design blueprint of the system to be
used during the system development and later on for
maintenance and reuse. At the same time SA can be used in
itself in order to analyze and validate architectural
choices, both behavioral and quantitative. For this
reasons architectural descriptions encompass not only
static information but also dynamic (behavioral) aspects.
To tackle system complexity several viewpoints
[Kruchten,Applied,JJWicsa99] have been introduced. The
Kruchten work [Kruchten] ('95) on the 4+1 views has been
recognized as the first relevant work on this subject but
the need
of multiple views has been previously advocated by Perry
and Wolf in [PerryWolf92] in which they say that ``the
software architect needs a number of different views of
the SA for the various uses and users", in [SAAM94] the
authors define three perspectives for understanding and
describing architectures
functionality, structure and allocation. Also Boehm in
[DefSA-Boehm95] says: ``behavioral/operational view,
static topological view and a dataflow view... and also
other views that are concerned with other stakeholder
needs".
The use of views allows to handle different aspects of the
system separately and to manage the description of real
systems. Several slightly different views are defined in
different approaches:
- in [Kruchten] the author defines four-plus-one views:
the logical view, which is the object model of the
design, the development view, the static
organization of the
software, the process view, which captures the
concurrency and synchronization aspects of the design, the
physical view which maps the software onto the
hardware. The fifth view is the use case one,
representing dynamic aspects (sequences of interactions
between objects) shared in all the other views;
- in [Applied] the authors present a different
organization of views: conceptual, module, execution and
code. These views are semantically close to those defined
in [Kruchten] but, in this case, each view may be
represented by several UML diagrams.
- [UmlProcess] also proposes an interpretation of
architectural views. It presents a use case driven,
architecture-centric, iterative and incremental process in
which
views are mapped into UML models.
Just to demonstrate the attention the community has given
to views, in the Proc. of the second Int. Software
Architecture Workshop (ISAW-2) [ISAW96] there are more
than twenty papers on views definition, consistency and
support.
Different notations, generally graphical, have been
introduced for views representation and approaches have
been proposed to check views consistency: in [Michael] the
authors propose an approach to design a method for
multiple view consistency checking. The SA specification
is defined in terms of a collection
of diagrams each one representing a software view without
a mathematical basis. To check the view consistency, they
provide a formal definition of the views and their
relationships, define their semantics as sets of graphs
and apply an algorithm to check the consistency of
diagrams.
In [Filken_Incons] the authors present how inconsistencies
may be handled using the ViewPoints framework
and a logic-based consistency handling. Their approach is
based on the assumption that to check specifications
consistency among view points is equivalent to an
inconsistency handling in distributed
logical databases: views specified in the ViewPoints
framework are translated into classical logic formulae and
stored in logical databases checked for consistency using
temporal logic.
In [ASE01,Straw01] we propose our approach to manage view
consistency checking, supposing to have state diagrams and
scenarios models representing the SA dynamics at the
architectural level; we want to prove that they describe,
from different viewpoints, the same system behavior using
the SPIN model checker. Our approach will be presented in
Chapter 11.
In the next section we will analyze how UML has been
adapted to model multi views SAs.
Software Architecture and UML
The multi-view design helps the software architect to
specify complex architectures from different perspectives
but does not provide a solution for the lack of standard
notations and languages. As already introduced, SAs are
formalized using several different ADLs, based on
different languages (poset, pi-calculus, process algebra,
Chemical reactions,...), and with different analysis
capabilities.
As a way to provide a standard notation to formally
describe SAs, some researchers have proposed to extend the
Unified Modeling Language (UML) [UML] to deal with SAs.
UML is a standard that has wide acceptance and is even
more widely used. Although its original purpose was for
detailed design, its extension mechanisms makes it
potentially applicable much more broadly. These facts
suggest a strategy to incorporate in the UML framework
pieces of
information that are provided by the architectural
descriptions.
In this direction various approaches have been proposed in
the last few years, mostly describing multiple views SAs:
- the first paper proposing the use of UML to formalize
static aspects of SAs is [RMRR98] in 1998. In this work
the authors show how UML can be extended to fit the C2 ADL
architectural style. The proposed idea is to extend
the UML meta-model with new meta-classes (as subclasses of
existing meta-classes) using the
UML-provided extension mechanisms. In [Neno_Wicsa99]
Medvidovic and Rosenblum refine the approach and they
believe Sequence, Collaboration and Activity diagrams may
be used to model C2's components behavior;
- another relevant work is that proposed by Booch in [Booch_W]:
the key idea is that each Kruchten [Kruchten] view may be
mapped into UML diagrams. The logical view is formalized
using Class diagrams, the process view is mapped to
Activity diagrams, implementation and deployment views are
modeled by Component and Deployment diagrams,
respectively. The fifth view is expressed through Sequence
and Collaboration diagrams;
- Hofmeister, Nord and Soni in [UML_Wicsa99,Applied]
propose different, with respect to Kruchten, views
(conceptual, module, execution and code), each one
implemented by more UML diagrams. In the examples the book
presents, the conceptual view is implemented by Use Case
and Interaction diagrams, the module view is formalized
through Class diagrams, the execution view is
formalized using Deployment, Interaction, Activity and
Class diagrams. The code view is related to Component
diagrams;
- the Unified Software Development Process [UmlProcess]
also proposes four evolutionary views (Use Case, Analysis
Model, Design Model and Implementation Model) to be
defined during the development process and formalized
using UML.
More recently, some other works have addressed the use of
UML to
formalize SAs:
- Garlan et al. in [GarlanSA_00] propose their approach to
model SA using UML. This work has been extended in
[GarlanSA_01] in which six alternatives are presented for
modeling architectural structure using UML. The first
three consider how to use classes and objects to model
components, the fourth is based on UML
components, the fifth on UML subsystems and the last is
based on the UML Real-Time Profile. Before mapping
architectural constructs into UML elements, the authors
identify the elements composing an architectural
structure, i.e., components, connectors, systems,
properties and styles. What this approach offers more than
others is a more systematic analysis on what needs to be
modeled, examining the strength and weaknesses of adopting
a particular
modeling strategy.
Anyway, it considers only structural aspects mapping SAs
in UML, as other approaches. Concluding, the authors point
out that ``there is no single best way to encode ADLs in
UML. Each of the strategies has strengths and weakness".
- The SA community and researchers in industry understand
SAs in different ways, and use them with different goals.
What is needed is a formalism to create a bridge among
these different communities. [NenoUML&SA] proposes UML has
the tool to close the gap. For this purpose, the authors
propose two different approaches adhering to the
requirement that the resulting approach still involve
standard UML. In the first approach, UML is used ``as
is", i.e., the existing UML notation is used to represent
SAs. The second approach, instead, constrain the
UML meta model using UML built-in mechanisms. A third
approach was
initially analyzed; it was discarded since it makes use of
not standard UML concepts. The first approach has been
used to model the Meeting Scheduler in C2. The second
strategy has been used to constrain UML in order to
formalize architectures in C2, Rapide and Wright.
These results have been analyzed to evaluate the UML's
ability to represent SA effectively, putting in evidence
UML lacking in modeling and exploiting architectural
styles, in explicitly describe software connectors and in
formalizing local and global
architectural constrains.
- In the ICSE 2001 program, a tutorial
[SA&UML_ICSE01tutor] and a workshop [SA&UML_ICSE01work]
have been dedicated to the use of UML to describe SAs. The
tutorial discusses how to express views in the UML, in the
spirit of the new IEEE Standard 1471:2000. The workshop
brings together researchers and
practitioners in the fields of SA and the UML and
encompass the following areas of concentration: ontology
of architectures, architectural methodology and experience
and architectural analysis.
|
