Uml 2 toolkit phần 9 ppsx

N OT E Not even UML 2 diagrams provide a consistent or elegant visual means to depict all the detail you might capture in the detailed design of a single class operation, and you invaria

■■ All calls to DAOs are made only through the appropriate businessobject For example, to access the BorrowerDao, you call the Borrowerbusiness object.

■■ JSP only access the model (in the MVC architectural pattern) via a ValueObject JSPs do not access any business-related objects directly

■■ JSP contain only presentation-related code No business functionality iscontained in the JSP

■■ JSPs do not contain any Java scriptlet code Instead, they use taglibs toconditionally show or hide certain presentation-related data

■■ Action classes supported by Struts framework contain only code related

to extracting the data from the request objects, passing data to theappropriate business object, and returning to the appropriate JSP There

is no business code in these action classes This enables you to supportmore than one type of client (other than a Web browser)

■■ Since FormBeans are an implementation mechanism of the Strutsframework, we chose to link the FormBeans to the Value Object andthen act upon the Value Object elsewhere in the application This way ifyou need to use a different framework, you can do so with minimalimpact

Performing Detailed Design

The purpose of the detailed design is to employ the strategic architecturaldesign and all of its associated implicit guidance (like key patterns for fre-quently performed or critical functionality) and adhere to it while evolving theresults of analysis, or even earlier iterations, into a precise and semanticallyrich representation of what you want to build in code This gets prettydetailed, including such things as refining individual class specs to ensure thatthey are complete, meeting the policies of the project for exception propaga-tion, reporting, general handling, and so on

After a few iterations, the design model should be detailed enough so thatyou can hand the model to a tool, and an appropriate compliable specification

so that its classes can be generated with a click of a button

Clearly, the visual parts of UML are insufficient to depict all that is needed;however, the combination of graphical elements and nongraphical UML ele-ments are sufficient to achieve the goal

The following sections describe the nature of detailed design considerationsand activities on a key package-by-package basis As a part of this discussion,

we focus on the business and presentation packages described in some of thedetailed design decisions based on original analysis

410 Chapter 11

business Package

The business package is primarily composed of control-type classes that resent the coarse-grained logic within the application All business objectclasses interact with DAOs from the database package and implement the nec-essary read and write operations

rep-The operations from the analysis have been detailed, which means thatsome of them have been translated into several operations in the design modeland some have changed names Additionally, as a part of the detailed design,all operations in the design model must have well-defined signatures andreturn values

N OT E Not even UML 2 diagrams provide a consistent or elegant visual means

to depict all the detail you might capture in the detailed design of a single class

operation, and you invariably need to specify details of the operation’s

signature in its nonvisual specification.

Note these changes between the design and the analysis:

■■ The current version of the system does not have to handle checks on

whether an item is returned in time, nor does the system have to handlethe ordering of reservations Therefore, the date attribute in the Loan

and Reservation classes has not been implemented

■■ The handling of magazine and book titles is identical (it would be

different if a lending period were in our requirements, but it isn’t), so

separating the subclasses for Magazine and Book Title is deemed as

unnecessary during the analysis Only a type attribute in the Title class

specifies whether the title refers to a book or magazine There’s nothing

in object-oriented design that says the design can’t simplify the analysis!Both of these simplifications can be removed easily if deemed unnecessary

in future versions of the application

presentation Package

The presentation package is “on top” of the other packages It presents the vices and information in the system to a user As noted, this package containsJSP It is a good idea to limit the amount of Java code contained within yourJSP Also, since you plan to support multiple Web browser platforms, you per-form the validation code on the server, thus reducing the amount of client-sidecode (that is, JavaScript)

ser-Case Study 411

Use-Case Design

Having analyzed the use case, and then made various architectural decisions,

we need to delve into more detail by further elaborating on the use case usingdynamic diagrams

The sequence diagram created during use-case analysis was of a reasonablesize, but as more detail is added in design, it becomes unwieldy Furthermore,

as we have created other analysis-level sequence diagrams, we have foundsignificant overlap in behavior For example, both the Checkout Item use caseand the Manage Items use case have requirements regarding searching for atitle Based on these issues, we created an Interaction Overview diagram topartition the diagram into manageable, reusable chunks Figure 11.13 showsthe Interaction Overview diagram for Checkout Item; although it is very sim-ple with no particularly interesting control flow, it greatly improves the under-standability of the model as we delve into more detail

