Molhado's Object-oriented System Model

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
relationship (ER) diagrams, or control hierarchies. In software systems with simple designs, a project can directly represent the source code structures at the implementation level such as class/package or program/directory structures. Technically, a project contains a structure that is composed of components. Developers can use that structure to represent various forms of overall system structure in a software project. That structure is implemented in the
form of a directed graph.

A component is basically an entity that represents a logical object in a software system. It can be versioned,
saved, loaded, and exists within the version space of a software system. A component is designed to represent a coarse-grained abstraction and can belong to multiple projects. It is not designed to model fine-grained objects or abstractions such as a character or a word, though it is not prohibited to do so. A component can be used to model logical abstractions at the design level such as design modules, architectural components, UML diagram entities, data
flow diagram entities, subsystems, etc. At the implementation level, components can model programs, files, documentations, packages, object-oriented classes, functions, directories, etc. A component is implemented based on the primitive data model. Each component carries a component identifier (CID) that serves to identify it
uniquely within a project. A user-assigned name for a component, which might change at different versions, is implemented as a versioned slot. A component also sets up object loading and saving functions in
derived types of objects in accordance with our persistence model. Components are classified into two groups: composite and atomic components.

A composite component is defined as a composition or aggregation of atomic components and/or other composite
components. Composite components can share the same constituent components, and have arbitrary internal structure. Examples include compound documents, Java packages, architectural composite components, system logical structures, class hierarchy, UML diagrams. Each of those objects and structures can be defined as an extended type of this composite component type.

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
structure of an atomic component might also be more complex than a tree-based hierarchy, for example, a graph-based structure in a graphic. In contrast, some atomic components, such as binary data files, are considered to have no internal structure for the versioning purpose. Molhado treats a logical unit as the smallest versionable unit. A logical unit is implemented as a node in the node-slot pattern.

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
in a class hierarchy (as a composite), but it can also be modeled as a logical unit in a program (as an atomic component), which might contain other classes.

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
slot contents.

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
declaration of a tree or a graph, Molhado inserts code for loading and saving nodes and associated attributes in the tree or the graph. If a new atomic component has no internal structure, Molhado's trees or graphs must not be used. The developer can use trees or graphs to represent various forms of structures in an atomic component such as
AST in a program or compositional hierarchy in a structured document. For a new concrete (non-abstract) class, Molhado also generates a ``factory'' inner class to facilitate the Java dynamic loading mechanism that is used to load a class. The factory class name is saved and used when the class is loaded.

This figure illustrates the definition of the class ``JavaClass'' for a Java class component. This new type is derived
from the atomic component type. Since ``JavaClass'' is non-abstract, a magic number is chosen. Since the name of the Java class is declared as a versioned slot, methods handling writing and reading values for the name are automatically inserted. Similarly for the syntax tree that was declared for the AST of the class, loading and saving functions (``loadDelta'', ``saveDelta'',...) are generated. To import a Java file, this component needs a parser, which is an
external tool that does not need to be versioned. So, it is just a regular Java type. The templates for two constructors are created and developers are free to add more code. Technically, one constructor is used when a new object is created, and the other is used when an object needs to be loaded from disks. Finally, since ``JavaClass'' is a concrete class, an inner class ``Factory'' is inserted. Other methods and fields can be added for other purposes.

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.