Peter is an assistant professor of computer science and mathematics at Rivier College in New Hampshire. He can be contacted through the DDJ offices.
Most CASE tools are meant just for software developers. They're designed to provide a level and scope of information that only these professionals have an interest in and a need for. However, developers must share their concepts and designs with a larger community that has a legitimate need to understand the application design, but may not have the technical background or patience to follow a library of detailed software-design diagrams.
In a team project I recently became involved with, the users of the software package we were developing were scientists, not programmers, and we faced the problem of how to communicate ideas and progress, but without using the traditional software-design tools. This meant choosing one or more design tools that could be useful to the developers, yet provide important information to the people who were paying for the effort.
Certainly it would be possible to use any good drawing package to create high-level diagrams, flow charts, illustrative displays, and presentation charts, but that effort would contribute nothing to the work of creating the software. What we needed was a toolset that would communicate our ideas both inside our team and to outsiders.
The project was to design and develop a complex software package for the setting up, running, and visual analysis of the results of several atmospheric simulation programs. The application was to have several modules--an expert system for choosing the appropriate program and setting up the input parameters, a data visualization package for examining the simulation output, a database of pre-computed results for fast estimates, and the simulation programs themselves.
The package would be implemented initially in Microsoft Windows, and each module would run as a separate task, communicating via Dynamic Data Exchange or similar mechanism. Since many of these simulation programs require long execution times, the separate-task approach would enable the user to start a simulation run, visually examine the results of a previous run, and send output to the printer.
These characteristics made the application much different from those that most professionals have to develop, in that it was actually several tightly integrated applications. These applications, or modules, had to communicate both with the user and with one another. The expert system passed data to the atmospheric-simulation programs as input parameters, while the programs passed their results into the visualization module.
Another requirement was that the application would eventually be ported to the Sun SPARCstation running UNIX and Open Look, and possibly to other UNIX/X platforms. This meant that those parts of the application that would be system specific had to be carefully separated from the code that could be reused between these platforms.
The design tools used for this system had to be flexible enough to accommodate the existence of and communication between the application modules, help delineate the code that was system specific, and successfully communicate the design concepts to our customers and end-user community.
Meta Design was a good tool to assist with the design of this software, for several reasons. Because it runs Microsoft Windows, it enabled me to pursue the design and development under the same operating environment. More importantly, several of the features available in Design directly supported the unique needs of this project. For example, the ability to layer the design, create more detailed diagrams on separate pages, link different layers of the design, import graphics, and customize the design environment all contributed to the initial design process.
Many of these capabilities are available in a number of CASE tools. However, Meta Design is both more and less than a typical CASE package. Less, in that the user does not carry around the baggage of one or more built-in design methodologies that may be inappropriate for the problem at hand. One of the biggest limitations of many CASE packages is that they are almost always built around a particular methodology. If you buy the package, you buy into that methodology.
Meta Design offers more in that it can be easily customized to support multiple design methodologies. It comes with support for flow charts and entity-relation diagrams, but the user can create new libraries for any number of methodologies.
Meta Design supports multiple methodologies by using the concept of the palette. A palette page can contain virtually any library of symbols, diagrams, or graphics. A palette can be created in several different ways--from the drawing tools within Meta Design, in an external drawing package (even a traditional CASE tool), or even from a scanned image.
Design supported an important feature not found on most CASE design tools--the ability to completely customize the palette of shapes and objects that could be used in a document. A palette can be composed of one type of graphic, and be used anywhere within a Design document. This allowed me to, in effect, create my own design methodology, or to combine methodologies to suit the needs of the different modules. Design has no built-in or predefined methodology, although Meta Software itself has devoted considerable effort to the Petri-net design approach.
Further, a single document could make use of multiple palettes. I didn't have to worry about creating a new Design document every time I wanted to use elements of a different design methodology. Combining different documents would have proved unwieldy for a design effort of this magnitude, and instead I was easily able to keep track of the overall system design in the same document.
My effort on the project described above was devoted mostly to the design of the knowledge-based system portion of the application. Novice users of the application would be assisted though a rather lengthy dialog to determine what atmospheric program or programs they should run, and how to set up its parameters. More experienced users could choose the appropriate program themselves and enter the parameters into a template.
I constructed the general design in a hierarchical fashion, much as a novice user would traverse the knowledge-base menu structure. While not showing every decision point (leaving that to the detailed design), I outlined the choices a user would have to make in order to enter either the expert-system dialog or the template for a particular program.
One feature of Meta Design that assisted during this process was the ability to move blocks around on the screen and not worry about reconnecting the blocks--the connectors follow the blocks anywhere they are moved. This enabled me to quickly construct new architectures, save them for later examination, and move on to new concepts.
An important part of the design concept was to have a one-to-one relationship, inasmuch as possible, between major functions as seen from the user's point of view and software components as seen from the programmer's point of view. This was the most important part of my strategy for interacting with the customer. The resulting diagram, then, is appropriate for the software designers to begin a more detailed design, as well as for the customer, who wants to ensure that all of the required functionality is included.
The primary Design diagram (see Figure 1) had multiple levels, each representing a level of the actual software design. The top level was both the top level of the overall design and the user's first view upon launching the application. The next level (see Figure 2) defined the top-level functionality--the expert system for setting up the problem, the data visualization module, the database of precomputed results, and the system maintenance facility. Subsequent diagrams go on to define lower levels of functionality, including templates for data input, unit transformations, and different graphical views of the output.
As a last touch, I constructed several mock atmospheric scenes, such as those that would be generated by the simulation programs, using the bitmap drawing tools provided with Microsoft Windows' Paintbrush accessory. I then imported these into Meta Design and installed them on pages linked to the design of the visualization modules. As the user navigates through the design of the software, these images will appear in those places where the actual visual image will appear in the completed software. This gives the user an idea not only of the high-level design, but also of the resulting outputs.
For the remaining parts of the diagram, I have created illustrative screen designs that are linked in the same way. These, however, were created mostly within Meta Design itself, using its drawing tools. The end result was not merely a software design, but also a part of a functional specification. The user can see the proposed displays.
Each display and atmospheric scene was simply copied from Paintbrush or other graphics package and pasted into a palette page. Once in a palette, the graphics could be pasted from the palette into the document. The result is a multilayered, multimedia document that serves the creative juices of the software designer and the curiosity of the customer.
The design of the simulation support and visualization application is well along, and coding should begin shortly. The expert-system development environments have been chosen, an overall system architecture has been developed, and we've begun a number of knowledge-acquisition tasks. The project team has also been prototyping the user interface.
During this process, the Meta Design documents have been useful to me in keeping the overall design objectives in mind, and in communicating various design features to others, both within and outside of the project. As knowledge engineer on the project, my Design diagrams have been especially invaluable in showing often-skeptical experts how the final product will work.
The one aspect of the Windows version of Design that I found lacking was the ability to run a simulation on a Petri net diagram. This option is found in the Macintosh implementation, but has not yet been ported to the PC. Therefore, I made much less use of Petri nets in my design than I might have otherwise. While I used a palette that contained some Petri-net symbols, there was no way of actually running a Petri-net simulation using them.
Design is also not an appropriate tool for full-blown prototypes. My diagrams were of high-level concepts rather than detailed operations, and there is no convenient way of letting the end user navigate through a Design document as though it were an application. We developed high-level user-interface prototypes using Microsoft's Visual Basic, and knowledge-base prototypes with Neuron Data's Nexpert Object.
One unexpected advantage I obtained in investing the time to create new object palettes was that I can now use these palettes in future software and system-design efforts. One project I am assisting with is an Actor application. Using Coad and Yourdon's book, Object-Oriented Analysis (Yourdon Press, 1990), I am in the process of extending one of my old palettes with symbols appropriate to an object-oriented design effort.
Granted, the designs for this project could not have been accomplished with Meta Design alone. There was still a need for a traditional CASE tool to incorporate the design into a more structured format, and to manage the data dictionary and other important constructs. While it is possible to do these things in Meta Design, the amount of effort involved in customizing the environment would have been prohibitive. Our traditional CASE tool was EasyCase, which like Meta Design provided a highly functional design environment at a modest price.
Meta Design, however, bridged the gap between the software professionals and the customers or end users. Our design concepts could be codified for those who had to have an overall understanding of the application as it came to life, while the end user could appreciate navigating through the design structure to reach displays and atmospheric scenes.
Meta Design Meta Software Inc. 125 Cambridge Park Drive Cambridge, MA 02140 617-576-6920 $350.00 System requirements: MS Windows 3.0, 2 Mbytes RAM, 1-Mbyte hard disk, EGA or better
Copyright © 1992, Dr. Dobb's Journal