Introduction

The Organization Modeling Environment (OME) is a modeling tool, meant to aid in the development and representation of models developed in various modeling
frameworks. It provides a graphical view of these models, which are themselves stored in a knowledge base. Users can use the graphical features of OME to aid in
the development and modification of these models.

This document aims to describes the architecture of the OME3 modeling tool ( the most recent version of OME Tool ). OME3 has been designed with an inherent dynamic nature and extensibility, so that "Power-Users" can easily adapt it to support new modeling frameworks by providing users with Plugin routines to develop and analyze models of these frameworks.The features and interface of OME3 can vary significantly between users, and even between executions.

Top-Level Architecture

The OME3 tool is mainly composed of two parts: the OME kernel and the Plugins. OME kernel has a layered architecture, comprised of three major modules, each of which is comprised of several Java classes and/or external tools. Plugins are classes implementing framework specific functionalities, which will be coupled with the OME kernel and provide service to the user together at run time. In each execution of the tool, different kinds of plugins are loaded according the frameworks that the current model is based on. Except OME kernel and plugins, there are also a group of files describing the configuration of frameworks.

In this section, these modules and their interconnections will be discussed at a high-level. Each of these modules will be examined in more detail in following sections.

In Figure 1, the five modules of OME3 are shown, their interrelations are also indicated.

The three modules in the left together form the kernel of the OME3 tool. At the core of the architecture is the Knowledge Base (KB) module. Here, we use the term KB to refer to runtime KB of a model. The KB stores the objects in a model, their relationships, and their attributes (pertinent to the model). The details of the frameworks for the model are also kept in the KB. The KB performs basic semantic checking (to ensure that the model being developed adheres to the frameworks stored in the KB). There is a KB manager responsible for creating a new KB for each model.

The next layer out from the KB is the Model/Framework module. The role of this layer is to abstract the KB from the rest of the tool. Objects in this layer serve as proxies for the model objects in the KB. An interface to the type information kept in the framework portion of the KB is also provided. The model layer has access to the KB, but the KB layer is totally unconscious of the existing of model layer.

Beyond model/framework layer is the View module. This module is responsible for presenting representations of the model to the user, and giving the user access to modify the model and/or its representation. This is done through a graphic user interface (GUI) provided by the View. The View also provides the user with access to the functionality provided by plugins (see below), as well as a means for plugins to receive input from the user. Changes to the model (either by users or plugins) occur by making changes to the copy of the model kept by the View. These changes are then passed on to deeper layers by the View. Each module can have several different kinds of views. These views give various presentations of the same model.

The above three modules compose the kernal of OME3 tool. They are necessary for the tool to fulfil the tasks of creating, modifying, and analyzing of any models.

The Plugins component is a set of modules that extend the functionality of OME3. A plugin is simply a collection of methods, each of which can analyze and/or alter the view of the model, or the underlying model itself. Plugins are loaded dynamically, depending on the model and framework(s) in use. This architecture allows framework specific functionality to be implemented in a plugin. Only the plugins that are associated with the frameworks used by the current model will be loaded. There is a special plugin, OMEDefaultPlugin, which is always activated no matter which model is loaded.

The frameworks available for a particular model are determined by a number of Framework Description files. These files specify the types of objects that may occur within a model, and the restraints on the relationships allowed between them. Currently, information describing the representation of the objects is also contained within these framework descriptions. When creating a new model, the user is presented with an option of which framework(s) to use with the new model. The model manager is responsible for determining the frameworks selected, and ensuring that they are incorporated into the KB. There is a special framework description file named ome.tel describing the meta framework of models supported by OME3 tool, which acts as the templete of the discrete frameworks, and is always loaded into the KB.

When multiple framework files are loaded into the KB, they are no longer considered as seperate frameworks by the KB.  The KB and the rest of the tool sees the model as having only one framework, despite the fact that conceptually the model has several frameworks, loaded from different files.
 

The KB

The major module in the KB is a Telos repository built by Techne implemented in C++, which is incorporated with OME as a DLL implemented in C++. It is wrapped by the jtelos interface, which provides Java applications with access to the repository. There is also a JTelosUtil class that provides some additional functionality to the jtelos interface. Figure 2 provides a more detailed diagram of the KB module, and it’s connection to the other major modules.

Figure 2. The KB module.

A KB is created for each model that is created or loaded. The model and its framework(s) are maintained in the KB as a series of Telos propositions.

The KB also provides the functionality for saving and loading models to or from the file system. This occurs through a "text dump" of the KB. View information (e.g. position of objects) is entered into the KB immediately prior to saving, and removed from the KB immediately after loading.
 

