Approach - Enterprise elaboration

The main purpose of elaboration, is to build on the framework set up in the planning phase.

There is a decision to make as to how the model is taken forward:

Whilst this decision should be made on project initiation, its effects are mainly felt in the following elaboration phase.

These approaches are described in turn, firstly taking a pure component view, followed by a analysis class centric view, and finally a hybrid approach that leverages benefits from both.

Regardless as to the decision the methodology can bring real benefits, but with a slight different approach for some artefacts. This is summarised, outlining the pros and cons of each method, and when each should be considered.

Refine responsibilities – Component level approach

To first understand how a component view is taken is to understand that a responsibility on a component can be described as a use case where the system boundary is set at the component level. An initial component level use case model is relatively straightforward to produce, and has the advantage of being coherent to the end-to-end scenario.

Figure 13: Prototype use case model

Compare this model with figure 8. Since this is the inception phase it is enough to treat these as initial use cases – that is a use case model (with component scope) and brief description of the goal of the use case is enough. Where it is difficult to define its goal, the chances are that the responsibility is incorrect or too detailed.

The challenge is for the “extending phase” type projects, since there may well be a use case model already defined. In such cases this will form the baseline for the following analysis activities (assuming it is accurate – not always the case). If these use cases have a reference number, it is recommended that the responsibilities are traced to these rather than reverting back to the original name since this may not be verbose enough for our purposes. The mapping should be one-to-one, if it isn’t then the original use case model may be not as goal driven as was hoped!

Note that the use case names do not have to be the same – they are often more process orientate and thus less verbose.

Figure 14: End to end scenarios with use case references

Note that even for changed use cases, adopting some of the conventions of the initial use case may still be of benefit to show the potential impact of change.

The initial responsibility specification can then easily be converted to an initial use case description, applying any use case mappings as appropriate in the inception phase. Such specifications will then be extended in this phase.

Figure 15: “Initial” component use case description

It is important to understand that whenever use cases are used at the component level, they individually lose some of the end-to-end nature, so it should be demonstrated that they map to an overall end-to-end scenario. If the are self contained specification then build teams have lassitude in finding the correct design and implementation for them, they should not take a lead in their definition as the likely consequence will be use cases that do not interrelate.

Detailed component level use case descriptions – some pitfalls

In the elaboration phase these initial use case descriptions can be extended to become a full use case narrative, using any use case description template (your organisation is likely to have one)

Before considering writing component level (or white box) use cases at this level a number of potential pitfalls with them should be considered before deciding if it is the right approach to elaborating the enterprise

Firstly they can be hard to write without straying into detailed design, and their narrow scope makes them difficult to review (see separate paper on this as to how to avoid some of these issues.)

However most importantly, it is hard to produce an analysis class model to support use cases at this level. In the following neither component has a full view of trade, lets say A references it and B persists it. Trade would have to appear in both analysis class models but with different responsibilities. By fragmenting the analysis class model at a component level difficulties are introduced (again this is best at enterprise level).

Figure 16: Issues with component level use cases

Trade Management in our scenario does not contain the validation rules, since the architects deemed these best managed centrally. So it does not have knowledge of these – hence the subsequent collaboration with Reference Data Repository. Our specification now becomes:

So what is being said here, is as long as reference data repository is given the trade details, it can use its knowledge of the validation structure and return equity validation structure. This process can become very powerful, and can be an alternative to component level use cases (and still avoids being design) – but on the downside it does require a degree of modelling competence.

Analyse component responsibility cohesion

Of course in this contrived example it is suggesting that Trade Management is not actually having the responsibility of actually doing the validation, rather reacting to the results given to it (i.e. perhaps it Reference Data Repository should return the Trade Structures and Trade Management decide whether it is valid or not). We are having a very precise definition of responsibility that cannot easily be misunderstood, something that could happen if responsibilities were just defined on the basis of name. This is highlighted in the following two figures:

Figure 17: Poor responsibility cohesion

Figure 18: Better responsibility cohesion

This is exactly the sort of discussion that should occur early in the process since errors here can have profound and costly consequences later on.

Static model (component  knowledge model)

Following the analysis described above can lead to a clear picture of what each component needs to “know”. This can be shown diagrammatically in the following figure.

Figure 19: Component knowledge model

This static view is easily created from the models we have already – in fact it can be considered a “free” by-product of them. It gives a useful in the following ways: