Patterns and Anti-Patterns in Object-Oriented Analysis

240 Pages·2004·0.74 MB·English

Katholieke Universiteit Leuven
Faculteit Toegepaste Wetenschappen
Departement Computerwetenschappen

Patterns and Anti-Patterns in
Object-Oriented Analysis

Promotor: Proefschrift voorgedragen
Prof. dr. ir. E. Steegmans tot het behalen van het
doctoraat in de toegepaste
wetenschappen door
Frank Devos
Abstract

The major goal of analysis is to establish the functional requirements of the
system to be developed and to establish the real-world facts that are involved
in these requirements. Because every system is concerned with a certain
reality outside itself, analysis of real-world facts is a necessary step in the
system development cycle. Analysis is gaining importance as the demand for
complex systems grows. It helps developers to understand and document the
business domain. Moreover, analysis helps in detecting errors early in the
development cycle, thereby reducing the cost to correct them.
In this work, an object-oriented approach was adopted to perform
analysis. It is generally accepted that this approach offers significant
advantages over more traditional advantages. These advantages are mainly
due to proper support for encapsulation, decomposition, specialization and
polymorphism. However, we observed that there still exist some serious
problems in applying an object-oriented approach during analysis. We
believe that the major problems are due to the vague border between analysis
and design, to the lack of adequate modelling constructs, guidelines and
quality criteria and to problems in transitioning from analysis to design.
The goal of this thesis is threefold. A first objective is to evaluate a
part of the Unified Modeling Language (UML), the default standard
modelling language for object-orientation, as a language for analysis. A
second objective is to offer patterns that guide the analyst in building quality
models and allow him to focus on the business domain. A third objective is
to define principles that help to evaluate modelling language constructs and
guidelines.
We do not consider the UML in its present form as an appropriate
modelling language for precisely and completely specifying functional
requirements and observed facts in the business domain. Several patterns
will be described to represent objects, properties, business rules and
functional requirements. Seven principles, such as the principles of
completeness, abstraction and extendibility, will be defined to evaluate the
proposed modelling constructs and guidelines.
i
Acknowledgments

“Doctoreren es vele schriv’n”
“Wat niet gemodelleerd kan worden is de waarheid niet”

No thesis is written in a vacuum. During the long process of writing I have
received support, without which this thesis would not exist, from colleagues
and loved ones.

First of all, I would like to especially thank Prof. Dr. Eric Steegmans, the
promoter of this thesis. I am in debt for the time he has spent with me in
almost endless discussions. I highly appreciate the fruitful and constructive
meetings, during which he provided me with valuable insights. I wish to
express my sincere gratitude to him.

My thanks go to the other members of the reading committee, Prof. Dr.
Carlos De Backer and Prof. Dr. Karel De Vlaminck, for their comments,
which have improved the quality of this text, and to the other members of the
jury for taking the time to read the text.

It is a pleasant task of acknowledging the help of colleagues and friends of
the Software Development Methodology research group. But very special
thanks to Geert Delanote and Pieter Bekaert for the discussions and
suggestions on many obscure topics, including football and politics.

Special thanks and appreciation goes to my family and friends for their
encouragements. By continually asking me about the date of defence of this
thesis, the social pressure was kept high enough not to give up.

Last but by no means least, I want to thank Katelijne, my spouse and anchor
point. My life would never have been the same without her.

iii
Contents

