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

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

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

Transcription

1 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

2 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, 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).

3 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 (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.

4 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.

5 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.

6 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,

7 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

8 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.

9 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.

10 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.

11 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.

12 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.

13 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

14 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

15 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

16 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.

17 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.

18 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.

19 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 := total := 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 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.

20 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.

21 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.

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

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

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

Software Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II)

Software Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) Software Engineering Prof.N.L.Sarda IIT Bombay Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue our discussion on process modeling. In the previous lecture

More information

COMP6471 WINTER User-Centered Design

COMP6471 WINTER User-Centered Design COMP6471 WINTER 2003 User-Centered Design Instructor: Shahriar Ameri, Ph.D. Student: Pedro Maroun Eid, ID# 5041872. Date of Submission: Monday, March 10, 2003. (Week 9) Outline Outline... 2 ABSTRACT...3

More information

CHAPTER 19: Building a Preliminary Behavioral Model

CHAPTER 19: Building a Preliminary Behavioral Model 1 z 7 CHAPTER 19: Building a Preliminary Behavioral Model Things are always at their best in their beginning. Blaise Pascal Lettres Provinciales, 1656-1657, no. 4 IN THIS CHAPTER, YOU WILL LEARN: Why a

More information

Database Optimization

Database Optimization Database Optimization June 9 2009 A brief overview of database optimization techniques for the database developer. Database optimization techniques include RDBMS query execution strategies, cost estimation,

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL. Fiona Rohde. Department of Commerce The University of Queensland, 4072.

AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL. Fiona Rohde. Department of Commerce The University of Queensland, 4072. AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL Fiona Rohde Department of Commerce The University of Queensland, 4072. Australia ABSTRACT Within the discipline of information systems, numerous

More information

Question 1: What is a code walk-through, and how is it performed?

Question 1: What is a code walk-through, and how is it performed? Question 1: What is a code walk-through, and how is it performed? Response: Code walk-throughs have traditionally been viewed as informal evaluations of code, but more attention is being given to this

More information

CS Reading Packet: "Database Processing and Development"

CS Reading Packet: Database Processing and Development CS 325 - Reading Packet: "Database Processing and Development" p. 1 CS 325 - Reading Packet: "Database Processing and Development" SOURCES: Kroenke, "Database Processing: Fundamentals, Design, and Implementation",

More information

QM Chapter 1 Database Fundamentals Version 10 th Ed. Prepared by Dr Kamel Rouibah / Dept QM & IS

QM Chapter 1 Database Fundamentals Version 10 th Ed. Prepared by Dr Kamel Rouibah / Dept QM & IS QM 433 - Chapter 1 Database Fundamentals Version 10 th Ed Prepared by Dr Kamel Rouibah / Dept QM & IS www.cba.edu.kw/krouibah Dr K. Rouibah / dept QM & IS Chapter 1 (433) Database fundamentals 1 Objectives

More information

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture Sadahiro Isoda Toyohashi University of Technology Toyohashi 441-8580, Japan isoda@tutkie.tut.ac.jp Abstract. UML2.0 recently made a correction

More information

Divisibility Rules and Their Explanations

