|Department of Electrical and Computer Engineering|
System modeling is the activity of describing the structure of a system in terms of its components and the relationships among them. Traditionally, system modeling has been concerned with only artifacts at the source code level. With the purpose of providing SCM infrastructures to manage a software system in terms of logical objects, we need to have a system model that works at the logical level and is capable of supporting any new types of objects. Here, the object-oriented approach comes into play. Molhado's object-oriented system model with its basic entities, constructed via the data model, provide both infrastructure for extensibility and a framework to model and version a software system according to any development paradigm.
Figure 1. Extensible System Model
Figure 1 summarizes the system model.
A project is a named entity that represents the overall
system logical structure of a software system (also called ``software
project'' in this paper). Depending on the software development framework
chosen, a project will represent different forms of system structures
such as architectural design diagrams, UML design diagrams, entity
A component is basically an entity that represents a logical
object in a software system. It can be versioned,
A composite component is defined as a composition or aggregation
of atomic components and/or other composite
Unlike composite components, an atomic component can not contain
other components. Therefore, it is the basic entity in a composition
or aggregation in a composite component. However, it may have internal
structure. In Molhado, to increase modularity and accommodate fine-grained
version control for components, an atomic component can be internally
composed of finer units, called logical units or structural
units. For example, a class can be defined as an atomic component
consisting of syntactical units (as logical units) in an abstract
syntax tree (AST). Internal
The key point that distinguishes this system model from others is
its logical and object-oriented approach that enables the extensibility
of new types of objects and allows them to be versioned at the logical
level and independently of the physical storage structure. Our system
model is not tied to any particular domain and its entities do not
contain version numbers since all objects share a global version space.
Therefore, this enables the reuse of our product versioning SCM infrastructure.
The idea of explicitly versioning at different levels of abstraction
is novel and also realized via this object-oriented approach. In addition,
the distinction between component and logical unit levels creates
modeling flexibility and increases the modularity for our system model.
Depending on the development method chosen, an object can be implemented
as a derivation of either a component or a logical unit. For example,
a Java class can be atomic
Define a new object type
The Molhado editor is built to help developers define new types of
objects. Template code for objects is automatically inserted. To define
a new atomic component, a developer needs to derive his/her Java class
from the atomic component type and declare a 32-bit constant magic
number that uniquely identifies the new object type. Only concrete
classes need the numbers. A component's internal property whose history
needs to be recorded must be represented by a versioned slot. For
example, the component name can be declared as a versioned slot containing
a ``string'' value. Other properties that need to be stored must be
defined as simple or constant slots. Otherwise, regular Java fields
can be used. For each slot that was used in a new class, Molhado generates
methods to read and write
In Molhado, an atomic component can be internally composed of logical
units. The developer can manage its internal structure by declaring
a tree or a directed graph (described earlier) in a new class. The
developer can use the associated programmatic interface for trees
and graphs to manipulate the component's internal structure. For each
This figure illustrates the definition of the class ``JavaClass''
for a Java class component. This new type is derived
The principles for the definition of new composite components are similar to those for atomic components. The most important difference is that a new composite object type inherits from the composite component type (in the system model) a special tree or a directed graph in which an additional attribute (``component'') defines for each node in the tree or the graph a versioned slot holding a reference to a member component of the composite component. Other principles and generated methods and fields still hold in this case.