CONTENTS

COMDEVALCO FRAMEWORK 191
3.1. Modeling language. The modeling language was improved in two different
directions, by (1) including module and execution environment, and (2) extending its
type system with structured types.
In order to ease the process of implementing modular concepts, an adaptable
infrastructure was created, based on a meta-model defining the concepts of module
and execution environment.
The module is considered in the general case, as a deployment unit, including
either (a) several data types, functions, and procedures - as in the traditional modular
programming model, or (b) several data types, including components - as in the case
of component-based programming. There are dependency relations between modules,
which must be specified during module definition phase and must be satisfied before
module execution.
Static execution environments load all modules of an application before starting
its execution. The proposed model loads modules and starts their execution provided
that all dependencies are solved. It also supports dynamic module load/unload facilities.
Some of the existing execution environments have these features - like OSGi [11],
which assembles Java applications from dynamic modules. Our proposal is described
in [5].
The initial modeling language used only primitive data types. Currently, its type
system includes a new ArrayType class, and PAL grammar was changed to allow the
definition of tables (vectors) and structured types, like lists. These achievements are
described in detail in [9], which proposes an extensible data type hierarchy.
3.2. Component repository. The interactions between component repositories, ComDe-
ValCo workbench and client applications are described in [5, 8].
The starting point in the work of providing a correct taxonomy for components
was the establishment of classification criteria. Several concrete approaches were
considered, including information domain and functionality. These criteria may be
used in searching of components stored in the repositories. All these matters are
discussed in great detail in [8].
The root of all objects managed by the component repository is RegistryObject
(see Figure 1), from which all components inherit (thru ExtrinsicObject class). In
order to provide a great degree of flexibility, the hierarchy contains distinct classes
for the two concepts: classification and classification scheme.
In order to describe the representation of components in the repository, an object
model was defined; it includes all component types covered by the modeling language
and allows for adding new ones.
Component representation format complies to OASIS RIM (Registry Information
Model) standard [10]. To achieve this, the class ExtrinsicObject was extended
by subclasses specific to component-based applications: DModule, DComponent,
Capability - functionality, and Requirement - component dependencies .
3.3. The toolset. The functionality of DEFCOMP and VALCOMP tools was extended
to include module and execution environment concepts. Papers [5, 6] describe