Because UML is essentially a set of diagrams, you can simply draw them by hand on a piece of paper. But, drawing UML diagrams on a piece of paper is certainly not a best practice to design systems. Software applications simplify the task of drawing diagrams of software designs. In addition, because the design is in an electronic format, archiving the design for future use, collaborating on the design becomes much easier. Also, routine tasks can be automated by using a UML tool. Hence, using a UML tool is by far the most preferred way for designing software applications.
Features in UML Tools
This takes us to an important question what exactly should we look for in a UML tool?
Because the primary use of a UML tool is to enable you to draw diagrams, first and foremost, we need to see what types of UML diagrams the tool supports. But, is drawing UML diagrams all that you would expect from a UML tool? For example, wouldn't it be great if the class diagrams that you draw in the tool can somehow be used to generate the source code for actual Java classes or C++ classes?
Let us take a look at another scenario. Suppose you were given a large set of source code files with lots and lots of classes. Wouldn't it be a nightmare wading through the code trying to figure out how all the classes are interconnected? This is where UML tools step in to make things a lot easier by providing support for such features. Now, let's define these features in technical terms:
· UML diagram support: The UML tool should support all the nine diagrams that make up UML. You should look for a tool that supports drawing use cases, designing the static view diagrams such as class diagrams and object diagrams, defining the dynamic view diagrams such as sequence, activity, state, and collaboration diagrams and the component and deployment diagrams that form the implementation view of the system.
· Forward engineering: A UML tool should not have its use limited to just a pictorial depiction of diagrams. Because the structure of the system defined by the diagram is translated by a developer into actual source code (classes), the UML tool should bridge this step by generating the source code of the classes with the methods stubbed out. Developers can take up this stub code and fill in with the actual code. This characteristic of automating the generation of source code is called forward engineering. Forward engineering support by a UML tool is normally for a specific language or a set of languages. If you are a Java developer, verify that the UML tool that you want to use has forward engineering support for Java. Similarly, if you are a C++ developer, the UML tool should provide you forward engineering support for C++.
· Reverse engineering: Reverse engineering is exactly the opposite of forward engineering. In reverse engineering, the UML tool loads all the files of the application/system, identifies dependencies between the various classes, and essentially reconstructs the entire application structure along with all the relationships between the classes. Reverse engineering is a feature normally provided by sophisticated and high-end UML tools.
· Round-trip engineering: Another useful feature apart from forward and reverse engineering is round-trip engineering. Forward and reverse engineering are essentially one-off activities that take input and generate the required output. Round-trip engineering extends these features.
An important rule in software design is that no design remains unchanged. This is as true for small systems as it is for large systems. During development, the design structure defined in the UML model does undergo changes to incorporate physical differences in implementation that may not have been envisaged during design. It becomes very difficult to keep the design of the system updated with the changes in the source code. The round-trip engineering feature enables the UML tool to synchronize the model with the changes in the application code.
· Documentation: Documentation is an integral aspect of a UML tool. Software designing, by nature, is an abstract process. Apart from a few syntax and semantic ground rules, there are no other rules. The thought process of a software architect who designs applications using UML can be lost if the reasons behind certain design decisions are not captured and well documented. This becomes painfully clear when large systems are maintained and no one has a clue to why a subsystem was designed in a certain way. Hence, a UML tool must necessarily provide some way for the designer to document design decisions in the diagrams by using simple things such as annotations or comments. In addition to this, the UML tool should support the generation of reports/listings of the different design elements of the diagram.
Template-driven modeling
Re-usability is the key to improving productivity. An application design may consist of several classes with relationships defined. Quite a few times, while designing applications, you encounter the same design problems or scenarios and end up defining the same design again and again. By using a modeling tool, you can define certain components or even subsystems that might potentially be reusable in the future. For example, design elements of an application used to define access to the database using, say, a ConnectionPool class are potentially reusable. You might need to define a similar database connection pool in another application as well. Hence, it would benefit us in the long run if we design the ConnectionPool class separately. We then can include the ConnectionPool design in any future subsystems and avoid the need of reinventing the wheel. Such reusable designs or models are termed as templates and the entire modeling process involving the identification and use of templates is called template-driven modeling. The benefits of template-driven modeling are apparent in the savings in design time. You can consider model templates to be very similar to reusable code libraries used in application development.
Integration of UML Tools with Integrated Development Environments (IDEs)
One interesting feature in UML tools that we discussed in the previous section was round-trip engineering. For round-trip engineering to be useful, we need to have the UML tool to be used in conjunction with an IDE. This integration of a UML tool with the IDE will help you to really benefit from round-trip engineering. Any changes in the application code that you make in the IDE are immediately reflected in the model in the UML tool and vice versa. For our discussion, we will be considering IDEs for the Java language.
Quite a few of the UML tools on the market can be integrated with the popular IDEs such as IBM's WebSphere Studio, Borland's JBuilder, WebGain's Visual Café, or Sun's Forte. For instance, Rational Rose (Java edition) provides integration with all of these popular IDEs. Together Control Center has a special version that integrates with IBM's WebSphere Studio.
The downside of UML tool integration is that the integration solution is proprietary to the UML tool vendor. Hence, you might not always find a UML tool providing integration with popular IDEs in the market. But all this is changing.
Popular UML Tools
Summary
UML tools will form the basis of our activities in the coming weeks. Each of the UML diagrams that we will cover will be built using any of the available UML tools in the market. Today's discussion helped us understand what features we should look for when selecting a UML tool. Apart from the "must-have" features, we also checked out a "wish list" of features that a UML tool could have. The classroom courseware case study application that we discussed will be designed using when we cover each of the UML diagrams in the coming weeks.
/4 
文章评论（0条评论）
登录后参与讨论