Component	Description	Location
KBManager	Creates a new instance of the KB	OME3\program\src
Techne Telos repository	External tool, C++	OME3\jtelos\NT\jtelos\cpp\jtelos.dll
jtelos	Java interface to repository	OME3\jtelos\NT\jtelos\*.class
JTelosUtil	Java helper class	OME3\program\src\JTelosUtil.java

 

The Model/Framework

As described in the OME Meta-Framework document, a model is simply a collection of objects, their attributes, and the relationships between them. In the KB, these are stored as Telos propositions, and an interface to add, modify and remove these propositions is provided.

 The Model/Framework layer of the architecture serves two crucial functions. The first is to provide a simpler, more abstract interface to the information stored in the KB. The second is to insulate the rest of the tool from a potential reimplementation of the KB. This layer also conceptually separates the model from its framework. This is done by supplying separate interfaces for the model and the framework. The fact that our particular implementation of the KB treats models and frameworks in the same manner (i.e. Telos propositions) is irrelevant to higher-level procedures. It is foreseeable that the implementation of the KB maybe change, perhaps to another version or vendor of a Telos repository, or even a different model altogether.

When a user has indicated that he would like to create or open a previously stored model, the details of this request are passed on to the ModelManager, which performs the "real" work. The ModelManager instructs the KBManger to create a new KB (this is the only role of the KBManager). If a new model is being created, the ModelManager prompts the user to choose which framework(s) he will be using in the new model. If a previously saved model is being loaded, the save file is loaded into the KB (the model’s framework is stored in the save file). In either case, the ModelManager will initiate the construction of the components of the Model/Framework module described above.

The ModelManager initiates the construction of the components the View module (see below).  It also determines which plugins should be loaded, and provides an an interface to these plugins that can be accessed by the View module.

ModelManager is also responsible for the saving of models, which simply involves instructing the KB to dump its contents to a file.

The Java interface of OMEFramework provides the View and Plugins modules with an interface to the framework information kept in the KB. Information on the types available, as well as the details of a particular type (e.g. type name, associated image and other visual representation information, and whether it is a link or element type) is made available through this interface. This interface is implemented by the Java class TelosFramework, which makes the queries to the KB.

TelosFramework, and other classes in this module, make use of a Java interface TelosFunctionality, which defines constants to represent particular strings in the OME Meta-Framework. These strings correspond to class names and attribute labels used in the Telos description file the OME Meta-Framework. TelosFunctionality serves to isolate and centralize the dependencies on these class names and attribute labels.

A note about types. Types are modelled as objects that can be passed as parameters. For example, they are used when creating a new object in the model (the type of the object must be specified). At this point, there is no specialized Java class used to encapsulate the notion of a "type". Instead a simple Java Object is used, this Object is in fact a TelosProposition.

Access to the model is provided through the OMEModel interface. This interface provides the ability to create and delete model objects, initiate loading and saving the model, and access the objects in the model. This interface is implemented by TelosModel.

Each object in the model is represented by an instance of a ModelObject. According to the OME Meta-Framework, there are two classes of objects that can occur within a model, elements and links. Each instance of a ModelObject is in fact an instance of a specialization of ModelObject, either ModelElement or ModelLink. ModelObject, ModelElement, ModelLink each in turn are specialized from OMEObject, OMEElement and OMELink. The OMEObject interfaces are used centralize commonality between the ModelObject and ViewObject (see View) interfaces. TelosObject, TelosElement, TelosLink are the KB specific implementations of ModelObject, ModelElement and ModelLink respectively. The inheritance hierarchy among these nine OMEObject, ModelObject and TelosObject Java classes and interfaces is shown in Figure 3.

Figure 3. Inheritance hierarchy for ModelObjects

Information about a particular model object can be found through the ModelObject interface (and its specializations). The information available through this interface includes the object’s name, type, and connectedness to other objects (its links, children, etc.). An object in the model can also be modified through these interfaces. In general, it is not good practice for a plugin to modify a ModelObject directly (since the View will not be updated of the change), instead a plugin should modify the ViewObject (see View) corresponding to an object in the model.

The OME Meta-Framework makes provisions for OMEAttributes. These are reference-attributes that an object in the model may possess. Frameworks that make use of OMEAttributes specify the possible targets of the attribute. These special attributes can be accessed through the ModelAttribute interface, which provides mechanisms for determining the possible targets for the attribute, and setting or removing the target. This interface is implemented by TelosAttribute, and member class of TelosObject.
 

