nach oben

2014 | Buch

Kapitel lesen Erstes Kapitel lesen

Enterprise Information Systems Engineering

The MERODE Approach

verfasst von: Monique Snoeck

Verlag: Springer International Publishing

Buchreihe : The Enterprise Engineering Series

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

The increasing penetration of IT in organizations calls for an integrative perspective on enterprises and their supporting information systems. MERODE offers an intuitive and practical approach to enterprise modelling and using these models as core for building enterprise information systems. From a business analyst perspective, benefits of the approach are its simplicity and the possibility to evaluate the consequences of modeling choices through fast prototyping, without requiring any technical experience. The focus on domain modelling ensures the development of a common language for talking about essential business concepts and of a shared understanding of business rules. On the construction side, experienced benefits of the approach are a clear separation between specification and implementation, more generic and future-proof systems, and an improved insight in the cost of changes.

A first distinguishing feature is the method’s grounding in process algebra provides clear criteria and practical support for model quality. Second, the use of the concept of business events provides a deep integration between structural and behavioral aspects. The clear and intuitive semantics easily extend to application integration (COTS software and Web Services).

Students and practitioners are the book’s main target audience, as both groups will benefit from its practical advice on how to create complete models which combine structural and behavioral views of a system-to-be and which can readily be transformed into code, and on how to evaluate the quality of those models. In addition, researchers in the area of conceptual or enterprise modelling will find a concise overview of the main findings related to the MERODE project.

The work is complemented by a wealth of extra material on the author’s web page at KU Leuven, including a free CASE tool with code generator, a collection of cases with solutions, and a set of domain modelling patterns that have been developed on the basis of the method’s use in industry and government.

Inhaltsverzeichnis

Frontmatter

Introduction

Frontmatter

Chapter 1. Enterprise Modelling

Abstract

As enterprises are complex systems involving both human and technological aspects and are highly influenced by the environment in which they operate, architecting an enterprise and the information systems that support its functioning is not an easy task. In the usual way of working, enterprise information systems development is guided by strategy development, programme management and Enterprise Architecture [72].

Monique Snoeck

Chapter 2. From Demand to Supply: Layers and Model Quality

Abstract

Although the development of an appropriate Business Architecture is essential in realising organisation’s strategy, reflection on the desired information system service functionality and information system architecture is needed as well. Moreover, from an enterprise information systems development perspective, we need to help software engineers in creating generic, flexible and (therefore) future-proof systems. Focusing in the first place on the demand side of a software project and ensuring the quality of enterprise models is one means to achieve this. At the same time, bridging the gap between demand and supply is also of prime importance. Therefore, the MERODE approach builds on two main principles which, next to being of benefit to the demand side, benefit to the supply side as well.

Monique Snoeck

Chapter 3. Overview of MERODE

Abstract

This chapter concludes the introductory part with a general overview of the approach by means of a small library example. It should give the reader scome insight in all the techniques and principles that are present in MERODE, without going too much in detail. Part II of this book will then present each technique separately in a more elaborated and formal way. The chapter starts with a global overview of the modelling process and then reviews the models from inner layer to outer layer: first domain modelling, then information system service identification and finally business process modelling.

Monique Snoeck

Domain Modelling Techniques

Frontmatter

Chapter 4. The Existence-Dependency Graph

Abstract

One of the main tasks in domain modelling is the identification of relevant concepts in the universe of discourse. Typical kinds of concepts are classes, attributes, methods and relationships between classes. In this chapter, we primarily deal with classes and relationships between classes. Business object types are classes that represent a set of similar objects in the universe of discourse of an enterprise. For example, in the universe of discourse of a library, we can identify members and books as business object types. As business objects do not exist independently, but coexist and interact with other business objects, relationship types called ‘associations’ are used to capture the semantics according to which business objects are related.

Monique Snoeck

Chapter 5. Object Interaction

Abstract

The dynamic aspects of a system are defined by the combination of the dynamic behaviour of the individual components of the system and the way components interact. In MERODE, these aspects are respectively modelled by means of sequence constraints and the object-event table. This chapter deals with modelling object interaction by means of the object-event table. Sequence constraints are the subject of Chap. 6.

Monique Snoeck

Chapter 6. Object and System Behaviour

Abstract

Business events are not allowed to occur in a random order during the life cycle of an object. For example, a book cannot be returned if it has not previously been borrowed. In order to specify this kind of constraints, each object type can specify sequence constraints on the business events it participates in by means of a finite-state machine (or FSM for short).

