![](bg2.png)
and behavioural modelling of the pattern to
evolution issues, which are essential for the precise
application of the pattern by the developer.
1. Name: Pattern identifier.
2. Also known as: Additional names that can also identify this pattern.
3. History: Chronological register of all previous versions of this
pattern. The following notation should be used: {Date, Author,
Reason and Changes}. To be used by developers who have already
used the pattern to check its changes.
4. Structural adjustments: Introduction of field extensions and
omissions to the pattern template.
5. Problem: A short description of the problem that this pattern solves.
6. Motivation: Description of the forces involved and a problematic
situation intended to motivate the use of the pattern.
7. Context: Wide description of the environment in which the problem
and solution recur and for which the solution is desirable.
8. Applicability: Description of the conditions wherein the pattern can
be applied.
9. Requirements:
9.1. Functional requirements (FR): List of all FR organised
through use cases.
9.2. Non-functional requirements (NFR): List of all NFR (e.g.
security) organised in a SIG (Chung et al., 2000).
9.3. Dependencies and contributions: Identification of
relationships between requirements. These may be
dependencies, meaning that a requirement depends on
another, or contribution, meaning that a requirement
contributes positively or negatively to another requirement.
This is represented with a graph.
9.4. Conflict identification & guidance to resolution: Explanation
for requirements interaction and conflict resolution.
9.5. Priorities: Definition of priorities among the requirements.
This could be represented by a hierarchical structure.
9.6. Participants: Identification and description of the actors that
interact with the system.
10. Modelling:
10.1. Structure:
10.1.1. Class diagram: Structure of the elements of the
pattern.
10.1.2. Class description: Description of classes and their
responsibilities.
10.2. Behaviour:
10.2.1. Collaboration or sequence diagrams: Suitable for
scenarios description.
10.2.2. Activity diagrams: Suitable for scenarios and overall
description.
10.2.3. State diagrams: Suitable for scenarios and overall
description.
10.3. Solution Variants: Description of alternative structural and
behavioural models.
11. Resulting context: System configuration after the pattern
application.
12. Consequences: Advantages and disadvantages of the pattern
application.
13. Anti-patterns traps: Most common pitfalls that can be originated
from the pattern application.
14. Examples: One or more application examples that illustrate the
usage of the pattern: initial context.
15. Related patterns: List of similar patterns (describing similar
problems and solutions).
16. Design patterns: Design or architectural patterns that can be used
for further refinement.
17. Design guidelines: Advices on how the pattern should be
implemented (without specific details).
18. Known uses: Known pattern occurrences and applications in
existing systems. This should include at least three different
systems.
Figure 1: Proposed analysis pattern template.
Each entry in the template is numbered for
referencing purposes only, not representing the
filling order. This order, wherein the various entries
should be filled, is given by the process described in
Section 3. In general, there are no systematic
processes defined to help developers building
analysis patterns. The pattern community is usually
more interested in building patterns than in defining
rules to build them. For a practitioner, however, such
a process may be essential to get started, and to
know exactly what steps to take to have a pattern
defined in the end.
3 A MODEL FOR ANALYSIS
PATTERNS SPECIFICATION
The process depicted in Figure 2 as an activity
diagram, illustrates a systematic model for analysis
patterns specification. This process shows what a
developer should do when defining an analysis
pattern. Each marked block in the activity diagram
will be described next. Each activity helps filling in
one entry of the template. It is not the aim of this
paper to define how an analysis pattern is identified.
This work presupposes that this has already been
realised. The process is explained next, step by step.
Due to space reasons we could not illustrate the
approach, but a full example can be found in
http://ctp.di.fct.unl.pt/~ja/AP-Process.pdf, where the
approach is applied to the analysis pattern “Repair of
an Entity” (Fernandez and Yuan., 2001).
Context and Problem Definition. The first
activities are realized based on the pattern
identification, rooted in a set of applications that
were analysed beforehand. The Name must be
generic and abstract enough, being adaptable to the
same problem within several domains. The Problem
states the reason why the pattern is being developed.
A pattern only addresses one problem. If we realize
that the problem can be decomposed in several self-
contained sub problems, then we isolate one
problem per pattern, and recursively apply this
process to each identified sub-problem. The Context
characterizes the domain in which the problem
recurs, addressing its origin, main causes/reasons,
and any other relevant aspect. The Motivation entry
describes the forces that drive the pattern and gives
one example that motivates the use of the pattern.
Applicability involves enumeration of the problem
core characteristics that are solved through the
solution described in this pattern.
Requirements. The Requirements set of activities
starts by identifying and describing FRs, NFRs and
participants (which can be realised in parallel as they
are strongly coupled). To complement the
description of the FRs we can employ a use case
diagram, where each use case refers to one FR or a
set of FRs. Participants are mapped to actors. NFRs
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
454