Refine - Analysis Classes
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 – Analysis class level approach

Class level responsibilities

The classic OO approach to defining responsibilities is first to create an analysis class model (ACM) from each use case, by identifying conceptual entities from the flow of the use case and any supporting business rules.

The description of how this is done is outside the scope of this paper, but an example of inspecting the following line:

ABC generic back office system calculates the risk both from the companies and the counterparties perspective.

By analysing our example use case this could give the following model:

Figure 20: Example of Static Model (Analysis Class Model)

That is, from the brief description above, it is clear that there could be a Trade and Counterparty class, with the former having the responsibility (“operation”) to determine limits breaks at a trade level, the latter at a counterparty level.

The only use cases written using this approach are those defined at the enterprise level – i.e. treating the system as a single black-box. Since use cases lend themselves more to a black-box approach, this is arguably a more suitable use for them.

Some pitfalls with this approach

Unfortunately what this does not give us is a component view, and as stated earlier, in an enterprise, delivery will be usually be through components.

The typical approach of assigning these analysis classes to separate packages and then identifying interfaces is substandard here since this can not occur in this stage of the project lifecycle.

In the analysis class only approach, the “enterprise” is treated as a single building block which makes this approach very suited to traditional use case modelling, where the system is treated as a black-box, and the only actors are those who sit outside of the system. However the issue with this approach is that it is too blunt a tool for architects and planners. To ignore component responsibility this at the early stage is a loss of opportunity to explore the early integration and validity of an prototype architecture.

bulletResponsibilities given to the wrong component causing poor cohesion (sledgehammer packaging at class level is very ambiguous with this regard)
bulletResponsibilities just don’t join up with the components suggested by architecture. This is a very bad situation since components can have separate management structures associated with their build and can be outsourced. A very costly error to fix.
bulletComponents may not completely “own” an analysis class (since these are more akin to conceptual/domain level – i.e. not fine grained). Therefore usage of operations may be split over several components.

There may also be cases where it is undesirable to treat use cases as black-box, in cases where there clearly isn’t a single system. In such cases some form of component based consideration is unavoidable. For example:

bullet

If it is an objective of looking at the integration of two separate initiatives serving two clearly different parts of the business – but nonetheless need to work together and integrate in order to be successful. Such an system cannot be treated as a single enterprise because it isn’t – it has separate accountability and budgets, and likely analysis teams. This would be a good case for modelling each as a system with there own system level use cases. An integration between financial control and product control (two discrete departments with a fair degree of dependency) or a merger are some good examples of this.

bullet

If the organisation structure forces a non centralised analysis team. For example if TM and RM both have own analysis team (perhaps there is a good reason if the expertise that not that transferable), then this would likely be carried forward to the build of the components to support these functions. However it is always best to avoid this where possible.

Importance of enterprise view

Focussing only on analysis classes will mean that there is no enterprise view of the problem domain. The purpose of enterprise modelling is to have some understanding of the suitability of the architecture to support the problem domain. This is not possible without the component dimension.

A component view is important as it shows architectural impact – and allows in planning phase to elicit architecturally significant use cases in a way better than guesswork.

Just using the black-box end-to-end use cases is difficult to plan an iteration, since an iteration should be based around component delivery. Since in an e2e use case different parts of the use case will be realised by different components it is in itself an unsatisfactory way of planning an iteration. In elaboration there must be some way of mapping this to components and used this as a basis of the iteration plan.

The following section describes a combined approach that takes the best features of OO modelling and combines them with the innovative component modelling that forms the backbone of the 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