Monique Snoeck

Chapter 7. Attributes and Constraints

Abstract

In essence, without attribute values, objects and business events cannot be identified by human users. In order to make objects and events identifiable for the outside world (including the user), we have to adorn them with values by which we can recognise them. For example, a customer becomes identifiable through his/her name, address and telephone number. An account becomes identifiable through its account number, and a deposit event becomes identifiable through the amount deposited, the account number of the account to which the money is to be deposited and the date and time at which the deposit took place. To this end, in a domain model, the definition of a business object type includes a number of attributes (called static features in UML). In terms of a relational database, the attributes will correspond to the columns of a table definition. Each object will have a value for each of the attributes in the definition of its object type. Together, all these values form the ‘state vector’ of an object. The range of values an attribute can take can be constrained to a particular type such as a numerical value, a date, a time, text and so on. This is called the data type of the attribute. For example, a customer may have a street name that is of data type ‘text’, and a ZIP code of that is of data type ‘numeric’.

Monique Snoeck

Chapter 8. Inheritance

Abstract

This chapter presents the use of the principle of generalisation/specialisation in conceptual modelling. Generalisation/specialisation is an abstraction principle allowing the definition of a class as a refinement of another class. The more general class is called a supertype, generalisation or parent class and the refined class is then called a subtype, specialisation or child class. With the advent of object-oriented analysis methods, many different ways of how to concretely use the generalisation/specialisation hierarchy in modelling were proposed. Most of the time, however, these proposals were not well integrated with the behavioural aspects in object-oriented modelling. Also today the definition of the generalisation/specialisation relationship is mostly formulated in the context of a static model only. In this chapter we will first address the definition of the concept from the perspective of the class diagram. Subsequently, Sect. 8.2 addresses the behavioural aspects of inheritance. To conclude Sect. 8.3 will address the question on when to use or not to use this construct.

Monique Snoeck

The Information System Layer and the Business Process Layer

Frontmatter

Chapter 9. The Information System Service Layer

Abstract

One of the main goals of building enterprise information system is to satisfy the information needs of the different stakeholders of the organisation. But before information needs can be satisfied, information obviously needs to be registered first. As a consequence, an enterprise information system needs to offer two types of services: input services to register information and output services to satisfy information needs. In combination with the enterprise layer, this leads to three loosely coupled subsystems, each addressing a specific concern:

Monique Snoeck

Chapter 10. Bridging Business Process Modelling and Domain Modelling

Abstract

As explained in Sect. 1.3.2 most Enterprise Architecture frameworks seem to agree that at least the following viewpoints should be included in a Business Architecture description [5]:

Monique Snoeck

Model Transformation

Frontmatter

Chapter 11. Model Transformation

Abstract

In a classic approach to software development, the requirements and analysis stages are a largely informal and iterative process. At a certain point in time, specifications are considered to be (more or less) finalised and they are handed over to the implementation team, which proceeds with the technical design, coding and testing. Also the sequence of technical design, coding and testing is actually an iterative process. If problems are discovered during coding and/or testing, one will return to the previous stage to take corrective actions. It is, however, rare that the analysis documents are updated accordingly. Surely, discovered errors may lead to some extra requirements elicitation and analysis activities during the implementation phase, but the results of these will be immediately incorporated into the code rather than documenting them first via updated models and requirements documentation. Figure 11.1 represents this way of working.

Monique Snoeck

Chapter 12. Application and Component Integration

Abstract

Although the MERODE approach was initially developed for the development of new intranet-based applications, its concepts also suit the problem of application or component integration very well [45, 46]. Essentially, the event layer leads to an event-driven target architecture. The principles of such architecture can easily be applied to achieve component integration. Components are typically coarser grained than individual business objects and are usually conceived as a black box to the outside world: they may contain multiple business objects but do not publish individual interfaces to each of these individual business objects. Therefore, in a component integration context, event-based interaction will occur at the level of components rather than at the level of individual business objects.

Monique Snoeck

Backmatter

Titel: Enterprise Information Systems Engineering
verfasst von: Monique Snoeck
Verlag: Springer International Publishing
Electronic ISBN: 978-3-319-10145-3
Print ISBN: 978-3-319-10144-6
DOI: https://doi.org/10.1007/978-3-319-10145-3