ObjChart - An Object-Oriented Modeling Tool for the VisualAge Environment

From EDM2
Jump to: navigation, search

by Kevin Poole

ObjChart is an innovative object-oriented modeling and rapid prototyping technology being developed at IBM Software Solutions' Santa Teresa Laboratory. Its numerous visual editors enable you to capture the static structure and dynamic behavior of the objects and classes in your domain. An execution engine within the tool facilitates iterative development of object-oriented application models - you can execute the models you have developed (even at early stages of development), visually validate their behavior, and enhance them interactively - all from within the ObjChart modeling environment. Over time, plans are to include ObjChart technology in several of IBM's key object-oriented programming environments (VisualAge language solutions) and to call it the Dynamic Designer component in these solutions. The terms "ObjChart" and "Dynamic Designer" will be used interchangeably in this article.

This article provides a high-level simulated demonstration of selected ObjChart capabilities and includes screen captures that are based on the October 1996 ObjChart beta driver. This driver is available on the Web and is included in the DevCon Java and Internet Tools CD-ROM. The user interface design will change as the technology is further developed, as feedback is obtained from further human factors testing and from early customer use.

An Example

The best way to introduce the capabilities of the Dynamic Designer is to imagine a problem to be solved and demonstrate how the tool would be used to attack this problem. Let's create a model for a Foreign Currency Exchange (FCE) program. This program provides foreign cash and foreign travelers checks to customers based on current exchange rates. The FCE model is provided as one of the samples in the beta version of the tool that is located on the CD-ROM.

Object Composition View

The first step in defining a model for an application domain is identifying the objects associated with the domain. These objects are then defined in the object model, which shows the object composition (or containment) hierarchy for the model. For example, an invoice in the FCE model may contain many customer orders. In turn, each customer order contains some number of order items (amounts and types of currency to be exchanged). As more understanding of a domain is achieved, additional detail regarding the composition of each of the objects can be added to the model.

The screen capture shown in Figure 1 illustrates some of the objects in the FCE Object Composition View. Nodes in the view can be expanded or contracted according to which part of the model you are currently working on. The containment relationship (mentioned earlier) between the customerOrder object and its orderItem objects is shown here. Also, the cashier and customerOrder objects have been expanded to show the attributes and operations that have been defined for them. The minus sign (-) in front of the attribute names indicates that they are private to the object; the plus sign (+) in front of the operation names indicates that they are public interfaces to the object. Attributes and operations may be added through the pop-up menu for an object or by opening the object's notebook (discussed later in this article).


Figure 1. Objects in the FCE Object Composition View


Scenarios enable quick examination of object interactions in a model and definition of operations for an object. Scenarios are used to provide the initial definition of behavior associated with an application domain. One or more scenarios can be defined for a set of objects within a model, where each scenario shows the flow of messages exchanged between these objects to accomplish a specific task.

To develop a scenario using ObjChart, you first use the Object Composition View to create the objects that are to participate in the scenario. Once the objects have been created, you must create a new scenario and bring up its Scenario Composition View. The Scenario Properties View that can be accessed from the Scenario Composition View lets the user change the name of the scenario and enter a description of what information the scenario should capture. The necessary objects then can be added from the Object Composition View to begin the development of the scenario. Additional objects can be added to the scenario at any time.

The messages that occur in the scenario then are added to the Scenario Composition View by using the "add message" icon (i.e., the right arrow) from the tool palette. As each message is added to the Scenario Composition View, it is automatically added to the structure of the associated object.


Figure 2. Messages added to Scenario Composition View

Messages that are received by an object in a scenario become events for that object. These events define the public interface for the object; requests it can receive from objects in the system during model execution. In the above screen capture, the customerOrder object receives a createOrder and purchaseCompleted message as part of the scenario. The events that were created as a result of this scenario can be seen as operations for customerOrder in the Object Composition View shown in Figure 1.

Object Properties Notebook

All information for the objects and classes that have been defined, is kept in an underlying model, which is accessed by all views in the tool. The Object Properties notebook allows the user to view and modify all facets of the object: name, attributes, events, states and methods. The Object Properties notebook can be opened by double-clicking on an object in the Object Composition View. Once the notebook is opened the user will see five major tabs in the notebook: General, Attributes, Events, Methods and States. Since the screen capture below is in VGA resolution, not all tabs can be seen at once. The "<<" and ">>" tabs to the right and left of the major tabs will allow the user to view any tabs which are not visible. The General page of the Object Properties notebook, shown in Figure 3, is used to provide basic information about an object. The object name should capture the nature of the object being defined. The text description should include such items as the purpose of the object and the business area responsible for definition of the object. The class field will show the name of the class to which this instance belongs. Since all objects are instances of a class, any structural changes made to an object are immediately reflected in its associated class (and all other instances of that class).


Figure 3. The General page of the Object Properties notebook provides basic information about the object

The Attributes page of the Object Properties notebook is used to define the attributes associated with each object. Each attribute has a name and a type. The supported types include string, integer, float, and reference (the latter being a reference to another object). The Description area can be used to indicate the purpose of the attribute, the allowable range of values, and so on. Attribute values are kept for each object. They can be changed during execution of a model as one or more of the actions taken by an object in response to receipt of a message.