Abstract
Acknowledgements
Chapter 1 Introduction...........................................................................1
1 Software Engineering..........................................................................2
1.1 Analysis.....................................................................................2
1.2 Design.......................................................................................5
1.3 Implementation and Deployment..............................................5
2 An Object-Oriented Approach for Analysis........................................6
2.1 Principles and Concepts............................................................6
2.2 Current Practices.......................................................................6
3 Problems with Object-Oriented Analysis............................................7
3.1 The Boundary between Analysis and Design...........................8
3.2 The Modelling Constructs.......................................................10
3.3 The Modelling Guidelines.......................................................12
3.4 The Modelling Quality Criteria...............................................14
3.5 The Transition into Design......................................................16
4 Goals of the Thesis............................................................................17
4.1 The UML and Conceptual Modelling Constructs...................17
4.2 Patterns and Anti-Patterns.......................................................19
4.3 Principles for Conceptual Modelling......................................20
5 Overview of the Thesis......................................................................26
Chapter 2 Patterns for Modelling Static Properties..........................27
1 Structuring Static Properties............................................................28
1.1 Problem Description.................................................................28
1.2 Anti-Patterns.............................................................................29
1.3 Patterns......................................................................................31
v
2 Modelling Links between Objects and Data Values.........................34
2.1 Problem Description.................................................................34
2.2 Anti-Patterns.............................................................................35
2.3 Patterns......................................................................................43
3 Modelling Links between Objects.....................................................45
3.1 Problem Description.................................................................45
3.2 Anti-Patterns.............................................................................46
3.3 Patterns......................................................................................47
4 The Use of Primitive Data Types and Units.....................................48
4.1 Problem description..................................................................48
4.2 Anti-Patterns.............................................................................48
4.3 Patterns......................................................................................49
5 Restricting the Set of Data Values....................................................50
5.1 Problem Description.................................................................50
5.2 Anti-Patterns.............................................................................51
5.3 Patterns......................................................................................51
6 Extending the Multiplicity of a Characteristic..................................52
6.1 Problem Description.................................................................52
6.2 Anti-Patterns.............................................................................52
6.3 Pattern.......................................................................................53
7 Modelling Dependencies between Static Properties.........................54
7.1 Problem Description.................................................................54
7.2 Anti-Patterns.............................................................................55
7.3 Patterns......................................................................................61
8 Partial Characteristics......................................................................62
8.1 Problem Description.................................................................62
8.2 Anti-Patterns.............................................................................63
8.3 Pattern.......................................................................................65
9 Avoiding Non-Definedness................................................................69
9.1 Problem Description.................................................................69
9.2 Anti-Patterns.............................................................................70
9.3 Patterns......................................................................................72
10 The Third Normal Form in Object-Oriented Analysis......................74
10.1 Problem Description.................................................................74
vi
10.2 Anti-Patterns.............................................................................74
10.3 Patterns......................................................................................76
11 Other Normal Forms in Object-Oriented Analysis...........................79
11.1 Problem Description.................................................................79
11.2 Patterns......................................................................................79
12 Modelling Dependencies on the Model Layer..................................82
12.1 Problem Description.................................................................82
12.2 Anti-Patterns.............................................................................83
12.3 Patterns......................................................................................83
13 Encapsulation during Analysis.........................................................85
13.1 Problem Description.................................................................85
13.2 Anti-Patterns.............................................................................87
13.3 Patterns......................................................................................87
Chapter 3 Patterns for Modelling Dynamic Properties.....................89
1. Modelling Prototypes of Dynamic Properties..................................90
1.1 Problem Description.................................................................90
1.2 Patterns......................................................................................90
2. The Frame Problem during Analysis................................................97
2.1 Problem Description.................................................................97
2.2 Anti-Patterns.............................................................................98
2.3 Patterns......................................................................................99
3. Refinement of the Inertia Principle.................................................102
3.1 Problem Description...............................................................102
3.2 Patterns....................................................................................102
4. Relaxation of the Inertia Principle..................................................105
4.1 Problem Description...............................................................105
4.2 Anti-Patterns...........................................................................105
4.3 Patterns....................................................................................106
Chapter 4 Patterns for Modelling Properties...................................115
1 Features involving more than one Object.......................................115
1.1 Problem Description...............................................................115
1.2 Anti-Patterns...........................................................................116
vii
1.3 Patterns....................................................................................123
2 Features involving no Objects or artificial Objects........................130
2.1 Problem Description...............................................................130
2.2 Anti-Patterns...........................................................................130
2.3 Patterns....................................................................................133
Chapter 5 Patterns for Modelling Restrictions................................137
1 Introduction....................................................................................137
1.1 Restrictions.............................................................................137
1.2 Constraints during Analysis and Design.................................138
2 Modelling Restrictions on Static Properties...................................139
2.1 Problem Description...............................................................139
2.2 Anti-Patterns...........................................................................140
2.3 Patterns....................................................................................146
3 Modelling Restrictions on a Dynamic Properties...........................150
3.1 Problem Description...............................................................150
3.2 Anti-Patterns...........................................................................151
3.3 Patterns....................................................................................157
4 Relaxation of the Principle of Non-Violation.................................163
4.1 Problem Description...............................................................163
4.2 Anti-Patterns...........................................................................164
4.3 Patterns....................................................................................166
5 Relaxation of the Frame Axiom......................................................171
5.1 Problem Description...............................................................171
5.2 Anti-Patterns...........................................................................171
5.3 Patterns....................................................................................172
6 Implicitly or Explicitly modelled Class Constraints.......................177
6.1 Problem Description...............................................................177
6.2 Anti-Patterns...........................................................................177
6.3 Patterns....................................................................................179
Chapter 6 Patterns for Modelling Classification..............................183
1 The Generalization-Specialization Relationship............................184
1.1 Problem Description...............................................................184
viii
1.2 Anti-Patterns...........................................................................185
1.3 Patterns....................................................................................186
2 To generalize or not to Generalize Classes and Model Elements of
Classes...................................................................................................189
2.1 Problem description................................................................189
2.2 Anti-Patterns...........................................................................190
2.3 Patterns....................................................................................191
3 Modelling Particulars.....................................................................197
3.1 Problem Description...............................................................197
3.2 Anti-Patterns...........................................................................198
3.3 Patterns....................................................................................201
Chapter 7 Patterns for Modelling Requirements.............................205
1 Modelling Functional Requirements...............................................205
1.1 Problem Description...............................................................205
1.2 Anti-Patterns...........................................................................206
1.3 Patterns....................................................................................211
Chapter 8 Conclusions........................................................................219
1 Contributions..................................................................................219
1.1 Evaluation of the UML for Conceptual Modelling.................219
1.2 Patterns for Conceptual Modelling.........................................220
1.3 Principles for Conceptual Modelling......................................224
2 Future Work....................................................................................225
Bibliography
Curriculum Vitae
Publications
Nederlandse Samenvatting
ix
Chapter 1