Figure 11.13 Interaction overview diagram for Checkout Item.

Each of the interaction occurrences in the interaction overview will bedesigned in its own sequence diagram It is important to remember that theseare not disparate visual diagrams; as we work on each of the detailed sequencediagrams, we are updating the overall model As new operations are identifiedwhile building these dynamic diagrams, they are added to static diagrams andthe underlying model As we walk through these detailed scenarios, we makenumerous design decisions, break apart and combine classes, identify rela-tions, and so on Keeping the model in synch across all the diagrams becomeschallenging, but tool support helps.

Figure 11.14 shows the detailed sequence diagram for the ItemDetailfragment The figure is worthy of significant explanation both inthe area of UML usage and in the actual design being rendered

Checkout-This interaction starts with the Borrower actor sending a checkout message

to a CheckoutJSP object While messages typically represent an operation orsignal, we have chosen to start this interaction with a checkout message that isnot attached with an actual operation Although in a strict technological sense

it would be most accurate to show the actor submitting an HTTP POST, thatwould not best communicate what is happening So the interaction is shown

as being initiated via a “checkout” message Since this is not associated with anactual operation within the design, the parentheses have been excluded fromthis message signature

We added a note to remark on the store operation initiated on the outItemActionobject In our use of the Struts framework there is a lot thatgoes on in constructing the object and getting the method invoked But we arenot authoring that design here, we are just working within it Rather thanshow all those details, we are just showing the message as going straight fromCheckoutJSPto CheckoutItemAction with the explanation that there aredetails not shown here

Check-It would rarely be appropriate to create a sequence diagram that showsevery small step involved in a complicated interaction The designer mustdecide what to include and what to exclude from a diagram Here, we areexcluding the steps involved in getting the borrower identifier and the itemidentifier from the request object in the CheckoutItemAction class (Anycoder familiar with the HttpServletRequest object will be familiar withhow to do this, and it is not worth the space it would take up on this diagram.)

We didn’t worry about when objects are created during use-case analysis Inany design, and especially in a Web-based design, you need to make sure thatyou know when each object is created and who creates it Here, you can see theItemMgr created by the initiation of a static getInstance method on theclass The constructors of the other objects are also shown with the exception

of DaoFactory The getItemDao operation is also a static method

Case Study 413

Figure 11.14 CheckoutitemDetail sequence diagram.

The DaoFactory is a notable part of this design As described earlierwhen discussing the architectural design, we have an ItemDao interface anddifferent classes implementing it for each database we use Here we are show-ing that the ItemMgr asks the factory for an ItemDao, the factory figures out

what kind of database we are using, and the ItemDaoMySql is created andreturned The ItemMgr is sending a message directly to the ItemDaoMySqlobject, but actually has no idea what concrete object is implementing theItemDaointerface.

Designing the User Interface

A special activity carried out while designing is the creation of the user face—the “look and feel.” Initiated during analysis, you perform this sepa-rately but in parallel to the other design work (Creating a successful userinterface is beyond the scope of this book; consult other sources devoted to thistopic for more information.)

inter-JSPs are used to display the information and capture the data entered by theuser; in short, they act as an interface to the user Because of the support formultiple Web browser platforms, we made a design decision to put as littleJava code as possible within the JSP Regardless, the decision should alwaysensure that the requirements for the application are met In this case, we chose

to use the taglibs provided by Struts so that the Java code is not includeddirectly in the JSP Ultimately, this choice allows for a more readable JSP forpurposes of this case study, because certain implementation details are notperformed in the JSP

The resulting Unified Library application user interface is composed of amain page (Main.jsp), featuring a menu and an appropriate graphic, fromwhich all other pages in the application can be reached The other pages typi-cally present a service of the application and are mapped to a particular usecase In some cases, a single user interface, or page, might map to multiple usecases You might recall from Chapter 3 how the actors interact with use cases,just as in analysis the borrower interacts with a boundary class in the sequencediagram In design, the borrower boundary class from analysis becomes a JSP

