INTRODUCTION
Rational unified process (RUP) (Jacobson, Booch, & Rumbaugh, 1999) is an iterative, incremental and use case driven methodology. RUP starts the software development with the requirements capture stage, taking into account that “the major challenge is that the customer, who we assume to be primarily a non-computer specialist, must be able to read and understand the result of requirements capture. To meet this challenge we must use the language of the customer to describe these results” (Jacobson et al., 1999, p. 113). As requirements are originated from the system’s context, RUP proposes the definition of it through a business model, more concretely, a business use cases model and a business objects model. There are several approaches to enhance this first stage of the RUP development. In this article, the author describes the most important proposals and briefly presents her strategy that defines a set of activities and heuristics to define a UML conceptual object model starting from stakeholder oriented requirements models. These models describe the overall context in which the software will be developed and operated, known as universe of discourse (Leite & Leonardi, 1998). The strategy enhances traceability (Pinheiro, 2000) between requirements and RUP models.
BACKGROUND: BUSINESS MODELING IN THE CONTEXT OF RUP
As mentioned earlier, RUP proposes a business model to define the organization without defining any explicit techniques or strategy to guide the construction of it. There are some works that present different proposals to enhance this stage, taking into account different starting points and perspectives. In this section, the author briefly describes the most important.
From the RUP/UML and business technology community, there are some proposals to model the organization. The work of Eriksson and Penker (2000) presents a combination of techniques to model the business with UML organization models representing processes,events, resources, goals, business rules and general mechanisms. The business architecture and its elements are represented from four different views: business view, business process, business structure and business behavior. They propose a set of UML business extensions to represent those concepts using the standard UML extension mechanisms. The authors propose three categories of business patterns to describe common modeling solutions during the business modeling: resource and rules patterns, process patterns and goals patterns. In Barros, Duddy, Lawley, Milosevic, Raymond, and Wood (2000), an interesting proposal is presented extending UML in order to define the organizational enterprise model for systems that will be implemented using distributed objects technology. This model is described in terms of processes, entities, lists and events of the business. Finally, in Marshall (1999), some key concepts of an enterprise and their components are modeling. Specifically, they define the purpose, processes, entities and organization of the enterprise with standard UML diagrams.
From the requirement community, one of the most important works is Santander and Castro (2002). This strategy allows the definition of use cases starting from the i* organizational model. This strategy captures organizational requirements to define how the system fulfills the organization goals, why it is necessary, what the possible alternatives are and what the implications to the involved parts are, all of them represented by the two i* models. The approach presents some guidelines to develop use cases from these models. This approach is a goal-based methodology useful for RUP software requirements definition phase since it generates use cases for the software system.
Although it is not directly related to RUP business modeling, one of the most important works in generating conceptual object-oriented specifications from natural language is the strategy presented in Juristo, Moreno, and Lopez (2000). This strategy consists of analyzing natural language-based descriptions (expressing the problem to be solved) from a syntactic and semantic perspective in order to identify the key elements of the object-oriented conceptual model (modeling the problem in the computer). The proposal is a semi-formal model that lets organizations systematically produce object-oriented models. It is based on two components: a mathematical component that defines formal rules to identify the elements of the object-oriented conceptual models from the natural language structures; and a method that guides the analyst in the development of such models, by means of the definition of a set of defined steps.
A CONSTRUCTION PROCESS OF THE RUP BUSINESS MODEL BASED ON STAKEHOLDER-ORIENTED REQUIREMENTS MODELS
During the early stages of development, when the interaction with the stakeholders is crucial, the use of natural language-oriented requirements engineering techniques seems necessary in order to enhance communication. These techniques are very useful to obtain a first specification of the universe of discourse that will be easily validated with the stakeholders and will be the basis for a development. Therefore, the necessity of integrating stakeholder-oriented requirements models and strategies to enhance the construction process of the business model keeping the RUP philosophy of using the customer language is highlighted. Stakeholder-oriented models are based on natural language, therefore the communication between engineers and stakeholders are facilitated. The author presents a strategy based on heuristics that guide the construction of the RUP starting from the stakeholders-oriented requirements models. Due to space reason, the author does not present the full strategy, which may be found in Leonardi (2003). The section is organized in three subsections: one to present the stakeholder-based models, the second presents the construction process and finally, in the third, its use is discussed.
Stakeholder-Oriented Requirements Models
The models presented in this section are well-known, used and accepted by the requirements engineering community (Leite et al., 1997; Leite & Leonardi, 1998). In this proposal, they are used as the first models to obtain a RUP business object model. The models are: language extended lexicon model, scenario model and business rules models.
• Language Extended Lexicon: The language extended lexicon (LEL) (Leite et al., 1997) is a structure that allows the representation of significant terms of the universe of discourse. The purpose of the lexicon is to help understand the vocabulary and its semantics, leaving the comprehension of the problem for a next step. It unifies the language allowing communication with the stakeholder. LEL is composed of a set of symbols with the following structure: symbol name ” word or phrase and set of synonyms; notions defining the denotation of the symbol; and behavioral responses describing the symbol connotation. In the description of the symbols, two rules must be followed simultaneously: the “closure principle” that encourages the use of LEL symbols in other LEL symbols forming a graph, and the “minimum vocabulary principle” where the use of symbols external to the application language is minimized. LEL terms define objects, subjects, verbal phrase and states. Figure 1 shows the heuristics to define each type of symbol.
• Scenario Model: A scenario describes situations of the universe of discourse (Leite et al., 1997). A scenario uses natural language as its basic representation, and it is connected to LEL. Figure 2 describes the components. In Leite, Hadad, Doorn, and Kaplan (2000), the scenario construction process is described.
Figure 1. Heuristics to represent LEL terms
| Subject | Notions: who the subject is. |
| Behavioral responses: register actions executed by the subject. | |
| Object | Notions: define the object and identify other objects with which the former has a relationship. |
| Behavioral responses: describe the actions that may be applied to this object. | |
| Verb | Notions: describe who executes the action, when it happens, and procedures involved in the action. |
| Behavioral responses: describe the constraints on the happening of an action, which are the actions triggered in the environment and new situations that appear as consequence. | |
| State | Notions: what it means and the actions which triggered the state. |
| Behavioral responses: describe situations and actions related to it. |
Business Rule Model: We define business rules as statements about the enterprise’s way of doing business, reflecting business policies (Leite & Leonardi, 1998). Organizations have policies in order to: satisfy the business objectives, satisfy customers, make good use of resources, and conform to laws or general business conventions. The business rule model distinguishes between functional rules and non-functional rules. Functional rules are general policies regarding organization functionality. Non-functional rules are divided in macrosystem rules that describe policies that constrain the behavior and structure of the organization and quality rules that are demands of the organization on the characteristics of its processes or products. Rules are built following some syntax patterns, in which the main components must be a LEL symbol. In Leonardi, Leite, and Rossi (1998), the authors describe the construction process.
THE CONSTRUCTION PROCESS OF THE RUP BUSINESS MODEL
Once the models are constructed and validated with the stakeholders, they have to be manipulated in order to be mapped to a RUP business model, more concretely a business use case model and a business object model. The strategy is organized in four stages, defining for each one a set of heuristics that guide the definition of the different models enhancing traceability. The stages are:
• Business Use Cases Model Definition: The business use case starting from the scenario model is described; each scenario will be a business use case. As there is a well-defined process for the scenario construction, the use cases obtained are a representative and validated group defining the behavior of the main actors of the organization.
Business Classes Identification and Definition:
The proposed heuristics in this stage guide the identification of the classes starting from the LEL symbols, taking into account the taxonomy of these symbols in order to define them as classes or responsibilities (see Figure 1). It is important to remark that when the universe of discourse is analyzed, active and passive entities can be distinguished. This distinction is reflected in the classification as actor or resource considered in the scenario model and as object or subject considered in the LEL. As business classes define the universe of discourse, they will have the same distinction. Therefore, primary and secondary classes can be considered. Although from the object-oriented paradigm there is no distinction between the kind of objects, heuristics, to define them, are different because inside the universe of discourse, they have different semantics; the primary classes are those that represent active entities, and the secondary classes are the ones that represent passive or resources entities. Therefore, we propose different heuristics for defining them: primary classes are defined from the subject LEL terms and some of the verbal phrase LEL terms; and secondary classes are derived principally from object LEL terms. Responsibilities of the classes are defined taking into account the behavioral responses of the corresponding LEL terms. As each business use case is a detailed description of a particular situation, it is used to complete the responsibilities and collaborations between the classes that appear in it as LEL terms. This is possible due to the traceability between LEL terms and classes. Finally, the functional business rules model is utilized to add more responsibilities to the defined classes or to create new ones if the relevance of a set of related business rules justifies the creation of a new class to represent them.
Figure 2. Components of scenario
Title: identifies a scenario.
Objective: describes the purpose of the scenario.
Context: defines geographical and temporal locations and preconditions. Resources: identify passive entities with which actors work. Actors: detail entities actively involved in the scenario.
Set of episodes: each episode represents an action performed by actors using resources.
Note: Notions of constraint and exception are added to some of the components of a scenario: a constraint refers to non-functional requirements and may be applied to context, resources or episodes. An exception, applied to episodes, causes serious disruptions in the scenario, asking for a different set of actions which may be described separately as an exception scenario.
• Business Object Diagram Definition: Once the classes and their responsibilities have been identified, structural aspects of the classes are modeled (methods, attributes, relationships) defining a UML object diagram. Attributes are defined taking into account the notions of the corresponding LEL terms. Methods are derived from the previously defined responsibilities; the heuristics consider the possibility of split responsibilities in several methods or group some of them into a single method, with the aim of enhancing the quality of the interface of the defined classes. LEL terms corresponding to the defined classes are analyzed in order to define inheritance, part-of and associations relationships between them. A set of heuristics is also defined to attach non-functional rules to the involved class. Rules are modeled as OCL expressions (Warmer & Kleppe, 2003) associated to methods, attributes or associations. The business object diagram defines the universe of discourse, and as such, it does not present software limits, leaving this task for the analysis stage where the actors of the system are defined and the use cases of the software system are identified from the business use cases.
• Business Use Cases Model Realization: The next step is to describe the business use cases based on the previously defined classes. Business use cases realizations may be defined by means of interaction diagrams (collaboration or sequence) or activity diagrams. The heuristics may be used as an informal validation mechanism, because by applying them, the business use cases are “executed”, and the engineer may analyze if the defined classes and their responsibilities perform the behavior of them.
Analyzing the Use of the Strategy
The strategy was used in several case studies. From this experience, some advantages of it are mentioned:
• Natural language allows communication with stakeholders, enhancing models validation.
• LEL and business rules models allow engineer to define objects from a global perspective, enhancing the specific behavior defined in a use case.
• From the object-oriented perspective, this strategy improves the analysis phase, by the incorporation of stakeholder-oriented techniques.
• From the requirements perspective, this strategy extends the requirements capture phase to the definition of an object-oriented conceptual model that allows engineer to visualize the problem in terms of objects, the same concept that he will use in the rest of the development process. A conceptual object model is obtained that serves as a basis for RUP oriented development, reducing the gap between analysis and design phases allowing that transition between conceptual modeling and design phase results in a more natural process (Kotonya & Sommerville, 1998).
• This strategy identifies and maintains the trace relationships generated by the application of the heuristics, allowing traceability between the RUP business model and LEL, scenarios and business rules models. It also defines internal RUP models traces and internal requirements models traces. Each trace relationship links two or more model components, defining its semantics, that is, the origin component, the source, cardinality and the kind of relationship between the components.
The main difficulties found during the application of the strategy are:
• One of the most significant problems is the level of detail of the specifications. Depending on the level, more or less classes can be found. But, this problem is inherent to specifications, independent on a particular strategy.
• It is very important to deal with the redundancy between the LEL, business rules and scenarios to avoid translating it to the object model.
• As the strategy generates a lot of traceability information, it is necessary to define what trace relationships are managed, since if all of the possible links are generated, the maintaining will be tedious, time consuming and labor-intensive.
FUTURE TRENDS
Integration between business modeling, requirements engineering techniques and the rest of the software development steps are essential. It is necessary to define some strategy to guide in the translation of the requirements models to an architectural model, in order to obtain a first description of an adaptable architecture that reflects the non-functional and functional requirements. New proposals are emerging from different areas with the objective of working in the integration (STRAW, 2003). Moreover, research must be set in the context of the OMG model driven architecture (MDA, 2004), to define business models that can be used as the computer independent model (CIM) and requirements model that can be used as the platform independent model (PIM) integrated to a completely MDA software development.
CONCLUSION
In this work, the author presented a brief survey of proposals that enhance the first stage of RUP development where the RUP business model is defined through the business use cases and the business-objects models. The author also presented her strategy based on well-known and used stakeholder-oriented requirements models to define this model. This strategy is compatible with the aims of RUP of enhancing the interaction with the customer by the use of easy reading and understanding models (Jacobson, Booch, & Rumbaugh, 1999). As use cases model is the key model of RUP, our strategy has incorporated them by means of scenario representation, but it has also added complementary models to enhance the knowledge of the business organization. LEL model and the business rules model also increase the abstraction degree of object-oriented modeling, allowing engineers to define objects from a global perspective, enhancing the specific behavior defined in a use case. The strategy proposes a set of heuristics to guide in the manipulation of the great quantity of information generated by the requirements models to define the RUP business model. A trace mechanism is defined in order to enhance traceability between models.
KEY TERMS
Business Model: A model of a company that shows the company’s function in the world, what it does, how and when. It is designed to serve the needs of one or more types of handlers, and it should contain the information these handlers need ” no more and no less (Marshall,1999).
Conceptual Model: A mental model that allows understanding and simplification of the problem. The purpose of domain modeling is to contribute to an understanding of the system’s context, and thereby also to understanding of the system’s requirements as they originate from this context. The system’s internal way of solving this problem will be dealt with in the analysis, design and implementation workflows (Jacobson, Booch, & Rumbaugh, 1999).
Rational Unified Process: A use case driven, architecture-centric, iterative and incremental software development process that uses UML to describe the artifacts (Jacobson, Booch, & Rumbaugh, 1999).
Requirements: Defined during the early stages of a system development as a specification of what should be implemented. They are descriptions of how the system should behave, application domain information, constraints on the system’s operation, or specifications of a system property or attribute. Sometimes they are constraints on the development process of the system (Kotonya & Sommerville, 1998).
Requirements Traceability: The ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the traces left by those elements on requirements (Pinheiro, 2000).
Stakeholder: People or organizations who will be affected by the system and who have a direct or indirect influence on the system requirements. They include end-users of the system, managers and others involved in the organizational processes influenced by the system, engineers responsible for the system development and maintenance, customer of the organization who will use the system to provide some services, external bodies such as regulators or certification authorities (Kotonya & Sommerville, 1998).
Unified Modeling Language (UML): A standard graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system (Booch, Rumbaugh, & Jacobson, 1999).
