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:

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.

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:

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.