Object Models Meet Tools

Tools, Models, and Techniques for High-End Object-Oriented Development.

Many Information Technology (IT) organizations are investing in high-end object-oriented development tools in order to evolve software practices and processes, implement software products quickly, or be technologically competitive. Purchasing such tools as Forté or Dynasty, and then getting developers and analysts trained in the tool, is only the beginning. Savvy IT organizations have learned that an even more significant investment must be made in conjunction with the purchase of the tool. Using an object-oriented modeling (CASE) tool, the savvy IT organization takes the time to perform requirements analysis and design and to shape team processes around the use of the development environment.

The applications development tool market is moving toward distributed, scalable object-oriented products. These products can support multi-threaded processing, high volumes of transactions and concurrent users, multiple logical and physical tiers, transaction reliability, and multiple execution platforms -- in other words, object-oriented online transaction processing (OLTP) using a client/server architecture.

Products in this market space include full-fledged development environments such as Forté, Dynasty, Nat Systems' NatStar, and Texas Instruments' Composer. (See Table 1.) These products are known for their dynamic partitioning capabilities, which let the developer literally drag and drop an object (or, more technically, a class) onto a client or server machine.

Even beyond this capability, the tools maintain multiple logical layers of an application built into the way the object is constructed. For example, objects can be mapped to logical layers such as interface, controller, business, and storage objects. Further, some of these high-end tools give an object additional potency through its runtime properties. In Forté, an object can be shared (allowing multiple tasks to concurrently access it and reliably change its data), distributed (allowing the object to be sent to a remote partition), transactional (allowing the object to participate in a transaction, enforcing the atomicity, consistency, isolation, and durability [ACID] properties of a transaction), or monitored (allowing the object to be displayed and mapped to a window).

Lower-end object-oriented tools such as PowerBuilder, Delphi, and Visual Basic don't scale logically and physically as easily as these high-end products. Although new releases and announcements indicate that the lower-end object-oriented tools are striving for increased scalability and object distribution capabilities, the high-end market continues to grow and become more competitive.

Some organizations have chosen these high-end products to accelerate the time-to-market of their applications. Others require time to market coupled with a vision of establishing a long-term architecture. Such an architecture is open and flexible for extending applications, adding new ones, and migrating legacy applications. For IT organizations interested in object-oriented technology, the benefits of business object or component reuse is compelling. Regardless of why the tool was chosen, when moving into high-end object-oriented development, organizations sometimes neglect the need to focus on requirements and design. Attention to requirements and design leads to the selection and use of an object-oriented modeling tool (such as a CASE tool) along with a set of modeling techniques.

What Does it All Mean

In technical terms, a high-end tool has many desirable features. It is scalable to many users and portable to many platforms, it exploits processor power through multi-threading, it provides a rich framework library, it allows for reliability through features such as replication and failover (the ability for an application partition to pick up for a failed partition by having the service request rerouted to a backup copy), it provides transaction integrity, it furnishes load-balancing capabilities, and it allows for flexible distribution. In other words: It is scalable, reliable, open, portable, and high-performing.

Models are Meaningful

An object-oriented application would have these object-oriented models: requirements (such as use case, event model, or object behavior analysis), static objects hierarchy (object model with inheritance, aggregation, and associations), object messaging (event trace diagram, object interaction diagram, object message diagram, or scenario view), and object dynamics (state transition diagram).

Mark Joyce, Supervisor Fiber Systems Engineering at Corning Inc., worked with Forté for several years. Corning performs rigorous analysis before generating code, thereby preventing thrashing during the development phase. Doing up-front analysis and design yields a grab-bag of goodies. Some of these goodies include documentation (remember that?), reuse, and facilities to divide teamwork more easily. Other organizations just crank out the code, realizing afterward that requirements and design would have been a good idea to save time on rework later.

Modeling Tool Options

Recently, deciding on an object-oriented modeling methodology has become less complicated. A variety of object-oriented methods have vied for attention. The literal merging of Grady Booch, Jim Rumbaugh, and Ivar Jacobson in 1995 and 1996 formalized what was happening in commercial, non-real-time object-oriented projects: using Jacobson's use cases for requirements and a mix of Rumbaugh and Booch's object modeling methods. Now the trio's UML, or Unified Modeling Language, will provide a (de facto) standard set of object-oriented modeling semantics. (For more information on Booch, Rumbaugh, Jacobson and their UML, see the interview in DBMS, October 1996, page 68.)

Many Dynasty and Forté application development projects are using Rumbaugh's Object Modeling Technique (OMT) in conjunction with Jacobson's use cases. Variations on this theme include preceding requirements with business process reengineering, incorporating Object Behavior Analysis (OBA), and using responsibility-driven design.

