Introduction and manifesto for event model patterns

This booklet is published under the terms of the licence summarized in footnote 1.

‘One must be careful to define an event clearly - in particular what the initial conditions and the final conditions are’. Richard Feynman writing on quantum electro dynamics

This is a unique book on event modeling. It says many new things and challenges prevailing orthodoxies.

The book presents a new knowledgebase of patterns for drawing event models. Event 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 process structure that meets performance requirements and can be readily maintained.

This book is perhaps the first to take a view of event modeling that applies equally to object-oriented software design and procedural program design in enterprise applications. It presents principles that apply to classes and objects as well as procedures.

Readers will range from analysts and designers working on enterprise applications, to students of computer science. For readers familiar with UML, an event model is a kind of object Interaction structure; you may choose to stereotype the control object with <<event>> and other objects with <<entity>>.

Helping professional analysts and designers

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.

Enterprise applications are driven by events. Events maintain state by imposing and assuring business rules. Yet knowledge of how to build event models to capture business rules and ensure data integrity is thinly distributed. This book can help anybody who works on enterprise applications.

Your time is at a premium. Patterns save you time. You can apply many of the patterns immediately. They help you:

· adopt modern analysis techniques that work with new technologies

· extend database development methods with object-oriented analysis

· understand and address the limitations of object-oriented analysis and design methods.

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.

A new angle for academics

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.

The place of event models within a logical model

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 structural things/features in the companion volume “The entity modeler”, and very briefly on this one. This book focuses on modeling behavioral things/features in the form of event models; see the How and When columns 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

In ordinary conversation, event can mean an event instance (a message or process) or an event type (a class of events). 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 event and model according to their context, as you do in conversation.

Events drive enterprise applications. An event model shows how an event affects entities. Event models are used by software engineers working on enterprise applications to:

· refine higher-level requirements and use case models

· facilitate discussions with business people and clarify requirements

· specify the business rules and processing constraints for developers

· specify control objects and Interaction structures

Trying to meet all of these goals in one model creates some tensions that are reviewed in this book.

Helping the Agile Modeler

The Modeler 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 Modeler knows a variety of approaches and embraces the philosophy of a well-known guru.

“It is important not to be dogmatic. Every approach has its advantages and limitations. You must use a mixture of approaches in the real world and not mistake any one of them for truth”. James Rumbaugh

The Agile Modeler keeps event models simple, is aware of different modeling options, understands trade offs between them, and introduces complexity only when and where it is needed.

Getting event models "right" is not straightforward. Event modelers face awkward questions to be explored later. It helps to understand patterns and transformations in models.

Analysis patterns manifesto

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), state-transition diagrams (aka state charts) and interaction structures and to be aware of possible transformations between related patterns. 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 modules, 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.

Event modelling manifesto

If only the OMG (Object Management Group) could host an EMG (Event Management Group) whose beliefs and ideals could be encapsulated in the following manifesto:

EMG 1: A software system does nothing but validate input data, store persistent state data, and derive output data from inputs and state.

EMG 2: The first challenge in application design is to maintain data integrity by defining business rules and controlling the many users and many clients that may update shared state; the second is to synchronise duplicated state; the third is to synchronise distributed state.

EMG 3: The ideal is to build applications on top of a service-oriented architecture.

EMG 4: Three levels of process specification can and should be distinguished: long-running business processes, shorter running use cases and atomic business services.

EMG 5: Entity-oriented and event-oriented views of a system are complementary, equally important, and united by event effects (each the effect of a transient event on a persistent entity).

EMG 6: Analysts must posit transaction management of events, and the key specification artefact is the event effect (not the operation(s) that implement an event effect).

EMG 7: Business rules are invariants of state and preconditions and post conditions of event effects; volatile rules should be stored as user-updatable attribute values.

EMG 8: Caching persistent data outside the persistent data store is an optimisation technique, not a design principle.

EMG 9: Persistence and flexibility undermine class hierarchies and aggregates; the more numerous and long-lived the entities, the less fitting the class hierarchy; the more multi-dimensional the entity model, the less fitting is the aggregate entity

EMG 10: The art, the skill, the goal of the architect and the analyst is to keep the design as simple as possible.

References

Assenova P. and Johannesson P. [1996] Improving Quality in Conceptual Modeling by the Use of Model transformations Stockholm University

Boman M. et al. [1993] Conceptual Modeling Stockholm University

Booch G. [1994] Object-Oriented Analysis and Design. Benjamin Cummins

Darwin C. The Origin of Species J M Dent and Sons (1956 edition, pp 56 and 59)

Dawkins R. The Blind Watchmaker

Gamman 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. London

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, Dublin City University.

Berrisford G. [1996] Database Newsletter Vol. 24 No. 6 Database Research Group Inc.

Berrisford G. [1997] The Journal of Object-Oriented Programming SIGS publications New York

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] chapter 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