Notice 11 MAY 2008 : This article is recently updated according to relationships described between BMM and SOA (Ref.Article "From BMM to SOA" placed on the top of the home page of this website)

 

Birol Berkem - Goobiz (Paris / France)

 

Abstract 

In the previous articles that we wrote in the last years, we 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, you will find steps of this methodology in their industrialised aspect that are conducted this time till the software implementation level 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 requirement 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 methods do not provide their organisations with good levels of reactivity in face of changes. This is because these systems are structured depending on the intentions of their end-users in using the system (use cases) and on the basis of its domain objects rather than being structured according to the business goals (2) and underlying rules (3) that support achievement of these goals. As a result, such systems are unable to capture changes on the business needs (such as tactics and business rules) and propagate them coherently toward IT applications in order to allow their organisation to capitalise on its business knowledge as well as helping end-users to invoke changing business behaviours according to their changing responsibilities.

In order to illustrate how to develop IT applications on the basis of business goals then aligning these applications to changing business rules on a Goal-Driven Service Oriented Architecture (GD-SOA) (4), 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 that also allows traceability with the requirements that are entered using the same tool.

 

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

 

(2) Business Goal : A statement about a state or condition of the enterprise to be brought about or sustained through appropriate means [BMM of the OMG]. For instance, in the case of a WebSale System, means like " Motivate Visitors to Register " and "Turn visitors into buyers" offer their support to the business goal "Profitable Websale System".

 

(3) Rules : A business rule is a statement that defines or constrains some aspects of the business [BMM]. In [Business Rules vs. Business Requirements], a rule is defined as a "Statement that tell you whether you may or may not do something" whilst a business requirement is "what you need to do to enable the implementation of and compliance with a business rule".

 

(4) GD-SOA : A Service Oriented Architecture where services of the IT system correspond to a business process or to a function that can be mutualised between business processes. A goal-driven service is composed of cohesive set of requirements and requires participation of resources (actors, use cases, workers, entities, ...) in order to be realised.

 

 

 

1         Introduction : wHY USE CASES ARE UNABLE TO ALIGN IT TO CHANGES ?

 

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 three main reasons.

 

In use case driven development :

 

• business experts are unable to evolve their business processes independently of user interactions as business rules are mixed within actor/system interactions inside use cases,

• end-users are unable to use the system according to their changing responsibilities when business goals or their supporting rules evolve, nor to focus accurately on their usage scenarios till detailed definition of their screens as they should do,

• the adaptation process of the software components to the changes on the business requirements cannot be handled directly due to the 1 to N traceability issue between functional specifications and their business entity based object oriented representations.

 

 

Such a lack of direct visibility of the rules and lack of traceability till their software implementations are an important obstacle for aligning IT implementations with the changing company goals and related business rules. As a consequence important maintenance effort is required in order to adapt IT applications to changes.

For the same reasons, emerging SOA approachs that try to determine services on the basis of use cases suffer from the same agility issues. 

 

In order to allow organisations to increase their business agility, a Goal-Driven Development Process becomes necessary. Such a case tool-assisted approach must help stakeholders to model business goals of their organisation, their underlying courses of action as well as rules that have to support these goals until discoverying and implementing SOA services as well as use cases of the end-users according to changes.

.

The Business Motivation Model Diagram [BMM] referenced in the figure 1 below shows such relationships. 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, business goals as part of the ends drive courses of actions, directives (rules and policies) till business processes.

 

 

Figure 1 :   The Business Motivation Model  for 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 right to left), the Goal-Driven Service Oriented Development Process aims at allowing stakeholders to :

       

•      establish a bridge between the business and IT components that have to carry out implementations of strategies and tactics as well as rules and policies that guide realisation of their business processes,

•       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.   

 

In this perspective, the next section shows steps of the Goal-Driven Development Process from requirements captured on the basis of goals through their software implementation. These steps are explained on a case study where one of the business goal and strategy of the organisation is fixed respectively to be "a beneficial websale system" by "turning its internet visitors into buyers".

 

 

2         Steps of the "GOAL-DRIVEN SOA DEVELOPMENT" process

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

 

 

Figure 2 :   Steps of the  Goal-Driven SOA Development Process on the basis of  BMM and MDA

 

 

 

The roles of these steps are as follow :

 

• Step 1 focuses on the description of tactics, business rules and business processes on the basis of business goals.

 

