What Is an Analysis Pattern?

Analysis Patterns. Solution Models for Subject Domain Problems.

What is an analysis pattern? What advantages does it offer and what analysis templates are there?

Knowledge Base:  analysis pattern coordinator

What Is an Analysis Pattern?

A pattern is a solution template that has proven useful for solving a concrete problem. In software development, this concept is known as a design pattern. It provides code solutions. Analysis patterns are patterns that are also used in software development. They describe solutions for problems in specialist domains. These solutions are class diagram models (a UML diagram type) instead of code. What does this mean, exactly?

Say, for instance, that a library has multiple instances of a particular book. These instances all have the same author and title. This means that the properties are available multiple times because there are multiple editions available. Applied to modelling with class diagrams, this means that if you work with a class like Book, you have the problem of having to save the same properties multiple times, redundantly. With the analysis pattern Instance type, from Heide Balzert, this problem can be solved: You add another class (book type) that contains unchanging properties like Title and Author as attributes. This analysis pattern can be used as a template in other subject areas where this problem occurs.

This problem can be solved with the analysis pattern Copy type according to Heide Balzert: You introduce a second class (book type) that contains the invariable properties such as title and author as attributes. If you now come from a different subject area, but encounter the same problem, this analysis pattern can be used as a template.

You thus apply analysis patterns in the analysis phase – i.e., for the creation of domain-oriented models – to reflect the structures of business processes. The patterns describe how a domain thinks about a problem, but do not represent a technical implementation. They serve as a basis for requirements elicitation and specify the interaction and responsibilities between classes.

Analysis patterns are highly relevant to the work of analysts and designers doing object-oriented business process modeling with UML.

Definition of an analysis pattern:

An analysis pattern is a template for solving an organizational, social or economic problem in a professional domain.

Advantages of Analysis Patterns

Analysis patterns in software development help better understand a problem. The class diagram represents knowledge that has been tried out and can be applied at a high abstraction level. Additionally, analysis patterns offer a means of communication between system analysts and domain experts. Because standardized presentation allows you to understand models better and take a closer look at the problem. This means the work in the analysis phase is reduced whereas the results will be of a higher quality.

Classification of Analysis Patterns

There are two types of analysis patterns:

General/universal (mainly defined by Balzert ):

  • Modelling templates
  • Building blocks for other patterns

Application-specific (mainly defined by Fowler ):

  • for planning system and merchandise management systems (Patterns that concern repeating problems when analyzing running information systems)

Analysis Patterns in Requirements Analysis

Creating models in the analysis phase creates a foundation for requirements elicitation or for deriving use cases. In his pattern catalog “Analysis patterns: reusable object models,” Fowler provides methods for object-oriented analysis of specific domains like health, accounting or finances which enable requirement analysis to take place more quickly. Darimone and Lamsweerde have developed analysis patterns for refining stakeholder goals. Jackson created something similar to an analysis pattern with his “Problem frames approach”. Problem frames don’t correspond to solutions, instead to repeating problems.

The analysis patterns defined by Balzert are kept general, that is why they can be used by and adapted to all technical domains. This offers the most flexible means of modelling class diagrams and deriving use cases or requirements.

Use Analysis Patterns to Analyze Technical Domains with objectiF RPM

Learn more about how objectiF RPM supports you with
sample catalogs »

objectiF RPM

10 General Analysis Patterns

(from H. Balzert: Object Management Handbook)


Example: An invoice contains one or more items.

Knowledge Base: analysis pattern list


  • Relationship type: Composition
  • A complete object consists of the same parts (There is only one part-class).
  • Partial objects are permanently allocated to an aggregate object, but they can be deleted without deleting the entire object.
  • The attribute value of the aggregate objects are also valid for partial objects. (here: number and date of the invoice).
  • The aggregate object generally contains at least one partial object (the cardinality is at least 1, normally 1…*).

Instance Type

