Tom Spitzer     

WHY HOW?

Riverton Software’s design tool offers comprehensive support in the application development cycle

During the course of preparing an article for Intelligent Enterprise (November 1998) about Microsoft’s Visual Studio suite, a couple of concerns really nagged me. One was the inclusion of a limited version of Rational Software Corp.’s Rational Rose modeling tool, packaged as Microsoft Visual Modeler. Visual Modeler is quite limited and imposes Microsoft’s conception of three-tier architecture on its users. I opined that people using Visual Studio languages should make their own methodology decisions and use a more robust set of design tools. Second, I struggled with the Microsoft repository architecture and wondered whether it would become an island or whether other vendors would introduce tools to support it. Searching for answers to this question, I discovered Riverton Software Corp.’s HOW products, which address both the repository question as well as the need for more robust design tools.

HOW is an ambitious product, offering support for the full application development cycle from analysis to design, development, and finally, deployment. The ease with which you can iterate between analysis and design tools — and between design tools and generated artifacts — suggests the maturity of the tool and the experience of its designers. HOW has versions that support three major business application development language platforms: Visual Basic, Java, and PowerBuilder. I looked at the Visual Basic and Java versions of HOW because I was specifically interested in Riverton’s approach to generating code and other software components. I found that HOW’s model for generating Java is extremely different from its model for generating Visual Basic (and PowerBuilder) code. When working with Java, HOW generates code that corresponds strictly to the class objects in HOW domains and to query objects. For Visual Basic developers, HOW provides what Riverton calls an OpenFrame application framework, which separates the presentation, business, and data access logic into distinct logical units and provides mechanisms for interprocess communications among the resulting units.

HOW it All Works

Before drilling into specific tasks, it’s worth describing the HOW environment. At the top level, you are working with projects and libraries. A project references a set of objects that becomes the basis for a specific application. Libraries contain the analysis and design objects you create; each object resides in one and only one library. Each project must be associated with at least one library; however, because a library can be associated with more than one project, libraries provide a way to reuse objects across projects. When you start HOW, it displays its repository explorer, which lists projects on one tab and libraries on the other. You can choose to work within either the library or project context.

HOW displays the contents of a project or library in an explorer-style list, with buttons to control the display or suppress specific object types. When you open an object in the contents list, one of two things happens. For some types of objects, HOW presents a modal dialog box in which you must work and that you must dismiss before opening or working on another object. Editors for other types of objects run in an MDI window. Typically these windows display a two-pane dialog in which the left pane contains the current task and the right pane contains an embedded set of tab pages that list related types of objects. When you switch between child windows that display different types of objects, the HOW menu changes to display commands pertinent to the current context. I prefer to design (and use) applications with a stable menu structure in which the application activates and deactivates specific menu items based on context.

Using HOW Analysis Tools

HOW tools and its approach span methodological boundaries. I started in the “use case builder.” (See Figure 1.) The tab control in the right pane lets you view defined business rules, use cases, and roles while you enter the use case’s specifics in the RTF editor in the left pane. A template file named ucboiler.rtf, which you can edit, supplies the section headings for the use case. From the use case editor, you can invoke the business rule, class object, and interaction diagram editors. HOW links objects that you define in editors invoked from the use back to the use case; for example, if you start the business rule editor from within a use case, HOW links the new business rule to the use case in which you started. You can also hyperlink words in the use case to objects throughout your project.

FIGURE 1 The Use Case View Builder lets you assemble predefined use cases as well as create new use cases, and associate them with roles.


Performing use case analysis requires that you identify the actors that participate in the use cases. HOW provides a dialog for defining actors, which it refers to as “roles,” and a canvas for associating related roles and use cases in “use case views.” A workflow documents the sequence of activity steps and decision points involved in completing a specific business process. When you have created a use case view, you can generate a workflow in which each use case is represented as a discrete activity. Alternatively, you can create a workflow on a blank canvas.

The business rule designer looks and works like the use case builder. You can classify a business rule as a requirement, definition, derivation, fact, or constraint. HOW does not provide a formal syntax or notation for describing business rules, nor does it represent business rules in the generated application. Its purpose is to allow the declaration of the rules, and then to have its design tools indicate to which business rules they apply. It does provide auditing capabilities in the form of a “where used” report for each rule. Thus, when you think you are finished with your application, you can go back and verify that you have considered all your business rules in your design.

Design