• Step 2 is interested in modeling business processes and determining responsibilities of their participants in order to realise tactics at the business level.

 

• Step 3 looks for services of the system that are candidate to support tactics and processes then finding use cases that have to invoke these services.

 

• Step 4 elaborates a first draft of the Goal-Driven SOA backbone by transforming functional specifications of the business experts related to step 1 into corresponding service-oriented software components.

 

• Step 5 describes underlying behaviours of the software components toward their implementation code for automated actions of the previous activities.

 

• Step 6 integrates behaviours of these software components into the Goal-Driven SOA backbone using plug-in and play mechanisms.

 

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

 

 

Step 1   Describing tactics and business processes on the basis of business goals

In this first step, on the basis of business goals and strategies, tactics and business rules that support them are hierarchically described until discoverying goal-driven processes and requirements that compose them.

 

A goal-driven process contributes to realise at least one tactic and is guided by business rules.

 

For detailed information, links from BMM to SOA Services are described in "From BMM to SOA".

 

The figure 3 below illustrates a decomposition of the business goal "Beneficial WebSale System " by "turning visitors into buyers (strategy)" using Tactics (G1,...G3) until discovering Goal-Driven Processes and Requirements.

 

Inside the tactic " G3 - Motivate visitors to register" two goal-driven business processes G3.1- Consult Products and G3.2 - Register Visitor are discovered. Both services may be realised by the participation of resources such an internet visitor and the marketing employee.

 

Figure 3 :   Decomposition of a Business Goal and Strategy using Tactics until discovering Business Processes and Requirements

 

On the basis of these specifications, we model at the next step business processes within described tactics then assign responsibilities to their potential participants in order to describe their realisation.

 

 

 

Step 2  Model business processes then discover responsibilities of their participants

 

This step allows us to formalise business processes and business rules to support tactics then discover responsibilities to assign to their participants in order to ensure their realisation.

 

The figure 4 below illustrates a formalised description of the business processes and responsibilities assigned to participants in order to support tactics.

 

In order to better represent causality between business processes, participants are modeled there as objects in different states where entering in a new state triggers the appropriate process.

For example, according to the business rule BR1.a , if the abandon rate of visitors is over than 50% while consulting products, the system assigns the responsibility of reviewing presentation of the products to the Marketing_Mgr by setting its state to [Product Review] in order to incite him to trigger the process Review presentation of the products.

 

  Figure 4 : Interaction between business processes and responsibilities assigned to their participants in order to support tactics in the context of the business goal "Beneficial websale system"

 

 

Step 3   Discover Goal-Driven Services and Use Cases

 

In order to confer coherent evolution and swift adaptation to changing tactics and business rules of the organisations till their IT implementation, business rules captured on the basis of tactics must be rendered visible.

Such a visibility requires a separate identification of the goal-driven services from the usage scenarios of actors (use cases).

 

A goal-driven service is a function at the IT system level that corresponds to a business process or to a function that can be mutualised between business processes. It is composed of cohesive set of requirements and requires participation of resources (actors, workers, entities, ...) in order to be realised.

For instance, on the basis of the previous specification (figure 4), business processes G3.1 - Consult Products, G3.2 - Register Visitor and G4.1 - Inform Visitors about Promotions... help us to determine three candidate goal-driven services.

Services constitute the essence of use cases as they make sense to actor / system interactions that are necessary to realise related functions. 

 

On the basis of these specifications, use case components are determined in order to allow actors to realise services by invoking their behaviours. In such a separation of the business behaviours from usage choices of the actors, use cases only represent corresponding goals of the actors in using these business services.

 

The figure 5 shows tactics (represented by boundaries) with underlying services based on the previous requirements. Specification of such boundaries as composite structures helps us to easily determine their underlying parts (business services with their supporting business rules that are included inside them) in order to evolve them coherently in respect to potential changes.

 

 

Figure 5 : Representation of Goal-Driven Services and Use Cases partitioned by Tactics that they have to support

 

 

 

 

Step 4   Draft the backbone of the Goal-Driven Service Oriented Architecture

 

This step allows us to elaborate a first draft of the architectural backbone of service and use case components at the PIM level of the MDA. A draft of the Goal-Driven SOA backbone on the basis of the specifications of business experts is given in the figure below according to the UML 2 component diagram notations.

.

In order to keep traceability with business level goal-structures of the system described in the previous figures, service components in the figure below are described within the same "Tactic boundaries" namely G1, G3, G4.

 

 

 

