Analysis Patterns. Solution Models for Subject Domain Problems.
What is an analysis pattern? What advantages does it offer and what analysis templates are there?
What Is an Analysis Pattern?
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.
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 »
10 General Analysis Patterns
(from H. Balzert: Object Management Handbook)
List
Example: An invoice contains one or more items.
Properties
- 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.
Properties
- 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.
Component
Example: A motorbike has a motor and two wheels. These are physical objects.
Properties
- 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.
Roles
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.
Properties
- 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.
History
Example: An employee has multiple tasks in a business. Only one can be valid at any time. The employee is also studying.
Properties
- 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.
Coordinator
Example: A student takes part in a professor’s exam.
Properties
- 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.
Properties
- 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.
Properties
- 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.
Groups
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…*).
Properties
- 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.
Properties
- Relationship type: Association
- Individual objects belong to different group objects over time.
- Existing object relationships remain the same, new ones can be added.
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.
