Framing Frameworks


Patterns help you solve small problems when you develop an application. Frameworks provide you with an “almost complete” application. For example MacApp provides you with a framework for building applications on an Apple Macintosh machine. You’ll notice some frameworks provide a solution for some important part of an application (frameworks that focus on the user interface design or a framework for accessing data in a relational database).

Frameworks also include special classes known as hotspots, which are the places in the framework that must change to bend the framework to your will. When you use a framework, you must develop classes and code for each hotspot. (For example, a reservation framework would have a hotspot for the specific commodity that a “reserver” can reserve.) You must provide the class definition that conforms to the commodity hotspot. For example, if you build a hotel-reservation system, then the commodity you provide is the room that a potential guest reserves.

 Warning   Building your own application framework is hard to do. Many developers have tried and failed. Good application frameworks involve many classes, multiple use cases, various hotspots, and intricate interactions—all of which require lots of documentation. (For example, the MacApp documentation runs to almost 20 megabytes.)

 Tip   Should you choose to develop a framework as the basis for your application, you have to document the following information:

  • Who’s involved: You need a class diagram to help others understand the details of each class involved in the framework.

  • Where you plug in to a hotspot: Each hotspot of the framework must be described so you can build customized classes that conform to the framework.

  • Collaborations: Instances of the most important classes collaborate to accomplish the job of the framework. You should provide composite structure diagrams that show the roles each major class plays in the framework.

  • How the collaborating objects interact: At runtime, the objects of your framework must interact to accomplish the functionality of your “mini-application.” Use sequence, activity, and communication diagrams to show the most important interactions.

  • Control mechanism: If your framework uses events, interrupts, and other such ways of controlling the application, then your framework documentation must include these details. For example, if the framework is event-driven, use a state machine diagram to describe the timing and control of the major application-oriented events. (See Chapter 16 for more on the state machine diagram. See Chapter 17 for more on events and interrupts.)

Frameworks can be quite complex. The often involve patterns of patterns. For example, Figure 15-4 illustrates a simple ownership collaboration. Figure 15-5 shows a reservation pattern that incorporates the ownership pattern twice.


Figure 15-4: The ownership collaboration.


Figure 15-5: The reservation collaboration.

The ownership pattern itself is simple, incorporating only two parts—the part playing the role of owner and the part playing the role of the property owned. What we haven’t shown in Figure 15-4 is the morass of details—any attributes, operations, and significant interactions between instances of the Owner class and instances of the Property class. You would see those in the alternative form of the collaboration, or in a simple class diagram.

For our reservation example, the important classes in any reservation play the following roles:

  • Reserver: This entity in the collaboration reserves the commodity by placing a reservation with the renter.

  • Commodity: The item being rented such (as a videotape, a crash dummy, or a room in a hotel) is known as the commodity being reserved.

  • Guarantee: The owner of the commodity must have some guarantee of payment. This guarantee often takes the form of a credit card or cash.

  • Renter: The renter offers a commodity for reservation by a reserver.

Figure 15-5 shows the Reservation collaboration with all these elements. We also show you that the Reserver plays the role of Owner in the Ownership collaboration. Here the Guarantee is the Property of the Reserver in the Ownership collaboration. You can also see that the Renter and the Commodity play roles in their own Ownership collaboration.

 Remember   Frameworks can be very complex. Even simple examples of frameworks involve collaborations involving other collaborations. Strive to keep your diagrams as simple as possible, while still communicating to other developers what they have to know when they use your pattern or framework.

Figure 15-6 applies the Reservation collaboration to the specific occurrence of reserving rooms in a hotel with a credit card. The Potential Guest class plays the role of Reserver, the Room plays the role of Commodity in hotel reservations, the Hotel plays the role of Owner, and the Credit Card plays the role of Guarantee.


Figure 15-6: A hotel reservation collaboration occurrence.

If you want to make the Reservation collaboration a usable framework, then you also have to show the following:

  • A use-case diagram with descriptions of each use of the reservations system for each actor.

  • A class diagram describing each class in the framework, especially the key classes shown in the collaboration occurrence of Figure 15-6.

  • A component diagram showing the components of your framework and their interfaces.

  • A series of sequence and communication diagrams telling other developers how each major use case is accomplished through the collaboration of the classes in the framework.




UML 2 for Dummies
UML 2 For Dummies
ISBN: 0764526146
EAN: 2147483647
Year: 2006
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net