Figure 6:    A draft of the backbone of the Goal-Driven SOA transformed at the PIM on the basis of CIM level specifications of the business experts

 

 

Step 5   Model underlying behaviours of use case and service components for realising actions determined in the previous scenarios

 

In this step, we describe underlying automated actions of the processes that require actor / system interactions for their realisations.

The below activity diagram illustrates a realisation scenario for the action Enter Visitor of the process Register Visitor described in figure 4.

 

 

 

Figure 7 :   Behavioral description of the use case and service components that realise the action Enter Visitor of the business process Register Visitor

 

 

 

 

Step 6  Plug-in the use case and service behaviours into the backbone of the GD-SOA and test

 

This step focuses on filling into the components of the architecture the appropriate software behaviours. In this perspective, behaviours of the other architectural layer components such as the presentation and data storage layers have to be implemented on the basis of the previous specifications.

 

After then implementation of these actions has to be distributed respectively as actions for underlying use case and service components depending on their nature (respectively application rule or business rule). We call such use case and service components goal-oriented objects (GOO) as they are designed to achieve a given goal (respectively the goal of the user or the goal of the business system). A goal-oriented object (GOO) has a controler operation that triggers its contextual operations depending on the state of the object (expressed by its attribute values) and the pre-condition of the contextual operation [Align-IT].

The below class diagram shows description of the use case (BUC) and service (GDS) classes on the basis of the previous specifications with the user interface (UI) and entity objects (Data Model) in order to test the action Enter Visitor of the business process Register Visitor.

 

 

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

 

 

 

In this final stage, the previous architectural components (GUI, use case, service, entity objects) are plugged into appropriate structures of the architectural backbone of the system for their integration with other components of the architecture.

The figure below illustrates plug-in of the previous UC and GDS components into the system architecture.

 

Figure 9 : Use cases and service components are plugged into their respective parent components within the goal-driven 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 other technical aspects for their unit and integration tests. 

 

The print screen of the figure 10 below shows correspondence between actions specified for the service component Visitor_Entry and their corresponding method bodies in 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 GOO classes of use case and service of the figure 9 have to be instantiated.

 

Final states such as [created], [validated], [linked to visitor], [sent], etc..  that have to be reached by entity objects are illustrated in order to guide developers about states that must be respected in the related actions. These states are indicated as comment lines in the generated source code for helping developers in implementing corresponding methods.

 

 

Figure 10 : Courses of actions and conditions for the service component Enter_Visitor are transformed to provide comment lines in Java

 

 

 

Click to visualise how to deal with changes on the Goal-Driven Service Oriented Architecture, ...

 

 

3         Conclusion

 

The steps of the Goal-Driven SOA Development Process illustrated in this presentation allowed us to explain how to align IT applications on the basis of business goals, their underlying means and processes according to BMM and MDA concepts.

By bridging these concepts throughout identification of SOA services and application use cases then ensuring their separate traceability toward software implementation, the purpose of the Goal-Driven SOA process is to allow stakeholders to adapt IT applications to the changes swiftly and coherently using goal structures, thus to capitalise on their business knowledge using a goal-driven service oriented architecture [GDDP4MDA].

Goal-Driven Development Patterns [Patterns] that support the infrastructure of this SOA process aim at helping organisations to enhance continuously their processes in order to increase their business agility without worrying about alignment of their IT applications.  This way, business experts focus on enhancing their business behaviours by describing more precisely services of their SOA-based systems, whilst end-users of the system can finaly concentrate their efforts on the precise specification of their interactions with the system as they should do.

 

 

 

 

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/10-04%20COL%20OMG%20Montreal%20-%20Hendryx.pdf  , October 2004

[Business Rules vs. Business Requirements] : Gladys S.W. Lam - Business Rules Journal, Vol. 7, No 5, May 2006), URL:  http://www.BRCommunity.com/a2006/b290

[Service Architecture - SOA : Why Sale isn't process driven] : Steve Jones - http://service-architecture.blogspot.com/2007/01/why-sales-isnt-process-driven.html

[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-with-BMM] Birol Berkem, How to align IT with the Changes using UML and according to BMM ? - Journal of Object Technology, vol. 5, no. 2, March-April 2006 , http://www.jot.fm/issues/issue_2006_03/column9

[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

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

 

 

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License

Birol Berkem (Ph.D), Goobiz