Divisibility Rules and Their Explanations Divisibility Rules and Their Explanations Increase Your Number Sense These divisibility rules apply to determining the divisibility of a positive integer (1, 2, 3, ) by another positive integer or 0 (although

More information

Software Engineering - I

Software Engineering - I Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 3 Requirement Engineering Copy Rights Virtual University of Pakistan 1 Requirement

More information

Introduction to the UML

Introduction to the UML c02.qxd p039-048 11/15/01 5:37 PM Page 39 CHAPTER 2 Introduction to the UML Why should I use the UML? What can it contribute to my software development effort? To effectively utilize any technology, we

More information

Introduction to Software Testing

Introduction to Software Testing Introduction to Software Testing Software Testing This paper provides an introduction to software testing. It serves as a tutorial for developers who are new to formal testing of software, and as a reminder

More information

Chapter 9. Software Testing

Chapter 9. Software Testing Chapter 9. Software Testing Table of Contents Objectives... 1 Introduction to software testing... 1 The testers... 2 The developers... 2 An independent testing team... 2 The customer... 2 Principles of

More information

TERMINOLOGY MANAGEMENT DURING TRANSLATION PROJECTS: PROFESSIONAL TESTIMONY

TERMINOLOGY MANAGEMENT DURING TRANSLATION PROJECTS: PROFESSIONAL TESTIMONY LINGUACULTURE, 1, 2010 TERMINOLOGY MANAGEMENT DURING TRANSLATION PROJECTS: PROFESSIONAL TESTIMONY Nancy Matis Abstract This article briefly presents an overview of the author's experience regarding the

More information

Universal Model Framework -- An Introduction

Universal Model Framework -- An Introduction Universal Model Framework -- An Introduction By Visible Systems Corporation www.visible.com This document provides an introductory description of the Universal Model Framework an overview of its construct

More information

Categorizing Migrations

Categorizing Migrations What to Migrate? Categorizing Migrations A version control repository contains two distinct types of data. The first type of data is the actual content of the directories and files themselves which are

More information

On UML2.0 s Abandonment of the Actors- Call-Use-Cases Conjecture

On UML2.0 s Abandonment of the Actors- Call-Use-Cases Conjecture Vol. 4, No. 6 Special issue: Use Case Modeling at UML-2004 On UML2.0 s Abandonment of the Actors- Call-Use-Cases Conjecture Sadahiro Isoda, Toyohashi University of Technology, Toyohashi 441-8580, Japan

More information

elements) and on the structure and representation of the information (i.e. the message format).

elements) and on the structure and representation of the information (i.e. the message format). Introduction to MDMI The global financial industry exchanges huge amounts of electronic information. Differences in understanding and interpretation of exchanged electronic information form an important

More information

A Structured Object-Oriented View on Systems Modeling

A Structured Object-Oriented View on Systems Modeling 19 A Structured Object-Oriented View on Systems Modeling G. Wu and G. Dedene Section of Information Systems, Department of Applied Economic Sciences, Katholieke Universiteit Leuven, Naamsestraat 69, 3000

More information

SAP. Modeling Guide for PPF

SAP. Modeling Guide for PPF Modeling Guide for PPF Contents 1 Document Organization... 3 1.1 Authors... 3 1.2 Intended Group of Readers... 3 1.3 References... 3 1.4 Glossary... 4 2 Modeling Guidelines - Application Analysis... 6

More information

Some doubts about the objectivity of logical determination of the uniqueness of the elementary process in the Function Point Analysis

Some doubts about the objectivity of logical determination of the uniqueness of the elementary process in the Function Point Analysis Some doubts about the objectivity of logical determination of the uniqueness of the elementary process in the Function Point Analysis Table of Contents Marian Zalcman, Ph.D. ASSECO Poland, Rzeszów 1. Introduction

More information

A Summary of Out of the Tar Pit

A Summary of Out of the Tar Pit A Summary of Out of the Tar Pit Introduction This document summarises some points from the paper Out of the Tar Pit (written by Ben Moseley and Peter Marks, dated 6 th February 2006) which are relevant

More information

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore Module No # 09 Lecture No # 40 This is lecture forty of the course on

More information

Data Analysis 1. Chapter 2.1 V3.1. Napier University Dr Gordon Russell

Data Analysis 1. Chapter 2.1 V3.1. Napier University Dr Gordon Russell Data Analysis 1 Chapter 2.1 V3.1 Copyright @ Napier University Dr Gordon Russell Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is

More information

SEEKING THE ACTUAL REASONS FOR THE "NEW PARADIGM" IN THE AREA OF IS ANALYSIS 2. GENERAL CHARACTERISTICS OF THE "STRUCTURED APPROACH" IN IS DEVELOPMENT

SEEKING THE ACTUAL REASONS FOR THE NEW PARADIGM IN THE AREA OF IS ANALYSIS 2. GENERAL CHARACTERISTICS OF THE STRUCTURED APPROACH IN IS DEVELOPMENT SEEKING THE ACTUAL REASONS FOR THE "NEW PARADIGM" IN THE AREA OF IS ANALYSIS Václav Řepa Prague University of Economics, W.Churchill sq. 4, 130 00 Praha 3, Czech Republic E-mail: REPA@VSE.CZ 1. INTRODUCTION

More information

The Benefits of Strong Authentication for the Centers for Medicare and Medicaid Services

The Benefits of Strong Authentication for the Centers for Medicare and Medicaid Services The Benefits of Strong Authentication for the Centers for Medicare and Medicaid Services This document was developed by the Smart Card Alliance Health and Human Services Council in response to the GAO

More information

Software Development Chapter 1

Software Development Chapter 1 Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic

More information

Entity Relationship Modelling

Entity Relationship Modelling Entity Relationship Modelling Overview Database Analysis Life Cycle Components of an Entity Relationship Diagram What is a relationship? Entities, attributes, and relationships in a system The degree of

More information

Chapter 4. Fundamental Concepts and Models

Chapter 4. Fundamental Concepts and Models Chapter 4. Fundamental Concepts and Models 4.1 Roles and Boundaries 4.2 Cloud Characteristics 4.3 Cloud Delivery Models 4.4 Cloud Deployment Models The upcoming sections cover introductory topic areas

More information

Cognitive Walkthrough Evaluation

Cognitive Walkthrough Evaluation Columbia University Libraries / Information Services Digital Library Collections (Beta) Cognitive Walkthrough Evaluation by Michael Benowitz Pratt Institute, School of Library and Information Science Executive

More information

ITERATIVE MULTI-LEVEL MODELLING - A METHODOLOGY FOR COMPUTER SYSTEM DESIGN. F. W. Zurcher B. Randell

ITERATIVE MULTI-LEVEL MODELLING - A METHODOLOGY FOR COMPUTER SYSTEM DESIGN. F. W. Zurcher B. Randell ITERATIVE MULTI-LEVEL MODELLING - A METHODOLOGY FOR COMPUTER SYSTEM DESIGN F. W. Zurcher B. Randell Thomas J. Watson Research Center Yorktown Heights, New York Abstract: The paper presents a method of

More information

Cincom Manufacturing Business Solutions. Cincom and complex manufacturing: meeting the goals of a Demand-Driven environment

Cincom Manufacturing Business Solutions. Cincom and complex manufacturing: meeting the goals of a Demand-Driven environment Cincom Manufacturing Business Solutions Cincom and complex manufacturing: meeting the goals of a Demand-Driven environment Cincom has long been providing solutions to companies that manufacture products

More information

Requirements Engineering for Enterprise Systems

Requirements Engineering for Enterprise Systems Association for Information Systems AIS Electronic Library (AISeL) AMCIS 2001 Proceedings Americas Conference on Information Systems (AMCIS) December 2001 Requirements Engineering for Enterprise Systems

More information

System Analysis & design

System Analysis & design Assiut University Faculty of Computers and Information System Analysis & design Year 2 Academic Year 2014/ 2015 Term (2) 5 A PICTURE IS WORTH A 1,000 WORDS A process model is a graphical way of representing

More information

Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs

Administrivia. Wednesday: Requirements and Specification. CS169 Lecture 4. We assign teams and you start on Monday. Determining Stakeholders and Needs Administrivia Requirements and Specification CS169 Lecture 4 Wednesday: Groups and one-sentence idea(s) due at class One per group If you have a small group, still submit so that you will be kept together.

More information

ISO/IEC/ IEEE INTERNATIONAL STANDARD. Systems and software engineering Architecture description

ISO/IEC/ IEEE INTERNATIONAL STANDARD. Systems and software engineering Architecture description INTERNATIONAL STANDARD ISO/IEC/ IEEE 42010 First edition 2011-12-01 Systems and software engineering Architecture description Ingénierie des systèmes et des logiciels Description de l'architecture Reference

More information

Chapter 1: The Database Environment

Chapter 1: The Database Environment Chapter 1: The Database Environment Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Prentice Hall, 2002 1 Definitions Data: Meaningful facts, text, graphics,

More information

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2)

SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay. Lecture #10 Process Modelling DFD, Function Decomp (Part 2) SOFTWARE ENGINEERING Prof.N.L.Sarda Computer Science & Engineering IIT Bombay Lecture #10 Process Modelling DFD, Function Decomp (Part 2) Let us continue with the data modeling topic. So far we have seen

More information

10 Hidden IT Risks That Might Threaten Your Business

