This booklet is published under
the terms of the licence summarized in footnote 1.
This is not the first book on entity modelling. This one begins by reviewing well-established principles. But it goes on to say many new things, and it ends up challenging the prevailing orthodoxies.
Is this a book on logical data modeling for analysts?
Yes. It is about ways to define a logical data model that specifies business rules.
Is this a book on physical data modeling for database designers?
Not really. It does have some relevance to defining a physical data model that becomes an efficient database structure, but this is not the main aim.
Is this a book on class diagramming for OO programmers?
Yes. It is meant to be about ways to define an OOP "class diagram" that can be implemented as Java classes on an app server.
This book takes a view of entity modelling that spans conventional relational data analysis and object-oriented software design for enterprise applications. It presents principles that apply to drawing database schemas and object-oriented class diagrams. It suggests object-oriented and relational paradigms are narrow views of a broader field.
The book presents a new knowledgebase of patterns for drawing an entity model. Entity model patterns are analysis patterns first and design patterns second. The analysis goal is to find out what the business rules are and specify them correctly. The design goal is to design a structure that meets performance requirements and can be readily maintained. The book presents a new knowledgebase of transformations between closely related patterns that help you to meet these goals.
Readers will range from analysts and designers working on enterprise applications, to students of computer science. For readers familiar with UML, an entity model is a kind of a class diagram; you may choose to stereotype the classes with <<entity>> under the class name.
It has been reported that 70% of the world’s programmers are writing code for enterprise client-server systems. An enterprise application supports a business by providing it with information about the real-world objects that the business seeks to monitor and perhaps control.
At the back end of an enterprise application are the layers of software that manage the stored data. Software that manages data about the real world is crucial. The enterprise has to invest a lot of time and money in specifying and coding business rules to ensure its stored data tells a true and consistent story about the business domain the enterprise operates in. Data integrity is the challenge for enterprise architects.
Almost every enterprise application is built on top of an entity model. Yet knowledge of how to build an entity model to capture business rules and ensure data integrity is thinly distributed. This book is immediately help to anybody working on an entity model.
Your time is at a premium. Patterns save you time. You can apply many of the patterns immediately. They help you
It is clear that many, perhaps most, applications have been written with little or no methodology. But most of our legacy systems only worked properly after a protracted process of iterative development, they contain redundant code and they are difficult to maintain.
The beginning of wisdom for an analyst or designer is to realise that a one-dimensional methodology, be it object-oriented or relational, is only part of what is needed.
This book describes the specification of business rules and constraints in a style that can be reconciled with formal specification. In doing so, I hope to break the stranglehold that the ‘object model’ ‘and relational theory’ and have over university teaching. Both theories make good servants and poor masters.
We need a broader theory that encompasses process structure as well as data structure, and event-orientation as well as object-orientation. This book also sheds light on various debates about object-oriented software design. E.g. it illuminates the difference between type-based and state-based theories of what a class it.
Models are tools we use to analyse and define the
requirements for software systems. A comprehensive model defines both
structural things/features and behavioral
things/features. I discuss the modeling of behavioral things/features in a companion volume, “The
Event Modeler”, and only very briefly in this one.
This book focuses on modelling structural things/features in the form of an entity model; see the What
column in the table below.
Models are drawn at
various levels of abstraction, from models of code in a specific programming
language, through specifications for such code, to specifications of an
enterprise regardless of any software that might be written. This book
focuses on the specification of an enterprise application; on the middle row in the table below.
The table below is the RAP group modelling framework.
|
Orientation Level |
Structural model |
Behavioural
Models |
|
|
What |
When |
How |
|
|
Conceptual model |
Real world entities |
Business processes |
Real world events |
|
Logical model |
Data entities |
Entity life
histories |
Data events |
|
Physical model |
Entity objects and
database tables |
State constraints
on procedures |
Control objects and
services |
David Hay (ref 99), who
draws entity models for the purpose of enterprise modeling,
has given me permission to copy substantial chunks of my email dialogues with
him.
In ordinary conversation, entity can mean an entity instance
(an object) or an entity type (a class of objects). Similarly, model can mean a
live model (a running enterprise application models the real world) or a dead
model (a specification for a live model). I started writing this book with
careful attention to such distinctions. This pedantry made the text unreadable.
I believe you will find it is easier to interpret the words entity and model
according to their context, as you do in conversation.
An entity model lies at the heart any enterprise application. An entity model shows a structure of
entities, attributes and relationships, annotated with business rules. Entity
models are used by software engineers working on enterprise applications to:
Trying to meet all of these goals in one model creates some tensions that are reviewed in this book.
The Modeller traditionally takes the view that specification and design up front are important.
The Agilist tends to the view that design up front is a waste of time, that models are a distraction from real work, that success depends mostly coding, testing and verbal communication.
The Agile Modeller knows a variety of approaches and embraces the philosophy of a well-known guru.
The Agile Modeller keeps an entity model simple, is aware of different modeling options, understands trade offs between them, and introduces complexity only when and where it is needed.
Getting the entity model
"right" is less straightforward than a course in either
object-oriented design or relational data analysis might lead you to believe.
Entity modelers face awkward questions to be explored
later. When should I include a class hierarchy in an entity model? When should
I build constraints into an entity model and/or database structure? It
helps to understand patterns and transformations in models.
It is increasingly apparent that analysis and design processes are not enough. There is more wisdom to be taught through patterns for analysis and design, and rules of thumb, than through the stages and steps of a process
The analysis patterns in this book are similar to object-oriented design patterns in some ways, and different in others. I will highlight a few points of correspondence, but the emphasis here is mostly on analysis and design questions for enterprise applications.
For more years than I care to remember, I have taught analysts and designers to recognise patterns in entity models (cf. class diagrams) and other kinds of model. As long ago as 1994, Grady Booch pointed out the kinship between my ‘analysis patterns’ and Coplien’s work on ‘generative patterns’ for object-oriented design. This prompted me to document my patterns more thoroughly. I ended up with many more patterns than one book can accommodate, so I have to publish the entity model patterns and event model patterns separately.
· Patterns raise productivity. They speed up thinking and help you to avoid mistakes. They apply equally to rapid and slow development, to engineering of new systems and reengineering of legacy systems.
· Patterns raise quality. They help you to elicit requirements. They prompt you to ask business analysis questions and quality assurance questions. Look out for the bad patterns as well as the good ones.
· Patterns connect things. They are recognisable structures or templates that capture expert knowledge about connecting the components, classes and objects of a software system, via interfaces, relationships and events.
· Patterns make wider connections. They enable you to link apparently distinct analysis and design techniques, coordinate different views of a system into one coherent specification, reconcile object-oriented and relational ways of thinking.
· Analysis patterns help you to get things right, discover the relevant requirements and design so as to minimise redundancy. If one or two of the patterns and questions save you a few days effort, then this book will have paid its way.
|
Assenova P. and Johannesson P.
[1996] Improving Quality in Conceptual Modelling by the Use of Model
transformations |
|
Boman M. et al. [1993] Conceptual Modelling |
|
Booch G. [1994] Object-Oriented Analysis and
Design. Benjamin Cummins |
|
|
|
Dawkins R. The Blind Watchmaker |
|
Gamma E. et al. [1995] Design
Patterns Addison Wesley |
|
Graham I. [1993] Object-oriented
Methods Addison Wesley |
|
Halpin T. [1995] Conceptual Schema and Relational
Database Design Prentice Hall |
|
Hoare A. [1986] Communicating
Sequential Processes Prentice Hall |
|
Hay D. Data
Model Patterns ISBN:
0-932633-29-3 |
|
Jackson M. [1975] Principles
of Program Design Academic Press |
|
Jackson M. [1994] Software Engineering Journal |
|
Mellor S.J. & Shlaer S. [1988] Object-Oriented Analysis Prentice Hall |
|
Meyer B. [1988] Object-Oriented
Software Construction Prentice Hall |
|
Ovum Evaluates: Workflow (1995) Ovum Ltd. |
|
Palmer J. [1993]
‘Anti-hype’ in Object Magazine. May-June issue. |
|
Partridge C. [1996] Business
Objects: Reengineering for Reuse
Butterworth Heinemann |
|
Robinson K. &
Berrisford G. [1994] Object-Oriented SSADM. Prentice Hall |
|
Berrisford G. [1995a] ‘How the fuzziness of the real world limits reuse by inheritance between business objects’ Proceedings of OOIS ‘95 conference, Dublin City University. |
|
Berrisford G. [1995b] ‘A review of object-oriented for
IS’ Proceedings of OOIS ‘95 conference, |
|
Berrisford G. [1996] Database
Newsletter Vol. 24 No. 6 Database
Research Group Inc. |
|
Berrisford G. [1997] The
Journal of Object-Oriented Programming
SIGS publications |
|
Berrisford G. & Burrows
M. [1994] ‘Reconciling object-oriented with Turing Machines’ Computer
Journal Vol. 37, No. 10 |
|
Berrisford G. Burrows M. and Willoughby A. [1997] paper for the OOPS group of the British Computer Society |
References
Ref. 1: Various papers in the Library at http://avancier.co.uk
Footnote 1: Creative Commons
Attribution-No Derivative Works Licence 2.0
Attribution: You may copy,
distribute and display this copyrighted work only if you clearly credit
“Avancier Limited: http://avancier.co.uk”
before the start and include this footnote at the end.
No Derivative Works: You may
copy, distribute, display only complete and verbatim copies of this page, not
derivative works based upon it. For more information about the licence, see http://creativecommons.org