Implementation

The implementation activities constitute the actual programming of theclasses One of the reasons to use Java to implement a system is because itworks with multiple processors and operating systems When you use Java,you find a natural progression from the logical classes that were created in thedesign to the code components during implementation because there is a one-to-one mapping of a class to a Java code file (and a one-to-one mapping to aJava executable class file) Java also specifies that the name of the file be thesame as that of the class it contains

Case Study 415

A component diagram helps in visualizing the physical representation asmapped from the design model The design was set up to manage the depen-dencies on particular database products For each entity there is a managerclass that depends on a specific DAO interface Then, the interface is realized

by separate classes supporting each of the databases, but the manager does notreally depend upon those classes Instead, they all depend upon the interface.Figure 11.15 shows a class diagram and the corresponding component dia-gram, which shows the artifacts that manifest those classes Although thedependencies of the physical code files can be surmised by an educated viewer

of the class diagram, the component diagram shows them explicitly

Figure 11.15 A class diagram and corresponding component diagram showing the

dependencies among a number of title classes.

For coding, the specifications are collected from the following diagrams inthe design model:

■■ Class diagrams.The class diagrams in which the class is present, ing its static structure and relationship to other classes

show-■■ State machine diagram.A state machine diagram for the class, showingthe possible states and the transitions that need to be handled (alongwith the operations that trigger the transitions)

■■ Dynamic diagrams (sequence, communication, and activity) in which objects of the class are involved.Diagrams showing the implementa-tion of a specific method in the class or how other objects are usingobjects of the class

■■ Use-case diagrams and specifications.Diagrams that show the result

of the system give the developer more information on how the system

is to be used when he or she might be getting lost in details—losingsight of the overall context

During implementation, deficiencies in the design model surface You mightidentify a need for new or modified operations, meaning that the developer

has 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 that follow demonstrate traversing the path fromthe presentation layer to the controller to the business to the data and backthrough the layers back to the presentation layer This is a good examplebecause other implemented use cases employ a pattern similar to this exam-ple The Java code for the entire application is available on the accompanyingCD-ROM When studying the code, read it with the UML models in mind andtry to see how the UML constructs have been realized in the code Considerthese points:

■■ The Java package specification is the code equivalent for specifying to

which package in the component or logical view the class belongs

■■ The private fields in Java correspond to the attributes specified in the

model, and the Java methods correspond to the operations in the

model

This example demonstrates the checkout of an item from the View Itemspage (ViewItems.jsp) The first code snippet contains the HTML and theStruts taglibs used for the ViewItems.jsp This JSP enables a user to enterand submit the data The JSP sends the request data to the server

// ViewItems.jsp

<logic:equal name=”item” property=”isCheckedOut” value=”false”>

<td><html:link page=”/Checkout.do?subAction=store” name=”item”

// CheckoutItemAction.java

ItemMgr.getInstance().checkOutItem(user.getId(),request.getParameter(Con stants.ITEM_ID));

Case Study 417

ItemMgris called by CheckoutItemAction and performs the related functionality for items ItemMgr abstracts out any of the HTTP- orStruts-related processing that takes place in CheckoutItemAction Item-Mgrcalls on the DAO Factory to get the DAO interface The Factory is respon-sible for determining which implementation to use In this case, it choosesbetween a MySQL or an Access DAO.

Test and Deployment

While testing requires significant attention and rigor, we are not going todescribe any of the testing efforts in UML here For this example, we used the

418 Chapter 11

original use cases to test the finished application to determine whether the usecases were supported by the application and can be performed as defined inthe use-case descriptions The application was also tested in a more informalway by putting it into the hands of a user.

N OT E A larger-scale application requires more formal specifications against

which the software is tested and a defect tracking system.

The deployment of the system is the actual delivery, including the mentation In a real-life project, user manuals and marketing descriptions aretypically part of the documentation work A deployment diagram should also

docu-be drawn of the physical architecture, as shown in Figure 11.16 This tion can be used on any computer with the supported Web browser platforms.This diagram shows our simple deployment structure for this case study Thewar file simply needs to be put in a J2EE application server on a machine towhich clients can connect

applica-Figure 11.16 A deployment diagram for the library system.