For example, CSC Consulting Inc. (Waltham, Mass.) created an object-oriented methodology called Lynx, a complete and rigorous approach to object-oriented development that includes Forté and Select Enterprise for Forté. CSC found that for several years Select Software, like other Forté users, had been using the modeling techniques that have emerged as de facto standards: OMT, use cases, and object interaction diagrams (OIDs).

According to Tom Reidy, service delivery manager at CSC, Lynx is a complete methodology incorporating the best-of-breed object modeling along with CSC's standard process and reengineering modeling. It includes five models: business process, OMT, Jacobson use cases, OIDs, and responsibility-driven design ´ la Wirfs-Brock. The business process models are generated from ABC Flowchart or Visio. A use-case template is stored in Microsoft Word. Complex object dynamics are worked out by manually inserting the associated use case into the Select tool and creating an OID model based on that use case. The Select tool matches well with this methodology.

Code Generation

A modeling tool with code-generation capabilities gives you added advantages, the least of which is automatic code generation. More important, a modeling tool will accelerate the transition from analysis and design to construction. Building the implementation semantics into the tool will force out design issues such as partitioning, multi-threading, and event management before the code is generated. Forté, for example, has a powerful publish-and-subscribe event model. An object can post (publish) the occurrence of an event (when an order has been generated, stock levels are low, or a diagnosis has been made) without knowing which objects have subscribed to that event. In turn, subscribers can respond to the event without the publisher knowing which objects are responding to the event. This publish-and-subscribe feature promotes loose coupling, a characteristic of well-designed object-oriented systems. The ability to specify and visualize object interactions during design promotes exploiting loose coupling in implementation.

