v

Previous column

Next article


How to align IT with the changes using UML and according to BMM1?

Applying the “Goal Driven Development” Process on a case study using UML 2 and the BMM

Birol Berkem, GOObiz / CNAM, Paris - France

space COLUMN

PDF Icon
PDF Version

Abstract

In the previous articles that I wrote for JOT in 2005 and 2003, I presented the ‘Goal-Driven Development Process’ and its patterns that aim at increasing the business reactivity of the companies in face of changes. In this article, this methodology is presented using a case study and according to BMM ( The Business Motivation Model - voted by the OMG in September 2005).

As you know, use case driven and object-oriented development processes are widely used in organisations for building their IT systems. This practice allows stakeholders to concentrate their requirements management efforts as well as analysis and design efforts on the usage choices of the systems.

However, IT systems developed only with use-case driven and object-oriented development methodologies do not provide their organisations with good levels of reactivity in face of changes. This is because these systems are not structured on the basis of business goals and underlying rules & policies that support the achievement of these goals, so they are unable to capture changes on the business needs and propagate them coherently toward IT applications [Align-IT].

In order to show in practice how to develop IT applications on the basis of company’s goals then align these applications with the changing business rules and policies, we present below steps of the Goal-Driven Development Process on a case study using the Enterprise Architect (EA), a UML 2 compliant case tool.


1 INTRODUCTION

For the last few years, organisations have tried to develop their software systems with use case driven and object-oriented development processes. This practice does not allow them to react to changes swiftly and coherently for two main reasons : in use case driven development

  • business rules are not rendered identifiable as they are often tightly coupled (mixed) with actor/system interactions in use cases that invoke their behaviours,
  • business rules, processes and their IT implementations are not aligned with company’s goals in order to allow IT applications to be adapted with good levels of reactivity in face of changes

In order to allow organisations to increase their business reactivity, a Goal-Driven Development Process becomes necessary for modelling company’s goals, use cases (usage goals of their “end-users”) that have to invoke courses of action that support these goals as well as business rules and policies that guide the business in getting there.

The Business Motivation Model Diagram [BMM] referenced in the figure 1 below shows such relationships for the Business Governance in a Volatile World. Its basic elements that are considered as primary by the Goal-Driven Development Process [Goobiz] are indicated using dashed circles. As shown in the figure, goals as part of the ends drive courses of actions, directives (rules and policies) and processes.

Steps of the Goal-Driven Development below explain how to instantiate such a chain till IT components in order to align IT applications with the changes.

Figure 1: The Business Motivation Model for a Business Governance in a Volatile World [BMM] of the Business Rules Group voted by the OMG in September 2005

According to these elements of the Business Motivation Model and their relationships (indicated using dashed circles from left to right), the Goal-Driven Development Process (GDDP) allows stakeholders to:

  • discover use cases that are tailored on the requirements according to business goals (indicated as parts of the desired results on the left)
  • establish a bridge between goals and IT architectures that carry out implementations of their courses of actions and directives using object components
  • trace impacts of the changes captured on requirements till their software implementation level in order to improve agility of their organisations to react to changes

The next section shows steps of the Goal-Driven Development Process that accompany software implementation of the business requirements captured on the basis of goals throughout courses of actions and business rules & policies that govern them. These steps are explained on examples of solutions for a case study where one of the high-level goals of the company is fixed to be “turning its internet visitors into buyers”.

2 STEPS OF THE PROCESS

The Goal-Driven Development Process (GDDP) using UML is constituted of six main steps. An insight of these generic steps is presented below.

Figure 2: Steps of the «Goal-Driven Development» Process with UML

Roles of these steps are as follows:

Step 1 focuses on grouping requirements by goals, setting objectives that quantify them as well as modelling goals and use cases that invoke them.

Step 2 is interested on showing courses of action that support the previous desired results as well as business rules and policies that govern these courses of action

Step 3 (optional step) set up rules for giving feed-backs to managers for allowing them to monitor advancement in achieving these goals

Step 4 focuses on business processes that describe possible realisations of these courses of action by assigning responsibilities to their participants and system components