Example: In a library, there are multiple instances of a book that have to be managed.

Knowledge Base: analysis pattern instance type


  • Relationship type: Single association
  • A type can exist independently from its instances – the cardinality is generally *.
  • The new class often contains terms like type, group or description.
  • Object relationships cannot be changes, only deleted or removed.
  • Only disadvantage: Doing without the class “type” would lead to redundantly saving attribute values.


Example: A motorbike has a motor and two wheels. These are physical objects.

Knowledge Base: analysis pattern module


  • Relationship type: Composition
  • Physical objects
  • The object relationship normally exists for an extended period of time.
  • Partial objects can be separated from the aggregate object and allocated to another complete one.
  • A complete object emerges from different parts.


Example: Many students are taking part in a course and have to do a talk during one session. A student is therefore an audience member but sometimes also a speaker.

Knowledge Base: analysis pattern roles


  • Relationship type: two or more simple associations between two classes
  • The object can take on multiple roles in reference to objects of other classes.
  • The objects have the same properties no matter what the role is.


Example: An employee has multiple tasks in a business. Only one can be valid at any time. The employee is also studying.

Knowledge Base: analysis pattern history


  • Relationship type: single association
  • Multiple criteria have to be documented for an object.
  • A time period must be available for each criterion.
  • Existing object relationships for the criteria can only be expanded.


Example: A student takes part in a professor’s exam.

Knowledge Base: analysis pattern coordinator


  • Relationship type: single association
  • Instead of an n-association (n>=2), there is a coordinator class (here: participation).
  • The coordinator class does not have many attributes or operations, but it has more associations to other classes instead. (It saves information referencing “who knows who?”).

Parts List

Example: A directory can contain other directories, files and connections. If one directory is deleted, then all its elements are, too. Individual elements from a directory can be saved in other locations. That way everything remains one unit, but some stand alone.

Knowledge Base: partial list


  • Relationship type: Composition
  • Aggregate object and partial objects can be one unit or handled individually.
  • Partial objects can also be allocated to other aggregate objects.
  • The aggregate class cardinality is 0…1.
  • An object can be made from multiple objects of different types.
  • Special case for parts list: An object can only be made up of objects of the same type.

Changing Roles

Examples: A publicly registered doctor works the first and second halves of 2016 as an employed doctor. On 01.01.2017, she receives her licence. Information on employed and licenced doctors can be differentiated.

Knowledge Base: change roles


  • Relationship type (in reference to roles): Generalization
  • A real-world object can take on different roles during different time periods. These roles can also have different properties and operations.
  • Object relationships between objects and their roles can only be expanded, not deleted or presented to other objects.


Example: There are multiple employees in a department. A department can exist without employees for a short amount of time (Cardinality: *) or has to immediately contain at least one employee (Cardinality: 1…*).

Knowledge Base: analysis pattern group


  • Relationship type: Single association
  • A group object contains multiple individual objects at one point in time.
  • Modelling decision to be made: Groups can exist without individual objects or have to have at least one (effects on cardinality).
  • Object relationships can be built and dismantled.

Group History

Example: Membership of a group should be recorded for a period of time.

Knowledge Base: analysis pattern history


  • Relationship type: Association
  • Individual objects belong to different group objects over time.
  • Existing object relationships remain the same, new ones can be added.
Download Whitepaper Planning and control in large agile projects

Knowledge to go

Project planning and control in agile and hybrid projects

PDF to download »

More Downloads

  • Whitepaper
  • Tips & Tricks
  • Software

Downloadcenter »

How to Use Analysis Patterns in objectiF RPM

objectiF RPM offers a pattern catalog for analysis patterns as per Balzert. To apply a pattern, mark a folder or package. Then right-click and select the command apply pattern… . There you decide which templates are needed for an analysis pattern. The necessary classes and attributes are then generated and you can create a UML class diagram.

Knowledge Base: objectiF RPM use analysis patterns