Previous column

Next column

---

Aligning IT with the Changes using the Goal-Driven Development for UML and MDA The Goal-Driven Development Process for increasing your business reactivity with UML and MDA Birol Berkem, GOObiz / CNAM, Paris - France

COLUMN PDF Version

Abstract

For the last few years, organisations have tried to develop their software systems with use case driven and object-oriented development processes. This practice brings some benefits by allowing them to concentrate their analysis and design efforts on the usage dimension of the system and on its architecture of domain objects.

However, modeling a system only with use case driven UML specifications - without focusing in the GOALS that have to be supported by the system – and its domain objects does not allow to organizations good levels of reactivity in face of changes (1).

Indeed, one of the main issues that we experienced about this lack of reactivity is that in use cases specifications, actor/system interactions are often tightly coupled (mixed) with business goals! In this situation, it is particularly difficult to reorganize use case descriptions in coherence when business rules evolve within these goals. On the other hand, implementing changes as a reaction to new requirements for time-to-market is still very much a challenge due to the orthogonality between functional and object-oriented representations of specifications and their absence of traceability toward the implementation layer.

Within such traceability issues, business experts, analysts, designers and developers ressort to "spaghetti oriented" development that renders the evolution of their system hazardous. In consequence, their business systems are very slow to react to changes!

In order to assist organizations for aligning IT with their changing business environment, a Goal-Driven Development Process should be considered to accompany the OMG’s MDA (2). Using such a methodology, MDA users could enable their organisations in propagating changes they capture through their business processes till their IT applications, thus synchronizing IT with their changing business rules, as a result to better capitalize on their business knowledge, independently of technological changes.

Business Reactivity: Agility offered by a business system that ensures to the corresponding organization swift and coherent adaptation to the changes of its environment.

MDA are registered trademarks of the Object Management Group (OMG) [Ref:www.omg.org].

(*) MDA and UML are both registered trademarks of the OMG (Object Management Group)

1 INTRODUCTION: ABOUT THE GAP BETWEEN BUSINESS AND APPLICATION LAYERS

One of the main factors that causes reactivity issues to IT systems in face of changes of the business rules is due to the lacks of traceability between business and application layers of the organisations. Such a gap causes important delays for adapting IT applications to changes!

As a direct impact of this gap, business analysts are not encouraged to formalize their business behaviors using appropriate business models : both business rules and their usage constraints of the applications are mixed inadvertently within application use cases.

This impacts negatively evolution of business rules and the validation process of use cases. As a result, use cases descriptions are often rendered very long, evolution of business rules they utilize become difficult!

In order to eliminate this gap, thus allowing organizations to align their IT with their changing business environment, changes have to be captured using identifiable goal¹ structures at the business layer. Their impacts have to be propagated first within the business layer for aligning underlying structures of the organisation and finally toward the application layer for synchronizing IT structures (applications, actors) with these changes.

To support such a propagation, specifications must be rendered visible and traceable by the use of goals within and between business and application layers.

The example below shows traditional requirement-gathering process by use cases in the business and application system layers. It also highlights needs for propagating changes within the business layer and toward the structures of the application system layer. An activity diagram could be used for illustrating actions that compose the Business Use Case and looking for potential use cases of the application layer. But an important problem arises: in business use cases descriptions, interactions with participants (actors, workers) are tightly coupled with business rules, so rules are hidden by use cases – Sales (Order-to-billing) in the example. As a result, business goals and underlying behaviours are not rendered visible in order to be aligned with the changes!

As a consequence of this “lack of visibility”, at the application layer, business behaviours cannot be traced to be invoked by the actors in order to synchronise applications with changing business rules.

Figure 1: Business Use cases hide rules, so that applications cannot be aligned on changes captured at the business layer

In order to propagate changes coherently within the business and application layers, specifications need to be identified and rendered executable as autonomous and traceable units on the basis of goals rather than domain objects for traceability reason! Thus, changes must be propagated first inside the business layer for aligning underlying structures of the organization. Then, use cases must invoke systematically these updated business behaviours. This is what we present in sections 2 and 3 below through the CIM² and PIM³ viewpoints (levels) of the OMG’s MDA. Finally in section 4, we zoom in automating adaptation to changes through these levels.

2 CAPTURING CHANGES WITHIN THE BUSINESS LAYER AT THE CIM AND EARLY TESTING AT THE PIM

For assisting business analysts 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) at the CIM level. 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 (behaviors of the system) that support the corresponding goal. For this reason, goal cases constitute the essence of use cases as they make sense to actor / system interactions that permit to realize a goal.

For example, the courses of actions presented in the figure below describe high-level business goals namely G1,..G6. Increase Rate of Visits (G3.1), Motivate Visitors to Register (G3.2) as well as Turning visitors into buyers (G3.3) correspond to underlying goal cases of the high-level goal case G3- Profitable Website by turning visitors into buyers.

Figure 2: Goal Cases of the system and their description (means)

Underlying goal cases that support the high-level goal case G3- WebSite [Turn Visitor into buyers] are illustrated in the figure below with other ones like Present Company and its Products on the Web (G3.1.1) and (G3.1.2).