Step 5 transforms these goals and rules based specifications in executable software components and plug-in them into the backbone of the goal-driven business process architecture

Step 6 integrate application choices of the IT actors in realising their responsibility according to previous business processes (this step is not covered by the case study)

The examples given below show an application of these steps using the Enterprise Architect (EA) UML tool.

Step 1 Grouping requirements by goals and showing goal cases of the system

In this first step, we enter requirements in the system by grouping them according to company’s goals (Step 1.1) then model them inside high-level goals of the company (Step 1.2).

Step 1.1 Grouping requirements by goals

For assisting non-technical business experts in capturing changes that arise in the business system and propagating them within the business layer of the organization in order to align its underlying structures, requirements have to be grouped using identifiable goal structures (goal cases).

A goal case is a set of requirements (behaviours for the system) that belong to (or support) a given goal. Goal cases are described by grouping courses of actions (behaviours of the system) that support a given goal. They also constitute the essence of use cases as they make sense to actor / system interactions that permit to realise a business goal.

The figure 3 below illustrates high-level goals and their underlying parts as well as requirements (business rules and policies) that have to support their achievement for making the company website system beneficial by turning its visitors into buyers.

Figure 3: Business rules and policies are first grouped using goals in order to determine business goal cases

In the next step, we model these goal cases and discover eventually their possible participants (actors) and use cases that have to participate to their realisation. Notice that potential participants and use cases that have to participate to the realisation of goal cases may also be found in the step 4 of the GDDP that focuses on the potential realisation scenarios for achieving business goals.

Step 1.2 Model Goal Cases then discover potential actors and use cases

In order to confer coherent and swift evolution to the desired results till their IT implementation, previous requirements captured by goals must be rendered visible. Such a visibility of the goals requires from them to be identified separately (without being mixed with usage choices of their actors). In this perspective, we model them using business goal cases.

The figure 4 shows high-level goals of the business system (represented via boundaries) with their underlying goal cases based on the previous requirements. Such goal boundaries allow business goal cases with their supporting business rules and policies (included inside them) to evolve coherently in respect to these higher-level goals in face of changes.

Figure 4: A draft of the architecture of the high-level business goals and goal cases for the “Beneficial website system”

On the basis of these specifications, components of use cases (indicated in yellow in the figure 5 below) are determined to represent corresponding goals of the participants (actors) in using these business goal cases. These actor’ goals have, in turn, to be supported by courses of actions related to actor / system interactions that are necessary for realising business goal cases (see step 4.2).

Figure 5: A draft of the desired results (goal cases) and corresponding actor’s usage intentions (use cases) for the “Website system”

Step 2 Formalise behaviours (courses of actions with appropriate business rules and policies) then draft the «architectural backbone» of the system

This step allows us to formalise courses of actions that channel efforts toward supporting the previous business goal cases. Along these courses of action, business rules and policies are formalised between and within actions.

We describe in figure 6 courses of actions that realise business goal cases defined in the previous step. In order to keep traceability with high-level goals of the system, courses of actions that support business goal cases are described within the same goals.

These courses of actions are illustrated below using UML activity stereotypes, control flows, conditions, etc…

Figure 6: Cartography of courses of actions and business rules / policies that support desired results for the ‘Website System’

At this stage, the cartography of courses of actions enriched by the rules and policies may be used as a basis to generate components of the architectural backbone of the system in order to early test its high-level behaviours. The resulting architecture would provide us with the components and rules illustrated in figure 9, except behaviours of the system related to the communication with its participants discovered next in step 4.

Step 3 (Optional step) Set up rules to monitor advancement in achieving goals

This optional step allows stakeholders to set up rules for providing them with feed-backs in order to monitor advancement in achieving previously defined business goals. In order to help stakeholders for setting up these rules, an initial structure of the high-level architectural backbone of the system may be used here in order to early prototype the above specifications.

Step 4 Describe business processes that have to realise courses of actions by assigning responsibilities to their participants and system components

In this step, we focus on the business processes that have to describe possible realisations (scenarios) of the previous courses of actions, being governed by the business rules and policies.