Component	Class/ Interface	Description	Location	Parent  class
ModelManager	class	Responsible for the creating, loading and saving of models, and also setting up the KB, and interacting with it.	OME3\program\src
OMEFramework	Interface	Interface to information about types.	OME3\program\src\
TelosFramework	Class	KB specific implementation  of OMEFramework.	OME3\program\src\	OMEFramework
TelosFunctionality	Interface	Isolates and centralizes dependencies on strings used in OME Meta-Framework	OME3\program\src\
OMEModel	Interface	Interface to create, delete, and access objects in models, and to load and save the model.	OME3\program\src\
TelosModel	Class	KB specific implementation of OMEModel.	OME3\program\src\	TelosFunctionality, OMEModel
ModelAttribute	Interface	Interface to access reference type attributes on ModelObjects	OME3\program\src\
TelosAttribute	Class	KB specific implementation of ModelAttribute	Member class of ModelAttribute	ModelAttribute
OMEObject	Interface	Interface for accessing objects (common to ModelObjects and ViewObjects)	OME3\program\src\
OMEElement	Interface	Specialization for Elements	OME3\program\src\
OMELink	Interface	Specialization for Links	OME3\program\src\
ModelObject	Interface	Interface for accessing/modify objects in  model.	OME3\program\src\	OMEObject
ModelElement	Interface	Specialization for Elements	OME3\program\src\	OMEElement
ModelLink	Interface	Specialization for Links	OME3\program\src\	OMELink
TelosObject	Class	KB specific implementation of ModelObject	OME3\program\src\	ModelObject
TelosElement	Class	Specialization for Elements	OME3\program\src\	ModelElement
TelosLink	Class	Specialization for Links	OME3\program\src\	ModelLink

The View

In contrast to the Model/Framework layer, which maintains and provides access to the state of the model, the View layer maintains and provides access to a representation of the model. It is the job of the View to present a representation of the model to the user, and to provide the user with a means to manipulate that representation (and to update the model via the Model/Framework layer where appropriate). Each model can have various kinds of views. and for each model, there exists a ViewManager controls all of the views.

The View interface duplicates most of the functionality of the Model interface (e.g. creating and deleting objects), and in addition supports access to information regarding the state of the representation, including which objects are visible in the view, which are selected, etc.

Just as there is a ModelObject that proxies for each object in the model, there is a ViewObject that proxies for each ModelObject. Again, ViewObjects duplicate the functionality of ModelObjects, and add view specific functionality (e.g. selection/deselection, hiding the object, and determining/changing its position in the representation). ViewObjects inherit from OMEObjects in a manner analogous to ModelObjects.

Currently there is only one type of view supported in OME3, the GraphicView. The GraphicView represents the model as a graphical diagram. Implementing other types of views are certainly foreseeable. Possible views to be implemented could include a "tree view", or a "table view" (really the sky’s the limit... 3D view, animated view, HTML view, etc.).

The current architecture only supports one view per model. A plan exists to modify the architecture to support an arbitrary number of views per model.

The GraphicView class implements the View interface, and keeps a list of the GraphicViewObjects that proxy for the ModelObjects. It also keeps track of what objects are selected in the view, and what part of the view is visible, and what part of the view has changed and needs to be redrawn.

The GraphicViewObjects keep track of whether they are hidden, expanded (if applicable), and their position in the view.

The view is presented to the user by the GraphicViewFrame, GraphicViewCanvas, and ScrollingPanel classes.

The GraphicViewFrame class is the window in which the representation appears. It maintains the menubar, the toolbar, and the status bar in the GUI. It also is used to hold the ScrollingPanel and GraphicViewCanvas components.

The ScrollingPanel is used to handle the scrolling of the graphical representation of the model.

GraphicViewCanvas (GVC) is the largest, and probably the most complicated class in OME3. It is responsible for presenting the graphical representation, and also getting input from the user. It handles the mouse gestures and clicks used by the user to move, select, and expand the objects in the view. It is also responsible for interpreting the keystrokes used to manipulate the model (currently only the delete key is used). It also generates the .bmp and .png graphics files created by the "Export" command.

The context-sensitive menu displayed in response to a right-button mouse click is also generated by the GVC. The GVC is responsible for hooking up the methods provided by the Plugins (see Plugins) to the various components of the GUI. The GVC also handles the parameter-collection phase used by plugin methods.

One of the features used by the Plugins is the concept of a view context. A view context specifies a particular state of the view when a plugin method was initiated (e.g. what objects were selected, what object (if any) the mouse was over, etc.) This concept is encapsulated by the ViewContext class, an instance of which can be generated by GraphicView.
 

