ObjectModeler™
A CASE tool for OOA, OOD and OOP

Doug Rosenberg

ObjectModeler is an application which is useful for Object Oriented Analysis, Design, and Programming. There are 3 main areas of functionality within the program:

a GRAPHICS EDITOR which provides drawing palettes for-

• Coad/Yourdon OOA diagrams
• Rumbaugh OMT (Object Modeling Technique) diagrams
• Booch Class diagrams
• Booch Object diagrams

a DICTIONARY which provides-

• a convenient place to capture additional detail beyond what is shown on the diagrams
• a mechanism for sharing a model across a developmentteam on a fileserver
• global change capability across a network
• access controls and collision detection
• integration with other ICONIX PowerTools™ modules

a TEXT EDITOR which provides-

• linkage between source code and diagram elements
• language templates on pull-down menus for
  • C++
  • Lisp
  • SQL
  • Pascal
  • PDL (ICONIX PowerPDL™ pseudocode language)

ObjectModeler can help to bring order and discipline to the often ad-hoc and chaotic process of developing O-O software without being overly rigid and stifling programmer creativity. Using ObjectModeler in conjunction with other ICONIX modules which support State Transition Diagrams, Module Architecture Diagrams and other techniques (e.g. PDL) makes it even more useful.

Object Oriented Analysis

The primary reason for not skipping the analysis phase of a software project is to ensure that the system under construction will properly meet the requirements of the customers or end-users. In other words, are we building the right system?

OOA methods tend to model the real world, often using notations that display classes or objects within the same symbol as their attributes (fields) and services or operations (methods). Other common themes across OOA methods are the kind-of and part-of relationships between classes.

These concepts lead to models of the objects, classes, and inheritance relationships in the problem domain which are readily understood by the end-users as well as the developers. These models are used to facilitate communication and lead to a common understanding of a system under development which is shared by all members of the development team as well as the end users.

ObjectModeler supports two methodologies which share these common themes; Coad/Yourdon OOA and Rumbaugh OMT. Each of these methodologies has its own set of strengths. Coad and Yourdon provide an easily understood notation for describing class hierarchies and address large system concerns with a 5-layer model which supports decomposition along Subject boundaries. Rumbaugh provides a rigorous approach based on Entity-Relationship modeling, extensive treatment of how to produce SQL from Class diagrams, and also includes State Machines and Data Flow diagrams as supplementary descriptions of object behavior and functionality; the ICONIX FastTask™ and FreeFlow™ modules support these representations.

Object Oriented Design

The primary reason for not skipping the design phase of a software project is to ensure that the system under construction is properly designed; that is, that the class hierarchy is appropriate, that the code is well modularized, and that the design will effectively meet performance constraints. In other words, are we building the system right?

ObjectModeler supports the Booch Object Oriented Design methodology. Booch is widely regarded as having the most comprehensive notation for OOD; his method consists of two primary kinds of diagrams, Class Diagrams and Object Diagrams. Booch also uses State Transition and Module Architecture diagrams in his OOD methodology; the ICONIX FastTask™ and AdaFlow™ modules support these representations.

Class Diagrams show the relationship between classes in a system, focusing on different kinds of inheritance and instantiation relationships. In Booch's words, they are used to answer the question "What classes exist and how are they related?"

Object Diagrams show objects and relationships between objects, focusing on visibility (how objects see each other) and message synchronization (how objects interact with each other). In Booch's words, they are used to answer the question "What mechanisms are used to regulate how objects collaborate?".

Booch proposes a set of templates for specifying details about classes, objects, messages and other design elements. These templates are available in ObjectModeler's Language Sensitive Editor as templates which can be picked off a menu and dropped into a text file that is linked to symbols on the diagrams.

name: Temp Control Display
documentation: <text>
visibility: <exported/private/imported>
cardinality: <0/1/n>
heirarchy:
    superclasses: Displays
    metaclass: <class_name>
generic parameters:  <list_of_parameters>
interface | implementation
(public/protected/private):
    uses: <list_of_class_names>
    fields: <list_of_field_declarations>
    operations: <list_of_operation_declarations>
finite state machine:  <state_transition_diagram>
concurrency: <sequential/blocking/active>
space complexity: <text>
persistence: <persistent/transitory>

Figure 6 - A Booch Class template. Booch defines an extensive set of templates which specify a variety of detailed information about system design elements.

