M.E.R.O.DE.: A Model-driven EntityRelationship Object-oriented DEvelopment method
section demonstrates how exactly the formal definition of M.E.R.O.DE. results in a gain of quality at the software specification level.
1. Reviewing current OOA methods appeared in ACM SIGSOFT Software Engineering Notes, Vol. 19, No. 3, 1994 Correctness of an information system can be defined as follows [18, p.4]: Prof. dr. G. Dedene
M. Snoeck
Katholieke Universiteit Leuven Dept. of Applied Economic Sciences Dekenstraat 2, 3000 Leuven, Belgium Tel. 32 16 28 58 04 Fax. 32 16 28 57 99 Email:
[email protected] [email protected]
Abstract Object Orientation has as primary goal to improve the software construction process. Object Oriented analysis, design and software construction should yield software of a high quality: software that is reliable, maintainable, extensible, adaptable. However, delivering large OO software systems in a qualitative way is a significant challenge. Scaling up requires formal precision of the semantics of the modelling techniques and languages used by the development team. And when the target system contains an abundance of parallelism, the problem of validation becomes unfeasible if it is not supported by formal techniques. With the incorporation of formal techniques in the development process, we can expect significant benefits in terms of software quality. For this reason, one might expect a high level of formality in current OOAD methods [9]. Unfortunately, most current OOAD methods are characterised by a low level of formality. The M.E.R.O.DE. methodology addresses this void. By making use of algebra, the methodology has been provided with a formal basis at several levels with a significant improvement of the quality of the software development process as a result. Before presenting M.E.R.O.DE. to the reader in the second section, the first section motivates the development of still another OOA method. The final
Correctness is the ability of software products to exactly perform their tasks, as defined by the requirements and specifications Meeting this goal demands that requirements and specifications are expressed in a completely formal way. Indeed, it is a well known fact that informal specifications lead to misunderstanding and thus to incorrect software. The need for formality has also been acknowledged by the object oriented community [9]. It is therefore surprising that the most recently developed object oriented analysis (OOA) methods are characterised by a low level of formality. The main goal of M.E.R.O.DE. is to address this void. An interesting overview of current OOAD research has already been published in [19]. This paper evaluates the various OOAD methods from a point of view of completeness with respect to the development process as well as representations for the various views on the specifications (static, dynamic, interaction). We will describe some of the more important methods from a different point of view, namely: the level of formality of the techniques used for describing the different views on objects and how correctness of the different views and consistency between views is achieved. This overview is not intended to be exhaustive, but rather to provide the reader with some relevant examples. Figure 1 lists the reviewed methods. author(s) method references 1. Rumbaugh et al. OMT [22] 2. Hayes, Coleman FUSION [14, 7] 3. Embley et al. OSA [12] 4. Shlaer, Mellor OOSA [23, 24, 17] 5. Coad, Yourdon OOA [6] 6. Kappel, Schrefl Object/Behaviour (O/B) [16]] 7. Booch OOD [2, 3] 8. Wirfs-Brock Designing Object[Error! Bookmark not defined.] Oriented Software (DOOS) figure 1: Reviewed OOA-methods
In order to evaluate the use of formal techniques in detail, a number of criteria are formulated. A complete analysis should at least model the following elements: the static aspects of the objects, the behavioural aspects (methods and sequence restrictions) and the way objects communicate with each other. The reviewed OOA methods all have a combinative approach to software development: different techniques are used to model the different aspects of the information system. Whether or not these techniques deserve the label "formal", depends on a number of elements. First of all, the method should have its own definitions for the syntax and semantics of the used techniques. Of course many techniques have repeatedly been formally defined. However, most methods extend the "standard" version of these techniques with proper constructions without giving a formal definition. An adequate formal definition is therefore a proper definition that completely defines syntax as well as semantics. This leads to the first six criteria: 1A, 1B, 1C:
2A, 2B, 2C:
Does the method have a proper formal definition of the syntax of the technique used for modelling the static, dynamic and object-interaction aspects ? Does the method have a proper formal definition of the semantics of the technique used for modelling the static, dynamic and object-interaction aspects ?
As all the reviewed methods use different techniques for modelling different aspects, procedures must be provided to integrate the three models with each other. The specifications of the static, dynamic and object-interaction model must be consistent with each other: 3:
Does the method provide a formal procedure for checking inter-model consistency ?
Finally, when dynamic behaviour of separate objects and object-interaction model are combined, it must be possible to derive the overall system behaviour: 4:
Is overall system behaviour defined in terms of individual object definitions and object interaction models ?
When such a definition is present, it should for example also allow to check the overall system behaviour for problematic behaviour such as deadlock or (un)fairness: 5:
Is it possible to check the overall system behaviour for problems such as deadlock or fairness ?
How well (or bad !) the reviewed methods score for these criteria is shown in figure 2. The scores are indicated by means of the symbols '●', '❍', 'o' and '.'.
For the criteria 1A to 2C a '●' means that this method has its proper definition of syntax and/or semantics. A '❍' indicates the use of a more or less standard technique for which formal definitions of syntax and/or semantics can be found in literature. This is the case for the ER-model [5, 20], Finite State Machines [1] and Harel Statecharts [13]. A 'o' means that the technique borrows elements from a "standard" technique, but that it is extended with own undefined features in a substantial way. The use of generalization/specialization hierarchy for example, deserves at least a 'o'. And finally a '.' indicates a technique for which no formal definitions were found. A '●' for the third criterion indicates that the method provides a formal and systematic procedure for verifying inter-model consistency. A '❍' means that no procedure is given, but that we can derive one from the given definitions or that an extended informal procedure can be found. The method scores a 'o' when only a partial procedure is defined and a '.' when the problem of consistency is not even mentioned. OMT FUSION OSA OOSA OOA O/B OOD DOOS 1. Formal definition of syntax of A. Static model B. Dynamic model C. Object interaction model
❍ ❍ .
❍ ● .
● ● ●
❍ ❍ .
o ❍ .
o ● ●
o ❍ .
o . .
2. Formal definition of semantics of ❍ A. Static model ❍ B. Dynamic model C. Object interaction model .
❍ ● .
● ❍ .
❍ ❍ .
o ❍ .
o ● ●
o ❍ .
o . .
3. Inter-model consistency check
o
❍
❍
o
.
o
.
.
4. Formal definition of overall system behaviour
.
❍
.
.
.
●
.
.
.
.
.
.
.
.
.
.
5. Check for problematic system behaviour
figure 2: Formal aspects of OOA methods Finally, a '●' for the fourth criterion means that overall system behaviour has been defined. Only two methods define overall system behaviour, namely Object/Behaviour and FUSION. In the case of FUSION, only static systems are allowed: dynamic creation and deletion of objects is not possible. As this rules
out a substantial class of applications, FUSION gets only a '❍' instead of a●' ' . None of the reviewed methods checks system behaviour for deadlock, fairness or any other kind of problematic behaviour, which explains the full row of ' .' for the last criterion. From this overview it is clear that only a limited use is made of formal techniques. Especially the definition of the syntax and semantics of the dynamic aspects (including global system behaviour) and inter-model consistency checking is poorly addressed. One of the better scoring methods is Object/Behaviour. In this method Predicate/Transition Nets are used to model dynamic behaviour of objects. However, Davis' comparison of techniques for specifying behaviour [8] points out that this technique is hard to understand for non-computer specialists. This is a severe drawback as fluent communication with end-users is essential to get specifications right. Moreover, Petri-nets are quite difficult to check for deadlock. Some kinds of Petri-nets allow for this kind of control, but a large number of problems are still undecidable [21]. The absence of publications on the matter of consistency checking between models or correctness checking for behaviour and interaction models, indicates that formal verification is clearly a very complicated topic. The choice of techniques for modelling dynamic aspects is crucial if we want to obtain feasible verification procedures. According to the authors of FUSION the use of Harel Statecharts does not yield a practical solution for consistency checking [14, p.181]: "In practice, proof (of consistency between models) is totally impractical. Thus we do not expect the analyst to prove consistency between models in the general case. Informal reasoning about judiciously selected examples has to be sufficient" Surely this can't be the right way to ensure qualitative software development !
2. Development with M.E.R.O.DE. A. What's in a name ? M.E.R.O.DE. is an acronym for Model-driven Entity Relationship Object oriented DEvelopment. This OOA-method uses a combinative approach to software development: different techniques are used to model different aspects of the system under development. Before going into the details of the method, the components of the methods name are shortly motivated.
Model-driven In M.E.R.O.DE. a model driven approach is taken to application development [10, 11, 28]. This approach starts from the business functionality, a much more stable base to build applications than the information needs, the basis for the classical waterfall model for application development. The model driven approach recognizes the existence of different levels of abstraction in the development process. The role of these different levels and more especially of the business modelling level are explained in the Zachman framework for Application development [30, 27], which is summarized in the following figure : Models required to represent the Architecture of an Information System: SCOPE MODEL : model the scope and underlying strategy for an information system. BUSINESS MODEL :
model the exact functioning of the business, show business entities, business constraints and business rules.
DESIGN MODEL :
model the information functions for information input and output.
TECHNOLOGY MODEL :
model the system as it is implemented in a particular technology. figure 3 : The Zachman Framework for Application Development.
Entity relationship The Entity Relationship modelling technique [5, 4] (and all its variants) is certainly one of the most widely used techniques for data modeling. Although Entity Relationship still has a number of flaws it is surely one of the most mature formal techniques for modeling static aspects of information systems. In M.E.R.O.DE. the static view on object types in the business model and the design model is represented by means of the Entity Relationship modeling technique. Object Oriented Object Orientedness is a paradigm that covers a large number of concepts such as encapsulation, inheritance, polymorphism, ... Which of these are essential to object orientedness is the subject of ever lasting discussions and in addition,
many of these concepts have varying definitions depending on their application in programming languages, databases, design or analysis. M.E.R.O.DE. does not claim to have incorporated all these concepts in all their possible definitions. However, those concepts which make an analysis method gain in quality are part of M.E.R.O.DE.. The development of an information system with M.E.R.O.DE. will be illustrated by means of a small example: A small organisation collects donations for development aid in Peru. The organisation delivers certificates for gifts of at least 1000 BEF. The giver can use this certificate to deduce the donations from his revenue so that he will pay less income taxes. To motivate the givers to donate more money, Help Peru publishes a quarterly journal with news from the various development projects. Givers can specify to which project their donation must be allocated. Usually givers receive one single fiscal certificate in January for the total amount of donations of the past year. But people can also ask the organisation to send one certificate per gift, immediately after reception of the money.
B. Scope model Help Peru wants an information system for the administration of givers and certificates. The bookkeeping and administration of development projects will be done manually. C. Business model The business model describes the exact functioning of the business in terms of object types, event types and relationships between object types and event types. Object types are the encapsulation of static and dynamic aspects. The static aspects of object types are described by means of the entity relationship modelling technique and an existence dependency graph. Within the delimited scope, two object types are considered to be relevant for the ' Help Peru' -system: PERSON (giver) and DONATION. The object type 'DEVELOPMENT-PROJECT' could be relevant too, but is, in this case, beyond the specified scope. The EntityRelationship model is shown in figure 5:
PERSON PERSON 1:1
0:N
DONATION
DONATION
figure 4: Entity Relationship model for Help Peru
figure 5: Existence Dependency graph for
The relationship between the two object types specifies that a donation is always made by exactly one person (minimum and maximum 1) and that a person can make zero, one or more donations. The existence dependency graph establishes an existence dependency relationship between object types. An object (called 'marsupial' ) is existence dependent on an other object (called 'mother' ) if the life of the first object is always embedded in the life of the latter. In this case, DONATION is a marsupial of PERSON as a donation always belongs to one and the same person (it can not ' change' from person during its lifetime) and information from a person cannot be deleted as long as donations are registered for that person. In the existence dependency graph the mother is drawn above the marsupial and both object types are linked with a solid line as demonstrated in figure 5. The dynamic aspects of object types are described by means of two diagrams. In the first place, an object-event-table (OET) identifies the relevant event types and specifies which kinds of event create (c), modify (m) or destroy (d) occurrences of a particular object type. The OET for Help Peru is depicted in figure 6. Relevant event types for this administration are: create-person = add a new person to the address file. modify-person = modify information about a person. delete-person = delete a person from the address file. register = register a gift. certify = include the donation in a fiscal certificate. delete-donation = delete a donation from the donation file.
and DONATION (figure 7) are exactly those event types for which a ' c' , 'm' or 'd' is drawn in the OET. PERSON
PERSON create-person
C
modify-person
M
DONATION
delete-person
D
register
M
C
certify
M
M
delete-donation
M
D
Once the static and dynamic aspects of object types are defined, the business model is further refined by defining attributes for object types and specifying what happens to an object type when a particular event type occurs. This results in the definition of an abstract data type per object type which contains the state vector for that object type and one method per event type to which this object participates. We exemplify this by defining the state vector for person and the event-method for modify-person: PERSON
state vector: code : unique identification of person; name : name of this person; address : address of this person; zip : postal-code of the city; certify : the value of this attribute specifies whether this person wants fiscal certificates delivered per donation or not.
figure 6: Object-Event Table for Help Peru
PERSON DONATION
deleteperson
createperson
register
certify
deletedonation
*
modifyperson
o
o
o register
certify
deletedonation
o
event-methods: ... person.modify-person code := input-code; name := input-name; address := input-address; zip := input-zip; certify := input-certify; ...
D. Design model figure 7: Structure diagrams for PERSON and DONATION. Secondly, per object type a structure diagram is drawn according to Jackson' s principles of System Development [15]. This structure diagram describes the sequence restrictions each object type imposes on its event types. In this kind of diagrams a ' *' indicates the iteration of a structure and ao' ' indicates an alternative in a selection structure. The event types in the structure diagrams of
The design model, in M.E.R.O.DE. also called function model, defines how information functions provide the end-users of the information system with input and output facilities. The functions are designed as a layer on top of the business model. Two types of functions can be identified: Information functions provide output to the end-user with some predefined screen- or print-layout.
Interacting functions generate events that are transmitted to the business model. Examples of functions for Help Peru are: F1 = F2 = F3 = F4 = F5 = F6 =
Register new person. Find the unique identification of a person, given some data like name or address. Register a donation. Make a certificate for one specific donation. Yearly generation of certificates. For each person print a labels with his/her address. labels F6-REQ
Certificates
F5
Time
components independent of each other, that can easily be plugged in and out the business model. Functions never introduce essential changes to the business model, However, at this stage application object types and event types can be defined. These are event types and object types that are required to fulfil information needs, but which are not essential to the business functioning. For example, suppose that the organisation wants to know how many times a year information about persons is modified. This means we must keep track of the occurrence of the ' modify-person' event. This can be done by introducing an application object type MODIFICATION as shown in figure 9. The static and dynamic views on these object types are modelled in exactly the same way as for business object types. In the remainder of this paper, the terms "object type" and "event type" refer to the business model as well as to the design model object types and event types.
F6
application objects F4-REQ
F2-REQ
PERSON
F4 F2
Person
certificate for one donation
PERSON MODIFICATION
DONATION
business objects
F1-REQ F3 F3-REQ F1
DONATION
figure 8:Design model for Help Peru Both information and interaction functions are allowed to inspect the state vector of objects in order to retrieve information. This is depicted by means of a diamond connected to the function and to the object type. A double bar across the connection between diamond and object type indicates that the function inspects the state vector of more than one object type occurrence. Events are depicted as circles. The design model with the six functions defined earlier is shown in figure 8. This figure also demonstrates that functions are modular
figure 9: Modified object model. A final element in the design model is the definition of transaction objects. Events are atomic units of handling which do not always keep the database in a consistent state (e.g. the deletion of a person while there are still donations
registered for this person). Therefore transactions are defined. Basically, transactions produce streams of correct event messages that leave the database in a consistent state (e.g. deletion of all a persons donations followed by the deletion of that person).
E. Technology Model Although the main emphasis of this paper in on Business and Design modelling, some considerations on how to generate working systems might encourage the practical implementation of M.E.R.O.DE.. Figure 10 is an example of a traditional on-line implementation of the Help Peru system. It is shown as a data flow diagram: Ovals are processes and arrows are data flows. In addition we see a USER sink/source and a State Vector data store. This diagram illustrates how implementation of M.E.R.O.DE. can proceed in traditional CASE-environments.
USER
choice
main selection
trx code
TRX handler trx code
TRX methods
state vector
event & function message
updated state vector
online scheduler event message
function handler
event handler state vector
state vectors
function output
function message
event message
function message
event methods state vector
function methods
figure 10: Generic implementation of a M.E.R.O.DE. business and design model. At the same time it becomes clear how M.E.R.O.DE. business and design models can be implemented in a traditional environment. Of course, object oriented implementation technology will facilitate the implementation dramatically as the object abstract data type definitions can be considered as
object declarations. Although this diagram might suggest a centralised implementation view, nothing prohibits the localisation of the abstract data types of the objects on some server technology while transactions and functions reside on the appropriate clients. This implementation diagram is generic, as most processes are reusable in building different systems. Only the methods are inherited from the business and design model. The scheduler and Handlers are reusable in different development projects. This is one of the enormous extra advantages that results from the use of object oriented techniques, even in the absence of a CASE-tools.
3. The formal definition of M.E.R.O.DE. The business model uses two kinds of schemas to model static aspects: the ERschema and the existence dependency graph. Dynamic aspects are modelled by means of the Object Event Table and JSD-diagrams. Object interaction happens by means of common events and is in this way incorporated in the definition of object behaviour. Within the scope of this paper it would not be useful nor possible to give all the definitions in full details. Hence, only basic and informal definitions of the existency dependency relation and of the structure diagrams will be given. Full aspects of all definitions can be found in [25]. One of the most important features of the formal definition of M.E.R.O.DE. is the clear distinction between object types and objects and between event types and events. The business and function model are formulated in terms of object types and event types. The transition from the type level to objects and events is only necessary for the definition of overall system behaviour and checking this behaviour for deadlock. In what follows the distinction between the type level and the occurrence level will be made consequently. A. Syntax and semantics of the static, dynamic and object interaction models The ER-schema defines entity types and relationship types. Both are considered to be object types. The semantics of the existence dependency graph are a subset of the semantics of the ER-model. The existence dependency (ED) relation is a partial ordering on object types which is defined as follows: Let P and Q be object types. P is existence dependent of Q (notation: P .( || ) if a=b ∈ α ∩ α' (2) || = if a ∉ α' = (6) ) + (