Introduction

Analysis is one of the first phases in software development. During this
phase, the functional requirements of the software system to be developed
are specified. This specification is built in terms of facts that have been
observed in the problem domain or business domain. The problem domain is
defined as that part of the real world that is of relevance for the envisaged
system.

The object-oriented paradigm is a software development approach covering
all phases of the life cycle of a software system, including analysis. The
object-oriented approach focuses on identifying and interrelating objects
with their corresponding characteristics and behaviour. In analysis, this
result in a model that describes all relevant real-world objects, including
their business rules.

A pattern is a description of a solution to a recurring problem within a
certain context. A pattern must describe how it resolves the stated problem
and why it is a good solution. We need both arguments to convince us that
the pattern is neither pure theory nor blindly following others [App97].

It is often useful to study how problems should not be solved. Understanding
a bad solution can help to determine the good ones. An anti-pattern is the
description of a bad solution to a recurring problem. An anti-pattern must
describe why it is not a good solution.

In this chapter, the title of this thesis will be further unravelled. In section 1,
the purpose and the need for an analysis phase is described and positioned in
the software life cycle. In section 2, the object-oriented approach for analysis
is briefly introduced and its main characteristics are discussed. Section 3
reveals some major problems and difficulties with current practices of
1
Chapter 1. Introduction

object-oriented analysis. In section 4, the goals of this thesis are given. In the
last section, an overview of the thesis is given.

1 Software Engineering

In software engineering, as for other engineering disciplines, the
development of a system is divided into a number of activities. Analysis,
design, implementation and deployment are common names for some of the
phases in the software life cycle. The exact number and naming of the
phases may vary between the different life cycle models. In the next
subsections, the different phases are positioned in the software life cycle.
The emphasis is on the analysis phase.

1.1 Analysis

1.1.1 The Purpose of Analysis

The major purpose of analysis is to establish the functional requirements
raised by the clients and to be solved by the system. As promoted eloquently
by Jackson [Jack83, p.4], a developer should begin by creating a model of
reality, followed by a description of the functional requirements that is based
on the created model of reality. Jackson argues that this principle promotes
extendibility, preciseness and communication. We claim that functional
requirements cannot be precisely described without detailed knowledge of
the real world that is relevant for the envisaged system. If this knowledge is
absent, a designer cannot be blamed that important aspects in the ultimate
system are overlooked. For instance, in such a case it is possible that the
ultimate system violates important business rules. In this thesis, it is assumed
that the relevant real-world knowledge and the functional requirements must
be completely and formally specified. The results of the analysis activity are
expressed in a conceptual model. These results are primarily intended as
input for the design phase.

2