Supporting Component-Based Development
through Customised Architectural Views
Rudi Vernik and Matthew Phillips
Software Systems Engineering Group
Information Technology Division
DSTO
Abstract
Architecture is often seen as an important aspect of software development; however, there
is considerable confusion as to what software architecture is and how architecture plays a
part in the overall development process. This paper argues that architecture should be
thought of as a customised set of developmental views based on key underlying domain,
design, and resource information/knowledge. We believe that architecture should not be
thought of in isolation: it should be considered it terms of the processes and approaches
used in a project (i.e. there is no standard concept of architecture, just a set of
characteristics that an architecture should provide in a particular context). This perspective
of architecture is discussed in terms of our component-based development experiences.
1. What is a software architecture?
A study of the literature suggests that there is no consensus as to the term “software
architecture”. It is often referred to in terms of the high-level structural characteristics of the
software (a type of high level design). For example, Boasson (1995) defines architecture as
being a system structure that consists of active modules, a mechanism to allow interaction
among these modules, and a set of rules that govern interaction. Buschmann, Meunier et al.
(1996) define software architecture as a description of the subsystems and components of a
software system and the relationships between them. They suggest that software
architecture of a system is an artifact - it is the result of the software design activity. The
relationship between architecture and component-based development features in many
definitions of software architecture. For example, the Second International Software
Architecture Workshop (ISAW-2) (Wolf 1997) suggested that software architecture “is
concerned with the principled study of large-grained software components, including their
properties, relationships and patterns of combination. Brown and Wallnau (1996) suggest
that software architecture is the “blueprint for component integration”.
To add to the confusion, there have been many schemes which define how a software
architecture should be represented. For example, Clements and Northrop (1996) suggest that
an architecture should be defined in terms of a specific set of views and representations:
conceptual, module, process, and physical. Meekel, Horton et al. (1997) define architecture
in terms of an Object View, Layered View, Task View, and Scenarios (all expressed using
the OMT notation). Soni, Nord et al. (1995) propose the following four views of software
architecture: Conceptual Architecture (components, connectors etc), Module Architecture
(subsystems, modules, exports, imports etc), Code Architecture (files, directories, libraries),
Execution Architecture (tasks, threads, processes).
The proposal that architecture is a specific developmental artifact resulting from an
“architecture” process raises a number of questions such as: What is the distinction between
architecture and design?
What is the relationship between the domain
knowledge/information and architecture? How does architecture fit into the overall
development process? How do we iterate between domain models, architectures, design and
implementation while maintaining consistency and traceability? What approach do we use
to describe the architecture and will it map with development approaches/tools? How will
the architecture be used? Will it result in a document focused approach where architecture
definition becomes an end in itself and where the resulting artifacts become shelf-ware
because they are difficult to update, contain superfluous information etc.
2. A Broader Perspective of Architecture
A number of authors have looked at the broader perspective of architecture. For example,
Kerth and Cunningham (1997) argue that a software architecture is a set of architectural
views that is based on a particular architectural philosophy and a set of requirements. This
philosophy is seen as a deep conviction as to how the system should be developed. They
suggest that it is important that this philosophy be communicated when dealing with large
projects and that effective pattern systems, much as Alexander (1979) has done for more
traditional architecture, will provide a basis for this communication.
Although architecture is often defined in terms of being a set of viewpoints, the nature of
these viewpoints in relation to user needs has had little mention. The draft IEEE standard on
“Recommended Practice for Architectural Description” highlights the importance of
selecting architectural viewpoints based on the interests of stakeholders (IEEE_Std_1471
1998).
3. Our Perspective
We argue that software architecture is an evolving set of core concepts, principles1, patterns,
guidelines and interfaces. It is that information and knowledge that is required to guide the
development and evolution of a software system. It can comprise high-level design
information which describes core structural principles but may also include contextual
information (including external interfaces), key concepts, frameworks, and components. We
believe that architecture should not be thought of in terms of a set of standard descriptions
that need to be produced. It should be thought of as a customised set of developmental
views based on key underlying domain, design, and resource information/knowledge.
Architecture should not be thought of in isolation: it should be considered it terms of the
processes and approaches used in a project (i.e. there is no standard concept of architecture,
just a set of characteristics that an architecture should provide in particular context). We
argue that architectures need to be tailored to the needs and approaches of a project.
Principles include Kerth and Cunningham’s concept of architectural philosophy. They can also include key
structural and dynamic characteristics including global control structures, distribution approach, protocols, and
concept/feature assignment.
1
4. An Example – Component Based Development
The following example will help illustrate our position. We are currently developing an
experimental infrastructure to support our research into the visualisation and description of
large complex systems (e.g. enterprise networks, heterogeneous software systems). As part
of this work, we are using a component-based software engineering approach to support the
development of a family of experimental domain-specific Integrated Visualisation
Environments (or IVEs). Domain engineering processes have developed a variety of
information/knowledge products including a set of concepts and features, use cases, highlevel design information expressed in the Unified Modelling Language (UML 1997) 2, a
database of component resources, functional and storyboard prototypes, etc.
Architecture
Domain
Knowledge
Infrastructure
Design
Implementation
Resources
Figure 1. Architecture within the project context
Figure 1 shows how this project information forms part of a continuum which ranges from
domain knowledge through to an implementation. This information is produced and used by
a range of developmental processes. For example, domain analysis processes produce
domain information and knowledge. The design process produces design-level information.
The construction process generates implementation artifacts, including the development of
core assets such as frameworks and components, as well as the assembly of these assets into
integrated artifacts and product releases.
In addition to the information and artifacts produced by the project, the Component-Based
Software Engineering processes draw from an underlying resource base. Resources could
include a range of reusable artifacts and information including Commercial-Off-The-Shelf
(COTS) components and frameworks, patterns, and standards.
Figure 1 shows two overlapping regions. These regions provide core information for the
component-based development process and are critical to the success of the approach. The
first is labeled as architecture. Since architecture is the focus of this paper, this aspect will
be discussed in detail in the next section. The second region is labeled as Infrastructure.
Infrastructure is shown as the intersection of design and implementation. It includes both
2
The use of UML for component-based development is itself an experiment, the results of which will be
reported separately.
software artifacts and design information used to support the assembly of software solutions.
Infrastructure comprises both custom-developed, Off-The-Shelf, and adapted frameworks
and components. It also includes design-level details and guidelines which are required as
part of the construction process.
5. Architecture in Context
In Figure1, Architecture is shown as the intersection of domain knowledge, design, and
resources. In the case of the IVE development, a Component Systems Architecture (CSA)
((Szyperski 1997), (Szyperski and Vernik 1998) ) is defined in terms of a set of Rational
Rose (1997) diagrams which provide abstract views of the underlying UML design. These
views show the various architectural principles inherent in the design. For example, IVE
products are developed using a layered set of “plugable” component frameworks and
components. CSA views show key relationships between these elements including the major
interfaces between frameworks and components. The views also show the use of those
elements of COTS software which have been defined as foundational elements (eg a
decision was made to use Java Swing as the framework for user interface development).
Key architectural principles are also described such as the approach for managing and
monitoring commands (i.e. aspects of system dynamics).
Rational Rose was used to provide tool support for the project. In addition to capturing the
design-level information, domain information was also stored in Rose to provide a mapping
between concepts and features to the underlying design. This then allows important domain
knowledge to be presented as part of of the CSA. The CSA is defined as abstraction of this
domain and design level information presented as a specific set of Rose diagrams.
Although our experiences show that Rose is not the ideal environment for integrated
component-based development, the approach we used does highlight a number of important
considerations. For example, by considering architecture as a set of views of underlying
domain, design, and resource information, there is a direct and consistent mapping between
domain information, architecture, and design. Updates to the architecture are directly
mapped to the design thereby addressing many of the problems inherent with the
“architecture is an artifact” approach. In fact, in the case of Rose, the “round trip
engineering” features allow a direct mapping through to implementation. Moreover, the
architecture is defined in terms of consistent project representations which may aid use and
understanding. Another important consideration is support for architecture validation.
Although the early design process focused primarily on defining the architectural concepts,
we found that in some cases we needed to undertake more detailed design in order to ensure
that the higher-level concepts were valid. Indeed, there may be a requirement to progress to
implementation (eg by way of a prototype) to effectively validate some architectural
principles.
6. Research Issues and Directions
The preceding discussion argues the benefit of considering architecture as being a set of
views of underlying project information rather than an artifact in its own right. However, this
approach raises a number of important issues that need to be considered such as:

What architectural characteristics do we need to describe for particular project domains
(eg a Component Systems Architecture)?

Do we need to customise architectural representations for individuals, roles, and project
contexts?

What supporting information is needed to aid architectural understanding?

How can underlying project information be filtered and customised into a set of
architectural views, particularly for large projects which may have diverse and
geographically distributed information sources?

How do software architectures evolve?
described?

What constitutes effective tool support in this area?
How can this evolution be captured and
Many of these issues will be investigated as part of our systems visualisation and description
research. This research aims at providing integrated computer-based visualisations which
can be customised and adapted to user needs. The approach focuses on a total domain
context which addresses issues related to the access, modelling and integration of
information as well as visual representation and presentation. The research provides an
interesting duality where the development of a family of experimental integrated
visualisation environments provides the focus of the component-based software engineering
investigations (including software architecture) and support for component-based
development itself features as one of the areas being investigated as part of the systems
visualisation research.
7. References
Alexander, C. (1979). The Timeless Way of Building, Oxford University Press.
Boasson, M. (1995). The Artistry of Software Architecture. IEEE Software November 1995:
13-16.
Brown, A. W. and K. C. Wallnau (1996). Engineering of Component-Based Systems. 2nd
International Conference on Engineering of Complex Computer Systems, IEEE Computer
Society Press.
Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad and M. Stal (1996). PatternOriented Software Architecture: A system of patterns. Chichester, John Wiley & Sons.
Clements, P. C. and L. N. Northrop (1996). Software Architecture: An Executive Overview.
Component-Based Software Engineering. A. W. Brown. Los Alamitos, CA, IEEE Computer
Society Press: 55-68.
IEEE_Std_1471 (1998). Recommended Practice for Architectural Description, Institute of
Electrical and Electronics Engineers, 345 East 45th Street, New York, NY 10017-2394.
Kerth, N. L. and W. Cunningham (1997). Using Patterns to Improve Our Architectural
Vision. IEEE Software January 1997: 53-59.
Meekel, J., T. B. Horton, R. B. France, C. Mellone and S. Dalvi (1997). From Domain
Models to Architecture Frameworks. Symosium of Software Reusability (SSR'97), Boston,
ACM.
Rose, R. (1997). Visual Modelling With Rational Rose.
http://www.rational.com/products/rose/.
Soni, D., R. Nord and C. Hofmeister (1995). Software Architecture in Industrial
Applications. 17 th International Conference on Software Engineering, Seattle, Washington,
ACM Press.
Szyperski, C. and R. J. Vernik (1998). Establishing System-Wide Properties of ComponentBased Systems: A Case for Tiered Component Frameworks. OMG/DARPA workshop on
Compositional Software Architecture, Monterey CA,
http://www.objs.com/workshops/ws9801/index.html.
Szyperski, C. A. (1997). Component Software: Beyond Object-Oriented Programming,
Addison-Wesley.
UML (1997). UML Resource Center. http://www.rational.com/uml/.
Wolf, A. L. (1997). Succeedings of the Second International Software Architecture
Workshop. ACM Software Engineering Notes 22(1): 42-56.
8. About the authors:
Dr Rudi Vernik is employed as a Principal Research Scientist at the Defence Science and
Technology Organisation (DSTO). In his position as Head of Software Systems Engineering
Group, he provides leadership to research teams which are focusing on defining, developing, and
applying new systems and software engineering approaches to support Defence in its development
of knowledge and information-based warfare capabilities. His group is currently undertaking
research in the areas of systems visualisation, component-based software engineering, systems
characterisation and modelling, systems dynamics, and evolutionary capability development
processes. Rudi has a Ph.D. in Computer and Information Science (Software Engineering) from the
University of South Australia. He also has a Bachelor of Electronics Engineering (with Distinction)
and a Diploma of Communications Engineering from the Royal Melbourne Institute of Technology.
Matthew Phillips is a researcher employed in Software Systems Engineering Group, Information
Technology Division. His research interests include distributed systems, programming language
design, software visualisation and object-oriented software engineering. Matthew has a Bachelor of
Computer Science (with Honours) from The University of Adelaide.