10 Hidden IT Risks That Might Threaten Your Business (Plus 1 Fast Way to Find Them) Your business depends on intelligence. But can you count on your technology? You may not be in the intelligence technology business, but it s probably impossible to imagine

More information

Section of Achieving Data Standardization

Section of Achieving Data Standardization Section of Achieving Data Standardization Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: mmgorman@wiscorp.com Web: www.wiscorp.com 1 Why Data

More information

Access Rights and Responsibilities. A guide for Individuals and Organisations

Access Rights and Responsibilities. A guide for Individuals and Organisations Access Rights and Responsibilities A guide for Individuals and Organisations This guide is aimed at both individuals and organisations. It is designed to bring individuals through the process of making

More information

Application generators: a case study

Application generators: a case study Application generators: a case study by JAMES H. WALDROP Hamilton Brothers Oil Company Denver, Colorado ABSTRACT Hamilton Brothers Oil Company recently implemented a complex accounting and finance system.

More information

CS112 Lecture: Defining Classes. 1. To describe the process of defining an instantiable class

CS112 Lecture: Defining Classes. 1. To describe the process of defining an instantiable class CS112 Lecture: Defining Classes Last revised 2/3/06 Objectives: 1. To describe the process of defining an instantiable class Materials: 1. BlueJ SavingsAccount example project 2. Handout of code for SavingsAccount

More information

Signature Travel Expert Certification Course

Signature Travel Expert Certification Course Signature Travel Expert Certification Course Module 14: Client Reach Introduction Revised May 18, 2017 First Introduced in 2014, Client Reach has quickly become one of our most popular client communication

More information

Testing! Prof. Leon Osterweil! CS 520/620! Spring 2013!

Testing! Prof. Leon Osterweil! CS 520/620! Spring 2013! Testing Prof. Leon Osterweil CS 520/620 Spring 2013 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad Relations The relations are

More information

We move from a general information system to a Computer Based Information System

We move from a general information system to a Computer Based Information System Introduction to Information Systems: In this section of the course we start to think of the computer as just being a component in a system which may contain one or many computers linked together. An Information

More information

Development of an interface that allows MDX based data warehouse queries by less experienced users

Development of an interface that allows MDX based data warehouse queries by less experienced users Development of an interface that allows MDX based data warehouse queries by less experienced users Mariana Duprat André Monat Escola Superior de Desenho Industrial 400 Introduction Data analysis is a fundamental

More information

Multi-Paradigm Approach for Teaching Programming

Multi-Paradigm Approach for Teaching Programming Multi-Paradigm Approach for Teaching Laxmi P Gewali* and John T Minor School of Computer Science University of Nevada, Las Vegas 4505 Maryland Parkway, Las Vegas Nevada 89154 Abstract: Selecting an appropriate

More information

Mathematics and Computing: Level 2 M253 Team working in distributed environments

Mathematics and Computing: Level 2 M253 Team working in distributed environments Mathematics and Computing: Level 2 M253 Team working in distributed environments SR M253 Resource Sheet Specifying requirements 1 Overview Having spent some time identifying the context and scope of our

More information

SOME TYPES AND USES OF DATA MODELS

SOME TYPES AND USES OF DATA MODELS 3 SOME TYPES AND USES OF DATA MODELS CHAPTER OUTLINE 3.1 Different Types of Data Models 23 3.1.1 Physical Data Model 24 3.1.2 Logical Data Model 24 3.1.3 Conceptual Data Model 25 3.1.4 Canonical Data Model

More information

Symbolic Execution and Proof of Properties

Symbolic Execution and Proof of Properties Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program

More information

Next-generation IT Platforms Delivering New Value through Accumulation and Utilization of Big Data

Next-generation IT Platforms Delivering New Value through Accumulation and Utilization of Big Data Next-generation IT Platforms Delivering New Value through Accumulation and Utilization of Big Data 46 Next-generation IT Platforms Delivering New Value through Accumulation and Utilization of Big Data

More information

Expression des Besoins et Identification des Objectifs de Sécurité

Expression des Besoins et Identification des Objectifs de Sécurité PREMIER MINISTRE Secrétariat général de la défense nationale Direction centrale de la sécurité des systèmes d information Sous-direction des opérations Bureau conseil Expression des Besoins et Identification

