M.E.R.O.DE. - Model driven Entity-Relationship Object-oriented DEvelopment technique

ONDERZOEKSRAPPORT NR 9211 M.E.R.O.DE. - Model driven Entity-Relationship Object-oriented DEvelopment technique by Guido DEDENE Serge DESARANNO Carine VAN DEN ACKER D/1992/2376/14

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique - page 1 M.E.R.O.DE. Model driven Entity-Relationship Object-ori~nted DEvelopment technique Prof. Dr. Guido Dedene, Serge Desaranno, Carine Van den Acker* Katholieke Universiteit Leuven Dekenstraat 2 B-3000 Leuven This paper was presented at the second International Federation of Operational Research Societies conference on the Transition to Advanced Market Economies in Warsaw, June 22-25, 1992. ABSTRACT This paper provides an overview on M.B.R.o.DB., a methodolog,y for desig.aing flexible information systems. M.B.R.O.DB. is believed to be a cure for current software maintenance problems. Following an introduction on the ~ortance of adequate information systems, the need for new design methods is illustrated in a first section. A second part deals with a brief discussion of the M.B.R.O.DB name co.q>onents. How the M.B.R.o.DB. approach is to be applied :ts explained :tn the third section. 'l'ecnn:tcal deta:tls were consc:tously c:trcumvented and e.q>hasis was put on M.B.R.O.DB. 's capac:tty to deliver flexible :information systems. T.be fourth section introduces the P~ ~. oil c~any as a case study on which M.B.R.o.DB. :ts illustrated, whereas a f:l.fth section :includes the system's desig.a for the same oil c~ai'l.y accord:l.ng to a c~et:tng development technique. In the s:txth sect :ton both result:l.ng spec:tf:tcat:tons are confronted w:tth two sources of change :tn order to demonstrate the:tr respective ab:tlity to deal w:tth new de.m.!u'lds. Finally, conclus:tons are summarized and add:l.tional features are ment:toned. INTRODUCTION For all kinds of organizations to succeed, they need to be able to process data and use information effectively. This has become especially true in today's rapidly changing environment. In conducting their day-to-day operations, organizations use information for functions such as planning, controlling, organizing and decision making. As a consequence, information is undoubtedly a critical resource in the operation of all organizations. Any means, mechanical or otherwise, which can help organizations process and manage information presents an opportunity they can ill afford to ignore. The introduction of the computer and its use in data processing has been one of the most important organizational innovations in the past thirty years. The progress of computer-based data processing and information systems has enabled organizations to cope with the vast quantity of information that needs processing and managing for the company's survival. Partly because of the dynamic world that we live in (and the concomitant need to process more information), and partly because of the dramatic recent developments in information technology, e.g. personal computers, fourth generation languages, relational databases, knowledge-based systems and office automation, the relevance and importance of proper information system construction has become apparent. ON THE USEFULNESS OF MISTAKES As much as in modern business life information systems (Is's) are willingly associated with strategic issues (e.g. competitive advantage), expectations All three authors are members of the LIRIS group (Leuven Institute for Research on Information Systems), Dekenstraat 2, B-3000 Leuven. An elaborate discussion of M.E.R.O.DE. can be found in Verhelst, Maurice : Objectgerichte systeemontwikkeling : een praktische aanpak met JSD en M.E.R.O.DE., Kluwer, Deventer, 1992, 334 p. (an English version from the same author is to be published).

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 2 towards these systems are strongly enhanced. Having left the _stage of bread-and-butter applications behind them Western compan1es are increasingly devoting their attention to a more noble domain of software construction. In this process efforts are not always directed as one would prefer them to be and initial expectations are bound to become no more than hopes. Unlike solutions to these problems, reasons are easier to find. Several sources (1) report that 80 % or more of software costs are spent on maintenance. This alarming percentage makes it easy to see that the expectations mentioned above are hard to meet. Companies seem to got caught in a continuous struggle to keep existing systems operational and to modify them when needed, rather than developing new systems. The need to adapt existing systems can be related to structural change (e.g. new legal requirements or business rules), technological change (e.g. conversion to new DBMS) and change of organizational environment (e.g. new user demands). Where automation of system design can shorten development time (2), new system design methodologies can produce more flexible systems and moderate future maintenance and modification costs, by anticipating different sources of change and provide ways to deal with them. As an example of the latter approach M.E.R.O.DE. is a systems design method which aims at building maintainable and adaptable software (3). This choice does ofcourse not preclude CASE-tool possibilities. MORE THAN A NAME Every young parenthood brings along the problem of coming up with a suitable name." So does ours and the choice of M.E.R.o.oE. gives us the oldfashioned feeling that we have been there. At the risk of missing out on other tails of tastes and flavours some clarification of M.E.R.O.DE.'s name components might at this point be appropriate. Hodel driven While M.E.R.O.DE. 's ultimate purpose is to deliver an information system (IS) suited to supply all information desired, it does not start from any kind of requirements pool. The latter way of proceeding in developing IS's (requirements driven) has been favoured in numerous system development methodologies and can be traced to the origin of several flaws in modern IS's. The main cause is found to be the instability of information needs and consequently the inappropriateness of systems built upon outdated requirements. In contrast to this functional point of view, M.E.R.O.DE. starts off by creating a model of reality (in casu the business entity) which will in later design stages serve as the basis for fulfilling information needs (model driven). In short, substance is built before functionality is considered. Reasons for proceeding this way are obvious when lessons learned from requirements driven approaches are born in mind. Hence, the aim is to provide a basis for information potential instead of tailoring the system's design to current information needs. Entity-Relationship Data issues of the model to be created (static part) are designed using the well known Entity-Relationship (ER) modeling technique. Only concepts with meaningful! equivalent or complementary counterparts in M.E.R.O.DE. 's dynamic part ( lifecycle-building) are withheld. As -a result, a subset of Extended Entity-Relationship (EER) is integrated in the set of M.E.R.o.oE.'s data modeling tools. The case study included in this paper will illustrate the use of ER-modeling. (1) Bush, Eric : CASE for existing systems, CASE outlook, 2(2), February 1988, pp. 1-15. (2) McClure, Carma :CASE is software automation, Prentice-Hall, Englewood Cliffs (N.J.), 1989, 290 p. (3)" Throughout this text change-handling features of the methodology will be e~hasized.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique - page 3 Object-oriented More than being a temporary rage of fashion object-orientedness (o.o.) has gained the confidence of a major group of academics as well as practitioners. Blessing IS's and IS-development techniques with a seemingly win-win feature like o.o., has become nearly as trivial as putting roofs on houses and assembling cars with wheels. Reasons for general acceptance of o.o. as a desirable feature can mainly be traced to its high promises in avoiding current problems in software maintenance. Although a consensus exists on the potential properties of object-oriented design (4) (e.g. information hiding, inheritance, identification, etc.) no precise overall definition of o.o. has been put forward. The latter unfortunately credits discussions on the right or wrong of o.o.-claims with eternal life. Having no intention to get caught in this kind of struggle, that M.E.R.O.DE. has integrated several, but not all concepts associated with object-oriented design is mentioned here. selecting only a subset out of the o.o. tools, are based on o.o. as a gain-only strategy. only the fact traditionally Reasons for the doubts of EXPLORING M. E. R. 0. DE. : AN INTRODUCTORY JOURNEY Working with M.E.R.O.DE. in practice means going through a number of phases. Each of these phases fits into one of the major development subcycles being specification, transformation and implementation. All three of them are briefly explained in the sequel (5). Specification The first and most comprehensive stage involves the construction of the abstract model as a set of layers. Hereby inner layers are more stable than outer layers, i.e. less vulnerable to change, but at the same time more costly to change when the unexpected should happen. In its most basic form, M.E.R.O.DE. foresees one inner layer (model core) and one outer layer (function layer). Separation of the model as such and its functionality protects the system from changes in organizational environment (see later). I :=::tj, model object :.,_object model core and function layer (4) Meyer, Bertrand : Object-oriented software construction, Prentice-Hall, Englewood Cliffs (N.J.), 1988, 534 p. (5) Terminology used in this section might be difficult to understand for readers not familiar with systems development. Matters will become clearer after going through the case study included.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 4 Elements to be included in the core are model objects, which from a static point of view are interrelated using a conceptual data model (ER-diagram). F7om a dynamic point of view model objects are represented by life cycle dj.agrams { 6) whereby the dynamic counterpart of static relationships is provided by common events. Both statics and dynamics are combined in abstract datatypes (7). The function layer consists of function objects that are connected with at least one of the model objects in the core through one of two basic connection mechanisms : state vector inspection and data stream connection. Statics of function objects are represented by system specification diagrams, dynamics by JSP-structures {6) and both are combined in abstract datatypes. In summary, an abstract model consists of : - a core comprising one ER-model and a number of model objects, each of which is defined by one life-cycle and one abstract datatype, - a function layer, containing function objects with one specification diagram and one JSP-structure for each object. system Tri!Uls:formation Transformation {mutation) is the transition between specification and implementation. A particular abstract model can be transformed into several concrete (actual) systems depending on the chosen mutation. This mechanism protects the system against technological and certain types of organizational change. An analogy with eastern religians in which the sole can reincarnate in a different body can clarify this point. "sole" 'bodies" During the transformation phase several decisions have to be taken with respect to the concrete shape and functionality of the system to be built. These aspects are labeled as being subject to more frequent change and therefore excluded from the abstract model. When practical decisions are reconsidered, a new transformation of the same (stable) abstract model will be necessary to generate a modified implementation. Hence, costly and time consuming operations when e.g. users alter their demands can be avoided. The extent to which transformation is a resource consuming activity depends on the number of specific practical restrictions as well as on the nature of the implementation to be performed. When programming will be done using (6) Jackson, Michael : JSP & JSD : the Jackson approach to software development, IEEE computer society, Silver Springs (Md.), 1983, 257 p. (7) Azmoodeh, Manoochehr Abstract data types and algorithms, Macmillan education, Basingstoke, 1988, 377 p.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 5 an object oriented programming language less efforts must be made to transform an object-oriented design in a running system. Transformation involves, among others, decisions on the transactions to be used. Transactions provide an interface between the model's building blocks and the preferred way of usage by the user. Hence, when user preferences change, only transaction definitions rather than the abstract model have to be adapted. Other relevant options to be taken are concerned with timing aspects (e.g. batch or on-line, timing of functions, etc.), design of controlling software, design of supporting data sets, choice of DBMS, etc. I..mpleme.ntatio.n The final stage involves actual preparation (programming) and installation of the software constructed and ends with a running system. Starting from the transformed abstract model, implementation is a rather trivial and purely technical matter, not dealt with in M.E.R.o.oE THE PLENTY ~NC. O~L COMPANY : A M.E.R.O.DE. CASE STODY The case study below provides a global view on the M.E.R.O.DE. way of constructing software. The example used is rather easy as it is not meant to introduce all technical details. Instead, efforts were made to demonstrate the method 1 s features in moderating maintenance costs under different assumptions of change. In the next section, the M.E.R.O.DE. technique will be faced with a traditional system development technique, called the structured technique (8). Comp~.Descriptio.n PLENTY INC., one of the major oil companies, owns 345 petrol stations all over the country. Throughout the years a high quality reputation was established, which explains the large group of regular customers. For simplicity, the only service provided is refueling. PLENTY INC. is interested in details on its business customers as well as its private customers. For business customers, an invoice is prepared and sent as soon as possible to the employing company. The latter will then pay the invoice. The rate of paying is independent of the rate at which invoices are received. Obviously, it is impossible to start paying before the first invoice has been sent. Private customers do not want an invoice : they pay on the spot and get a discount when they show their PLENTY LOYALTY CARD. Customers who wish to obtain this card, only have to buy it once in one of PLENTY 's stations. At that moment the customer 1 s details are asked for such that the marketing departement can follow up these regular customers. The loyalty card can be used in all PLENTY stations. 1 PLENTY s marketing departement is also doing a research on geographical strategy and wants to know where a regular customer bought his loyalty card and at which station an employee of a company came to refuel for the first time. PLENTY 's petrol stations are refilled at irregular moments in time. The supplier part of the problem is not considered here. (8) Gane, Chris and Sarson, Trish : Structured systems analysis Prentice-Hall, Englewood Cliffs (N.J.), 1979, 241 p. tools and techniques,

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 6 Specification As stated earlier the specification phase should deliver both core and function layer of the abstract model. These components are constructed in the model and function step respectively. Model Step 1. Construction of the Business Model The business model comprises the data model (ER-model) and the object life cycles. In order to arrive at these deliverables, stable elements must be extracted from reality to become object classes in the model, and basic events encountered during the "life" of these objects must be detected to serve as the model's event types. More formal criteria to check whether elements of reality qualify as elements of the model do exist, but do not need elaboration within the extent of this paper. An initial indication of potential model elements is usually provided by listing nouns and verbs from the problem description. In this case the resulting list of object classes and events types for PLENTY INC. is given below. object classes (<nouns): station customer invoice company event types (< verbs): refuel prepare an invoice refill pay invoice pay (on the spot) sale, out-of-use In addition event types are completed with create-events (in short : cr) for each object class for which no such event yet exists, or renamed in case an equivalent is already present. For PLENTY INC. this results in the renaming of "prepare an invoice as cr-invoice and inclusion of crstation, "cr-customer and cr-company. At this stage it is necessary to let clear definitions of both kinds of model elements accompany the resulting list. For explanatory purposes only comments on potentially confusing names are added for PLENTY INC. customer company this object class contains customers loyalty card; only in this case personal are registered. Consequently, customers are not registered in PLENTY INc.'s files. that have bought the details of individuals without a loyalty card the class company consists of business entities; all categories of private persons are excluded from this class. After completion of the list of event types and object classes an objectevent table is created to provide a first understanding of object interrelationships. Again, rules exist to support this table's construction but their clarification is considered to be beyond this paper s objectives. For PLENTY INC. the object-event table would be the following : station customer company invoice cr-station X cr-customer X X cr-company X X cr-invoice X X X pay-invoice X X X pay X X refuel X X X refill X sale X out-of-use X

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 7 Information included in this table is both extensive and diverse. Important to mention here are the table s features to generate the datamodel (ER-model) and to expose the existence of special types of object classes. Without going into the mechanisms used, a tentative BR-:model corresponding to the PLENTY INC. problem description and the object-event table can be represented as : This data model reveals an unexeptable shortcoming. When instantiating (9) the "refuel" relationship, both the relationship between station and "customer" on the one hand and station and company on the other would be transformed in equal objects. This ER-irregularity could have been avoided as it were already preluded by the object-event table (10). Not shown by neither of the object-event table and the ER-model is the obvious missing of refueling done by nonregular private persons. In case plain common sense or additional interactions with future users would not have revealed this gap, it was bound to show up in developing the information model (see later). All irregularities mentioned can be rectified by substituting the "refuel" by camp-refuel" (company), cust-refuel (customer, i.e. owner) and "priv-refuel" (private person that does not own a card). leads to the ER-model with instantiated relationships (11) event card This.. (9) Instantiating is the process by which a relationship is turned into an object alias an entity. (10) Event type refuel' can not be related to object classes customer and company at the same time in the object-event table. ( 11) Considerations to model refuel as an exclusi ve-or-specialization which is an EERconcept, are persuasive. Still, this is avoided for obvious reasons of simplicity.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 8 The object-event table should demonstrate these changes as well. some event names are adapted to represent the create events : Note that station customer company invoice camp-refuel cust-refuel priv-refuel cr-station X cr-customer X X cr-company X X cr-invoice X X X cr-comp-refuel X X X cr-cust-refuel X X X cr-priv-refuel X X pay-invoice X X X cust-pay X X X priv-pay X X refill X sale X out-of-use X A final step in constructing the business model is life cycle building. The latter is based on Jackson's principles of system development (12) and provides a way of modeling the objects' dynamics. An object's life cycle (or structure diagram) describes its evolution (life) through basic events from the moment of creation untill its destruction ( 13). Life cycle building blocks are sequences (rectangular), iterations (rectangular with star) and selections (rectangular with circlet). The whole is often called a set of business rules since it describes an approved and acceptable way of proceeding. After syntaxis has become clear, life cycles are claimed to be easily understandable to users as well as designers. Again, theoretical foundations exist to check life cycles on desirable features (e.g. completeness and absence of contradiction) and rules are established to detect special kinds of object classes and their modelling demands. Once more, these are not elaborated as it is our intention to demonstrate M.E.R.O.DE. 's quality improving features rather than its practical design issues. The life cycle for the object customer is given below. cycles are included in appendix A. Remaining life During the construction of the object life cycles an additional event invoicing was discovered to end the camp-refuel life cycle. This is not uncommon since problem descriptions often reveal incompleteness with respect to creation and ending events. The event invoicing is not the same as cr-invoice as we wish not to take any decision on the possible grouping of several refuelings in one invoice. (12) Jackson, Michael A. : System Development, Prentice-Hall, Englewood Cliffs (N.J.), 1983, 454 p. (13) Destruction is a logical and not a physical event ; a book in a library can be worn out and taken out of circulation, whereas related data can be withheld in the information system.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique - page 9 Life cycles for all object classes corresponding to entities in the ERmodel end the business model construction phase. 2. Construction of the Information Model The second and final part of the model step combines both static (ER-model) and dynamic views (object life cycle) into abstract data types. Each one of the latter consists of one state vector and several event routines. All data attributes relevant to the object type (14) are included in the state vector. constituting the primary key (15) are marked foreign keys are added. The ER-model resulting model step serves as a point of reference. as well as a state pointer Further, data attributes (underlined) and possible from the first part of the Each event participating in the object's life cycle is matched with an event routine with the same name. The latter can be defined as a pseudolanguage instruction set describing all changes to the object's state vector caused by the event under consideration, including a state pointer update instruction. Later design steps can add routines that are needed for function development. As an example the abstract data type of the object class invoice is included {16) Class INVOICE state vector : sp, inyoice-no, station-id, company-id, amount-due, date, paid, date-paid event routines : cr-invoice seq invoice-no - invoice-no-e; station-id := station-id-e; company-id := company-id-e; amount-due := amount-e; date := date-e; paid := 0; date-paid := ; sp := 1; cr-invoice end pay-invoice seq date-paid := date-e; paid := 1; sp := 2; pay-invoice end When {tentative) abstract data types are completed, event type attributes should be listed to ensure proper provision of data to corresponding event routines. Therefor, mandatory attributes are event type identification {event code : ec), primary key of each object class in whose life cycle the event type participates and data elements necessary in each of its induced event routines. Again, the function step can justify the inclusion of additional~ttributes in later design stages. For PLENTY INC. the event type cr-invoice would look like cr-invoice ec, invoice-no-e, station-id-e, company-id-e, amount-e, date-e (14) A state pointer is a numeric variable that keeps track of the state of an object, i.e. the current position in the life cycle. (15) Primary and foreign keys are concepts used in relational data models. For their precise meaning any book on data models or database design can be consulted. (16) Data elements delivered by events are tagged with suffix e to make the distinction with state vector attributes.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 10 Function step After the core of PLENTY INC.'s abstract model is finished, the function layer can be built. During the process of function design addition of some data attributes in the model core may be necessary. The need for major changes should however not appear since a well designed core should exhibit a maximal information potential. Function design is only a matter of extracting information already present and reshaping it in the user's favoured format. Function objects, function only one objects design involves, comparable to the construction of model the generation of abstract data types. Unlike model objects objects do not always posess a state vector and usually induce event routine. User demands need not be asked before the function design problem is addressed. Still, functional requirements may have entered the problem description in an earlier stage, mostly because of users' tendency to brief on expectations rather than on vested procedures. In that case, designers should take special care to separate functionality from substance. At this point the problem description is expanded with the following function request : Corporate management asked for a program to generate an invoice immediately after refueling (on-line), which looks like : invoice number company name : address :... date :... Service provided at station : date : amount : taxes total : Before actual function design can be started, the core of the model is inspected on the availability of all necessary data elements. Occasionally data sources other than the model's core can deliver necessary data elements (e.g. system generated dates). For PLENTY INC., the following availability check results : invoice number : to be provided when activating the function company name, address : included in state vector of object company date : system generated or to be provided when activating the function station : included in the state vector of object comp-refuel date : included in the state vector of object comp-refuel amount : included in the state vector of object comp-refuel taxes to be computed total : to be computed As the availability check reveals no proceed. Therefor the function's sso program structure are to be provided. gaps, actual function design (system specification diagram) can and Important to note at this point is the fact that the on-line feature of the function to build does not intervene with the design at this stage. Although it seems possible to trigger the invoicing function from the event routine cr-comp-refuel" to guarantee its immediate execution, this type of dependence between function and model objects should be avoided whenever possible. The timing of functions execution is to be considered as a requirement highly subject to change and should therefore not be mixed with elements in the model's core.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment tecr.nique -page 11 Interrelationships between function objects and model objects are shown in the sso. Two basic ways of connecting function objects with core objects are availabe : data stream connection and state vector inspection. State vector inspection (represented by a diamond) is chosen whenever necessary data elements are included in the state vector (as is the case for PLENTY INC.). A routine to consult (inspect) these attributes is then included in the routine set of the model object's abstract data type, which will be activated by the function object's routine. In case attributes needed are not part of a model object's state vector but are included as event type attributes, the corresponding event routine will be used to send these data elements to an intermediate file (data stream) which will be used by the function object (represented by a circle). The sso for the requested invoicing function is given below :..,.,.._ In contrast to function objects designed only to extract information, the invoicing function is of an interactive nature : besides printed invoices cr-invoice" and "invoicing events are sent to the Iss (input subsystem (17)) The second part of function design involves the development of the program (function) structure. For these purposes the principles of JSP (Jackson Structured Programming) are used. According to this technique program structure is derived from input and output structures and is then completed with operations. Applying this for PLENTY INC. 's invoicing function leads to the following (18) ( 17) The ISS is the software element that receives users transactions and activates all necessary software components to deal with them. (18) It was assumed that the company object's implementation will at least support an indexed search; in case implementation will allow structured searches in a relational database system, function structures will be simplified.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 12 list of operations : input and output : 1. Read (comp-refuel) 2. Get company (comp-id) 3. Print invoice. 4. Write cr-invoice-event 5. Write invoicing-event computations : 6. amount := 0 7. taxes := 0 8. total := 0 9. amount.- amount(comp-refuel) 10. taxes := amount * rate 11. total :=amount + taxes preparation of output : 12. invoice-no := no(function) 13. name := name(company) 14. address := address(company) 15. current-date := date(system) 16. station := station(comp-refuel) 17. date := date(comp-refuel) conditions none function structure completed with operations For details on input and output structures, we refer to appendix B. Notice that a simple match between input and output structures exist. Hence, derivation of the function structure was straightforward. Although common practice in JSP the "end-of-iteration is not specified. As a consequence, decisions with respect to the function's run frequency are postponed until transformation. Trans:format:l.on As explained earlier transformation serves as a transition step between specification and implementation. At this point physical and functional decisions carefully circumvented in previous stages are finally dealt with. A major transformation issue is the development of transactions. The latter represent combinations of events for easy usage, preferred by the user but unknown to our model as a group. In the case of PLENTY INC. one could imagine that the station's operator would like the possibility of a "first refuel by business customer and next refuel by business customer t~ key in company and refueling details for the first refueling and refueling details only for the nonfirst refueling respectively. The first refuel by business customer is in essence a grouping (transaction) of one

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique - page 13 "cr-company and one cr-comp-refuel" event. The next refuel by business customer can be considered as a transaction containing only one event crcomp-refuel". Proceeding this way results in an enormous flexibility with respect to users' preferences of day-to-day operations. Translation of transactions (user point of view) into events (model point of view) is provided by a "transaction handler (special purpose software) which generates the model events through consultation of a transaction table" (containing transaction definitions). During transformation decisions on timing aspects left out of the specification are reconsidered. For PLENTY INC. case company management still wants invoices to be printed immediately after refueling. Hence, only the iterating routine of the function structure is retained for implementation and upper levels will be cut off. A third major issue to deal with in the process of transformation is the specification of controlling software. The most important part involves "schedular" design. The schedular can be defined as higher level software invoking and controlling all lower level routines (transaction handler, context filter, request handler) and incorporates all timing decisions. The schedular is tailor-made and needs re-writing whenever a new transformation is performed. Lower level software is designed to perform checks on acceptable objects state transitions and other restrictions, to invoke read and write operation and object event routines, to deal with function requests, etc. Finally, preparation of implementation with respect to the chosen DBMS, record and file formats, choice of programming language, layout of user interface and other practical issues must be performed. Implementation As was already mentioned before matters of implementation are not dealt with in this text. THE PLENTY INC. OIL COMPANY : A STRUCTURED TECHNIQUE CASE STUDY Rather than providing a detailed description of how to develop a system using the structured technique, it is our intention to highlight three of its fundamental characteristics that possibly cause severe problems in systems maintenance. The structured technique can be illustrated as follows

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 14 IJ88r requiremen1s budget and schedule user 111quiremen1S Firstly problems can be caused by the requirements driven approach to systems development. This approach results in systems that are fitted to situation at hand and are hard to extend with new user requirements. Another potentially problem causing factor is the early development stage (the structured analysis phase) at which physical requirements (e.g. online facilities versus batch) intervene with the design. As a consequence changes with respect to these issues imply re-work from the the very beginning. Finally, the interleaving of the system's temporary functionalities and its long term structure may lead to maintenance difficulties changes of inbedded functional choices may lead to extensive rebuilding. Since all three characteristics appear in the structured analysis step, attention will be directed to this phase. The output of the structured analysis phase (besides the physical requirements) is a structured specification. A structured specification consists of : a data flow diagram, showing the major decomposition of function, and all interfaces between components, - a data dictionary, documenting each of the interface flows and data stores on the data flow diagram, - transform descriptions, documenting the internals of the data flow diagram processes in a rigorous fashion. For PLENTY INC. the data flow diagram would look as follows

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 15 For purposes of illustrating the content of interface flow payment and the data store below : the data dictionary, the camp-refuel are included payment invoice-no comp-refuel invoice-no, company-id, station-id, date, amount-due, paid, date-paid Finally, invoice as an example of a transform description, is documented in Structured English. the process prepare- Search for comp-refuel-record with invoice-no equal to invoice-no in invoiceinfo in comp-refuel-file. Search for station-record with station-id equal to station-id in camp-refuelrecord in station-file. Search for company-record with company-id equal to company-id in camp-refuelrecord in company-file. Set paid equal to false in comp-refuel-record. Write comp-refuel-record to comp-refuel-file. Prepare invoice with data from comp-refuel-record, station-record and companyrecord. THE ULTIMATE TEST : PLENTY INC. REVISITED As we believe that the proof of the pudding is still in the eating, maybe time has come to gather around the table and find out whether a M.E.R.O.DE. dish really tastes better. As it were stated that maintenance efforts can be reduced by developing flexible information systems, and M.E.R.O.DE. was claimed to provide flexibility, what better way could we then think of than submitting both designs for the PLENTY INC. oil company to the same changes. In this section two sources of change are introduced. They could both make sense in a real world environment and should cause not too many problems considering the case's extreme simplicity.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 16 Lirst change : time lag in ordering loyalty cards The original case description assumed that a customer that buys a loyalty card can take it with him immediately (after e.g. filling out a form with personal details). Let us suppose now that new procedures demand that customer's details are sent to head office which in turn prepares this loyalty card within two weeks. Before a customer has received his card he is put on a waiting list and not entitled to the reduced price refueling that goes along with the card ownership. M.E.R.O.DE. design changes In M.E.R.O.DE. terminology this change is a modification of a business rule. Business rules describe vested operational procedures and are enforced in model objects' life cycles. Keeping in mind the numerous remarks made before about the stability of core elements compared to function layer components, changing an object's dynamics can be one of the most severe tests of a M.E.R.O.DE. model. At the specification level only the life cycle of the object customer needs adaptation. Previously a customer was able to undertake refueling (at a reduced price) right after the cr-customer event had taken place. Under changed procedures this cr-customer event will move the customer's "life" in a waiting state untill his card has arrived. This can be represented as follows : Consequently, the customer state vector needs one more attribute in its abstract data type. Hence, an additional event routine will be created to ensure state transition through a new waiting stage. Finally, state pointer updates in the customer's event routines must be changed to reflect the new number of states. As a result a new transformation is needed with respect to the software routines designed to control proper state transition of model objects. Here as well only minor changes are necessary (19). Hence, only a small part of the implementation must be revised. Structured analysis changes As opposed to the rather limited changes in the M.E.R.o.DE design, the structured specification is subject to major changes in all its components. In the data flow diagram, the process add-new-customer is initiated by a new external entity "oil-company. (19) Only the practical representation of the customer life ~cle needs changing.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 17 In the data dictionary, the data store customer has to be extended with an additional attribute indicating whether the customer is already entitled to the reduced price refueling. Finally, both transform descriptions of the process cust-control and the process "add-new-cust have to be changed. The process cust-control needs extension with a component that adds a person's information in the data store "customer as a person waiting for his loyalty card. The process add-new-cust" has a completely new purpose : it retrieves persons on the waiting list to make them real customers. second change : new requirements for invoice preparation The immediate preparation of invoices after each company refueling has proven to be a striking example of unpracticality. Hence, PLENTY 's management would feel more comfortable when invoices were made once a week combining all refueling done by the same company during that time. M.E.R.O.DE. design changes Invoice preparation was provided by a function object. Consequently, impact is expected to be reasonable since the model's core is not directly affected (20). Where specification is concerned the invoicing function's design must be reconsidered. Unlike the function' s sso the function structure needs changing to reflect the combination of several refuelings into one invoice. This change in function structure is caused by an additional level in the output structure (namely of the list of invoices). Below an adapted list of operations and the final function structure are stated : (20) Note however that the one-to-one relationship between invoice and refuel-comp in the ~-model must be changed in a one-to-many relationship. T.his more realistic data model is included in appendix c.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique - page 18 list of operations : input and output : 1. Read (refuel-comp) 2. Get company (comp-id) 3. Print invoice-heading 4. Print refueling-details 5. Print invoice-totals 6. Write cr-invoice-event 7. Write invoicing-event computations : 8. amount : = 0 9. taxes := 0 10. total := 0 11. amount :=amount + amount(refuel-comp) 12. taxes := taxes + amount(refuel-comp) rate 13. total := total + amount + taxes preparation of output : 14. invoice-no := no(function) 15. invoice-no : = invoice-no + 1 16. name := name(company) 17. address := address(company) 18. current-date := date(system) 19. station := station(refuel-comp} 20. date := date(refuel-comp) conditions : c1. until next company c2. until end-of-week Along with this change in timing as well as contence of the invoicing function go'e!s a revision of the schedular which should not longer invoke this function immediately after refueling but only once a week. Implementation changes involve receding of the function and part of the schedular. Structured analysis changes Again, the structured specification is suffering from major changes in all its parts. The changes in the data flow diagram are represented below. Note the introduction of the data store invoice. This data store is needed because an invoice is now covering multiple refuels. The process prepareinvoice is now initiated by the external entity "oil-company instead of the process "record-liability.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 19 invoioeinfo In the data diet ionary, the data store invoice could be documented as follows invoice invoice-no, company-id, amount-due, paid Because an invoice is covering multiple refuels, there is an link needed between an invoice and the concerning refuels to be able to prepare the invoice. As a consequence, the data store comp-refuel" has to be extended with an additional attribute indicating the invoice number of the invoice to which it belongs. Some major changes also have to be made to the transform descriptions. The process pay-invoice has to refer to the data store "invoice instead of to the data store comp-refuel. The process "prepare-invoice is subject to the most extensive changes as can be seen in the Structured English text here below. Generate new invoice-no. Set amount-due equal to 0. Add invoice-no to invoice-record. Get first comp-refuel-record. Repeat for all companies Search for company-record with company-id equal to company-id in camprefuel-record in company-file. Add data of company-record to invoice. Add company-id to invoice-record. Repeat until next company or end of comp-refuel-file If date is of appropriate week Add invoice-no to comp-refuel-record. Set amount-due equal to amount-due + amount-due in camp-refuelrecord. search for station-record with station-id equal to station-id in comp-refuel-record in station-file. Prepare part of invoice with data of comp-refuel-record and stationrecord. Get next comp-refuel-record. Add amount-due to invoice. Set paid equal to false. Add paid to invoice-record. Write invoice-record to invoice-file. Set amount-due equal to 0. If not end of comp-refuel-file Generate new invoice-no.

M.E.R.O.DE. Model driven Entity-Relationship Object-oriented DEvelopment technique -page 20 FINAL REMARKS Both foregoing sections have illustrated M.E.R.O.DE.'s ability to deal with new requirements as compared to a popular alternative technique. As could have been expected M.E.R.O.DE. 's ultimate intend to produce easy adaptable systems provided it with a headstart for the change-handling test. Both examples were believed to demonstrate the advantages of flexible design in environments of different types of change. Not included in this paper but equally important are the possibilities of M.E.R.O.DE. in the construction of generic business models. Since functional aspects do not intervene the design of the model core, economies of scale can exist in building reusable cores for comparable business entities (e.g. banking sector) and tailoring function layers to individual preferences. Other opportunities can be found in the possibility of easy prototyping. As soon as functions are being developed, alternative users requests can be rapidly and fairly easy complied with. Being able to understand the consequences of their different demands in a timely way, improves user interaction and ultimate acceptance of the completed system. Finally, it might be useful mentioning that mathematical techniques are being developed to perform integrity controls on the M.E.R.O.DE. specification. This obviously will provide a strong basis for the development of a M.E.R.O.DE. CASE-tool.

APPENDIX A life cycle object "station life cycle object "company life cycle object "priv-refuel"

life cycle object "cust-refuel" life cycle object "comp-refuel" life cycle object "invoice"

APPENDIX B input structures output structure APPENDIX C ER-model after second change