The Goal-Driven Development Process via a Case Study
NEW : The "Goal-Driven SOA" Development Process on the basis of BMM
|
The Goal-Driven Development Framework for automating adaptation to changes
Patterns described in the previous section do help analysts and designers in rendering specifications identifiable, evolutive (flexible), traceable and executable, based on requirements provided by non-technical business experts.
A methodological framework is then necessary to assist stakeholders in this process by suggesting necessary artifacts (textual specifications, UML diagrams, prototypes,..) and patterns to use at each step of the development process.
In this context, in order to offer good levels of traceability between related artifacts in the system lifecycle, the Goal-Driven Development Process is presented below in two dimensions : 1) the organizational dimension and 2) the architectural dimension.
The Organizational Dimension of the Development Process
Steps of the process explained below allows non-technical people and business analysts/designers specify respectively business needs and formalize them using components of goal-oriented objects. Generic steps of the process are shown below :
Figure 1 : Steps and generic artifacts of the Goal-Driven Development Process. The steps of the development framework allow non-technical people to specify their business needs and business analysts and designers formalize them using components of goal-oriented objects.
We explain these steps based on an example of requirements listed below (step 1) :
Step 1 - Structure Requirements using Goals
In this first step, requirements are listed being grouped by goals and hierarchically structured under these goals. Goals and requirements they capture provide behaviors required from the system within goal-cases. For example, in the case of an ATM machine, requirements related to asking the customer code, filling in and checking the entered code can be grouped inside the goal Customer Authentication.
Step 1.1 - Draft Requirements by Goals
Goals may be provided as empty fields at this starting point of the requirement gathering process.
As an example for the process of Product Development, requirements shown below gives an initial list of high-level strategic goals.
Figure 2 : Grouping requirements using goals is the first and fundamental step of the Goal-Driven Development Process
These initial high-level goals need to be completed progressively by the target system components (subsystems) that are able to process them via their expertise (functional boundaries).
Step 1.2 -Impact appropriate components by related changes
In order to ensure coherent evolution to the system, requirements that belong to the same functional context (intention) are assigned to goal-structures able to perform them inside their functional boundaries. The Pattern for Coherent Evolution (PCE) is then used to look for components that may host required behaviors inside their functional boundaries and for ensuring propagation of related impacts through top-down refinement chains.
Requirements drafted by goals in the first step are forwarded to subsystems (goal components or classes) able to process them inside their functional boundaries. These structures correspond to existing system components or they may be newly created in the system as shown in the communication (collaboration) diagram below.
Figure 3 : Requirements grouped by goals G1,..G8 are sent to existing system components capable to process them inside their functional boundaries. For instance, the component Website [development] is an expert component able to process requirements conducted within the goal G8:Turn Visitors to buyers..
As we have seen in the Pattern for Identifiable Specifications (PIS) , a set of tightly-coupled requirements that belong to the same intention generates a goal-case within the system that receives these requirements. Goal Cases offer to business experts locations where they describe their needs from the system without considering initially actor / system interactions (use cases) that realize these requirements.
For example, in the figure 3 above, the requirement G8 : Turn internet visitors to buyers that is captured by WebSite [Development] causes the creation of a goal case WebSite [Turn visitor to buyer] as a nested component inside this system. This new goal-case permits to track independently evolutions related to the requirement G8.
We focus below on system behaviors (rules) specified by business experts for supporting achievement of the business goal-case G8 that is composed of goal-cases G8.1, G8.2 and G8.3 as described in its textual description below :
Figure 4 : Description of the Business Goal-Case Website [Turn visitor to buyer] that is composed by underlying goal-cases like Register Visitor
Based on this description, we model underlying business goal cases that are encapsulated within the composite goal case Website [Turn visitor to buyer].
The diagram below illustrates these goal cases with actors that potentially participate to their realization within the Company Web Site System. For example, the business goal case Turn Visitor to buyer is to be initiated by the business actor Sales Manager. The goal case Register Visitor is to be initiated by the Visitor and may necessitate potentially providing information to the Sales Manager at the end of its realization.
Figure 5 : Business Goal Cases within the Website system and actors that potentially participate to their realization
However, participants of goal cases are accurately defined only when we focus on their realization. Such a realization of goal cases with their participants (actors, workers, entities) may be represented by activity diagrams (see steps 4 and 5, described later).
The next step provides a high-level view on the communication between business processes that realize goal cases found in the previous diagram.
Step 2 - Formalize realization of goal-cases and establish bridges from the CIM to the PIM
Business behaviors described textually within business goal-cases provided in step 1.2 have to be formalized in order to be validated by the business experts. Activity diagrams (the preferred UML diagram by non-technical business experts) may be used in order to describe their realization.
For example, the activity diagram drafted below provide a high-level view on the business processes that realize underlying goal-cases encapsulated in the system G8-WebSite [Turn Visitor to buyer]. The label of related requirements is appended to the processes drafted in this diagram to show their traceability.
Figure 6 : High-level description of the Realization of Business Goal Cases (business processes) within the Website [Turn visitor to buyer]
A high-level bridge between the MDA's CIM (Computation Independent Business Model) and PIM levels may be initiated at this point.
In this perspective, activities of business processes described in the activity diagram shown above are transformed in operations within corresponding GOO classes (Ref. Pattern for Identifiable Specifications (PIS)) at the PIM level. Operations that need to be zoomed separately for evolution purpose are reified using nested GOO classes as we have seen with the Pattern for Evolutive Specifications (PES) in the previous section GOO classes within composites of goals (GOO-Comp) and their operations are then discovered by applying this pattern.
The component diagram below illustrates structures of the business process cartography obtained after these transformations. Goal classes (GOOs) and components of goal cases are illustrated respectively using stereotyped UML components and packages. Guard-conditions that could be specified on the control flows of the previous activity diagram are indicated using conditions on dependencies between corresponding components.
Figure 7 : The component diagram shows nested components of WebSite [Turn to buyer] based on the behaviors specified on the activity diagrams of the figure 6 (actions that potentially necessitate evolution are directly reified as goal components using the Pattern for Evolutive (Flexible) Specifications (PES) )
Step 3 - Monitor advancement in achieving goals (Optional)
This step is rather an organizational step. It allows business experts to obtain feed-backs on the effective realization of the goals they have defined. In this sense, this step is particularly applied in the case of strategic goals. Content and frequency of feed-backs are reviewed and corrected if necessary. This step, depending on the completeness of requirements specified within goals described in the step 1, may be initiated in step 2.
Step 4 - Assign responsibilities to the participants of business processes
In this step, according to the Pattern for Traceable Abstraction Layers (PTAL), we assign responsibilities of actors and workers that participate to goal-cases.
Activities of participants for the realization of a business goal-case (business process) may be described within swimlanes of an activity diagram as illustrated below.
Figure 8 : The activity diagram shows responsibilities assigned to participants in the realization of the business goal case Register Visitor
In order to transform these CIM level specifications in PIM level ones with 1 to 1 traceability relationship, responsibilities assigned to participants of goal cases (workers and actors) may also be illustrated using UML's classes-in-states.
The figure shows the activity of Sales_Mgr as an object-in-state produced at the end of the activity Register_Visitor, once the condition visitor notified become true.
Figure 9 : The activity diagram shows cartography of business processes with the resulting activity of the participant Sales_Mgr
The component diagram below shows at the PIM level updated business process components and their relationships in the architecture of business process components.
Figure 10 : The component diagram shows components of WebSite [Turn to buyer] with responsibilities assigned to participants
Step 5 – Plug & Play operations due to interactions between components within the Business Architecture
In this step, according to the Pattern for Traceable Abstraction Layers (PTAL), we look for plugging behaviors due to interactions between participants of business processes and their target components specified in the architecture of business processes.
For instance, such a responsibility assigned to the participant Visitor in the action Enter Visitor of the process Register Visitor at the analysis level of the CIM may be realized at its design level by the collaboration between actions of the use case and goal case components as described in the activity diagram below.
Figure 11 : The activity diagram shows responsibilities assigned to use case and goal case components in the realization of Enter Visitor
Responsibilities required from use cases and goal cases components give operations in related classes (Ref. Pattern for Identifiable Specifications (PIS)) at the PIM level. The figure below shows CIM to PIM transformation of these behaviors using UML's classes-in-states.
Figure 12 : The activity diagram shows responsibilities assigned to use case and goal case components in the realization of Enter Visitor
Finally, responsibilities assigned to use case and goal case components are integrated within the related components of the business architecture according to the pattern for Coherent Evolution (PCE).
Figure 13 : The component diagram shows plug-in of behaviors inside components of the business architecture
In order to early test correct understanding of requirements and to guarantee platform independence of related specifications, the pattern of Executable Specifications (PEX) may be used for prototyping system behaviors at this point (analysis level of the PIM).
To ensure this, business objects like Company, Product, Visitor, etc.. are added to the system in order to be handled according to behaviors described within goal components of the business architecture.
Step 6 - Integrate Use Case Constraints and Test the System at the PIM
This last step aims at completing business specifications with the usage constraints of the actors of the application layer.
Use cases invoke business behaviors with respect to application constraints of actors as described by the Pattern for Using Business Behaviors (PUB-BAL) that we have seen in the previous section.
In this context, use cases focus in actor-system interactions whereas business and application goal-cases incorporate respectively controls related to the business and application layers. The schema below gives at the right of the figure a summary of different scenarios for invoking business behaviors from application use cases as referenced by the pattern PUB-BAL.
Figure 14 : Actors of the application layer invoke behaviors related to business and application layers
The component diagram below shows an example of integration of the application choices of actors within related business components. This scenario corresponds to the invocation of application choices of the actors during the execution of business rules with respect to their pre/post-conditions (see the scenario 3 of the pattern PUB-BAL)
Figure 15 : The component diagram shows integration of the application behaviors inside the business components
In order to test the system at the PIM, components related to the application choices of the actors are integrated in the business architecture as shown in the figure below :
Figure 16 : The application use case and goal case components that are plugged in the business architecture encapsulate application constraints of actors while using business behaviors specified in the business component Visitor [Entry]
The Architectural Dimension of the Goal-Driven Software Development Process
This final aspect of the development process shows how the software development artifacts may be traceably linked depending on the business goals and on the usage constraints of the actors of the application layer.
Main steps and artifacts of the Goal-Driven Development Process are shown on the architectural levels of the OMG's Model Driven Architecture given below.
At the left, we have CIM level artefacts that assist non-technical business experts in capturing requirements using goals.
In the middle of the column of the PIM, application use cases invoke interfaces of Goal-Oriented Components where business behaviors are stored.
At the right (in the column of the PSM), actor-system interactions are implemented by the application control layer, whereas dynamic and static aspect of the business and application components are implemented respectively by the Goals Layer and Entities Layer of the architecture.
Figure 17 : An overview of the Goal-Driven Software Development Process guided by business goals and organized depending on use case choices of the actors
Conclusion
Goal-Driven Development Patterns and the development framework briefly presented above aim at increasing reactivity of systems developed with UML in the sprit of the OMG's Model Driven Architecture (MDA).
In this direction, patterns PIS, PES and PEX allow analysts and designers to render their system specifications easy to change and assist them to keep the validity of analysis specifications at lower development levels (design and implementation) in order to execute them independently of target technologies. The pattern PCE allows business components evolve coherently with changing business strategies. Patterns PTAL and PUB-BAL close the gap between business and application layers guiding actors of the application systems to use business rules as these are defined at the business layer with their application choices.
The Goal-Driven Development Framework acts as a catalysor in such a development process by ensuring traceability between related UML artefacts. Thus, it contributes directly to the reactivity of the resulting system in face of changes.
Copyright © 2005- 2008 GooBiz – Birol Berkem
Click for a new version of this presentation adapted to BMM and SOA : " From BMM to SOA"
Birol Berkem
Consultant Methodologist & Trainer – Goobiz Paris / Cergy (F)
cell : +33 (0) 6 72 34 71 25