More information

The Web Service Sample

The Web Service Sample The Web Service Sample Catapulse Pacitic Bank The Rational Unified Process is a roadmap for engineering a piece of software. It is flexible and scalable enough to be applied to projects of varying sizes.

More information

INTERNATIONAL STANDARD

INTERNATIONAL STANDARD IEC 62443-2-1 Edition 1.0 2010-11 INTERNATIONAL STANDARD colour inside Industrial communication networks Network and system security Part 2-1: Establishing an industrial automation and control system security

More information

Chapter 10. Database System Development Lifecycle

Chapter 10. Database System Development Lifecycle Chapter 10 Database System Development Lifecycle Chapter 10 - Objectives Main components of an information system. Main stages of database system development lifecycle. Main phases of database design:

More information

EXAM PREPARATION GUIDE

EXAM PREPARATION GUIDE When Recognition Matters EXAM PREPARATION GUIDE PECB Certified ISO 22000 Lead Implementer www.pecb.com The objective of the Certified ISO 22000 Lead Implementer examination is to ensure that the candidate

More information

Guide to IREE Certification

Guide to IREE Certification Guide to IREE Certification Certification Congratulations on your decision to pursue Investor Ready Energy Efficiency (IREE) Certification for your project! As a building owner, by choosing to pursue IREE

More information

THINGS YOU NEED TO KNOW ABOUT USER DOCUMENTATION DOCUMENTATION BEST PRACTICES

THINGS YOU NEED TO KNOW ABOUT USER DOCUMENTATION DOCUMENTATION BEST PRACTICES 5 THINGS YOU NEED TO KNOW ABOUT USER DOCUMENTATION DOCUMENTATION BEST PRACTICES THIS E-BOOK IS DIVIDED INTO 5 PARTS: 1. WHY YOU NEED TO KNOW YOUR READER 2. A USER MANUAL OR A USER GUIDE WHAT S THE DIFFERENCE?

More information

The architecture of Eiffel software 3.1 OVERVIEW classes clusters systems

The architecture of Eiffel software 3.1 OVERVIEW classes clusters systems 3 Draft 5.02.00-0, 15 August 2005 (Santa Barbara). Extracted from ongoing work on future third edition of Eiffel: The Language. Copyright Bertrand Meyer 1986-2005. Access restricted to purchasers of the

More information

Usability Report. Author: Stephen Varnado Version: 1.0 Date: November 24, 2014

Usability Report. Author: Stephen Varnado Version: 1.0 Date: November 24, 2014 Usability Report Author: Stephen Varnado Version: 1.0 Date: November 24, 2014 2 Table of Contents Executive summary... 3 Introduction... 3 Methodology... 3 Usability test results... 4 Effectiveness ratings

More information

The data quality trends report

The data quality trends report Report The 2015 email data quality trends report How organizations today are managing and using email Table of contents: Summary...1 Research methodology...1 Key findings...2 Email collection and database

More information

Is IPv4 Sufficient for Another 30 Years?

Is IPv4 Sufficient for Another 30 Years? Is IPv4 Sufficient for Another 30 Years? October 7, 2004 Abstract TCP/IP was developed 30 years ago. It has been successful over the past 30 years, until recently when its limitation started emerging.

More information

RED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE.

RED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE. RED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE. Is putting Contact us INTRODUCTION You know the headaches of managing an infrastructure that is stretched to its limit. Too little staff. Too many users. Not

More information

(Refer Slide Time 00:01:09)

(Refer Slide Time 00:01:09) Computer Organization Part I Prof. S. Raman Department of Computer Science & Engineering Indian Institute of Technology Lecture 3 Introduction to System: Hardware In the previous lecture I said that I

More information

QIIBEE Security Audit

QIIBEE Security Audit PUBLIC QIIBEE Security Audit of QBX TOKEN Smart Contracts June 28, 2018 Produced for by Table Of Content Foreword...................................................... 1 Executive Summary................................................

More information

CONSUMER BRAND PREFERENCE OF LAPTOPS IN MADURAI DISTRICT

CONSUMER BRAND PREFERENCE OF LAPTOPS IN MADURAI DISTRICT CONSUMER BRAND PREFERENCE OF LAPTOPS IN MADURAI DISTRICT Dr.K.Uma Assistant Professor, Department of Commerce, Madurai Kamaraj University Abstract Branding not only gives separate identity and easy recognition