In order to describe precisely realisation scenarios for these courses of action, responsibilities must be assigned to the participants of the business goal cases as well as to related system components (from user interfaces till business objects-entities). Thus, we describe such realisation scenarios using two refinement levels. The step 4.1 presents high-level descriptions of these realisation scenarios that aim at ensuring communication between courses of actions described in figure 6 whereas the step 4.2 presents underlying behaviours of the use case and goal case components that have to collaborate for realising these scenarios.

Step 4.1 Model responsibilities that have to be assigned to the participants and the system for ensuring communication between courses of action

The figure 7 below illustrates a realisation scenario that describes responsibilities assigned to the participants and to the system for ensuring communication between courses of action specified in figure 6. Communications between courses of action are modeled using control flows or object flows (when objects have to be produced by an action and consumed by another action).

For example, according to the business rule R1.2.1.a , if the abandon rate of visitors is over than 50% while consulting products, the system produces an object flow toward the Marketing_Mgr in order to incite him/her to review presentation of the products.

The assignment of the responsibility about reviewing products to the Marketing_Mgr is illustrated by setting his state to Marketing_Mgr [Prod_Review] when the previous condition becomes true.

Thus, the Marketing_Mgr switches to the state Prod_Review (review of the product) at the end of the process Consult Products then this new state causes starting of the target process Review Product Presentation.

Figure 7: Description of the responsibilities assigned to the participants and the system for realising courses of action

Step 4.2 Model underlying behaviours of the use case and goal case components for realising the previous scenarios

In this step, we describe underlying scenarios for the actions of the previous processes that require actor / system interactions for their realisation. The resulting actions are distributed as actions for underlying use case and goal case components depending on their nature (controls for the user interface objects or for the business entity objects, etc).

The below activity diagram illustrates a realisation scenario for the action Enter Visitor of the process Register Visitor (by clicking on its icon illustrated in figure 7). Actions of the underlying use case and goal case components - that respectively handle user interface objects (on the left) and entity objects (on the right) are described within corresponding partitions. The final photos that are desired in term of state changes such as [created], [validated], [linked to visitor], [sent], etc.. are illustrated under these objects in order to guide developers about states that must be reached by these objects in the related actions. These states are indicated as comments in the generated source code (see figure 11) for helping developers in implementing corresponding methods.

Figure 8: Behavioral description of the components of use cases and goal cases that realise the action Enter Visitor of the business process Register Visitor

Step 4.3 Draft the architectural backbone of the system using use case and goal case components

In this stage, a second draft of the goal-driven architectural backbone of the system may be generated for early testing system behaviours. Use case (UC) and goal case (GC) components of the system are specified with their interfaces. These components have to host software level behaviours related to business rules, actor/system interactions, etc that will be transformed into object-oriented specifications in the following step based on the above. The figure 9 below shows such an initial structure of the architectural backbone with its use case and goal case components and responsibilities assigned to participants.

Figure 9: The Goal-Driven Architectural Backbone of the WebSite System with its basic components

Step 5 Plug-in the business behaviours into the architectural backbone and play

This step requires transformation of the use cases and goal cases behaviours -described in figure 8- using object-oriented specifications such as classes, attributes, methods, constraints of pre/post conditions, etc… in order to plug-in them finally into their parent components in the architectural backbone.

Step 5.1 Transform functional representations of the specifications into their object-oriented representations

In order to be plugged into the architectural backbone of the system, the above specifications that are related to user interfaces, use cases, goal cases and entity objects are transformed into their corresponding object oriented specifications. In this perspective, conditions and actions described for use case and goal case components (of the figure 8) are respectively transformed for giving corresponding attributes and methods as well as for specifying pre-conditions of these methods (figure 10 below).

The below class diagram shows description of the business use case (BUC) and goal case (BGC) classes for Visitor_Entry on the basis of the previous specifications (figure 8) with the user interfaces (UI) and entity objects (Data Model) they have to handle.

Figure 10: Internal structure of the components of Use Cases and Goal Cases to be plugged into the architectural backbone of the system

