Once a project starts exploring design issues, class diagrams tend to be more varied. You can expand your classes using the full UML notation, or you can explore classes at a lower level of abstraction and continue to suppress the details (perhaps because those details are well-defined elsewhere). One form of design-level class diagram is simply a more expansive version of an analysis-level diagram. Figure 3-3 expands the analysis-level class diagram of Figure 3-2 to show operations. Figure 3-4 delves into some of the design-level classes that are connected with the ShoppingCart class that appears in Figure 3-1. The new ShoppingCart class is an HTML page that contains a static form displaying the contents of the cart and a Java applet that allows the Customer to make changes to the contents of the cart. The CandidateOrder is a JavaServer Page that retrieves the essential information from the ShoppingCart page (the client) and stores the information on a server in a format suitable for further processing by the system. SShoppingCart is an Enterprise JavaBean that lives only until the Customer is done with his or her shopping cart, at which point the system creates a “persistent” EJB with the name EOrder; this is the form that the Customer’s order takes going forward. Figure 3-5 takes things another step closer to implementation by showing the classes that sit underneath the ShoppingCart class shown in Figure 3-4.
The elements of Figure 3-5 are as follows:
Figure 3-5, which is adapted from a diagram in The Art of Objects,3 can serve as a diagram of a pattern in that everywhere ShoppingCart appears, you can simply plug in the name of another design-level class that involves EJBs. One idea, then, is to replace ShoppingCart with a generic class name and then refer to the resulting diagram from various other diagrams as appropriate.
blog comments powered by Disqus |