Figure 3: Underlying goal cases of the high-level goal case G3 – Turn visitors into buyers

At the CIM level of the MDA, business experts describe realizations of goal cases using business processes. In order to increase their reactivity by early testing correct understanding of these requirements, the figure 4 shows activities of the business process that realize the goal case Register Visitor (at the left) and transformation of these activities and their guard-conditions respectively as operations and pre-conditions of a Goal-Oriented Object (GOO) at the PIM of the MDA (at the right).

Figure 4: Realization of a goal case by a business process and transformation using a GOO at the PIM

In order to test these operations, a special operation that is called the controller operation of the GOO executes them according to their preconditions and depending on the state of the system which is expressed by the attribute values of the related GOO.

In such a way, Goal-Oriented Objects aim at assisting system analysts and designers by making identifiable units of specifications to test at the PIM, thus ensuring to them good levels of traceability between functional and object-oriented representations of specifications. Such a traceability aims at reducing effort for the maintenance of the system in face of changes.

GOOs also confer easy evolutions to complex system specifications by allowing refinement and traceability of these specifications toward lower refinement levels.

In this perspective, complex operations specified at a given refinement level are considered as goal cases that have to be realised at the immediate lower refinement level. For example, in the figure below operations enter_visitor() and notify_visitor() in Visitor [Registration] are refined using underlying GOOs Visitor[Entry] and Visitor [Notification]. These goal cases have to be realized by actor/system interactions that are necessary respectively for entering and notifying the visitor.

Figure 5 : Refinement of complex activities of business processes using underlying GOOs at the PIM. Types of entity objects (the content) that are handled by the operations of the GOOs are illustrated in the bottom part of the figure.

Such PIM level components constitute an evolutive embryon of the architectural backbone of the business processes as the refinement process by goals permit to them to retain their validity independently of futur design decisions in the CIM level. So, such design decisions at the CIM couldn’t alter this architecture when they are mapped at the PIM.

3 PROPAGATING CHANGES TOWARD THE APPLICATION LAYER

In order to align IT with the changes captured at the business layer, changes must be propagated first through appropriate business components of the business layer and finally toward the application layer for allowing actors to use updated software components according to their business responsibility.

As actors of the application layer may be represented at the business layer by business actors and workers, in order to assuring traceability of specifications between business and application layers, responsibilities of these participants must be discovered first at the business layer by considering their support to the interactions between such processes as well as in the realization of their activities.

The business process cartography illustrated in figure 6 presents an overview on the interactions between business processes. For example, the responsibility for turning visitor into buyer is assigned to Sales_Manager using the UML’s object-in-state Sales_Mgr [turn to buyer] in order to ensure communication between the processes Register Visitor and Turn Visitor to buyer once visitor is entered.

Figure 6: Business process cartography with responsibilities assigned to participants

The responsibility about turning visitor into buyer assigned to the Sales_Mgr in the figure 6 may be realized at the design level of the CIM by a couple of use case and goal case components where the use case component describes actor/system interactions whereas the goal case component describes behaviours of the system as illustrated in figure 7 below.

Figure 7: The realization relationship between analysis and design level descriptions at the CIM

Similarly, activities of business processes are realized by underlying actions at the immediate refinement level.

The figure 8 shows behavioral description of use case and goal case components that realize the activity Enter Visitor of the process Register Visitor described in the process cartography of the figure 6.

Figure 8: Description of actor / system interactions for realizing the activity Enter Visitor

In order to plug these behaviours into the architectural backbone of the business process components at the PIM, goal cases and use cases components are reified using corresponding types of GOO. Operations and their pre-conditions for the use case and goal case components are discovered from the activity diagram as illustrated in the figure 9 below.

Figure 9: Operations and their pre-conditions for the use case and goal case components at the PIM are discovered from CIM level specifications provided by the activity diagram

The component diagram of the figure 10 shows the architectural backbone of the business components where the previous goal cases and use cases components are plugged.

Figure 10: Components of the architectural backbone are directly obtained from the Cartography of Business Processes (figure 6). Based on actor/system interactions, related use case and goal case behaviors are plugged into their appropriate parent components

Separate description of the goals of the system from actor/system interactions ensures for use cases the ability to focus only on actor / system interactions for realizing required goals. This way, goal cases descriptions can evolve independently of use cases and are able to guide and govern use cases to let actors of the application layer use the system for realizing “the right business goals”!

Using business behaviours at the application layer

At the application layer, according to responsibilities assigned to the participants of business processes, actors of the application system may invoke business behaviours depending on their application choices, but in respect to the constraints that have been specified at the business layer.

Application choices of the actors of the application system are specified using application goal cases that are constituted by a set of requirements that belong (or support) the goal of an actor. These choices may be applied before, during or at the end of the execution of business goal cases. For example, during his registration on the website system, the visitor may decide to look for available promotions or take a look on products of his interest.

Thus, depending on the needs, an actor may require from an application use case to invoke:

Scenario 1- One or more business processes of his/her choices without any complementary application process

Scenario 2- An application process before or after using a business process