The underlying behaviours of these actions (user interface and entity object handling, etc) that are expressed using specifications (such as conditions, final states for objects) are also transformed into O.O specifications. Such an early transformation permits to prototype specifications of the business experts and to guide designers to complete them by technical aspects for their unit and integration tests. The print screen of the figure 11 below shows correspondence between actions specified for the component of goal case Visitor_Entry and their corresponding method body in the Java code on the right. This is just an initial ‘mono user’ version of the code that is elaborated for early testing these actions. For a final multi-user version, method declarations have to be setting up as non-static and components of use case and goal case of the figure 10 have to be instantiated.

Figure 11: Transformation in Java of the courses of actions for Enter_Visitor

5.2 Plug-in the use case and goal case behaviours into the architectural backbone

After their unit testing, use case and goal case components are plugged into appropriate structures of the architectural backbone of the system for their integration test with the other components of the system.The figure below illustrates the plug-in of the previous components into the system architecture using a simple “plug and play” mechanism.

Figure 12: Components of use cases and goal cases are plugged into their appropriate parent components within the goal-driven architectural backbone of the system

Thanks to its goal-driven and component based architecture backbone that allows traceability of the requirements (business rules, policies) captured on the goal basis till their implementation level, the Goal-Driven Development Process makes easier adaptation of these components to the changes. Indeed, changes captured on the business rules and policies using the goal-driven development framework are propagated till their lower-level courses of actions that in turn are implemented by underlying use case and goal case components.

3 CONCLUSION

Solutions presented for implementing business rules given at the figure 3 illustrate how to specify these rules step by step on the basis of company’s goals using the Goal-Driven Development Process [Align-IT] and according to the Business Motivation Model [BMM] in order to align IT applications with changes captured on these business rules.

Thanks to the separation [Visibility of the Rules] of the business goals from their usage scenarios (use cases) and to its architecture based on goal-oriented object components, the «Goal-Driven Development» process provides its users with means that allow them to adapt their IT applications to the changes swiftly and coherently [GDDP4MDA].

By carrying these principles at the organisational level, the infrastructure of the GDDP [Goobiz] helps organisations to enhance continuously their business processes in order to increase their business reactivity without worrying about alignment of their IT applications.

Copyright © 2005 - 2006 Goobiz.com - Birol Berkem

Footnote:

1 The Business Motivation Model [BMM] - Business Governance on a Volatile World voted by the OMG in September 2005


REFERENCES

[BMM]: Business Motivation Model - Business governance in a volatile world of the Business Rules Group voted by the OMG in September 2005 http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf

[Visibility of the Rules]: Stan Hendryx - Business Rules - BPTrends / BPT http://www.businessprocesstrends.com/publicationfiles/Hendryx%2Epdf, October 2004

[Semantic Web]: John Hall , How will the Semantic Web support business? - W3C Workshop on Rule Languages for Interoperability http://www.w3.org/2004/12/rules-ws/paper/127, April 2005

[GDDP4MDA]: Birol Berkem, Goal Driven Development for MDA – OMG’s Technical Meeting in Athens http://www.omg.org/cgi-bin/doc?omg/2005-04-05, April 2005

[Align-IT]: Birol Berkem, Aligning IT with the Changes using the Goal-Driven Development for UML and MDA - Journal of Object Technology, vol. 4, no. 5, July-August 2005 http://www.jot.fm/issues/issue_2005_07/column5

[Goobiz]: How to increase your business reactivity with UML and MDA? (White paper on the Goal-Driven Development Patterns and Processes) http://www.goobiz.com/GOObizWP/GOObizWP.htm

About the author





Birol Berkem is a consultant and trainer in the areas of business and application system analysis and design with the object technology. He is the author of the “Goal-Driven Development” patterns and frameworks for aligning IT with the changes using UML and MDA. His e-mail address is birol.berkem@goobiz.com


Cite this article as follows:Birol Berkem: “How to align IT with the Changes using UML and according to BMM”, in Journal of Object Technology, vol. 5, no. 2, March-April 2006, pp. 85-102 http://www.jot.fm/issues/issues 2006_03/column9


Previous column

Next article