| Master
Java's object-oriented power with the Unified Modeling Language
by Hans-Erik Erikkson and Magnus Penker The case study in this article provides a feel for how UML is used in the real world. The application, which handles the borrowing and reserving of books and magazines in a library, is large enough to put UML through some realistic paces. If it were any larger, we couldn't fit it in the magazine. We analyze and describe the app in an analysis model with use cases and a domain analysis. We expand it into a design model that describes representative slices of a technical solution. Finally, we code a piece of it in Java. (The code, plus the complete analysis and design models are supplied online, in a format readable by the included evaluation copy of Rational Rose.) Remember that what's shown is only one possible solution. There are plenty of others, and there is no "right" solution for all circumstances. Of course, some solutions will prove better than others, but only experience and hard work will result in that knowledge. Requirements
The first version of the system doesn't have to handle the message that is sent to the borrower when a reserved title becomes available, nor does it have to check that a title has become overdue. Analysis The developer shouldn't think in terms of code or programs during this phase; it is just the first step toward really understanding the requirements and the reality of the system under design. Requirements Analysis. The first step in analysis is to figure out what the system will be used for and who will be using it. These are the use cases and actors, respectively. The use cases describe what the library system provides in terms of functionality: the functional requirements of the system. A use-case analysis involves reading and analyzing the specifications, as well as discussing the system with potential users (customers) of the system. The actors in the library are identified as the librarians and the borrowers. The librarians are the users of the system and the borrowers are the customers, the people who check out and reserve books and magazines, although occasionally a librarian or another library may be a borrower. The borrower is not intended to directly interact with the system; the borrower's functions are done on behalf of the borrower by the librarian. The use cases in the library system are:
Because a library often has several copies of a popular title, the system must separate the concept of the title from the concept of the item. The library system analysis is documented in a UML use-case diagram as shown in Figure 1. Each of the use cases is documented with text, describing the use case and its interaction with the actor in more detail. The text is defined through discussions with the user/customer. The descriptions of all the use cases are included online; the use case Lending Item is described as follows:
Besides defining the functional requirements of the system, use cases are used in the analysis to check whether the appropriate domain classes have been defined, and they can be used during the design process to confirm that the technical solution is sufficient to handle the required functionality. The use cases can be visualized in sequence diagrams, which detail their realization. Domain Analysis. An analysis also itemizes the domain (the key classes in the system). To conduct a domain analysis, read the specifications and the use cases and look at which "concepts" should be handled by the system. Or organize a brainstorming session with users and domain experts to try to identify all the key concepts that must be handled, along with their relationships to each other. The domain classes in the library system are
as follows:
Some of the classes have UML state diagrams to
show the different states that objects of those classes can have,
along with the events that will make them change their state. The
classes that have state diagrams available online are A sequence diagram for the use case Lend Item (the borrower does not have a reservation) is shown in Figure 3. Sequence diagrams for all the use cases are online. When modeling the sequence diagrams, it becomes obvious that windows or dialogs are needed to provide an interface to the actors. In this analysis, it was sufficient to be aware that interface windows are needed for lending, reserving, and returning items. The detailed user interface is not specified at this point. To separate the window classes in the analysis from the domain classes, the window classes are grouped into a package named "GUI Package," and the domain classes are grouped into a package named "Business Package." Design The design can be divided into two segments: Architectural design. This is the high-level design where the packages (subsystems) are defined, including the dependencies and primary communication mechanisms between the packages. Naturally, a clear and simple architecture is the goal, where the dependencies are few and bidirectional dependencies are avoided if at all possible. Detailed design. Here all classes are described in enough detail to give clear specs to the programmer who will code the class. Dynamic models from the UML are used to demonstrate how objects of the classes behave in specific situations. Architecture Design The packages, or subsystems in the case study are as follows: User-Interface Package. These classes are based on the Java AWT package, a standard library in Java for writing user-interface applications. This package cooperates with the Business-Objects package, which contains the classes where the data is actually stored. The UI package calls operations on the business objects to retrieve and insert data into them. Business-Objects Package. This includes
the domain classes from the analysis model such as Database Package. The Database package
supplies services to other classes in the Business-Object package so
that they can be stored persistently. In the current version, the
Utility Package. The Utility package
contains services that are used in other packages in the system.
Currently the The internal design of these packages is shown in Figure 4. Detailed Design Database Package. The application must
have objects stored persistently, therefore a database layer must be
added to provide this service. For simplicity, we store the objects
as files on the disk. Details about the storage are hidden from the
application, which calls common operations such as An important factor in the persistence
handling is the The The current implementation of the Business-Objects Package. The Business-Objects package in the design is based on the corresponding package in the analysis, the domain classes. The classes, their relationships, and behavior are preserved, but the classes are described in more detail, including how their relationships and behavior are implemented. Some of the operations have been translated into several operations in the design model and some have changed names. This is normal, since the analysis is a sketch of the capabilities of each class while the design is a detailed description of the system. Consequently all operations in the design model must have well-defined signatures and return values (they are not shown in Figure 5 due to space restrictions, but they are present in the model online). Note the following changes between the design and the analysis:
Both of these simplifications could be removed easily if deemed necessary in future versions of the application. The state diagrams from the analysis are also
detailed in the design, showing how the states are represented and
handled in the working system. The design state diagram for the User-Interface Package. The User-Interface package is "on top" of the other packages. It presents the services and information in the system to a user. As noted, this package is based on the standard Java AWT (Abstract Window Toolkit) class. The dynamic models in the design model have been allocated to the GUI package, since all interactions with the user are initiated through the user interface. Again, sequence diagrams have been chosen to show the dynamic models. The design model's realizations of the use cases are shown in exact detail, including the actual operations on the classes. The sequence diagrams are actually created in a series of iterations. Discoveries made in the implementation (coding) phase result in further iterations. Figure 7 shows the resulting design sequence diagram for Add Title. The operations and signatures are exactly as they appear in the code online.
Collaboration diagrams can be used as an alternative to sequence diagrams, as shown in Figure 8.
User-lnterface Design The user interface in the library application is based on the use cases, and has been divided into the following sections, each of which has been given a separate menu bar in the main window menu: Figure 9 shows an example of one of the class diagrams in the user-interface package. This contains typical AWT event handlers. The attributes for buttons, labels, edit fields are not shown.
Each window typically presents a service of the system and is mapped to an initial use case (although not all user interfaces must map from a use case). Creating a successful user interface is beyond the scope of this article. The reader is invited to consider the UI code for this application, included online, which was developed using the Symantec Visual Café environment. Implementation
Figure 10 illustrates that the component diagrams in the design model contain (in this case) a simple mapping of the classes in the logical view to components in the component view. The packages in the logical view are also mapped to corresponding packages in the component view. Each component contains a link to the class description in the logical view making it easy to navigate between the different views (even if, as in this case, it is just as simple to use only the filename). The dependencies between the components are not shown in the component diagrams (except for the business objects package) because the dependencies can be derived from the class diagrams in the logical view. For coding, the specifications were fetched from the following diagrams in the design model: Naturally, deficiencies in the design will be uncovered during the coding phase. The need for new or modified operations may be identified, meaning that the developer will have to change the design model. This happens in all projects. What's important is to synchronize the design model and the code so that the model can be used as final documentation of the system. The Java code examples given here are for the Loan class and part of the TitleFrame class. The Java code for the entire application is available online. When studying the code, read it with the UML models in mind and try to see how the UML constructs have been transferred to code. Consider these points:
The code example in Listing
1 is from the Loan class, which is
a business-object class used for storing information about a
loan. The implementation is straightforward and the code is
simple since the class is mainly a storage place for
information. Most of the functionality is inherited from the You can examine the The code for all the sequence diagrams in the design model is included in the source code (the operation and class names are shown in the sequence diagrams). Test and Deployment Summary
|