Component	Class /Interface	Description	Location	Parent Classes
View	Interface	Interface for accessing and modifying the state of a view	OME3\program\src\
GraphicView	Class	Implementation of View inteface specific to a graphical view of the model	OME3\program\src\	View
GraphicViewFrame	Class	The window in which the graphical view is presented	OME3\program\src\	JFrame
GraphicViewCanvas	Class	The component in the GUI that display the graphical respresentation of the model. Also handles most user input/output	OME3\program\src\	JPanel
ScrollingPanel	Class	Used to handle scrolling of GraphicViewCanavas	OME3\program\src\	JPanel
ViewContext	Class	An object that encapsualtes a context within a view (used for context sensitive menus)	OME3\program\src\
ViewObject	Interface	Interface for accessing/modifying objects in the view	OME3\program\src\	OMEObject
ViewElement	Interface	Specialization for elements	OME3\program\src\	OMEElement
ViewLink	Interface	Specialization for links	OME3\program\src\	OMELink
GraphicViewObject	Class	The implementation used for objects in the GraphicView	OME3\program\src\	ViewObject
GraphicViewElement	Class	Specialization for elements	OME3\program\src\	ViewElement
GraphicViewLink	Class	Specialization for links	OME3\program\src\	ViewLink
ViewManager	Class	Creates and keeps track of the Views associated with a model.	OME3\program\src
ViewSerializer	Interface	Interface to allow view-specific information to saved with a model	OME3\program\src
TelosViewSerializer	Class	KB specific implementation of Viewserializer	OME3\program\src	ViewSerializer, TelosFunctionality

 

Plugins

The plugins module is a number of classes that handle the majority of manipulations to the model and view. Plugins provide an easy means of extending the functionality of the tool. They also allow for framework specific operations on views and models.

Each plugin is a Java class, typically outside the OME package visibility. When a new model is created or loaded, each plugin can look at the model and framework and determine if the operations provided by the plugin should be made available to the user.

In essence, a plugin can be thought of as a collection of methods. A method is a user-initiated process that can access and modify the view/model, and also get input from the user. One means a method may use to get input from the user is by requesting "parameters". These are inputs the user must give to the method before the method is invoked. The View is responsible for collecting parameters requested by the method prior to "invoking" the method.

The plugin specifies how its methods should be made available to the user (e.g. a button on a toolbar, an option in a menu, or perhaps one day a keystroke, mouse gesture, etc.).

To give the plugin creator more control over the presentation of method options in the GUI, special methods can be used as a "menu" that holds other methods. This allows for arbitrary nesting of menus in the GUI.

Each plugin must implement the OMEPlugin.java interface. Each method must implement the PluginMethod.java interface. These files are well-commented, and should be read by any aspiring plugin developer.

The PluginParameter.java file is a class used to encapsulate the information necessary for a method to request a parameter from the user. This includes the type of parameter, and the instruction to be presented to the user when requesting the parameter.

A number of classes have been developed to make the development of new methods easier. These are usually abstract classes which can be inherited by a new method, with many of the operations that a method must perform already implemented. AbstractPluginMethod.java gives a minimal implementation of a PluginMethod. It also lists the parameter types currently being supported by OME.

CreateElementMethod.java and CreateLinkMethod.java make methods to create new objects in the model very easy.

MenuMethod.java is designed to simplify adding a sub-menu (where each option on the submenu is a PluginMethod) to the GUI. PopupMenuSeparatorMethod.java is a "GUI only" method is used to simply to put a separator in a menu of methods.

ObjectMethod.java is a very useful class. It used to perform an operation based on some arbitrary number of model objects specified by the user. For example, a method that compares the name of two elements and deletes one of them if they are the same could be easily implemented using ObjectMethod (it could probably be done in under twenty lines).

Examples of plugins are NFRPlugin.java, IStarPlugin.java, AnnotatePlugin.java, and the special OMEDefaultPlugin.java which is loaded with every model and provides much of the core functionality of the tool and has full OME package visibility.

Two conditions are necessary for a plugin to be loaded with a model. First, the compiled byte-code (.class) files associated with the plugin must be located in the OME3\program\plugins\ directory. Second, the (main) plugin class must have a method with this signature:

public static boolean isCompatibleWith(OMEModel model)

Framework Descriptions

The framework description files provide the details of the modelling frameworks available to the user at run-time. These files are Telos files which are read directly by the KB (upon direction from the ModelManager as described above).