More information

ETNO Reflection Document on the EC Proposal for a Directive on Network and Information Security (NIS Directive)

ETNO Reflection Document on the EC Proposal for a Directive on Network and Information Security (NIS Directive) ETNO Reflection Document on the EC Proposal for a Directive on Network and Information Security (NIS Directive) July 2013 Executive Summary ETNO supports the European Commission s global approach to cyber-security

More information

WHAT CIOs NEED TO KNOW TO CAPITALIZE ON HYBRID CLOUD

WHAT CIOs NEED TO KNOW TO CAPITALIZE ON HYBRID CLOUD WHAT CIOs NEED TO KNOW TO CAPITALIZE ON HYBRID CLOUD 2 A CONVERSATION WITH DAVID GOULDEN Hybrid clouds are rapidly coming of age as the platforms for managing the extended computing environments of innovative

More information

SIS Operation & Maintenance 15 minutes

SIS Operation & Maintenance 15 minutes 2005 Emerson Process Management. All rights reserved. View this and other courses online at www.plantwebuniversity.com. SIS 301 - Operation & Maintenance 15 minutes In this course: 1 Overview 2 Planning

More information

Briefing Paper: developing the DOI Namespace

Briefing Paper: developing the DOI Namespace 010123-DOI-NS-paper.doc 1 Briefing Paper: developing the DOI Namespace This briefing paper describes a project that has been commissioned by the IDF for completion during the first half of 2001. The paper

More information

Crash Course in Modernization. A whitepaper from mrc

Crash Course in Modernization. A whitepaper from mrc Crash Course in Modernization A whitepaper from mrc Introduction Modernization is a confusing subject for one main reason: It isn t the same across the board. Different vendors sell different forms of

More information

C22: SAS 70 Practices and Developments Todd Bishop, PricewaterhouseCoopers

C22: SAS 70 Practices and Developments Todd Bishop, PricewaterhouseCoopers C22: SAS 70 Practices and Developments Todd Bishop, PricewaterhouseCoopers SAS No. 70 Practices & Developments Todd Bishop Director, Risk Assurance Services, PricewaterhouseCoopers Agenda SAS 70 Background

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 8 Agile Methodologies: XP 1 extreme Programming (XP) Developed by Beck in 1996. The first authentic XP book appeared in 1999, with a revised

More information

I am sure most readers will agree that designing

I am sure most readers will agree that designing Text and illustrations by Vlado Damjanovski CCTV focus I am sure most readers will agree that designing a CCTV system is not a simple task. Not everybody can design a system, and this is why very often

More information

Experiences with Object Oriented Model-Driven Development

Experiences with Object Oriented Model-Driven Development Experiences with Object Oriented Model-Driven Development Monique SNOECK Guido DEDENE Presented at the STEP 97 conference, London, July14-18, 1997 Katholieke Universiteit Leuven Faculty of Economics and

More information

Coding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!

Coding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends! Requirements Spec. Design Coding and Unit Testing Characteristics of System to be built must match required characteristics (high level) Architecture consistent views Software Engineering Computer Science

More information

Module 11. Directed Graphs. Contents

Module 11. Directed Graphs. Contents Module 11 Directed Graphs Contents 11.1 Basic concepts......................... 256 Underlying graph of a digraph................ 257 Out-degrees and in-degrees.................. 258 Isomorphism..........................

More information

Workshop: Modeling Scenarios Using Data. Fiona Charles BCS SIGIST 22-Sept-2009

Workshop: Modeling Scenarios Using Data. Fiona Charles BCS SIGIST 22-Sept-2009 Workshop: Modeling Scenarios Using Fiona Charles BCS SIGIST 22-Sept-2009 Who I Am: Fiona Charles - Test Consultant and Test Manager, President and Principal Consultant of Quality Intelligence, Inc. I teach

More information

*ANSWERS * **********************************

*ANSWERS * ********************************** CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO

More information

Taming Rave: How to control data collection standards?