In addition to analysis tools, HOW provides an extensive collection of design tools that meld object-oriented design with object-relational mapping and task analysis. Designers experienced in working with other graphical design tools will be most comfortable starting in the domain builder. (See Figure 2, page 58.) From within the domain builder, you can create class objects and interfaces and depict aggregation, generalization (such as inheritance), and other general-purpose associations among them. The “class object” properties tab dialog permits specification of the usual class characteristics such as attributes and methods. The dialog also lets you indicate which use cases and business rules the class implements. The generation tab provides a way to specify a variety of generation options, such as whether property changes to Java objects should generate notifications.

FIGURE 2 The Domain Builder presents a familiar class-design surface. The tab pages you can select refer to business rules and use cases that objects in the current domain must implement.


HOW articulates a taxonomy that categorizes class objects along one dimension as business or service objects and along a second dimension as entity or service objects. Business objects represent business-oriented semantics, whereas service objects represent objects in your architectural or language domain. Entity objects represent entities that must have a persistent representation, whereas service objects encapsulate behaviors that may interact with other objects.

One interesting facet of HOW is that it generates and synchronizes changes with entity/relationship diagrams based on the classes and relationships specified in its design tools. Using this capability requires either the ERwin (from Platinum Technology Inc.) or PowerDesigner (from Sybase) data modeling products. You assign domains to the data model using the data model map dialog. For each included domain, HOW will generate a table in the data model for each entity object marked as persistent. After you generate a data model from HOW, you elaborate on it in either ERwin or PowerDesigner, and then use HOW’s data synchronization model process to capture physical database information back into HOW. Once you have completed this process, you can view physical database attributes from the class object properties dialog, as well as generate code that implements the specified database interactions effectively.

HOW offers the concept of data collection as a means of specifying the structure of data sets that you want to associate with an application component such as a form or grid. In complementary fashion, a query specifies the set of persistent objects that the generated application should retrieve and associate with a data collection. The task builder provides a canvas for modeling an application’s presentation layer. You can assign one or more windows to a task and populate them with user interface controls, such as list controls, edit boxes, and grids. For each control, the data collection page in the properties dialog provides a place to specify whether the collection should be created or updated by a query, an instance method, or a class method.

Team Development with HOW

In my initial comments, I indicated that HOW is compatible with Microsoft’s repository. Although it can read objects from the Microsoft repository and populate the Microsoft repository with HOW objects, it maintains its own repository in an object database supplied by Poet Software Corp. You can specify a location for a team repository, and team members can then check HOW objects out of or into the repository. For large-scale projects, it’s easy to divide projects up by tasks, such as creating use cases, documenting workflow, and specifying presentation components for tasks. You would also represent relatively independent subsystems as separate domains and assign one or more domains to a team. The ability to create libraries of application or corporate standard objects and share them between domains and projects further supports such a division of labor.

HOW offers a variety of flexible reporting capabilities that further support the separation of task and function. It offers the tools (including commands that extend Word) to generate object documentation that can be inserted into a Word document and that can build compound documents from that object. By working in Word, you can create your own templates and add annotations to construct documentation sets that describe analysis-phase objects, design-phase objects, specific domains, or any combination thereof. In addition, HOW can output repository information into a relational database and provide a set of basic queries and reports that you can execute against this representation of its object data.

Overall, I found HOW to be a comprehensive toolset, and I recommend it. In most respects, the product appears to be relatively mature — with the exception of its Java support and the dead-end nature of the interaction builder and the workflow builder, which fail to inform the design tools in meaningful ways. I appreciate the approach HOW’s designers took to extending unified modeling language semantics with tools to document business rules and specify presentation layer components and their relationship to the data sets that the application will manage. This capability, together with the tight round-trip linkage to widely used data modeling tools, lets you do a lot of work in the design tool that other tools make you do in the target language. I know that Riverton is busy working on a version 3 upgrade, and I am eager to see how it will address the few shortcomings I did encounter.

Tom Spitzer a member of the EC Wise fast response team, contributes to various Miller Freeman publications. You can reach him at tspitzer@home.com. EC Wise specializes in adaptive Web interfaces applying rules-engine and object-oriented technologies.

PRODUCT SPEC SHEET HOW 2.0 Riverton Software Corp. One New England Executive Park Burlington, MA 01803 Phone 781-229-0070 www.riverton.com Pricing: Pricing: $1,995 to $6,995 per developer license, depending on edition. Contact manufacturer for more detailed pricing information. Installation requirements: Minimum Requirements: Windows NT (Service Pack 3) or Windows 95, Platinum ERwin/ERX 3.0 or Sybase PowerDesigner 6.0, Microsoft Access 7.x for producing repository reports, Microsoft Word 7.0 for producing documents that include objects from the HOW repository. Hard drive space: 80MB. Memory: 32MB. Contact manufacturer for additional requirements.