Scenario 3- An application process during the execution of a business process

In scenario 1, the application use case of the actor invokes behaviors defined in the corresponding business use case(s). This is materialized by the “invocation” relationship between use cases in the figure 11.

In scenario 2, the application use case invokes additional behaviors from application goal cases before or after invoking those from business use case(s).

Finally, in scenario 3, the application use case and goal case specialize respectively behaviors defined in the business use case and business goal case according to their constraints of pre-condition and post-condition that have to be respected. In other terms, these application components are “conform” to their corresponding business components.

The figure below illustrates an overview on these scenarios.

Figure 11: Behaviors stored in business goal case components are invoked by the actors of the application layer depending on their choices

The next section presents a summary of the Goal-Driven Development Process that illustrates how to bridge the related UML artifacts to confer good levels of reactivity to the resulting system using the CIM, PIM and PSM levels of the MDA.

4 STEPS OF THE GOAL-DRIVEN DEVELOPMENT PROCESS FOR AUTOMATING ADAPTATION TO CHANGES THROUGH THE MDA’S CIM/PIM/PSM LEVELS

Solutions described above do help analysts and designers in rendering their system and software specifications identifiable, flexible, executable and traceable, based on the requirements of non-technical business experts.

A development process is necessary for using these solutions inside the Goal-Driven Development Process where specifications of the business experts are captured first at the CIM being grouped by business goals (step 1). Realization of these specifications are then formalized using the UML’s activity diagram at the CIM (step 2). These may be transformed at this stage for getting a preview of the architectural backbone of the system at the PIM. At the next step responsibilities of the business participants (actors and workers) while realizing activities of the process are specified at the CIM (step 4) and the resulting PIM level components are plugged to the architecture (step 5). Finally, in the last step of the process, application choices of the actors are integrated in the architecture for allowing them to invoke business behaviours via their application use cases (step 6). An overview of these steps are described schematically in the figure below.

Figure 12: An overview of the UML diagrams partitioned between the CIM, PIM and PSM levels of the MDA with the bridges required by the Goal-Driven Development Process

The Goal-Driven Development Framework shows distribution of these artefacts and bridges through the CIM/PIM/PSM levels of the MDA along the model transformation.

Figure 13: An overview of the UML diagrams partitioned between the CIM, PIM and PSM levels of the MDA with the bridges required by the Goal-Driven Development Process

The development framework allows traceability of specifications from requirement analysis (at the CIM) till implementation of related business and application behaviors on the PIM. On the basis of generic architectural layers of the PIM, it does also assist transformation of these PIM level specifications into appropriate components of the Platform Specific Model (PSM) such as Servlets/JSPs, Session and Entity Beans in J2EE, WebServices, etc...

5 CONCLUSION

Solutions presented above as part of the Goal-Driven Development Process aim at aligning IT applications with the business needs in order to guide actors of the application systems to use the system according to its business goals whatever changes that may arise on these goals, their supporting strategies as well as on the business processes that realize them.

In this direction, these solutions represent key factors for increasing reactivity of business systems developed with UML in the sprit of the OMG's Model Driven Architecture (MDA).

As a support to these solutions, the methodological framework of the Goal-Driven Development Process acts as a catalysor by ensuring traceability between related UML artifacts through the CIM, PIM, and PSM levels of the MDA, contributing so directly to the reactivity of the resulting system in face of changes.

Footnotes

¹ In the OMG's Business Motivation Model [OMG], a goal is defined as a statement about a state or condition of the enterprise to be brought or sustained through appropriate means. A goal amplifies a vision (an overall image of what the organization wants to be or become) - that is, it indicates what must be satisfied on a continuing basis to effectively attain the vision.

² CIM: Computation Independent Business Model (a specification platform dedicated to the language of non technical business experts).

³ PIM: Platform Independent Model (a specification platform dedicated to the language of the system analysts and designers) PSM: Platform Specific Model (a specification platform dedicated to the languages of the specialists of target technologic platforms)

REFERENCES

[Kend98] Elizabeth Kendall, 3 Goals and Roles http://www.ibissoft/se/events/oocontr/kendall.htm

[OMG] The business governance in a volatile world. Business Motivation Model http://www.businessrulesgroup.org/second_paper/BRG-BRMM.pdf

[MDA] http://www.omg.org/cgi-bin/doc?mda-guide

[Berk05] 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

[Berk03] Birol Berkem, “How to increase your business reactivity with UML/MDA”, in Journal of Object Technology, vol. 2, no. 6, November-December 2003 http://www.jot.fm/issues/issue_2003_11/article4

[Berk99] Birol Berkem, Traceability Management with UML - Journal Of Object Oriented Programming (JOOP), September 1999

[Goobiz] How to increase your business reactivity with UML and MDA? (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 the traceability of specifications with MDA/UML. His e-mail address is birol.berkem@goobiz.com

Cite this column as follows: Birol Berkem “Aligning IT with the Changes using the Goal-Driven Development for UML and MDA", in Journal of Object Technology, vol. 4, no. 5, July-August 2005, pp. 49-65 http://www.jot.fm/issues/issue_2005_07/column5

---