Refine - Combined
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Approach
Enterprise Planning
Enterprise Elaboration
Refine - Analysis Classes
Refine - Combined
Which Approach
Uses of Deliverables
Other Methodologies

Refine responsibilities – Combined approach

If there is a desire for a strongly defined enterprise component level view, but without losing the OO nature of a enterprise analysis class model, then a hybrid approach can be used that satisfies both these issues.

Objectives of a combined methodology

Is it appropriate to do design in the inception phase? The short answer to this is no – unless it is to prove an architecturally significant (and limited) area. Early design, when it gets ahead of requirements nearly always causes problems, since it prejudges what the requirements are, and can cause unnecessary constraints. 

Given this argument, is therefore enterprise analysis design and therefore inappropriate? The answer to this is no – there is no technology dependency – the only dependency are the architectural building blocks (“components”) which may be as equally led by commercial and legacy reasons as by technology.

An issue with component level use cases is that is hard to write these without entering into some form of design mode, whereas with a Analysis Class Model (ACM) approach all issues of design are avoided. However the ACM approach has been shown to promote lazy architectural decisions and has difficulty in integrating and adapting to the architectural vision.

The answer to this is that both of the above approaches are correct, but from different perspectives. The challenge therefore with a model-led approach is not to have two separate visions, but one single vision that is satisfactory from both perspectives.

How  use case realisations are refined in a combined approach

With the combined approach, the ACM to used to identify domain classes and their responsibilities in the standard OO manner.

These are then assigned to the component responsibilities identified in the end-to-end scenarios as an alternative to describing these as component level use cases. This is shown in the following two figures.

Figure 21: Example of Static Model as from Analysis Class Model approach

These responsibilities (i.e. class operations) are then assigned to the components using the className::operationName notation, as shown in the following example:

Figure 22: Assigning analysis class operations to components from end-to-end scenario

By forcing a mapping of how components are using these responsibilities in joined up way forces the enterprise analyst to challenge both the prototype architecture and the completeness of the responsibilities themselves. If the responsibilities cannot interact with one another in by the components offered then either the choice of components are wrong or the ACM is wrong.

This works best where the operations on the ACM are described in a verbose manner. Readability is enhanced if these interactions are aligned to the same (enterprise) use case narrative defined earlier.

It will be also easier to derive interfaces at an early stage be using the dependency model, and to show which classes and operations these support.

Figure 23: Showing analysis model responsibilities on component interfaces

So in conclusion, in the inception phase start off with a set of interactions that make sense from the description of the use case (since at this stage you are unlikely to have the ACM and its responsibilities set up at this stage). These are kept at a high level as described in section 3. Then as part of the elaboration phase these are “turned” into interactions as shown here, with the high level verbose named moved to documentation of the operation in the analysis class model.

These operations can then be specified using pseudo code in the construction phases. Some examples of how pseudocode is used is shown in the Codel Service’s Rules Based Methodology

Back Next

© 2002-2005 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: info@codel-services.com