Once the classes and their responsibilities have been identified, structural aspects of the classes are modeled. In this strategy, we define a class diagram for the primary classes and the business entities or secondary classes to enhance the proposal of RUP to define an object model for the business entities. This diagram defines the UofD. As such, it presents no software limits (a task left for the analysis stage, where the actors of the system are defined and the use cases of the system are identified from the business use cases). The following heuristics guide in the definition of the attributes, methods, and relationships among classes.
•
HM1:DEFINITIONOFCLASSESANDTHEIRATTRIBUTESUSINGTHECANDIDATESCLASSESAND THELELDescription: Each class candidate becomes a class of the object diagram. For each
class, we analyze the notions of the corresponding LEL term, searching for the characteristic properties. It is also necessary to analyze the responsibilities of the class since new attributes can appear, enabling the class to perform the action of the responsibility. Two things can happen:
HM1.1: HANDLINGOFSIMPLEPROPERTIES
Description: The property is modeled directly as an attribute of the compo-
nent, since in the LEL, it represents the name of the property.
HM1.2: HANDLINGOFPROPERTIESTHATREPRESENTDIFFERENTVALUES
Description: In the LEL term, several properties appear modeling different
states or concrete values of the term. In this case it is possible to choose one of two alternatives:
•
The first alternative is to define an attribute whose domain is the group of values that appear in the term.•
The second alternative is to define a Boolean attribute for each property. If it can be detected that some non-functional rules affect these values, then it is better to model as an independent attribute to be able to reflect the rule.•
HM2:DEFINITIONOFTHEMETHODSDescription: Each responsibility is a candidate to be modeled as a method.
98 Leonardi
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
HM2.1: ANALYZING RESPONSIBILITIESRELATEDTO THESAMEATTRIBUTE
Description: Several responsibilities of a class can modify the same attribute in different ways. The Software Engineer decides to define a method for each responsibility or to define only one method for managing the different alternatives through parameters. Although this is a design decision that depends on the software engineer, it is possible to obtain information that helps to make a better decision (for example, how many times each method candidate is used or if there is some rule that affects a particular responsi- bility) through the business use cases, business rules, and LEL models. HM2.2:ANALYZINGTHEDIVISIONOFARESPONSIBILITY
Description: A responsibility may be split within several methods, since it defines actions that are also performed by other responsibilities of the same class. For this reason, it is better to isolate this action and transform it into a method.
HM2.3: DEFINING PARAMETERSOFARESPONSIBILITYANALYZINGTHEBUSINESSUSECASES
Description: In order to define the parameters of the methods, the group of business use cases containing the responsibility of each class is analyzed. For each one of them, the data used to perform the method is analyzed and new attributes are defined in case there is no previous definition.
HM2.4: INCORPORATING BASICMETHODSTOCLASSES
Description: To complete the definition of methods, the basic methods of access and modification, which were not defined in previous stages, are described. This takes into account any disregard for those attributes that represent a property that can not be modified explicitly.
HM2.5:FACTORING OFRESPONSIBILITIES
Description: Although in the definition of the responsibilities the services of each class were expressed concretely, it should be analyzed if similar responsibilities exist when defining the methods and thinking of an object- oriented solution. To do this, it is necessary to “think” the responsibilities in a generic form, i.e., if a certain responsibility is for example, “printXX,” and another responsibility is “printMM,” the method will be “print.” This strategy decreases the number of methods of a class, improving the future object-oriented design (Cockburn, 1999).
Figure 8 shows a partial description of a class with the heuristics that created or modified some of its attributes and methods.
As illustrated by the example, there are some attributes and methods modified or created by heuristics (HM4) related to the application of business rules (as we will see later on in this section).
•
HM3: DEFINITIONOFRELATIONSHIPSAMONGCLASSESUSINGTHELELDescription: The notions of the LEL terms that correspond to each defined class are analyzed in order to detect other LEL terms that have been defined as classes.
TEAM
FLY
Enhancing RUP Business Model with Client-Oriented Requirements Models 99
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written In this case, an association relationship is determined between the classes. Cardinality of the associations can be deduced starting from the LEL notions that mention the association. The following sub-heuristics consider the different types of relationships:
HM3.1: DETERMINING INHERITANCERELATIONSHIPS
Description: In this stage, inheritance relationships reflect real relation-
ships among terms of the UofD. The notions and the impacts of each LEL term for which a class was built are analyzed. Relationships can be identified in two ways:
Figure 8: Class definition
______________________________________________________________________ Administration (HM1) Attributes Name Address Saving Plans (HM1.1) AdmissionFee (HM3.1) AllowedRejectAmount (HM4.1) MinimalCardinaltyGroup Methods - Transfer (cft) (HM2/ HM2.3) cft.applicant?.changeData(cft) self.eliminateSubscriber analizeRejectOfCar(adh) (HM4.3) If ( adh.#Reject?.<= AllowedRejectAmount) toEliminateSubscriber(adh) ... toAcceptAdmission (solAdh)
pre: today() <= solAdh.data +10 or toAcceptAdmission =true (HM5.3)
...
toEliminateSubscriber (adh) (HM2/ HM4.3)
adh.group? toEliminate (adh)
If adh.group? .#Adh? <= MinimalCardinaltyGroup
adh.group?.Savingplan? toEliminateGroup(adh.group?.) toGiveCar(grt)
pre: today() <= grt. BidDate +60 (HM4.3) ...
toFormGroup (gr)
pre:gr.subscribers->size>=gr.savingPlan. MinimalCardinaltyGroup (HM4.3)
toChangeTypeOfCar
(AuthenticComunication.new) notify (self, group,”changeCar“) (HM4.3) ...
100 Leonardi
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
•
In the notion of the LEL terms, it is suggested explicitly that this term is a specialization / generalization of another LEL term. This concept is generally expressed as a linguistic pattern identified by Juristo (Juristo et al., 1998) as bottom-up verbs and top-down verbs: “to be, to be a type, to be a class, it can be.” Other types of verbs can be “to specialize, to generalize or to refine.”•
Similar behavioral responses appear in different LEL terms suggesting a common behavior that can be modeled as an inheritance relationship. However, this is not common. Through the “closure principle,” engineers model explicitly the relationships between the two LEL terms, obviating in consequence, the repetition of impacts.HM3.2: DEFINING PART-OFRELATIONSHIPS
Description: This relationship is identified if reference “that the class is
formed by other classes” appears explicitly in the notions of the LEL term that is considered the container. These notions contain verbs of the type “component_composition_verb” (Juristo et al., 1998): “to consist / to con- tain / to have / to possess / to include / to form, to compose, to divide” (these three last in passive voice). Likewise, the notions of the “component” term must suggest that the component is involved in the “part-of” relationship, which is identified with the content_composition_verb (Juristo et al., 1998): “it is part, it belongs, it is a component, it is included,” among others. Behavioral responses of the LEL term of the container class are analyzed in order to determine if the class participates in the creation or destruction of the components. It is difficult to detect the type of composition (shared aggregation or simple aggregation vs. not shared aggregation or composi- tion), following the UML terminology, since the semantics of this relation- ship is still under discussion (Henderson Sellers & Barbier, 1999). In this sense, only dependence of existence can be deduced from the notions and impacts or in the related business use cases. This determines if the life of the LEL term that corresponds to the component class is bound to the life of the class that contains it.
HM3.3:DETERMINING ASSOCIATION RELATIONSHIPS
Description: Determining association relationships can be accomplished by
analyzing the collaborations among the classes. Any collaboration among classes that does not represent a relationship of the previous type repre- sents an association. The verb that figures in the responsibility (categorized as general verb) in Juristo et al. (1998) determines the name for the relation- ship.
Example: Starting from the LEL terms of Figure 2 , the following analysis can
be carried out: in the first notion of Subscriber, the bottom-up/top-down verb “is” appears connecting the subscriber class with an Applicant via inheritance relationship (HM3.1). The second notion has the verb “to belong” of the type content-composition-verb. In the same way found in the
Enhancing RUP Business Model with Client-Oriented Requirements Models 101
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written LEL term group, the first notion suggests a composition relationship. This indicates a composition relationship between Group and Adherent (HM3.2).
•
HM4: APPLYING NON-FUNCTIONALRULEMODELTO THEOBJECT DIAGRAMDescription: The Macrosystem, non-functional rules model introduces modifica-
tions in the object diagrams in order to reflect the non-functional business rules that affect the structure and behavior of the organization. The aim of the incorpo- ration of these rules in the business object model is the identification of the components, and more concretely, the methods, attributes, classes, and relation- ships among classes that are affected by each rule. Rules may be expressed using the OCL (Warner & Kleppe, 1999). Taking into account that the rules are anchored to the LEL by the use of the LEL symbols, (from an object-oriented point of view), rules will affect classes, attributes, or responsibilities that arise from the LEL symbols that appear in the original rules. Quality rules will be applied further, during the software limits definition, which is out of the scope of this chapter.
HM4.1: TOANALYZERULESTHATAFFECT ACLASS
Description: The rule can affect the class as a whole or the attributes of
the class:
•
In the first situation, the only characteristic of the class that can be affected is cardinality, since any other characteristic would imply an attribute, class, or method. This is not a frequent situation. Cardinality may be expressed in OCL with the method size of collection. (className.size -> quantity of instances of the class).•
If the rule affects an attribute, it is marked in the class as an invariant. Responsibilities implicit in the rule or related to a functional rule should be sought. In this case, sub-heuristic HM4.3 will be applied.Example: The business rule “ ...A subscriber can reject the car up to
three times ...” is expressed in the same way: Context : Subscriber
#Rejections <= 3
This restriction may be enhanced by adding an attribute in the Administra- tion class, (AllowedRejectAmount=3), therefore any change in the particu- lar value affects only the class Administration and the rest of the classes use this attribute.
Context : Subscriber
#Rejections <= Administration. AllowedRejectAmount
HM4.2: ANALYZING RULESTHATAFFECT SEVERALCLASSES
Description: Rule may affect the classes as a whole or the attributes of the
classes.
•
In the first case, rule affects the cardinality of some type of relationship between the two classes (composition or association). These relation-102 Leonardi
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
ships were previously generated. If this is not the case, it should be added. Cardinality restriction is indicated in the relationship.
•
If the rule affects the attributes, it can be modeled as an OCL expressionover the corresponding attributes.
Example: The rule “...The quantity of members of a group doubles the
quantity of installments of the elected plan...” determines the minimum quantity of Subscribers of a Group. This may be expressed in the following way:
context: SavingPlan
minimalGroupSize := self.#installment * 2 context: Group
(Subscribers.size + Grantee.size) >= SavingPlan.minimalGroupSize
HM4.3: ANALYZING RULESTHATAFFECT METHODS
Description: If the rule has associated some class responsibility, the
methods associated to the rule should be sought. In each method, pre- and post- conditions are added to reflect the rule. Whether it is necessary to add an attribute into the class that contains the method should be analyzed.
Example: Continuing with the example of the sub-heuristic HM5.1, the rule
“...If the subscriber rejects the car three times the Administration expel him of the Group...” indicates the behavior associated with the rejection. It is indicated in the corresponding method.
Subscriber: toRejectCar
post= pre@#reject = 3 implies subscriber.Group -> includes (subscriber) =
false