UML Modeling for Java with Rhapsody
by Peter Varhol01/25/2001
While there are sophisticated development environments and tools for building Java applications, including some good visual tools (IBM's VisualAge comes to mind), most of them are geared toward specific tasks in the development process, usually writing code. For most Java developers, there's no inherent connection between designing software systems and writing code.
I-Logix's Rhapsody changes the developer's point of view from writing code, or assembling software components, to modeling the system to be built. The design methodology it incorporates is the Unified Modeling Language (UML). UML is based on OMT, Booch, OOSE, and other earlier modeling techniques that by themselves only modeled a single aspect of the system. UML diagrams are able to represent unambiguously all aspects of the system being built.
Rhapsody is unique in that it builds Java applications visually but not in the same sense as VisualAge or Visual Café. Instead it uses a type of visual programming that translates detailed, formal graphical models based on UML directly into Java code.
UML provides a combination of visual modeling techniques that unambiguously describe a software system. These views describe the system's architecture, behavior, and component collaboration. Once these views are created, you can generate high-level code or executables that correctly reflect the software design.
UML defines a number of views that provide different perspectives of the system under development. Each view shows a different aspect of the full software model, and each is necessarily incomplete. Think of it like three dimensional photography. To get a complete picture of a car, for example, you have to photograph it from a number of different angles and perspectives. UML offers a total of nine views of a model, including class diagrams, Statecharts, use-case diagrams, and sequence charts. Not all are needed to represent unambiguously every software system, often three or four are sufficient.
UML and Rhapsody
Rhapsody in J (I-Logix offers implementations of Rhapsody for generating Java, C++, C, and Ada) provides more than just an environment for developing Java code. It's a visual design environment that enforces a comprehensive methodology for building formally correct system models. Like most UML design tools, it lets you build formal models that prevent ambiguities and illogicalities. Unlike others, it takes those designs and creates Java code that implements the UML design.
Compiling a UML model into Java code works in two parts. First, Rhapsody checks the model's syntax and to a certain extent its semantics. This is possible because the model should be logically consistent; the editor doesn't allow things that are illegal in the modeling language. It can also do some checking for internal consistency, primarily to make sure that the model as represented by one diagram coheres with any related diagrams.
Once the model is verified, the next step is to produce Java code. This works through a mapping between UML constructs and Java classes derived from the Java class library. What results from this process is a software implementation that uses the standard Java object model.
Rhapsody includes an editor for four different diagram types: sequence, object model, use case, and statecharts. Rhapsody diagrams are combined into one model, ensuring consistency across the different views. You can inspect the entire model or automatically review it for consistency and syntactical accuracy.
 |
| Figure 1. Use cases are a structured way of describing the behavior of an embedded system. (Click for full-size view) |
A good place to begin a Rhapsody design with UML is with use cases (see Figure 1 for an example). As the name implies, a use case is a structured way of describing the desired behavior of a system. Think of a use case as an entire class of examples. Individual variations of the class are called scenarios. Scenarios may help users accurately describe the requirements of the system, but they're not necessary to the design process.
A statechart joins behavior to architecture, very similar to an old-fashioned state transition diagram. Statecharts have additional structure and constraints so that they unambiguously define the movement from one state to the next. Anyone who has worked with state transition diagrams or even finite state machines will grasp the statecharts quickly (Figure 2).
 |
| Figure 2. A statechart is very similar to an old-fashioned state transition diagram. (Click for full-size view) |
Object modeling diagrams join architecture to collaboration. They have an architectural aspect because your code will likely be built along the lines indicated by the objects you define, even if you don't use code generation or object-oriented programming languages. And they have a collaborative aspect because properly designed objects are intended to pass messages to one another. Sequence diagrams illustrate the way different components of a system collaborate. They show the flow of data and control between different aspects of the system as the application executes.
Using these four for moderately simple (but not trivial) applications will probably take a novice from three to four days, most of which will be spent learning UML and the software. Once you've gained experience, you can expect your productivity over manual coding to improve by about fifty percent. For those who want to incorporate existing Java code, or rewrite some of the generated code manually, Rhapsody in J can encapsulate changes to the code, incorporate them back into the model, thus keeping the model and code synchronized.
If you need to pursue system views beyond these four, you must look elsewhere for tools, possibly committing to the entire Rational Unified Process. Using all nine UML views is probably most appropriate for complex and highly interactive software systems. But Rhapsody in J lets software designers use UML as a higher level of abstraction for developing Java code without the overhead of full UML.
Many modeling tools generate code. The value of Rhapsody is its use of a widely accepted, formal modeling language as the basis for design, and in a unique ability to incorporate code written by hand into the model. Software developers actually get to be software designers, while delegating the implementation to an automated process. The model also serves as excellent documentation of the implemented system.
Computer science educators (a job I once did) perennially espouse the virtues of designing software over coding, yet in many cases in real life designing takes a back seat to getting the application out the door. Modeling tools such as I-Logix Rhapsody force developers to do just what they should be doing. And in so doing, it removes the potential for errors in translating designs into actual code.
I-Logix markets Rhapsody in J to embedded systems developers, who have embraced both Java and UML more completely that general-purpose application developers. However, developers who are interested in spending most of their time designing software rather than writing code will benefit from the Rhapsody approach.
366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