There are currently three framework files of particular importance. The file "ome.tel" provides the roots of the hierarchy upon which all other framework description files must be based. The framework described in "ome.tel" is often refered to as the "OME Meta-Framework". The OME framework is automatically included with each model that is created.

The files "istar.tel" and "nfr.tel" are descriptions of specific modelling frameworks being developed at the University of Toronto.

There is an additional framework specified in "annotate.tel" that allows user to add nodes to a model whose purpose is to simply describe other objects in the model.

Framework description files must be located in OME3\program\frameworks\ to be seen by the tool. The choice of frameworks presented to the user is based on the contents of this directory. "Junk" files in this directory will be presented as choices to the user, and if selected will cause the creation of a new model to fail.
 

Component	Description	Location
ome.tel	Basic modelling framework from which all others must be derrived.	OME3\program\frameworks\
istar.tel	i* modelling framework	OME3\program\frameworks\
nfr.tel	NFR modelling framework	OME3\program\frameworks\
annotate.tel	Small framework to allow annotation of models	OME3\program\frameworks\

Tool Interface and Static KB

Actually, OME has two separate interfaces to communicate with end users. One is the model-based GUI we introduced above, through which the user can operate on a model through the GUI. The other is a graphical interface for the user to organize his models. Part of this interface includes the creating and loading of models. A ProjectManager is responsible to control models and projects. Each project is a folder in the file system, and each model is corresponding to a .tel file under the folder in current implementation. All existing projects and the models included in these projects can be seen as a static KB, where domain-specific knowledge can be retrieved.
 
 

Component	Description	Location
OME	Contains "Main" function. Initiates ProjectManager.	OME3\program\src\
ProjectManager	Provides user with interface for organization of different models into projects.	OME3\program\src\
NewModelInfo	Helper to ProjectManager, used to encapsulate the information needed to create a new model.

Miscellaneous Utilities

The modules described above are simply conceptual partitions of the various pieces that comprise OME3. There are a number of Java classes, and some external tools, that do not fit neatly within any of these modules. These components, however, often perform vital tasks, and should be mentioned.

An external tool called "IrfanView" is used convert bitmap images (.bmp) to portable network graphics images (.png). This conversion is used the export process (when graphic views of a model are saved as an image).

The BMPWriter class creates a bitmap file from a Java Image class.

The ImageTable class is responsible for the caching and altering of images used by the views. Some of the services it provides include rotating and scaling images. It can also draw lines through images, which can be useful to make something look more like a link.

The class called "D" is a debugging utility class. Developers use D to make assertions and to output diagnostic messages. (It is called "D" not be cryptic, but rather to be quick to type. Outputting a diagnostic message using D.o("message") is thought to be considerably better than System.out.println("message") ).

The Pair class is very simple class that allows two objects to be wrapped in one.

PessimisticCollection is a full (but minimal) implementation of Java’s Collection interface.

Choice, CheckboxChooser, and RadioButtonChooser are used to get input from the user. Choice encapsulates the things associated with an item that might be chosen by a user. CheckboxChooser and RadioButtonChooser are GUI components that present these choices to a user and get his input.

The ContinueCancelDialog class is another GUI component. It makes it easier to create dialogues that present "Continue" and "Cancel" options to the user.

InputDialog presents a String and gets a line of (text) input from the user.

JMenuPlus and JPopupMenuPlus are extensions of the JMenu and JPopupMenu Swing classes. These extensions fix misfeatures in the original classes that caused the components to occasionally appear partially off-screen.
 

Component	Description	Location
IrfanView	Converts .bmp’s to .png’s	OME3\ivew\
BMPWriter	Writes Image classes to .bmp files.	OME3\program\src\
ImageTable	Caches and manipulates Images.	OME3\program\src\
D	Useful for debugging. Provides centralized mechanism for assertions and diagnostic output.	OME3\program\src\
Pair	Wraps two objects.	OME3\program\src\
PessimisticCollection	Minimal implementation of the Collection interface.	OME3\program\src\
Choice	Abstracts and encapsulates the concept of an item that a user may wish to choose.	OME3\program\src\
CheckboxChooser	Presents a number of choices to a user and records the users selection. User may select multiple items.	OME3\program\src\
RadioButtonChooser	Presents a number of choices to a user and records the users selection. User may select only one item.	OME3\program\src\
ContinueCancelDialog	Presents arbitrary information to user, and provides him with option to continue or cancel.	OME3\program\src\
InputDialog	Gets one line of text input from a user in response to a question.	OME3\program\src\
JMenuPlus	Fixes bug in JMenu	OME3\program\src\
JPopupMenuPlus	Fixes bug in JPopupMenu	OME3\program\src\