SAN MATEO (03/23/2000) - Developing business applications that use different technologies is like trying to hold a meeting among people with completely different agendas: It's possible, but you're just as likely to fail as to succeed. What you need is a well-designed plan before you begin. Similarly, if you don't have a solid outline to build from, your application development team could waste time and money spinning its wheels --and, worst of all -- you might end up with a solution that can't address your business needs.
That's where UML (Unified Modeling Language) comes in. Developed by the Object Management Group (OMG), UML is a powerful method for describing business processes in a form that helps both developers and users. In this Test Center Analysis, we'll show you how UML can speed up development cycles and increase the reliability of your applications.
Moving from data to objects
Flowcharts are marvels of simplicity. Using graphical notation, they describe the steps required to complete an action. Processes are broken down into clean, logical sequences, making flowcharts excellent tools for describing business problems and facilitating application coding.
For example, in the flowchart depicted on this page (which shows some of the activities involved in a reordering process), it's easy to see how one step is related to the one that follows. At the same time, however, so many details must be provided that each activity is essentially an isolated act. You might also notice that, in building the flowchart, a great deal of effort has gone into describing common behaviors such as troubleshooting problems with database access. The level of detail required makes it difficult to describe business processes, inevitably leading to errors and inaccuracies. But this method was the norm back when Cobol was the hottest programming language on the planet. In those days, developers had to crush their business scenarios into fragments that Cobol could understand.
A much-needed evolution resulted from the OO (object-oriented) approach. This stratagem gave software developers a concept that mirrored real life: a world made of things, each with their specific attributes and behaviors. We can easily drive a car because all cars share a set of standard controls. The ignition system, steering wheel, and brakes are controls we use to make the car perform a specific action, regardless of whether or not we know how each control was built. Similarly, OO programming languages let you define controls to trigger specific behaviors from an object.
By letting developers define objects as unbreakable mixtures of data and behavior, OO pushed system engineering to new heights. Developers could remove repetitive descriptions of typical actions from their code, embedding them instead within the definition of each object. Thanks to a structure that makes behaviors and controls public while hiding the underlying code, programmers can now use objects without actually knowing how they were built. Thus code can be written that focuses on real business problems, omitting object-related issues from applications.
A new modeling tool
Not surprisingly, the adoption of OO technology triggered the need for tools more sophisticated than flowcharting to describe business processes. Developers needed something that would let them create visual depictions of business processes, similar to blueprints of machinery, that could describe objects and object classes. They also needed a language that nontechnical people could understand, letting them participate more fully in development cycles.
UML was the result of an effort led by Rational Software to merge major modeling techniques. The UML approach (which defines a modeling language, not a programming language) lets systems architects describe classes and methods, and document their relationships.
By offering a common blueprinting language, UML relieves developers of the proprietary ties that are so common in this industry. Major vendors including IBM, Microsoft, and Oracle are brought together under the UML umbrella. And because UML uses simple, intuitive notation, nonprogrammers can also understand UML models. In fact, many of the language's supporters claim that UML's simplicity is its chief benefit. If developers, customers, and implementers can all understand a UML diagram, they are more likely to agree on the intended functionality, thereby improving their chances of creating an application that truly solves a business problem.
One step beyond flowcharting
UML is more than an aggregation of other techniques. Its approach is completely different from that of old-fashioned techniques such as flowcharts and spreadsheets. Rather than illustrating isolated steps in the process, UML favors top-view diagrams that let developers hide details and focus on functionality, not sequences of activities. This approach lets users start from a generic view of the application and introduce details and complexity later.
For example, in a typical order entry model as depicted in the screen shot (based on a sample from Rational Rose), you can simply identify an actor (the order administrator) and a business scenario. Because UML has such a rich set of interrelated symbols, it's easy to accurately describe business processes and development projects. You don't have to define individual steps in the order management process, meaning you save time and money.
Each of the diagrams used in UML lets you see a business process from a different angle. Business users, for example, can view use-case diagrams to see the business scenario overview and understand who's doing what, while developers can use class and object diagrams to get accurate descriptions of how to build those components into their code.
Object and class diagrams depict static "snapshots" of the elements within a system, showing objects' structure, attributes, and relationships to one another. Activity diagrams show the flow of control from one activity to the next, and use-case diagrams illustrate elements outside the system. (For example, the internal workings of a new payroll system would be shown in an activity diagram, whereas external actors, such as the mail order department, would appear in a use-case diagram.) Sequence and collaboration diagrams show interactive processes: You not only see objects and classes, but also the messages that pass between them. Thus, you can simulate passes through your system using a conventional "what if" approach. State diagrams are used for very dynamic objects that receive and send messages frequently. Finally, component and deployment diagrams show the physical view of your system (including executables, libraries, and interfaces).
A UML software kit, such as Rational Rose, provides tools that let you easily create UML models for your business processes and automatically generate code in various programming languages (including Java, C++, and Visual Basic). Most packages also let you drill down on each icon to open further details -- in order entry, for example, that might include activities to manage the order and a sequential diagram of actions.
You can also use modeling software to reverse-engineer an existing system, automatically creating a blueprint from machinery. If, for example, you wanted to put a Web front end on an application, UML software lets you generate class diagrams from the code to get a static picture of how all the objects are related to one another. Even if case or system views cannot be derived working from the class diagram, you could create new classes for extra functionality.
Even though reverse engineering may require some manual adjustment, depending on the existing applications, it still lets you reduce the time needed to analyze and understand your applications.
Furthermore, a UML modeling product lets developers describe business problems with tools that are as technically accurate as their programming language, but much easier to use. The class and object diagrams are so detailed, describing elements such as interfaces and attributes, that translating UML notation into actual programming code is a virtual no-brainer.
The current UML specification (Version 1.3) offers a range of improvements, including several new semantics, better document organization and readability, new XMI (XML Metadata Interchange) support, and various bug fixes. And the specification isn't standing still: Further down the line, UML should offer precise interfaces to CORBA, Enterprise JavaBeans, and XML for business models, tools for model versioning and diagram interchange, refined notation for enterprise architecture views, and better semantics for refinement and trace dependencies.
For now, one of the most noteworthy trends in the world of UML is known as stereotyping. This is a method that extends the basic vocabulary of UML. By using the building blocks in your UML map, you can build new codes that are specific to your business problems. Stereotype code can be used to identify such items as executable and physical files, create or destroy instances of classes, or trigger code when a certain event occurs. Developers can link icons to stereotypes to modify UML for specific operations.
Look for more extensions to the UML semantic in the months to come.
Mario Apicella is a technology analyst for the InfoWorld Test Center. You can reach him at firstname.lastname@example.org.
THE BOTTOM LINE
Business Case: UML offers the tools to gather business and technical expertise around complex development projects. The language can simplify projects, reducing costs and boosting efficiency.
Technology Case: The UML approach lets developers define technically complex application methods that can be deployed in multitier, distributed environments. The user-friendly view facilitates interaction with nontechnical business analysts without impeding the development cycle.
+ Standard methodology
+ Easily understandable, yet powerful, notation+ Automatically generates codeCons:
- May require training
- Success requires departmentwide adoption