Modeling the Trace Relationships: A Trace View

Following a similar philosophy as used in the configuration view (Leite & Oliveira,1995), the strategy defines a trace view to reflect the relationships among the classes of Figure 10 generated by the application of the heuristics. Figure 13 defines the trace view.

An instance of a trace view relates instances of the classes presented in Figure 10 that are generated by the relationships between the classes as a result of the heuristics. These relationships are formally defined using the navigational context concept presented in the object-oriented hypermedia development methodology proposed by (Rossi, 1996). A navigational context is a group of nodes that are related with some criteria (in this strategy a trace relationship) that can be navigated in a certain way. In this strategy, classes of Figure 10 are the nodes that will be navigated through the trace views. The navigational context returns a group (sometimes unitary) of components that fulfills the condition defined in the context for the input parameter. This group of

Figure 13: Trace view

Trace View:

Name: Indicates the semantics of the relationship mentioned in Figures 11 and 12.

Justification: Explains the reason of that relationship, i.e., the heuristic that generated the trace relationship.

Responsible: Indicates the author of the application of the heuristic.

Origin: Identifies instance of any class of Figure 10 that generates the relationship; also, input parameter of the navigational context.

Destination: Identifies instance of any class of Figure 10. (Note: it always retrieves the container class of the involved class, for example if a trace relationship relates an impact and a responsibility, Destination retrieves the candidate class that contains the responsibility.)

Cardinalityof Destination: Reflects quantity of instances generated

TEAM

FLY

Enhancing RUP Business Model with Client-Oriented Requirements Models 109

Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written components corresponds to the attribute destination of the trace view (Figure 13) . The syntax of a navigational /context is defined as:

Trace_n: Context _name (input parameter) = { output parameter class / conditional sentence }

where:

•

n indicates the trace number indicated in Figure 10.

•

Name is the name of the semantics expressed in Figures 11 and 12.

•

The input parameter determines the instance of a class that generates the relationship.

•

The output parameter class indicates the class that the retrieved instances belong to.

•

The conditional sentence represents the different trace conditions that instances must satisfy with respect to the input parameter.

The variables used in the definition of the navigational context are: • t is an instance of the LEL class.

• crc is an instance of the candidateClass(CRC) class. • i is an instance of the Impact class.

• buc is an instance of the BUC class. • fr is an instance of the RF class.

• r is an instance of the Responsibility class. • n it is an instance of the Notion class. • rnfc is an instance of the RCal class. • rnfm it is an instance of the RMac class. • at is an instance of the Attribute class.

We exemplify some of the forward navigational contexts generated by the relationships detailed in Figures 11 and 12. The examples are instances of the ViewTrace.

•

Trace1: Context mandatory modeling (t) = {crc / t.clasification= Subject AND

mandatory modeling (t,crc)}

This context retrieves all the primary classes. Figure 14 shows two instances of the trace view for this context. The first context is evaluated for the LEL term, t = Subscriber, retrieving the class originated through the heuristic HC1. The same situation Figure 14: Instances of trace view created by HC1

Trace:

Name: mandatory modeling Justification: HC1

Source: Subscriber LEL Destination: Subscriber CRC Cardinality: 1

Trace:

Name: mandatory modeling Justification: HC1

Source: Administration LEL

Destination: Administration CRC

110 Leonardi

happens for the second instance of the example that shows the relationship among the term t = administration and its corresponding class.

•

Trace2: Context optionally modeling (t) = {crc / res Responsibility, t.clasification = Verbal Phrase, part-of (crc, res) AND optionally modeling (t,Res)}

This context retrieves the classes that possess responsibilities that are LEL terms. Figure 15 shows two instances generated by the heuristic HC2. The first instance is the result of applying the context for the LEL term, t = Reject Subscriber that became a responsibility of the Administration class. The second instance corresponds to the application of the context for t = to Reject Car related to Subscriber class, with the responsibility generated by the term.

Figure 15: Instances of trace view created by HC2 Trace:

Name: optional modeling Justification: HC2

Source: to Expel Subscriber LEL Destination: Administration class

(responsibility: toExpelSubscriber) Cardinality: 1

Trace:

Name: optional modeling Justification: HC2

Source: to Reject Car LEL

Destination: Subscriber Class

(responsibility: toRejectCar)

Cardinality: 1

•

Trace 5: Context appears in context (buc) = { crc/ crc CRC, res Responsibility part-of (crc, res) AND res context includes (buc)}

The method context of responsibility class analyzes if the responsibility contains the business use case, according to the extended CRC notation (see Figure 7).

Given a business use case, this context retrieves all classes that have responsibilities that appear in it. Figure 16 shows an example, For buc = “to Pay due Monthly Installment” the context returns a group of classes indicated in destination = {Sub- scriber, Administration...} since they have responsibilities that appear in this business use case.

Figure 16: Instances of trace view created by HC5 Trace:

Name: appears in context Justification: HC5

Source: to Pay due Monthly Installment BUC

Destination: { subscriber class (resp: to pay due installment )

Administration class (resp: to get paid due installment ) ... }

Enhancing RUP Business Model with Client-Oriented Requirements Models 111

•

Trace 9: Context optionally modeling (t) = {cl / t.clasification = Object, cl ConceptualClass, at Attribute, part-of (cl, at) AND optionally modeling (t, at) } This context returns all the classes that possess attributes that are LEL terms. Figure 17 shows examples. The first instance shows the attribute, monthly installment Fee of class Saving Plan, which was generated starting from the LEL term, t = monthly installment applying the HM1.2. The second instance shows how the term, t = admission installment, becomes an attribute of the Administration class.

Figure 17: Instances created by HM1.2 Trace:

Name: optional modeling Justification: HM1.2

Source: monthly installment LEL

Destination: Saving Plan Class (attribute: monthyInstallment)

Cardinality: 1

Trace:

Name: optional modeling Justification: HM1.2

Source: admission installment LEL

Destination: Administration Class (attribute: admissionFee)

Cardinality: 1

Figure 18: Instances of trace view created by HC2 and HC4 Trace:

Name: optionally modeling

In document UML and the Unified Process fly pdf (Page 121-124)