This case study demonstrated how stakeholder requests of a system can bemodeled with use cases, refined into an analysis model, expanded anddetailed into a design model, and finally implemented and programmed inJava The various parts of this case study were designed by a group who madeevery effort to work in the same manner they would have worked on an actualproject And though the different activities might seem separate and to havebeen conducted in a strict sequence, the work is more iterative in practice The lessons and conclusions resulting from the design were fed back into the analysis model, and discoveries made in the implementation wereupdated and changed in the design model This is the normal way to buildobject-oriented systems

Exercises

The exercises presented here enable you to immediately begin to apply UML.They are divided into analysis and design/construction categories The firstcategory lists new requirements on the system that have to be analyzed,designed, and implemented in the system The second category contains tech-nical changes and improvements that primarily affect design and implemen-tation You can decide to what extent to implement the solutions to theexercises, but note that some can only be made in the analysis and design models If you are proficient in Java, you can code and test the solutions in thefinal application Look at the different views, the different diagrams, and thespecifications

Requirements and Analysis Exercises

Exercise 1:Introduce functionality to inform a borrower with a reservationwhen an item of the reserved title is returned to the library The cus-tomer with the oldest reservation should be informed first

Exercise 2:Introduce functionality to inform a borrower that a loan is due

Exercise 3:Extend the system so that reservations are removed after aspecified amount of time

Exercise 4:Extend the handling of titles so that they can be placed in ferent categories and so that user-defined information can be added toeach title (for example, a review of a book)

dif-Exercise 5:Extend the system to administrate the purchases of new items

420 Chapter 11

Exercise 6:Introduce rules in the library model to constrain the loans For

example, restrict borrowers to no more than five reservations at the sametime, or to no more than 10 loans at the same time Make it easy to

define such new rules

Exercise 7:Enable a borrower to search for titles and items over the Internet

Exercise 8:Rebuild the library model to support integration of other

libraries using the same system This means that one library should be

able to search for a title or an item in another library A library should beable to lend an item in another library by sending a message to that spe-

cific library, which then performs the loan procedure and sends the item

by mail to the lending library Show a deployment diagram for this new

system

Design and Construction Exercises

Exercise 9:Add the Book Title and Magazine Title classes to the design andadd some new appropriate attributes to each of these classes Make the

existing Title class abstract and make sure the new classes can be stored

persistently

Exercise 10:Change the design of the search facility of objects, so that

“wildcard” characters can be used when searching for titles, authors, or

borrowers (for example, “UML*” returns all titles starting with “UML”)

Exercise 11:Change the design of the search facility of objects, so that tiple search results are handled (currently only the first match is

mul-returned) The number of “hits” should be reported, and the user should

be able to choose from among the result records

Exercise 12:Add a new utility class for creating a log that can be used by

all parts of the application to log either debug or trace messages The

type of information actually saved in the log should be configurable

from the user interface

Case Study 421

Flow Final:

Activity Edge, Control Flow or Object Flow:

Decision or Merge Node:

Decision Input

Input Pin

Action With Required Input

Action With Required Input or

«decisionInput»

Items needed

for Decision

424 Appendix A

Action With

Output

Action With Output or

Visual Glossary 425

Structured Activity

Expansion Region

Edge Weight on Activity Edge

{weight = Number of Tokens Needed}

Streaming, Parallel

(Concurrent) or Iterative

Action Collections Entering

Structured Activity, or

Protected Actions that will

Throw the Exceptions

Handle Exception Type

Exception Type

Visual Glossary 427

Action Path Two

Set One

Set Two

428 Appendix A

Object Node:

Object Node with Signal as Type

Send Signal Action:

Accept Signal Action:

roleB {property}

Association with Direction to Read

Association Name

ClassName

attribute1: type [multiplicity] = default

/derivedAttribute: type [multiplicity]

attribute2: type = default {property string}

classScopedStaticAttribute: type = default

operation1(param1, param2)

operation2(param1): {property-string}

operation3(param3: type = default)

430 Appendix A

Visual Glossary 431

Interface, Provided and Required Notation:

Parameterized Class (Template):

Instantiated Parameterized Class:

Object or Instance Specification: