Report from TSA-3. Tools for Architecture Descriptions
Subsubworkshop held as part of the NWPER'98 subworkshop on Tools for Software
Architecture (TSA)
Participants
PerOlof Bengtsson, University of Karlskrona/Ronneby, Sweden
Jan Bosch, University of Karlskrona/Ronneby, Sweden
Christian Damsgaard Jensen, IMAG-INRIA, France
Erik Arisholm, University of Oslo, Norway
??, University of Tartu, ??
Introduction
The domain of software architecture represents a rapidly developing area
in software engineering research. The architecture of a software system
refers to the top-level decomposition of a system into its major components.
This is, among others, because especially the ability of a system to fulfil
its quality requirements (QRs), e.g. reliability, performance, maintainability,
real-time etc., is influenced considerably by its architecture. The architecture
chosen for the system has associated upper limits to many quality requirements.
In addition, software architecture is used in the domain of product lines,
i.e. a group of products that share a common architecture and set of reusable
assets. In the figure below, a concept map describing the various concepts
related to software architecture.
The notion of software architecture provides the foundation of a number
of different concepts. An object-oriented framework can be viewed as consisting
of a domain-specific software architecture (DSSA) and a set of reusable
components. A DSSA contains, as the name implies, a software architecture,
although it is domain, rather than application specific. The quality factors
of a software system are influenced are both influenced by the software
architecture and by the implementation of the components. To fulfil quality
requirements, the software architect can, among others, make use of architectural
styles, architectural patterns and design patterns. In our terminology,
an architectural style is a predominant, architecture-wide organizational
principle. An architectural pattern provides a system-wide solution that
is not predominant as styles. An architectural pattern generally provides
a solution to dealing with a driving quality requirement. Design patterns
are local solutions in an architecture generally used to improve quality
factors in a part of the system. We refer to [2] for a more extensive discussion
of these issues.
We use the definition of software architecture as proposed in [1]: The
software architecture of a program or computing system is the structure
or structures of the system, which comprise software components, the externally
visible properties of those components, and the the relationships between
them.
Tools supporting software architectures
The notion of software architectures is highly promissing, but would benefit
considerably from advanced tool support. In this section, a number of different
tools are proposed, the subworkshop participants, believe would benefit
the industrial usage of explicit software architectures. The tool proposals
are categorized into architecture evaluation, architecture design and architecture
instantiation. Each of the categories is briefly discussed below.
Architecture evaluation: A software architecture is designed
to facilitate the fulfillment of quality requirements by the software system
built based on the architecture. However, to assure that the architecture
actually supports this, it has to be evaluated during design. Several approaches
to architecture evaluation are available making use of, e.g. scenarios,
simulation or mathematical modelling. Tools automating or supporting the
manual evaluation could greatly deminish the effort required on architecture
evaluation.
Architecture design: A description of a software architecture
generally consists of components and connectors between components. Architecture
design tools could support the selection and generation of connectors between
components. In addition, architecture design tools could support the application
of architectural styles, architectural patterns and design patterns on
an architecture description. One can view the architecture design to be
taken from version to the next by the application of one of the aforementioned
styles or patterns.
Architecture instantion: Assuming the presence of a completed
architecture design, one generally is interested in instantiating a system
based on the software architecture. A number of tools may support this
process and below we discuss two examples. First, the selection of reusable
components matching the requirements posed by the particular component
specification in the architecture would benefit from tool support where
present. In general, the subworkshop participants prefer a visual approach
to instantiating architectures. A second example is a tool generating the
application code based on the architecture description and the selected
components.
Conclusion
The notion of software architecture is receiving increasing amounts attention
in the software engineering research community. Two reasons for this are
related to the fact that a software architecture considerably influences
the ability of the software system to fulfill its quality attributes and,
secondly, that a software architecture can be used as a means to select
and incorporate componets in the software system that match the component
defintion.
With respect to tools for the domain of software architecture, we have
identified three relevant tool domains, i.e. architecture evaluation, architecture
design and architecture instantiation. We have discussed concrete tools
that could be built to address issues in each to these tool domains. Several
of the workshop participants intend to address the lack of tools in the
software architecture domain in the coming time.
References
[1] L. Bass, P. Clements R. Kazman, Software Architecture in Practice,
Addison-Wesley, 1998.
[2] PO Bengtsson & Jan Bosch, 'Scenario-based Architecture Reengineering,'
Proceedings of the 5th International Conference on Software Reuse,
June 1998.