ObjectModeler also supports the development of pseudocode (PDL) linked to symbols on diagrams. PDL may be used at any time during analysis or design when an algorithmic specification is called for. The ICONIX PowerPDL™ module may be used to collect PDL fragments created with ObjectModeler and format them into a design document, complete with a Table of Contents and several useful Cross References.

IF the steering wheel is rotated by more than 45 degrees THEN
    send a "turn complete" message to the turn indicator
ENDIF

Figure 7 - The ICONIX PowerPDL™ module can collect PDL fragments into complete documents with a Table of Contents and extensive Cross References.

Team Project Considerations ObjectModeler's dictionary provides a convenient place to store additional information about symbols on analysis or design diagrams. Items are automatically added to the dictionary as they are named, and can be accessed from the graphics editor by option-double-clicking on a named symbol. Each different type of symbol has its own set of attributes available on a pull-down menu.

ObjectModeler supports server-based development for project teams. Data is copied from the server into local RAM on program start-up; during editing operations, the server is polled periodically (at user-specified time intervals) and any changes are downloaded, minimizing network traffic while providing excellent performance and real-time updates. Each dictionary entry has a complete set of Access Privileges which control who gets to view, edit, rename, and delete it. Judicious use of these access controls allows a project team to provide an appropriate level of protection for design elements which are common within a subsystem or across subsystems.

The dictionary may be viewed as a scrolling list. The list can be scrolled or users can type the first few characters of an entry's name to access it. The dictionary provides several powerful functions which are useful in real-world project situations, including Global Rename and Delete (which affect all diagrams on the network), and cross referencing options to tell where entries are used and what they contain.

Object Oriented Programming

Once you have determined that you are building the right system and that you are designing the system right using ObjectModeler's OOA and OOD capabilities, it's time to implement, probably in some OOP language (perhaps C++).

ObjectModeler provides templates for a variety of languages (including C++, Lisp, and SQL) on pull-down menus. Code files may be accessed from diagrams by shift-double-clicking on a named symbol. The language templates may be used to eliminate a variety of syntax errors including keyword spelling and punctuation errors, and to provide a consistent code formatting style across an entire development team.

class TAudio_Display {
    public:
       TAudioDisplay(int volume);
       TAudioDisplay(int volume,
                     int bass,
                     int treble);  // overload
       virtual ~TAudioDisplay();
          
    protected:
       virtual void SetVolume();
       virtual void SetTone();
    
    private:
       int fVolume;
       int fBass;    
       int fTreble;
};

class RadioDisplay : TAudio_Display {
    public:
       TRadioDisplay(int volume
                     int frequency
                     int station);
       virtual ~TRadioDisplay();
          
    protected:
       virtual void SetFrequency();
       virtual void SetStation();
    
    private:
       int fFrequency;
       int fStation;
};

Figure 11 - ObjectModeler's Language Sensitive Editor is used to build source code directly linked to CASE model.

Coding may be carried through to completion within ObjectModeler or transitioned at any time to any back-end environment, at the user's option. All ObjectModeler code files are stored as flat ASCII text and may be transported to host platforms or other environments with ease. If Module Architecture Diagrams are used, an identical editor is available in the ICONIX AdaFlow module.

Summary

Requirements analysis is useful because it gives us an opportunity to determine whether we are in fact building the right system. Software design is useful because it gives us an opportunity to determine whether we are building the system right. While it is possible to achieve success without going through formal analysis and design activities, the chances of success are clearly maximized by taking the time to think about these issues. OOA and OOD methodologists have developed analysis and design methods which encapsulate useful experience gained across hundreds of O-O software projects. They have developed notations which represent O-O constructs and they have written books which ask the right questions about software under development.

ObjectModeler packages up three popular O-O methodologies into a tool which addresses team project concerns and multiple lifecycle phases (analysis, design, coding) in a reliable, cost-effective, and easy-to-use manner. ICONIX provides other tools which complement ObjectModeler with techniques like State Transition Diagrams, Module Architecture Diagrams, and PDL, in a synergistic manner. When conscientiously applied, the use of CASE methods and tools leads to successful projects; clean, well-designed programs delivered on-schedule and within budget.

For further information on ObjectModeler, other ICONIX PowerTools™ modules, or training in O-O methods, please contact us at:

ICONIX Software Engineering, Inc.
2800 28th Street, Suite 320
Santa Monica, CA 90405

Phone (310) 458-0092
FAX (310) 396-3454
Applelink: ICONIX
Internet: ICONIX@applelink.apple.com