Taming Rave: How to control data collection standards? Paper DH08 Taming Rave: How to control data collection standards? Dimitri Kutsenko, Entimo AG, Berlin, Germany Table of Contents Introduction... 1 How to organize metadata... 2 How to structure metadata...

More information

Certification program PCWU-3

Certification program PCWU-3 The certification program of utility products type 3 of the certification program according to PN-EN ISO/IEC 17067 Number: Page: 1 z 8 MS-0013527 Is valid from: 01.03.2016 Prepared: Tomasz Marcinek Approved:

More information

OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis

OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance

More information

CPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018

CPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018 CPSC 444 Project Milestone III: Prototyping & Experiment Design Feb 6, 2018 OVERVIEW... 2 SUMMARY OF MILESTONE III DELIVERABLES... 2 1. Blog Update #3 - Low-fidelity Prototyping & Cognitive Walkthrough,

More information

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model.

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model. E-R Model Hi! Here in this lecture we are going to discuss about the E-R Model. What is Entity-Relationship Model? The entity-relationship model is useful because, as we will soon see, it facilitates communication

More information

Cyber Security Incident Report

Cyber Security Incident Report Cyber Security Incident Report Technical Rationale and Justification for Reliability Standard CIP-008-6 January 2019 NERC Report Title Report Date I Table of Contents Preface... iii Introduction... 1 New

More information

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Dr. S. Srinath Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 3 Relational Model Hello everyone, we have been looking into

More information

Fig. 7.1 Levels of normalization

Fig. 7.1 Levels of normalization 7 Normalization 7.1 INTRODUCTION The concept of normalization was introduced in Section 3.2. A normalized relation may be defined as one for which each of the, underlying domains contains atomic (nondecomposable)

More information

Implementing ITIL v3 Service Lifecycle

Implementing ITIL v3 Service Lifecycle Implementing ITIL v3 Lifecycle WHITE PAPER introduction GSS INFOTECH IT services have become an integral means for conducting business for all sizes of businesses, private and public organizations, educational

More information

Usability Inspection Report of NCSTRL

Usability Inspection Report of NCSTRL Usability Inspection Report of NCSTRL (Networked Computer Science Technical Report Library) www.ncstrl.org NSDL Evaluation Project - Related to efforts at Virginia Tech Dr. H. Rex Hartson Priya Shivakumar

More information

Notes on Turing s Theorem and Computability

Notes on Turing s Theorem and Computability Notes on Turing s Theorem and Computability Walter Neumann About 60 years ago there was a revolution in mathematics and philosophy. First Gödel and then Turing showed that there are impossible problems

More information

Why Continuity Matters

Why  Continuity Matters Why Email Continuity Matters Contents What is Email Continuity and Why it Matters........................... 1 Challenges to Email Continuity................................... 2 Increasing Email Management

More information

Data Models: The Center of the Business Information Systems Universe

Data Models: The Center of the Business Information Systems Universe Data s: The Center of the Business Information Systems Universe Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: Whitemarsh@wiscorp.com Web: www.wiscorp.com

More information

Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No. # 20 Concurrency Control Part -1 Foundations for concurrency

More information

Best Practices for. Membership Renewals

Best Practices for. Membership Renewals Best Practices for Membership Renewals For many associations, it s easy to get caught up in the marketing efforts associated with attracting new members. But as important as membership growth is, renewal

More information

Data Migration Plan (40) Fingrid Oyj

Data Migration Plan (40) Fingrid Oyj 1 (40) Fingrid Oyj FI10728943, VAT reg. 2 (40) Table of Contents Definitions... 5 1 Summary... 6 2 Introduction... 7 2.1 Datahub... 7 2.2 Members of the data migration plan... 8 2.3 Datahub's data migration

More information

The IDN Variant TLD Program: Updated Program Plan 23 August 2012

The IDN Variant TLD Program: Updated Program Plan 23 August 2012 The IDN Variant TLD Program: Updated Program Plan 23 August 2012 Table of Contents Project Background... 2 The IDN Variant TLD Program... 2 Revised Program Plan, Projects and Timeline:... 3 Communication

More information

critically examined in the Federal Archives.

critically examined in the Federal Archives. Bettina Martin-Weber BASYS - The Federal Archives database-driven archival management system for description, administration and presentation of metadata and digital archives Back in 2004 I already took

More information