Jun Han
Peninsula School of Computing and Information Technology
Monash University
McMahons Road
Frankston, Vic. 3199, Australia
jhan@monash.edu.au
A position paper presented at the 1998 International Workshop
on Component-Based Software Engineering
Abstract
Understanding and codifying the characteristics of components is
essential to the effective management and development of component-based
software systems. In this paper, we analyse the characterization of objects,
review the treatment of components in software architecture description
languages, and contemplate an object-oriented characterization of
components in view of their use and management.
1. Introduction
As more and more systems are built from existing components, it has become
increasingly important to have proper characterization of components. Without
such characterization, much effort is wasted on the comprehension and
adaptation of components each time they are used. This has been evident from
practice. Furthermore, characterization of components is crucial to the
management of components as required by systematic component-based software
engineering.
It is still not clear how we should characterize components. In this paper,
we have a look at how objects are characterized in the object oriented
approach, and how components are treated in the context of software
architecture research. Then, we contemplate an object-oriented
characterization of components from the viewpoint of their use and management.
2. Objects
Object technology has been widely adopted , and has become the standard
for much of the software industry. Objects are the core concept of object
technology. In general, objects have static and dynamic aspects with
structural and behavioural definitions. In terms of characterization, objects
take on different forms at different levels of abstraction. In object oriented
programming, objects are characterized by attributes and operations:
OOP: object = attributes + operations.
where
all the constraints about the object structure and interaction are supposedly
embedded in the operations. OMG's object Interface Definition Language
also follows this characterization. There are also cases where
assertions are specified to state certain object invariants (or constraints)
[Meyer88].
In object-oriented analysis and design, the characterization of objects
are enriched to capture the sequencing and interaction of object manipulation
[Booch94]:
OOAD: object = attributes + operations + sequencing
[ ~ interactions/scenarios].
The sequencing of object operations usually takes the form of a state transition
diagram for the object (class). The interactions of objects are set in
the context of scenarios (rather than relative to individual objects),
and are usually specified in object diagrams and interaction diagrams.
In such characterization of objects, the constraints about the object behaviour
are captured explicitly through sequencing and interaction specifications,
which contributes towards the comprehension, management and use of
objects in system development.
3. Architectural Components
Over the past few years, we have seen growing research interests in
software architectures [Shaw96] and software
architecture description languages (SADLs) [Medvidovic97]. In this context, the architecture of
a software system is described in terms of components, connectors,
configurations, constraints, and possibly other aspects. The components may in
turn have their own internal architectures. The treatment of components in
this context takes rather diverse forms with varied emphasis. In [Medvidovic97], components are summarized as having
the following aspects: interface, types, semantics, constraints and
evolution. However, this does not give a clear characterization for
effective component management and use in an "open" manner.
In the object-oriented paradigm, objects are characterized as independent
entities and in terms of their usage and interactions with other objects
in the system. It is our view that components in software architectures
should be looked at in the similar manner. As such, the architectural components
can be seen as follows:
SAD: ArchComponent = attributes + operations +
constraints/sequencing/interactions.
The attributes are the structural elements of the architectural component
, and are usually those relevant to its interface (i.e., observables).
The operations are those allowable on the architectural component. The
constraints, sequencing requirements and/or interactions are those parts
of the architecture description that constrain the usage/interaction and
internal composition/state of the component. Different notations
are used to describe constraints in SADLs. Some focus on the constraints
on component usage/interaction, while others focus on the component's internal
consistency. The constraints that serve as the internal invariants of a
component are often not separated from restrictions about external interaction
scenarios.
In the current SADLs, in general, the encapsulation role of components
and their relationships to the overall system architecture are not clearly
defined or characterized. Consequently, the support for proper component
characterization is not obvious in the SADLs.
4. Object-Oriented Characterization of Components
As mentioned above, proper characterization of components is essential to
the effective management and use of components in component-based software
engineering. While there have been industrial/experimental projects that build
systems from (existing) components, the approaches taken are ad hoc and
heavily rely on the specifics of the systems and components concerned. That
is, component-based system development is still very much in its infancy, and
there are no proven systematic approaches to follow. Characterization of
components is a step towards such systematic approaches and their enabling
technologies, including component management infrastructures. In this section,
we contemplate a characterization of components in a manner that is similar to
but extends the characterization of objects in object technology, in the
hope to provide a basis for the development, management and use of components.
Therefore, it can be referred to as object-oriented characterization of
components.
The structural elements are essential aspects of a component in the
sense that they constitute the component, which we call attributes (following
the general convention). Among these elements are those that are relevant
to the interface of the component, i.e., the elements that form part of
the component's external view. These observable elements are particularly
important from the viewpoint of component management and use, and form
the basis of other aspects of component characterization.
Another aspect of a component is the operations, with which other
system components interact with it. These operations capture the dynamic
behaviour of the components and represent the service/functionality that
the component provides.
As in the case of objects, attributes and operations are the most essential
aspects of a component. In addition, the structural composition of the
component from attributes is usually subject to certain further constraints,
i.e., certain compositions of attribute instances may not be allowable.
We call these constraints structural constraints. Some examples
are constraints about the abstract state of the component, like those one
can specify in Rapide.
In terms of the dynamic behaviour of a component, not all possible sequences
of operation invocation on the component are allowable. That is, there
are operational constraints that specify the permissible operation
patterns. This aspect is similar to that of an object captured by the state
transition diagram.
Besides proactive control (usually in the form of explicit operation
invocation), another form of control used to capture system behaviour is
reactive control (usually in the form of event-driven implicit operation
invocation). It is often the case that certain aspects of a system are
better captured through proactive control while other aspects of the system
are better captured in the form of reactive control. To facilitate reactive
control, a component may generate events from time to time, that
other components in the system may choose to respond to. The Java component
model (i.e., JavaBeans) provides such support.
A component may interact with a number of other components from specific
perspectives (or playing specific roles). The interactions between the
component concerned and these other components may differ depending on
the components and their related perspectives. When interacting with a
particular type of component from a specific perceptive, for example, only
certain operations are applicable and some specific operational constraints
may apply. The port specifications in Wright goes some way towards this
direction. In general, this suggests the need for defining perspective/role-oriented
interaction protocols for a given component, i.e., multi-interfaces.
Besides, a component may be used in different scenarios and plays different
roles in these scenarios. The scenarios provide the contexts
of use for the component. From the viewpoint of the component, therefore,
there may be the need for different sets of interaction protocols, with
each set for a scenario in which the component is to be used. Alternatively,
one may argue that the role that a component plays in a (use) scenario
and consequently its interface towards that scenario is better defined
from the viewpoint of the scenario (rather than from the viewpoint of the
components involved). This requires further debate and investigation.
Another aspect of a component is its non-functional properties (code
named illities [Thompson98]), such as
security, performance and reliability). In the context of building systems
from existing components, the characterization of the components' illities
and their impact on enclosing systems are particularly important. However,
there is not much work done in this area.
To summarize the above characterization of components, we may have
Component = attributes + operations + structural constraints + operational
constraints +
events + multi-interfaces * scenarios + illities.
As indicated above, there are still issues to be resolved. In existing
approaches to software architecture description, the issues are addressed
with different concerns and therefore result in varied treatments. For
example, the port specifications in Wright can be seen as interaction protocol
specifications on the one hand and operational constraints (in a fixed
interaction scenario) on the other hand. In general, many existing approaches
adopt fixed specifications of interaction protocols for a component (e.g.,
fixed ports). It is also quite possible that a more dynamic (or "fluid")
approach is more appropriate, that allows the definition of varied interaction
protocols for different scenarios (all subject to the other (fundamental)
component characteristics, of course). Again, this is an open issue for
further debate.
It is pleasing to see that some industry-based component models are
being actively pursued and/or used, including COM components, JavaBeans,
and initial component model submissions to OMG. While providing valuable
support for component-based system development, these technologies are
still too simplistic and immature. Certain strategies taken are debatable.
For example, key features of components are only enabled through some "design
patterns" (in fact, just some naming conventions) in JavaBeans and some
OMG submissions, which is obscure and does not provide the "right" level
of support for system developers. In some way, it may be due to the models
and their support mechanisms' over reliance on the concept of objects.
In general, components should "grow out-of and above" objects.
5. Conclusions
In this paper, we have attempted an object-oriented characterization of
components. It is argued that such characterization is essential to the
systematic use and management of components. This characterization is set
in the context of analysing object characterization and reviewing component
treatments in current software architecture description languages. A few
open issues for further debate are also identified.
References
|
[Booch94]
|
G. Booch. Object-Oriented Analysis and
Design with Applications. 2nd Edition. Benjamin/Cummings, 1994.
|
|
[Medvidovic97]
|
N. Medvidovic and R.N. Taylor.
A framework for classifying and comparing software architecture description
languages. In Proceedings of 6th European Software Engineering Conference
and 5th ACM SIGSOFT Symposium on the Foundations of software Engineering
(LNCS -1301), pages 60-76, Zurich, Switzerland, September 1997.
Springer.
|
|
[Meyer88]
|
B. Meyer. Object-Oriented Software
Construction. Prentice-Hall, 1998.
|
|
[Shaw96]
|
M. Shaw and D. Garlan. Software Architecture:
Perspectives on an Emerging Discipline. Prentice-Hall, 1996.
|
|
[Thompson98]
|
C. Thompson. Workshop on Compositional Software Architectures: Workshop
Report. Monterey, USA, 6-8 January, 1998. (http://www.objs.com/workshops/ws9801/report.html). |
[papers]
[presentations]
[program]
[next]
[prev]
contact the author
contact the organizers [report errors]