"Ptech has a complete Forté idiom like the policy manager objects, service manager objects, and message manager object along with the Forté class library framework. I can model the system the way I am going to build it in Forté," says Bill Gonch, senior project manager from a Fortune 10 consumer products company (I'm omitting the company's name at Gonch's request) that has implemented Forté in 14 projects. Gonch is managing a software factory group whose mission is to improve effectiveness of development organization with advanced tools and techniques. The developers have about 18 months experience with the Forté/Ptech combination and are able to deliver systems fast. Gonch's group recently delivered another application measured by 450 function points in 35 person-days.

In the future, tools will have a "round-trip" engineering capability that enables changes to the Forté environment to be hooked back into the modeling tool. This capability will help synchronize models and applications, and it could potentially address one of the post-implementation weak points of CASE tools: the fact that the application models immediately become untrustworthy or obsolete once the code is put into production and is changed. In addition, object-oriented CASE tool vendors are strengthening the link between their products and Forté so that less manual import and export will be necessary.

Modeling Tool Uses and Issues

If team-sharing of the models is important (as opposed to having one person responsible for updating models), the object-oriented CASE tool might have weaknesses in its repository capabilities. The repository should be shareable and have check-in/check-out version-control capabilities. In addition, repository objects should be reusable across projects. Depending on which tool you evaluate and which release of the tool your timing coincides with, reusability may or may not be an issue for your projects.

Another potential weakness is in transitioning from design to construction (and back). Object-oriented CASE tools today have limited ability to intelligently map the object model to a relational schema. Current relational databases do not support inheritance, so this limitation poses a design challenge. The most direct way to "flatten" the object model is to generate one table for each object (or more correctly, for each class). This process would create a table for each superclass as well as each subclass.

Other options exist. The designer can "rollup" the subclasses and generate one table for the superclass, merging all of the subclass attributes into the single table. A "roll down" is another choice in which subclasses are generated as tables with the generalized attributes from the superclass being replicated in each of the subclass tables. Today's tools still cannot determine which strategy makes sense. Beyond evaluating the depth and width of the inheritance structure, the designer must consider issues such as the performance capabilities of the runtime environment, size and volatility of the data, and ease of extending the physical design once it is implemented.

Because the UML is becoming the de facto standard for object-modeling semantics, most object-oriented CASE tool vendors promise support for UML. Therefore, tool selection should not be based on which methodology the tool supports per se. Some suggested criteria are provided in Table 3, page 58. I have observed that the tool selection process can easily become a "religious" issue, wherein individual preferences for a particular modeling diagram or vendor slow down or inhibit a company's ability to evaluate its choices objectively. The best approach is to have a cross-functional team determine which criteria are important and why and then rank those criteria prior to evaluating a short list of tools that meet the criteria.

Management Awareness

Time. The artifacts of requirements and design are abstract, which makes it difficult to support the notion that studying the problem domain before constructing for it is worthwhile. Management typically sees code and executables, rather than the practice of taking time to create artifacts of analysis and design, as measures of productivity. This tendency is known as the WISC(Y) (why isn't someone coding [yet]) syndrome.

Few mature organizations --such as Gonch's, which I discussed earlier in terms of function-point delivery of systems --have had the vision, patience, and financing to pursue the science and art of metrics aggressively for seven years. But Gonch's organization is the exception: Most IT organizations are at the mercy of their IT and business leaders, who need to support and invest in the staff time, training, and process-management disciplines necessary to get long-term payback.

Time is also needed to create objects for reuse and extension in future projects. Many organizations find that in the first couple of years they work on architectural objects such as material, customer, product, vendor, logistic, and person. They also work on extending infrastructure objects such as object, database access, and window. Organizations eventually begin to focus on segregating and securing implementation code into libraries that are controlled using configuration-management tools and techniques. This segregation promotes greater reuse and object extendibility. Organizations must learn that reuse comes not just from sharing object code, but also from the models such as use-case and object models. The future trend in more evolved organizations that use technology will be to move the benefits of reuse from construction to earlier in the systems development lifecycle.

IT managers must understand that they will not save time on their first two to four projects. It takes time to learn the tools and techniques --a difficult sell in these days of downsizing and outsourcing. Many IT and business organizations are taking the short view, acting and thinking tactically with a "just do it," short-term payback preference. Making the decision to invest in object modeling --let alone object technology --requires acting and thinking with a strategic, "learning to learn" point of view.

Training. The most common approach to training is to start with the applications development tool and then perhaps conduct training on what on object is and how to design one. But this approach is backward. The ideal flow is: concepts (object thinking) --> techniques (object-oriented analysis and design) --> tools (CASE and object-oriented development environment). IT organizations that are making gains with these high-end object-oriented environments already have a well-thought-out training curriculum in place, and funding and time have been allocated for developers, architects, and analysts to learn in a more productive manner.

Techniques. Several techniques stand out: establishing a formal mentoring program, using facilitated sessions (structured workshops, or "JAD" --Joint Application Design) for use-case and object modeling, conducting model walkthroughs, and designing an effective team process for accelerating design and quality assurance of the models.

A well-defined object mentoring program includes established objectives, clearly defined roles of both mentors and protégés, guidelines for the frequency and format of communications, a mentoring training program in which skills such as problem solving and interpersonal communications are highlighted, and plans for expanding and validating the mentoring program. These components are needed whether the organization uses external consultants or internal employees as the mentors. In either case, "seeding" the organization with mentors will frequently accelerate the object-oriented learning curve.

Facilitated sessions with customers and development teams promote collaboration and accelerate the modeling process. Facilitated sessions for use-case requirements gathering are heavily geared toward business customer participants. Object modeling sessions using techniques, such as class-responsibility-collaboration (CRC, from responsibility-driven design), enable the team to flush out the details of the object structure and behavior. Sessions should be carefully planned (with deliverables, session process, and session rules of engagement defined and communicated), professionally facilitated, and well documented. The presence of the modeling tool in the session provides added rigor to the session deliverables and gives the participants session deliverables for post-session validation.

Walkthroughs and inspections continue to be a low-tech and high-payback-quality activity, and they are applicable to object-oriented projects. A well-executed walkthrough will detect requirements and design defects earlier in the lifecycle and thus increase team efficiency. A walkthrough of the object-oriented models ensures consistency of purpose of a use case or object model and thereby increases object cohesion.

Using a well-defined team structure minimizes confusion and speeds the learning process. When a well-defined modeling approach is used, each class or class structure can be assigned to one person, each use case can be assigned to one individual, or a combination of use cases and classes can be assigned to one individual. The object-oriented team should mirror the best in design: loose coupling and high cohesion.

IT organizations that use high-end object-oriented tools effectively are finding the process a nontrivial undertaking. Issues such as learning the tool's object framework, maintaining the models, concurrently undertaking business-process reengineering with customers, ensuring that business-driven applications are being built, addressing training issues, and standardizing all present challenges in implementing any high-end object-oriented tool. It requires forward thinking about migration to objects --a process well beyond just tool selection.

TABLE 3. Selection Criterion for Object-Oriented Modeling Tools

code generation to target implementation environment technical support vendor responsiveness to suggestions platforms supported number of methods supported depth of methodology support BPR support UML support ease of use object-to-relational mapping vendor viability vendor partnerships repository strength (reuse, extension) architectural vision (layer, tiers) ability to model asynchronous and synchronous messaging integration between requirements and design cost import/export capabilities workgroup support