The next step is to describe the business use cases based on the previously-defined classes. As indicated in this chapter, business uses cases realizations may be defined by means of interaction diagrams (collaboration or sequence) or activity diagrams. The heuristics may be used as informal validation mechanisms. By applying heuristics, the business use cases are “executed” and the engineer may analyze if the defined classes and their responsibilities may carry out the behavior of the BUC.
•
HBOM1:MODELINGBUSINESSUSECASESASACTIVITYDIAGRAMDescription: Activity diagrams emphasize the sequential and concurrent steps
inside a process, taking into account the actors who perform the behavior. Activity diagrams describe the order of the activities and optionally, the inputs / outputs by means of the flow of objects. There is no explicit assignment of responsibilities to the object. However, the swimlane of the activity diagram can be used to organize the activities with a particular criterion. In this context, activities are grouped, taking into account the primary classes. The secondary classes remain as activities (if it is a class that represents an action) or as input / output of the activities.
Enhancing RUP Business Model with Client-Oriented Requirements Models 103
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written For each business use cases:
For each episode:
1. Are actors and workers of the BUC represented as primary classes? To define a swimlane for each class, start with the class that unchains the business use cases. The name of the swimlane is the name of the primary class.
Else:
To define the corresponding primary classes and return to this pro- cess.
2. Is each activity of the episode represented in the responsibilities of the corresponding primary classes?
2.1. To write the activity with the name assigned for that responsibility in the swimlane of the corresponding class.
2.2. The resources used in the activity can be used as input or output values, indicating the changes of state through a flow of objects. 2.3. To indicate the beginning/end sign control indicating the concur- rent activities for concurrent episodes.
2.4. To indicate the corresponding “guards” and the alternative ac- tions with the class responsibilities if conditional sentences or context restrictions exist.
Else:
To add responsibilities and return to this process.
•
HBOM2: MODELING BUSINESSUSECASES AS SEQUENCEDIAGRAMSDescription: The sequence diagrams show the interaction of the objects in a
sequence of time, defining the interchange of messages between the objects. This diagram is one of the most used by UML in order to specify the use cases. For each business use cases:
For each episode:
1. Are actors and workers represented as primary classes? To create a line with the name of the primary class. Else:
To define the corresponding primary classes and return to this pro- cess.
2. Are the resources of the episode modeled as secondary classes?
2.1. To create a line with the name of the secondary class to represent the “rol” in the activity.
2.2. To use the special notation if the object is created as a conse- quence of that message.
Else:
To define the corresponding classes and return to this process. 3. Is each activity of the episode represented in the responsibilities of the
corresponding class?
3.1. To create an arrow with the message from the class requiring the services to the class performing it (both represented with lines).
104 Leonardi
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
3.2. To define the input in the message and the output in the dotted line that it returns to the class.
3.3. To indicate corresponding “guards” in each alternative arrows if conditional sentences or context restrictions exist.
Else:
To add responsibilities and return to the process.
•
HBOM3:TOMODELTHE USECASESTHROUGH COLLABORATIONDIAGRAMSDescription: These diagrams show the interactions of the objects organized by
“rol” (i.e., squares representing instances and their associations inside collabora- tion) showing explicitly the relationships among the rol.
For each business use cases: For each episode:
1. Are actors and workers represented as primary classes?
To create a slot with the name of the primary class to represent the rol. Else:
To define the corresponding primary classes and return to this pro- cess.
2. Are the resources of the episode modeled as secondary classes? 2.1. To create a slot with the name of the class to represent the rol. 2.2. If the object is created as a consequence of a message, to place in the slot the key word “ new.”
Else:
To define the corresponding classes and to reassume this process. 3. To define the links corresponding to the object’s associations. To analyze
this association (obtained in HM3) and define a line that indicates the navigability.
4. Is each activity of the episode represented in the responsibilities of the corresponding class?
4.1. To create and numerate an arrow with the message sent by the requester class to the performer class.
4.2. To define the parameters in the message among brackets. 4.3. To indicate sub-responsibilities by means of a relative-nested numeration to the message that contains them if the responsibility has sub-responsibilities (obtained in the heuristic HC5).
4.4. To add a letter to the numbers of messages if the episodes are concurrent.
4.5. To indicate the corresponding “guards” as predecessors of the names of the messages if conditional sentences or context restrictions exist.
Else:
To add responsibilities and to return to this process.
Example: Figure 9 shows the realization of “To transfer the saving plan” business use
Enhancing RUP Business Model with Client-Oriented Requirements Models 105
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written