When developing or building a construction or project of some sort, such as a house or a machine, we all rely on previous experience from similar work. In this way, we can be sure that we will be more productive and will, therefore, be able to complete the job better and in less time than an inexperienced person.
We will know what solutions work, and can thus avoid pitfalls, and we will know or have qualified guesses about possible ways to tackle problems that arise. In some cases, we know how a part, a service, or an assembly was successfully built in another project, and we can then reuse that solution in the current situation. In other cases, it is not a particular solution that can be reused; instead, it is the underlying design that is relevant when we decide how to solve the current problem. In other words, we reuse both existing solutions as well as techniques that have proved to be well suited and efficient in other contexts.
Use-case modelling does not differ from other kinds of developmental work in the sense that an experienced modeller will reuse solutions that he or she has found useful and efficient. The more experience the modeller has, the more frequently and efficiently will he or she reuse earlier solutions.
The experienced use-case modeller does not focus on a single use-case when expressing what the system under development is meant to do. Instead, the modeller knows that a specific problem as a whole should be expressed with a particular set of use-cases. The solution to the problem may include several use-cases as well as the relationships between them. Hence, the modeller will reuse fragments of previous, successful models when producing a new use-case model.
The reused model fragments are seldom identical copies of parts produced in the earlier models. After gathering more and more experience, the fragments boil down to blueprints which capture the essence of how a particular service offered by a system should be modelled in general, or how a common use-case modelling problem should be solved. Hence, a blueprint may be a use-case model of security in terms of access control of information in the system, or a use-case model capturing the use of a legacy system.
Blueprints can be, more or less directly copied into a use-case model of a system including the service or modelling situation captured by the blueprint. Usually, it will be necessary to tune some of the details in the blueprint to the specific needs at hand, such as choosing names that are natural to the stakeholders of the current project and stating particular sequences of actions that are to be performed in the use-case descriptions.
Similarly, the successful techniques and designs that are used repeatedly in the use-case models become formalized as patterns expressing good use-case model designs. Such a pattern does not describe a particular usage of the system. Instead, it captures a technique for making the model maintainable, reusable, and understandable. To apply a pattern in a use-case model means structuring a part of the model or describing an individual use-case in a specific way. Hence, use-case patterns capture good practice in use-case modelling. For example, a subsequent function that must be the same in several use-cases should be modelled as a separate use-case with explicit relationships to the original use-cases, and services that are optional in the system should be modelled separately from the mandatory ones.
As opposed to blueprints, patterns are not just copied into a use-case model. Instead, they are used as templates for how the model should be structured, or, for description patterns, how use-case descriptions should be organized.
First, it describes an understanding of a problem, either a particular usage of a system or an underlying design and gives a solution that is proven, sound and reliable. Second, it includes information on situations where the blueprint or pattern is applicable, and Third, it describes what the consequences will be when it is applied.
Experienced use-case modellers will not only know how to develop a good use-case model, they will also discover when certain use-cases are missing, simply because they know that such use-cases will most likely appear in this kind of system. In most systems, for example, the users must be identified before they can use the system, that is, they must log in to the system. This implies that there must be use-cases not only for logging in but also for logging out and for registering and deregistering users. Furthermore, if all the users are not supposed to have the same access rights to everything in the system, there must be use-cases for registering and checking their access rights as well.
Altogether, this means that experienced modellers do not look for single use-cases; they look for groups of use-cases. Therefore, the patterns and the blueprints include not only the significant use-cases for the modelling problem but also the supporting use-cases needed to be able to perform the significant use-cases. This means that your whole collection of patterns and blueprints offers a lot of help when producing use-case models by providing comprehensive solutions to modelling problems.
However, other people’s experiences, as well as our own, do not only tell us how things should be done, they also make it clear how things should not be done. Experienced use-case modellers can often quickly identify imperfections in use-case models they review. This is not because they have modelled the same system before, but just by studying the structure of the model, they detect common mistakes, such as an abnormally large number of relationships in the model, or functional decomposition of use-cases. We have therefore enhanced our collection of patterns and the blueprints with a set of common mistakes that we have found over and over again. Use this collection as an indicator that something may be flawed in the model, but not as a sharp divider between right and wrong. There might be a good reason why a specific model triggers such an indicator and still is acceptable. However, such situations are rare!