Object operations are described on the Events and Methods pages of the Object Properties notebook. An event operation definition specifies the actions to be taken when an object receives a message, and the conditions under which the actions are to be taken. Actions may use simple expressions to set attribute and temporary variable values, invoke user-developed methods, or generate messages that are to be sent to other objects or to itself. These actions may be written in LotusScript, BASIC or a shorthand modeling language provided with the tool.

A method operation specifies the code that is to be executed when an object receives a message with the specified signature. Multiple method operations may be defined for an object. They can be used to display user interface screens, access DB2 or other data, perform special computations, and so on. Methods can be written in IBM VisualAge C++, COBOL, or Java. They are displayed and edited using the context sensitive LPEX embedded editors of the VisualAge product family. In addition, many callback functions provided with the Dynamic Designer allow the modeler to interactively update their model during model execution (for example, create new objects, get and set attribute values, and so on).


Figure 4. A customerOrder object in a complete state

The States page of the Object Properties notebook is used to define the life cycle of an object. The life cycle of an object is defined by the states the object can assume and the transitions that cause the object to change from state to state. An object can have "state-independent" behavior (i.e., it has only a single state defined, and therefore does not exhibit any state dependent behavior). This is probably the most common situation for simple objects.

Objects that have more complex behavior requirements often have multiple states defined, where the specific response to an incoming message depends on the current state of the object. For example, a customerOrder object that is in the "complete" state should respond differently to a createOrder message than a customerOrder object that is in the "new" state. State values can be interactively examined and modified as part of the model validation process, to verify that a model is behaving as intended.

The state model in Figure 4 shows that the customerOrder object is in the "complete" state, and that it also can be in either the "new" state or in the "inProcess" state. The default starting state would normally be the "new" state. An object makes the transitions between these states in response to each of the messages that are shown on the state model.

Model Execution

One of the major advantages of modeling your application with ObjChart is the capability to execute the model at all stages of development. The Model Trace View can be used to visually validate the behavior of a model. Model execution starts with a user-specified object and operation, and with the model's object attribute and state values as they exist at the time the model execution starts. Object attribute and state values can be set by the user prior to model execution. ObjChart provides "run" and "step" modes for execution. "Step" mode allows model execution to be paused and resumed or stopped at any time and the user can examine and change attribute and state values to facilitate model validation.

The model execution trace shows the actual sequence of model messages and state changes that take place. The screen capture shown in Figure 5 shows the graphical and text parts of the execution trace, along with the object and operation that were selected to begin execution.

The graphical section of the execution trace window shows messages that are passed between objects, object state changes, and method invocations. When a message causes an object state change, the old/new state values are shown in a box at the head of the "message arrow." The text section of the execution trace window shows textual representations of message receipt and return, plus such items as changes in attribute values and user-defined messages.


Figure 5. The graphical and text parts of the execution trace, along with the object and operation that were selected to begin execution

Class Composition View

After the object definitions and scenarios for a model are refined sufficiently, the class structure for the model can be developed. The Class Composition View is used to define the class structure for a model. ObjChart makes a clear distinction between objects and classes—an object is an instance of a class.

An initial version of a class model is generated automatically by ObjChart as objects are created in the Object Composition View. In addition, new classes may be defined by using the "new class" icon (for example, the rectangle) from the tool palette. Relationships between classes may be defined by using the appropriate icons from the tool palette. The available relationships are:

  • Containment (for example, OrderItemClass is part of CustomerOrderClass)
  • Inheritance (for example, AccountPaymentClass inherits from PaymentClass)
  • Association (for example, CustomerOrderClass has a "pays" association with PaymentClass)

Classes may be specialized with respect to their superclasses by adding structural and/or behavioral differentiators (for example, "accountApplied" in the AccountPaymentClass shown in Figure 6). Both single and multiple inheritance are supported.


Figure 6. Classes may be specialized with respect to their superclasses by adding structural and/or behavioral differentiators


Dynamic Designer is intended to provide an open modeling environment with the best aspects of both behavioral and structural modeling approaches. It supports an iterative process for modeling object-oriented applications, and supplies the user with many visual editors to capture model information.

By using ObjChart's interactive executable models, the behavior analysis and model verification process can be more productive. Furthermore, the "live documentation" provided by the executable model can facilitate communications with an application's users. Developers can show users actual model execution at all stages of application development.

Through the use of methods, ObjChart can invoke user interface screens designed within the VisualAge Visual Builder and access data in relational databases through the use of parts developed with the VisualAge Data Access Builder. Developers can use this capability to iteratively add more content to their model as it matures, invoking the actual screens and updating the actual databases that the final application will use. Validating these enhanced models with end users will give developers a much higher level of confidence that the final application will satisfy user requirements.

Kevin Poole is a Staff Software Engineer currently providing technical marketing for the Dynamic Designer tool. The tool is being developed at the IBM Santa Teresa Laboratory in San Jose, California. Previously, Kevin was the test team lead for this project. Kevin can be reached at poole@vnet.ibm.com

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation