Extending CDIF to Support Enterprise Modeling

Extending CDIF to Support Enterprise Modeling

Per Burman

Submitted by Per Burman to the University of Skövde as a disser- tation towards the degree of M.Sc. by examination and disserta- tion in the department of computer science.

September 1997

I hereby certify that all material in this dissertation which is not my own work has been identified and that no work is included for which a degree has already been conferred on me.

Per Burman

there should be an explicit connection between the rationale of the system developed and the system itself. In the “From Fuzzy to Formal” project an attempt to develop a method- ology supporting this was made. Within the project a method called Enterprise Modeling was developed, aiming at creating this connection. This method contains five different sub-models. The sub-models are connected to each other by inter-model links. The models developed using EM are of high complexity. Therefore tool and repository support should be provided. To be flexible and extendible, such a tool set should be based upon a stan- dardized meta-model. CDIF is an example of such a standard.

In this dissertation we develop a meta-model capable of capturing the information that is created using the Enterprise Modeling technique. We use the extensibility mechanism that is provided with the CDIF standard to extend the existing CDIF Integrated meta-model to support the models used in this work. We also develop a procedure supporting the map- ping between the representations. Finally we discuss the functionality of a tool capable of supporting the work with the models.

1 Introduction ... 3

2 Background... 6

2.1 Introduction ... 6

2.2 Meta models ... 6

2.3 CDIF... 8

2.3.1 Introduction to CDIF... 8

2.3.2 CDIF graphical notation... 9

2.3.3 The CDIF Architecture ... 11

2.3.4 The extensibility mechanism... 13

2.4 F3 Enterprise Modeling ... 15

2.4.1 Introduction ... 15

2.4.2 Way of working with F3 EM ... 15

2.4.3 F3 EM and the SDLC ... 16

2.4.4 Perspective of EM... 18

2.4.5 Sub-models in EM ... 20

2.4.6 Explicit links between the sub-models (inter-model links) ... 22

2.5 Mapping between F3 EM and CDIF... 23

2.5.1 Introduction ... 23

2.5.2 Mapping... 23

2.6 Tool support for Enterprise Modeling... 24

2.6.1 Introduction ... 24

2.6.2 Tool functionality... 25

2.7 Summary ... 26

3 EM Requirements ... 27

3.1 Introduction ... 27

3.2 Selection of sub-models ... 27

3.2.1 Selection criterias... 27

3.2.2 Arguments for selection ... 28

3.3 F3 EM requirements... 28

3.3.1 The Activities and Usage Model... 29

3.3.2 Concepts model ... 32

3.3.3 Inter-model links... 35

3.4 Summary ... 36

4 Schema Design ... 37

4.1 Introduction ... 37

4.2 A new Subject area... 38

4.3 Design for AUM... 38

4.4 Design for CM ... 43

4.5 Design for Inter-model links ... 48

4.6 Evaluation of design... 48

Contents

5.4 Mapping of CM... 57

5.5 Mapping of inter-model links... 60

5.6 An example ... 61

5.6.1 Mapping of AUM components... 62

5.6.2 Mapping of CM components ... 64

5.6.3 Mapping of inter-model links ... 65

5.7 Summary ... 66

6 Tool Functionality... 67

6.1 Introduction ... 67

6.2 F3 EM in Requirements Engineering... 68

6.2.1 Elicitation ... 70

6.2.2 Representation ... 71

6.2.3 Validation ... 72

6.3 Required functionality... 73

6.3.1 Elicitation ... 73

6.3.2 Representation ... 73

6.3.3 Validation ... 75

6.3.4 Other functionality ... 76

6.4 Summary ... 77

7 Summary ... 78

7.1 Introduction ... 78

7.2 Achievements ... 78

7.2.1 F3 EM sub-models... 78

7.2.2 Design of CDIF meta-model ... 79

7.2.3 Mapping from F3 Enterprise Models to CDIF... 80

7.2.4 Tool functionality... 80

7.3 Open issues ... 81

7.4 Future work ... 82

References ... 84

List of Figures ... 88

List of Tables... 89

Appendix A... 90

Appendix B... 91

Appendix C ... 92

Introduction

1 Introduction

Information systems development is a very complex task. The process generates a great amount of information. There is a need to support the handling of information generated in the different stages of the development process and to integrate this information. Users of different systems development methods are starting to demand the requirements spec- ification clearly specify why a specific product has been developed and also that it explains the rationale behind every requirement in the specification [Per97]. This shows that it is an important criterion that all development information gathered during a devel- opment project should be maintained and carefully managed through the different sub- processes of the development life-cycle. One method that has been designed with this goal in mind is the F³ methodology [Bub94]. Within this methodology a method was developed called Enterprise¹ Modeling (EM²) which supports the Requirements Engi- neering process.

As stated above the information generated during this process is highly complex. Experi- ence has shown that it is too difficult for humans to handle without tool support [Per97].

It is almost a prerequisite to have an automated system that is capable of supporting the humans involved in the systems development process. If the models developed, using F³ EM, and other information could be handled by a database and a proper tool set many purposes could be served, e.g.:

• Different views of integrated models could easily be created;

• Searching for information pertaining to a specific deliverable could be supported;

• Support for change management as the project proceeds could be given;

• Automatic maintenance of the inter-model links could be provided

A database containing this kind of information is often referred to as a repository. A repository system is a database application with some additional features that distin- guishes it from a traditional database system. One of the more important is a meta- model³ which is a schematic and semantic description of the contents of the database [For89a].

CDIF⁴ is an evolving family of standards that is being developed by the EIA⁵ [CDIF97].

It is meant to be used as an external interface for tools or repositories when transferring data. CDIF contains a large meta-model that describes information created in the systems development process, a transfer format and an extensibility mechanism. The extensibil- ity mechanism can be used to extend the meta-model of CDIF. CDIF is claimed to be an open standard, meaning that it is method independent and vendor independent. It is being investigated by ISO with respect to acceptance as an international standard. The stan- dardization work is being done together with a number of other standard bodies, i.e.

OMG, ANSI H3H4 and ISO/IEC JTC/SC7/WG11 [Ern97].

It has been stated by the originators of F³ that:

“We strongly suggest that the CDIF standard is considered for F³ and its inter-tool communication” [Bub92b, p.39].

A repository system, as described above, can be an important asset for an organization. It can serve several purposes in different activities within the organization, not only as sup- port for the systems development process. One example of this usage is to store more general enterprise information, e.g. business goals, objectives, concepts and rules [Tan94].

With regard to what has been discussed above, the aim of this dissertation is:

3. Meta-models are more thoroughly introduced in section 2.2 4. CASE Data Interchange Format

Introduction

• To produce a CDIF extension capable of capturing the high-level enterprise infor- mation obtained using the F³ EM methodology. A relevant subset of the models will be chosen based upon a number of criterias thereby identifying all constructs in the chosen models. A CDIF meta-model, with the property of being non-ambig- uous, will be designed using a systematic mapping of each construct. Finally, a procedure for mapping the F³ EM constructs into CDIF will be developed. For the procedure we will identify the ordering of the mapping and consider consistency with regards to the rules of the F³ EM methodology.

• To describe the functionality of a tool that is capable of browsing the models cap- tured by the CDIF meta-model.

Our main emphasis is the design of a schema, using CDIF, that is capable of capturing the information created when using the F³ EM models.

The outline of this dissertation is as follows. In chapter 2 the framework for this work is set. It introduces meta models, CDIF and also the F³ EM methodology. Chapter 3 describes the requirements on the schema capable of capturing the models. Chapter 4 then describes the conceptual design of the schema, using the information model that is provided by CDIF, and when necessary the meta-model will be extended. In chapter 5 the mapping procedure that describes how the mapping should be performed is given.

The required functionality of a tool for handling the models is outlined in chapter 6.

Finally, in chapter 7 a critical review of the work done in the project, together with a dis- cussion of achievements and a description of possible future work in this area is done.

2 Background

2.1 Introduction

In this chapter the framework is set for the rest of this dissertation. The area in which the work is done is defined. Similar work previously done by others is analyzed and dis- cussed. This is done to establish the work in a broader context of research in this particu- lar area.

The main concern of this chapter is the introduction of the methods and standards that are to be used in the rest of the work. The purpose and use of the standards and models is discussed. The choice of the different methods and models is motivated.

The chapter is divided into a number of sub-sections. Section 2.2 introduce and discuss CDIF, the underlying theories and ideas. In section 2.3 the Enterprise Modeling tech- nique that is to be used in the work is introduced, the different models and its constructs are introduced. In section 2.4 the mapping between the F³ Enterprise models and CDIF is introduced in a general way discussing the principles of the mapping. The Background section is concluded with an introduction to modeling tools and the specific functionality required for a tool aiming at supporting the F³ EM methodology.

2.2 Meta models

CDIF contains a complex meta-model that is aimed at describing the information gener- ated during the systems development process. In this section an introduction to the con- cept of meta-models will be given.

The term meta model is in itself not very clear. Meta stands for a relationship between the meta model and something else, the model. A model is an artificial representation of something in the real world. We will consider a requirements specification as something which describe phenomenon being observed in the real world. The model is developed by the use of some kind of language that have a number of constructs. These constructs

Background

models. As well as models are described using some language also meta-models are described using a language, this is called meta-modeling.

In short, a meta model is a representation of the constructs allowed at the model level. If the meta-model is to be extensible a new level of abstraction must be introduced. This level is called the meta-meta level [Wel89]. At this level the allowed constructs in the meta-model is defined, including objects, object types, classes, roles, etc.

Table 1: The four level architecture.

With this addition we can see the models described by four levels. The first level con- tains the actual instantiated data, (e.g. 100, Carl, Red). At the second level, the model level, the data level is described and it contains descriptions of the various objects of that level, (e.g. CUSTOMER, CAR, CUSTOMER_INVOICE). The third level, the meta level, describes the elements of a particular design method, (e.g. the object types and rules used when creating a ER model [Che76]). At the top of the hierarchy there is the

Level Example

Meta-meta schema Constructs allowed in the Meta schema, e.g. Objects, Roles, Classes.

Meta schema ER, DFD, EER. (Instance of the Meta-

meta schema.)

Model ER schema of a manufacturing system,

i.e. an instance of a meta-schema

Production Data 100, Dog, Red, SAAB

The meta-model describes the object types for a certain set of design notations [Wel89], for example the object types and rules concerning the notation used in the ER Model [Che76].

Today there exist a number of suggestions of how meta models should be designed. We will only mention some of the most well known suggestions, these include IRDS [IRDS97], PCTE [PCTE97] and ATIS. These will not be further described in this work.

Instead we will now turn to the CDIF standards proposal and introduce it.

2.3 CDIF

2.3.1 Introduction to CDIF

CDIF [EIA106] is a standard which defines how software engineering information is to be transferred between different CASE tools used in the development process. It pro- vides a set of vendor and method independent definitions for meta-data concepts which are aimed at data modeling and related concepts.

It is important to notice that CDIF is not a specification of a repository, it specifies an export/import utility to be used as a CASE tool or repository external interface [EIA106].

The CDIF Technical Committee has developed the CDIF family of standards. These are divided into three parts:

• one specifying the underlying architecture;

• one defining the transfer formats used;

• one defining the CDIF Integrated Meta-model.

The part defining the Integrated Meta-model is by far the most complex, since this part defines the information that can be expressed using CDIF. It is the meta-model that defines the semantics of the information being modeled. The separation of transfer for- mat and meta-models makes it possible to separate the syntax from the semantics in an information transfer. This is makes it possible to use the Integrated meta-model as an

Background

The Integrated Meta-model tries to cover all techniques used by CASE tools today.

Since this would create a huge meta-model, almost impossible to handle, the model has been divided into Subject Areas. Each Subject Area covers a specific technique used in a CASE tool, such as Data modeling, Dataflow modeling or OO-modeling. Each Subject Area is a view of the total meta-model and hence a meta-entity can be defined once and then used in several Subject areas, i.e. the meta-entity Attribute is defined once in the DataModeling subject area, but it is then used in the DataFlow modeling subject area as well.

As of today there are fourteen different Subject Areas published, under development or about to be defined [cf. CDIF97].

The body specifying CDIF has realized that it is hard to anticipate all the different needs that users might have now or in the future. To solve this an implementor can define his own Subject Areas using the CDIF extensibility mechanism, see section 2.3.4. Using this mechanism any information needed by a user can be defined and in a transfer no differ- ence is made between transfer of user defined models and transfer of models using the Integrated Meta-model.

The Integrated Meta model is defined using a four level architecture with the meta-meta concepts at the top of the hierarchy and the instantiated data at the bottom. This architec- ture is the same as the one defined in section 2.2. Using this meta-hierarchy the seman- tics of the models can be transferred. Above we mentioned that there is clear separation between the syntax and semantics in the CDIF standard. This is useful when transferring models between different CASE tools since different tools uses different notations to express the same information. However, CDIF does not assume a specific representation of the information, it only transfers the semantics of the information and hence the receiving tool can represent it according to its style.

2.3.2 CDIF graphical notation

• Meta-entities are drawn as a rectangular boxes, with the name of the meta-entity on white background. If the meta-entity is not used but included for clarity the box shall be shaded in grey.

• Meta-relationships are drawn as straight line, with a single arrowhead, joining two meta-entities. The two meta-entities participating in the relationship are referred to as source and destination as indicated by the arrowhead. There can be three vari- ants of the representation of a meta-relationship, if used for clarity the line shall be shaded. If a supertype meta-entity participating in a meta-relationship is not included in the diagram, the inherited meta-relationship may be shown as a broken line from/to the inheriting subtype meta-entity.

• Reflexive meta-relationships is drawn from a meta-entity to itself.

• The cardinality and optionality of a relationship is defined by labels (x:y) where x denotes the minimum and y denotes the maximum number of instances of the meta-entity nearest the label from the perspective of a single instance of the other meta-entity. To exemplify this, figure 1 can be used. The meta-relationship between SubjectArea and CollectableMetaObject states that a CollectableMetaOb- ject must at least be used in one subject area but can be used in several. Reading it the other way a SubjectArea must not contain any CollectableMetaObjects but can contain several.

• Meta-entity subtypes are drawn as a “fork” with the supertype meta-entity occurs above the subtype meta-entities. The lines depicting the sub/supertype hierarchy are not labeled they are also restricted to being horizontal and vertical.

• Meta-relationship inheritance hierarchies are not shown graphically. The inherit- ance of meta-relationships is shown in the AttributableMetaObject hierarchy, which is represented in text with indents to show super/subtype hierarchies.

Background

2.3.3 The CDIF Architecture

At the top-level in CDIF there is a meta-meta-model which in terms of its own notation describes the expressiveness of the notation technique used. This level defines the meta- models themselves. At this level there are meta-objects and meta-relationships. The meta-relationships are binary relationships which relates the meta objects to each other.

In the meta-meta-model there is a inheritance hierarchy defined. This inheritance allows multiple inheritance both of meta-objects and meta-relationships. In figure 1 the meta- meta-model is shown. It is this meta-meta-model that sets the rules for all other models developed using CDIF.

However, although the meta-meta-relationships are restricted to being binary, it is possi- ble to express more complex relations using the meta-entities that are defined in the dif-

Figure 1: The CDIF Meta-meta model, adapted from [EIA107].

important meta-meta-attribute is the CDIFMetaIdentifier which defines every single meta-object (meta-entity, meta-relationship and meta-attribute) uniquely.

At the next level down meta-models are defined. They are predefined definitions for transferring models for a specific subject area like Data models and Data Flow models. It is all of these subject areas that together makes up the CDIF Integrated Meta Model. The CDIF Integrated Meta Model is defined by the modeling technique used at the meta- meta-model and hence CDIF is defined in means of itself. The two most important sub- ject areas are Foundation Subject Area and the Common Subject Area. They are neces- sary for any use of the CDIF Integrated Meta Model.

Foundation Subject Area

This subject area serves as the root of all other subject areas within CDIF. All meta-mod- els defined in CDIF must be a subclass directly or indirectly the meta-entities RootObject (which is an abstract class of type AttributableMetaObject) for RootEntity and the meta- relationship IsRelatedTo.

RootEntity RootObject

Figure 2: The CDIF FoundationSubjectArea, adapted from [EIA111]

IsRelatedTo

0:N

0:N

Background

Common Subject Area

In the Common Subject Area the primitive Foundation Subject Area is refined by defin- ing the meta-entities ToolUser, AbstractionLevel, SemanticInformationObject, Textual- Constraint, PresentationInformationObject and AlternateName. The SemanticInformationObject serves as the abstract superclass of all of the meta-entities that is involved in the transfer of any semantic related information in the other subject areas, defining for instance the semantics of a transferable dataflow model.

2.3.4 The extensibility mechanism

The body working with the standardization of CDIF has realized that it is impossible to

Figure 3: The CDIF CommonSubjectArea, adapted from [EIA112].

mechanism is introduced in the standard. The extensibility mechanism gives the possibil- ity to exchange information between tools or repositories that is not present in the CDIF Integrated meta-model. Using extensibility new meta-entities, meta-relationships and meta-attributes may be introduced. On a more specific level this done by having the exporting facility to warn the importer that the transfer includes information not speci- fied in the standard meta-model before the transfer is started. There a a number of rules and guidelines that specifies how the transporter and importer shall handle extensibility in the transfer of information. There are also rules specifying how the extension of the CDIF Integrated meta-model shall be done [cf. EIA107].

If there is a need for transfer of non-standardized information, a new subject area must be created since it is not allowed to extend the existing subject areas. The new subject area that is introduced shall address either some functional area or technique found in the Software Development Life Cycle (SDLC, discussed in section 2.4.3), or provide similar functionality, or both of these. In the new exporter defined subject area existing stan- dardized meta-objects may be used. It is the responsibility of the exporter to reuse as much of the standardized meta-entities and minimize the use of extensibility. When reus- ing an existing meta-object a reference must be given to the subject area containing the full definition of the meta-entity must be given.

Even though it is specified that the exporter shall export all information it is not neces- sary that the importer understands all of the information sent. The exporter shall not try to anticipate this an adjust to the importer, the exporter shall always export all informa- tion available to it. If the exporter follows this rule then it is the importer that has to decide what information that is relevant to it. This is called the maximum output princi- ple in CDIF. While the importer receives information during an transfer, a “working meta-model” is created. The initial working meta-model only contains one meta object, the RootObject. As the import process continues the importer populates the working meta-model with the information it encounters as the process continuous. The working meta-model is not a model implemented in the importer, it is an conceptual device used to explain the process of importing models.

Background

2.4 F ³ Enterprise Modeling

2.4.1 Introduction

In recent years some authors [Bub93, Lou95] have claimed that in order to develop more high quality information systems there is a need to take the environment in which the system is to operate into account. The environment is the organization that the informa- tion system (IS) is to support. This makes it necessary to create a stronger connection between the IS development process and the organization’s various goals, objectives, concepts and processes. In the ESPRIT III project 6612 “From Fuzzy to Formal” (F³) [Bub94] a set of models, techniques and tools were developed which were aimed at sup- porting the requirements specification process [F394a]. Most of the models were aimed at what can be regarded as traditional areas of systems development. However, one of the main goals of F³ was to establish a connection between business development and the development of information systems. The part aiming to describe the enterprise was the part called F³ Enterprise Modeling (EM). In this work we will only use the Enterprise Model, the other models in F³ will not be further discussed here.

2.4.2 Way of working with F

EM

The F³EM methodology provides a certain way of working that is iterative. When work- ing with F³ EM all sub-models are being developed in parallel and the work is issue- driven [Bub94]. The work is carried out by populating the different sub-models simulta- neously, not one at a time. This gives a continuous switch of the focus in the work and thereby aspects of the enterprise is analyzed from various perspectives and can therefore be better understood [Lou95]. This way of working supports the gradual move from early fuzzy requirements into the formalized representation that is represented in the requirements specification [Poh94].

The way of working in F³ EM can give many benefits, but since the concern of this work is the information generated using the models, the process of developing them is not a

2.4.3 F

EM and the SDLC

Software Engineering is defined as [Lou95, p. 6]:

“Software engineering is a systematic approach to the development, opera- tion, maintenance, and retirement of software.”

This definition implies that there is some kind of life-cycle of software engineering.

There are a number of models that describe this life-cycle. In this work we use the Soft- ware Development Life Cycle (SDLC) model that is taken from [EIA106] as an exam- ple, (see figure 4). There is no definition made in the standard of what the different phases is supposed to mean. To overcome this we give our interpretation of what is meant by the first two phases. We only define the two first phases since it is these that are the ones most similar to the extension to the traditional SDLC that are proposed in the F³ approach.

• Planning is the phase where a systems development project is planned. Risks are analyzed, activities are scheduled and the organization of the project is set up [Pre94]. The planning phase is very important and difficult, this is only a very brief introduction to what is included in this phase.

• Requirements Analysis enables the developer to specify the functionality and per- formance of the software to be developed. The interface of software to other sys- tems is established, there are also a number of other constraints that the system must meet. These constraints are specified in this phase. [Pre94]

This SDLC does however start at the point where the decision to develop an IS already has been made. We take a broader view of systems development and include the business analysis phase in our SDLC.

Background

F³ EM is used as a business analysis tool in the problem definition phase which is a phase prior to the ones in figure 4. This earlier phase includes analysis of the organiza- tion and its need of change. These changes can involve development of new information systems or change of the existing ones. When a decision, based upon the F³ EM analysis, to develop or change information systems in the organization, some of the information obtained in the EM phase is used as input in the development of the new system. It can also be the case that there is a need to develop a system and change the organization. In either case the information from the work with F³ EM is very useful.

One more use for the information generated by the F³ EM process is the creation of a Enterprise Knowledge Repository (EKR) [Bub96]. An EKR is a collection of the knowl- edge available in the organization. Among many other areas of use it could be used in the

Planning

Requirements Analysis Logical Design Physical Design Implementation

Testing Maintenance

Figure 4: An example of a Systems Development Life-cycle (SDLC).

accessible, the work of eliciting this knowledge from the people working in the organiza- tion can be reduced.

The connection, as we see it, between EM and the SDLC is described in figure 5.

2.4.4 Perspective of EM

There are quite a large number of commercially exploited methods for systems develop- ment in the marketplace today. Most of these models address the middle or late phases of the SDLC (see fig. 4), almost none of the methods address the earliest, business driven, requirements generating phases in a structured way [Bub93]. These methods also fail to

Planning

Requirements Analysis Logical Design Physical Design Implementation

Testing Maintenance

Organizational changes, Marketing activities, etc.

Problem definition, Business analysis.

Performed with, among other methods, F³ EM.

Systems development

Other actions

Figure 5: Our view of the connection between EM and traditional SDLC.

Background

address the problem of moving from the fuzzy, ill-structured phases into the more formal domain, a transformation which was mentioned above.

The need to establish and maintain a firm connection between the enterprise models and the information systems specification is not fulfilled by existing methods. The impor- tance of establishing a connection between the development of business objectives and the development of IS is well confirmed [Bub94]. If there is an understanding of how the development of the enterprise is connected to the development of information systems the requirements of the IS can be derived from this understanding. Making the system much more adaptable and thereby being a greater asset to the enterprise.

A requirements specification is usually seen as a specification of what a system is sup- posed to do, this in distinction from how it should be doing it. However the F³ methodol- ogy claims to add one perspective to this, the why perspective [Bub94]. It adds the information concerning why the system is built and in what surrounding context the sys- tem is to exist in. The main objective of F³ EM is to

“understand and document the business, its objectives, problems, concepts, actors, and activities, better, and in a more structured way than by simply providing natural language descriptions” [Bub93, p. 6]

More specifically the role of the F³ EM is to answer a number of questions within a requirements specification [Bub93]:

• Why is the system built?

• Which are the business processes and which is to be supported by the system?

• Which are the actors in the organization, which processes are they performing and how are they related to each other?

• What concepts are the actors using; what are their information needs?

• What initial objectives and requirements can be stated regarding the information system being developed?

The Enterprise Modeling process is based upon the notion that a number of sub-models needs to be populated. These models will be discussed in the following section.

2.4.5 Sub-models in EM

The Enterprise Model consists of five different sub-models. These models are inter- related (see figure 6). The models are represented graphically and described using natu- ral language modeled in semantic networks [F394a]:

• The Objectives Model (OM)

describes the motivation or reason for different activities and concepts in the enter- prise. It addresses the above discussed why perspective of the enterprise. The con- cepts in this sub-model are related to the enterprise itself and its rationale. The components used in the OM are Goal, Problem, Opportunity, Cause, Rule and Development Action. Business rules can be defined within the OM. The links used

IS-Requirements

Activities Actors

Concepts

Objectives motivate

refer to

are responsible for perform

motivate

are responsible for

Figure 6: The sub-models used in EM and the minimal inter-model links between these [Per97].

Background

• The Concepts Model (CM)

defines what we are talking about. The main purpose of this sub-model is to define application concepts and data at the conceptual level. The model is used to better understand the requirements specification or the enterprise processes. It is repre- sented using an ER like notation [Che76]. The main component used in the CM is Concept. Mechanisms for generalization (ISA) and aggregation (Part-Of) are pro- vided.

• The Activities and Usage Model (AUM)

describes the organizational activities, i.e. the functions and processes of the enter- prise. External agents outside the scope of the current activity are identified. Infor- mation and material flows between processes are described. This is a quite traditional dataflow diagramming technique. Components in this sub-model are Process, External process, Information set and Material set.

• The Actors Model (AM)

defines the actors that are involved in the different enterprise processes and their relationship and use of different resources. Components in the AM are Role, Orga- nizational unit, Non-Human Resource and Individual. The AM is modeled using the same kind of relations as in the CM.

• The Information Systems Requirements Model (ISRM)

is used to state the objectives, goals and problems of the information system being built. The components of this sub-model are IS Goal, IS Problem and IS Require- ment. The links are similar to the ones used in the OM.

A complete Enterprise Model is a number of populated sub-models, often several of each type. There can, for instance, be a number of CM’s which are partly overlapping, but each focusing on different issues in the enterprise. See figure 7 for a conceptual picture of what is meant.

2.4.6 Explicit links between the sub-models (inter-model links)

There are a number of links between the sub-models. These links are used to connect the sub-models and by that creating a wholeness in the model. The links gives the property of explicit traceability between the models. The property of traceability is something that is considered important [Got94].

Explicit traceability means that there are explicit pointers that points out for example which enterprise goal that motivates a certain process in the organization. The property of traceability is among other things very important for the validation of models. The important contribution by the traceability created in F³ EM is the explicit and firm con- nection between business objectives and the information system development. This is something that is considered important by several authors [cf. Bub93]. Methods that are most common today does not maintain the property of explicit traceability between the

Figure 7: Schematic picture of how the inter-model links between the AUM and the CM can be seen.

CM

CM CM

CM

AUM

AUM

AUM

CM AUM

Background

enterprise and the information system development and thereby evolution of the organi- zation can not be explicitly mapped to the information system requirements [Bub93].

The minimal set of links between the sub-models are:

• enterprise goals (OM) motivates business processes (AUM).

• enterprise goals (OM) motivates information system goals (ISRM).

• actors (AM) performs business activities (AUM).

• actors (AM) are responsible for the business processes (AUM).

• actors (AM) are responsible for enterprise goals (OM).

• information systems requirements (ISRM) refers to business processes (AUM).

• information and material sets (AUM) are defined in the CM.

• any concept used in the OM, AUM, AM and ISRM can be defined in the CM.

2.5 Mapping between F ³ EM and CDIF

2.5.1 Introduction

In the previous sections we have introduced CDIF and F³ EM. The aim of this work is to create a CDIF design capable of capturing the information generated when using F³ EM.

To do this a mapping between the two different representations must be done. There are number of problems associated with performing a mapping and there are also a number of aspects that must be considered. It is the concern of the section below to discuss these problems and aspects.

2.5.2 Mapping

When developing the meta-models in CDIF capable of capturing Enterprise Models we will use a meta-model over F³ EM and from that derive which constructs that are neces-

that exactly describes how the mapping is to be performed. Using this approach we will give a step by step procedure to show that the design is working.

It can be argued that we will not prove that our design works for all possible combina- tions of constructs. This is true to some extent, but since we have systematically devel- oped the design for each construct from the Enterprise Models to CDIF, we consider the design as being correct for each primitive used in the F³ Enterprise Models.

One problem that might arise when performing a mapping is that there maybe some ambiguity regarding which construct to use when changing representation. In the design developed in this work we do not face this problem. The constructs have clear semantics and the mapping procedure gives a clear description of which construct to use when.

There are a number of rules defined for the development of the F³ Enterprise Models [F394a]. These rules describe how components can be combined and what is necessary for the models to fulfill in order to be regarded as complete. The mapping of the models has to take some of these rules into account in order to create representations that are consistent with the F³ EM methodology. The design of the meta-models that is outlined below is done in a way that will not allow for inconsistent representations with regard to the F³ EM methodology rules. It is the task of the mapping procedure to make sure that the models created using the procedure always are consistent with the constraints in the CDIF meta-model.

2.6 Tool support for Enterprise Modeling

2.6.1 Introduction

As we stated above it has been shown that there is a need for automated tool support when working with F³ EM. A ordinary drawing tool such as ABCFlowCharter [Mic97]

can be used, but the work with the models will be much easier and faster if a tool specif- ically developed to support F³ EM can be used.

There has been some attempts to create a tool for the F³EM methodology [F394b], but

Background

successful use of the F³ EM methodology is a powerful tool to support the development and maintenance of the models [Per96].

The creators of the F³ EM methodology have also realized that good tool support is a critical success factor for the method [F394a]. They have stated that a tool should address:

• The capture, representation, and refinement of non structured information which should be analyzed and validated.

• The capture and representation of information contained in Enterprise Modeling activities.

In [Per97] two types of necessary functions for the F³ EM methodology were identified, one dealing with the maintenance of consistency in the models that are developed and one type dealing with the representations of the models, i.e. browsing, querying, draw- ing, etc.

Since the CDIF meta-models developed in this work is designed to only accept models that are consistent with the rules of the F³ EM methodology. This makes a tool that sup- ports consistency maintenance abundant. The tool functionality outlined in this work will concentrate on support for different aspects of representation, querying, browsing and maintenance of models.

2.6.2 Tool functionality

The models developed using the F³ EM methodology can be used in the Requirements Engineering (RE) process. This process can be divided into a number of sub-processes:

Elicitation, Representation and Validation. These sub-processes are introduced in chap- ter 6. These processes will be used as a framework for the discussion of tool functional- ity.

In chapter 6 there are a number of requirements for tool functionality outlined. Some of

be supported by the tool and what functionality that should be provided by the repository system.

The functionality that will be described will be the kind of functionality that is specifi- cally needed by the models of F³ EM. We will not regard the functionality that is general to all kinds of Computer Aided Engineering Software Engineering (CASE) tools. That kind of functionality is most certainly interesting, but our aim is to emphasize what spe- cific functionality that is required for the models used in this work.

2.7 Summary

In this chapter the foundation for the rest of this dissertation has been introduced. We started by introducing meta-models which is an important concept through out the rest of this work. After this the CDIF standards proposal was introduced. After this the F³ Enterprise Modeling technique was introduced. CDIF will be used to capture the models used in F³ EM. A brief introduction was made of how the mapping between the two dif- ferent representations should be made. The chapter was concluded with an introduction to a tool capable of handling the models captured by the CDIF representation.

In the next chapter a selection of sub-models from the F³ EM methodology is made. The constructs used in the selected models are then carefully analyzed.

EM Requirements

3 EM Requirements

3.1 Introduction

One of the aims of this work is to create an information schema design, using CDIF, that should be capable of capturing F³ Enterprise Models. The first that has to be done is to select a relevant subset of models. This is done in section 3.2. The goal is to create a schema that is capable of capturing the models without loss of semantics. To achieve this the semantic of each construct used in the models has to be very clearly defined and understood. In section 3.3 the semantics of the different constructs in the F³ EM method- ology will be analyzed and described. The inter-model links used in F³ EM will also be discussed. Another aim is to create a procedure that describes how the mapping between the models is to be performed. The requirements on the mapping procedure will be dis- cussed in section 3.3. The procedure is to be used to describe how the mapping should be done.

3.2 Selection of sub-models

The aim of this work is to produce an extension of CDIF that is capable of capturing enterprise information, which is traditionally not regarded as software engineering infor- mation. To do this we have chosen the EM part of F³. This model consists of five differ- ent sub-models, each describing a different view of the enterprise. However, in this work we will not make a CDIF design using all of these five sub-models. We will select a rel- evant subset of the sub-models.

3.2.1 Selection criterias

The criterias upon which the selection of the sub-models will be based are the following:

• The models should contain different constructs. This is important since some of the models have the same structure.

• The constructs in the models should cover a wide range of constructs in EM. This is important since it gives the possibility to test as much as possible of the various constructs from F³ EM.

• It should possible to use the existing subject areas of CDIF to some extent. It is not relevant to create a totally new subject area that does not use any constructs defined in CDIF. We regard it as more interesting to see to what extent CDIF cov- ers the content of the F³ EM models as it is. And in doing this investigate whether it is possible to use CDIF to capture the inter-model links.

3.2.2 Arguments for selection

The CM and the AM is defined using the same constructs. It is the semantics of the com- ponents that are different. If we can show that CDIF is capable of handling the CM then we can make the conclusion that it will be capable of handling the AM.

The AUM is a quite ordinary dataflow model, and there is a Subject Area within CDIF that is supporting this. In these two models, the AUM and the CM, a wide variety of con- structs are represented. The ISRM and OM will be omitted since they contain constructs that are specific to the F³ EM methodology and hence there is no support at all in the cur- rent CDIF proposal. Therefore it would probably be necessary to use extensibility to specify the constructs for these models. Instead we aim at making a deeper analysis of the usage of AUM, CM, the inter-model links between these and CDIF and thereby more carefully verify our findings.

3.3 F ³ EM requirements

The F³ EM methodology contains, as described earlier, five different sub-models each focusing on different aspects of an enterprise. Within each model a number of constructs are used to represent various entities of the enterprise being modeled. One of the most important contributions of the F³ EM methodology is the links between the sub-models, the inter-model links. These links connect the sub-models to each other and thereby they

EM Requirements

In this work we will consider the Activities and Usage model and the Concepts model.

The constructs and semantics of these models will be described below. (For an overview of the models see appendix A.) Since we only will consider the AUM and CM, the links within and between them are the ones that will be considered. There are links between these two sub-models and the other sub-models in the F³ EM methodology but we will not discuss these.

The description of the models is taken from [F394a].

3.3.1 The Activities and Usage Model

The Activities&Usage model (AUM) is designed for analyzing the processes and flows of information and material in the enterprise. These processes are the core of the enter- prise and each should be contributing to overall value of the business of the enterprise.

Besides the processes and flows within the enterprise the processes external to the focus of the model which has an impact must be identified. The AUM supports decomposition of processes into sub-processes into any level of detail, this is used to support overview and detail in the models.

Below the constructs of the AUM will be described.

Process

A process is a collection of activities which uses a number of inputs (information or material) and produces a number of outputs (information or material). The set of activi- ties which constitutes a process is denoted by a short name, e.g. “Activate Terminal Equipment”. Processes can, as we mentioned above, be decomposed into sub-processes.

This is done using the has_component relation. Processes are the only constructs that can, and has to be, decomposed. In other DFD techniques, e.g. the one used in SSADM [Mel94], there is support for decomposing flows and external processes also. A Process is required to have at least one incoming and one outgoing Information and/or Material set.

External process

An External process is a process that is external to the focus of the model. An External

Process01

Process02

Process03

Process04 ExternalProcess01

Subscriber is con nected

Activate terminal equpment

End transmission of number info.

Send ringsignal Detect signal

sequence Switch

polarity

No.

Info

Switch polarity

Signal

Figure 8: Example of an Activities&Usage model depicting number transmission in a telephone net- work.

EM Requirements

rial) OR produces a number of outputs (information or material), i.e. an External process has either inputs OR outputs. The set of activities which constitutes an External process is denoted by a short name, e.g. “Subscriber is Connected”. An External process can be performed by humans or by machines. In the AUM decomposition of External processes is not supported.

Information set

An Information set is a set of information that is sent from one Process or External Pro- cess to another. Each Information set should have at least one sending Process/External Process and at least one receiving Process/External Process. Each Information Set must appear as a concept in the CM. This connection is established using the Concept/infor- mation link construct. An Information set can be decomposed in the CM, the it is not structured in the AUM.

Material set

A material set denotes a set of concrete “real-world” objects. These objects can be trans- ported or can flow from one Process/External process to another. Each Material set should have at least one sending Process/External Process and at least one receiving Pro- cess/External Process. Each Material set must appear as a concept in the CM. The Mate- rial set can be decomposed in the CM, but it is not structured in the AUM.

Links within the AUM

Between the constructs described above there are a number of links. The links are stated below. (For a better overview see appendix A).

• Process has_output (0:N) Information, connects the information flows out from a process.

• Process has_input (0:N) Information, connects the information flows into the pro- cess.

• Process has_output (0:N) Material, connects the material flows out from a Process.

• External Process has_output (0:N) Information.

• External Process has_input (0:N) Information

• External Process has_output (0:N) Material

• External Process has_input (0:N) Material

• Process has_component (0:N) Process, used to decompose structured Processes into lower-level descriptions.

3.3.2 Concepts model

The main purpose of the Concepts model is to define concepts and data at the conceptual level. The CM shall a least contain definitions of the Information and Material sets included in the AUM, this is called the minimal CM. In the description of the AUM we stated that Information and Material sets can be decomposed and explained in the CM, this is done using ISA hierarchies and Part-of relationships. In the CM there is also a possibility to create what is called concept component groups, this grouping is a view of the complete CM. Concept component groups can overlap each other, they can be mem- bers of each other and so on.

Not only object classes such as “order” can be defined in the CM. The CM can also be used as a dictionary for concepts used in the enterprise, using this approach general con- cepts as “profit”, “salary” and “Customer value” can be documented and defined.

The language used in the CM is similar to the one used in ER [Che76] modeling.

EM Requirements

Figure 9: Example of a Concepts model, adapted from [Per96], our translation.

Concept

A concept is something in the domain that is of interest and that we want to reason about, characterize or define. In the CM relations to other concepts is shown using the ISA, part_of and binary relations. A concept can be defined using other concepts or by the use of attributes.

Attribute

An attribute is a concept which is used only to characterize another concept, i.e. a person is characterized by the attributes age, name and address.

Concept group

A concept group is a grouping of concepts and concept relationships. It can be a view of a part of the model that is of special interest. Concept groups can have different focus, they can overlap in terms of the components in the groups.

Binary relationship

A binary relationship is a semantic relationship between two concepts or within a con- cept. The semantics of the relationship is defined by the name that the user puts on the relation. Binary relationships are bidirectional, each direction can be given a separate name. It is not mandatory to name the relationship in both directions, but since the semantics is defined by the name at least one of the directions must be named.

ISA relationship

An ISA-relationship is a specific kind of semantic relationship between two concepts. If A ISA B then B is a more generic concept and A is a more specific concept. Establishing this kind of relations is referred to as generalization. When specifying an ISA relation- ship an inheritance is also established. Everything that is true for the more generic con- cept is also true for the more specific concept, i.e. all attributes and constraints are inherited from the more generic level to the more specialized level. The sub-types that are created are mutually exclusive, i.e. in the specialization of person into male person and female person there is no possibility that a person can belong to both at the same time. However, a concept can be specialized in more than one way, using different spe- cialization criterias. A person, for example, can be specialized using sex, age or income.

The ISA-relationship has one attribute that specifies whether the specialization is total or not. A specialization is total when all of the instances of the generic type are members of one specific type. If the specialization is not total there are members of the generic type that are not members of the sub-types.

EM Requirements

Part-of relationship

A Part-of relationship is referred to as a aggregation. It is a semantic relationship which expresses that the participating concepts are aggregated into one object. The most typical example of an aggregation is a part explosion where the top part has a number of compo- nents and those components in their turn has a number of components. The aggregate relationship can also be specified whether it is total or partial. The total indicates that there are no more parts making up the higher-level item.

Links within the CM

Between the constructs in the CM there are a number of relationships, the links are stated above. (For a better overview, see appendix A).

• Concept Has Attribute, used to connect attributes that describes concepts.

• Concept From Concept Relationship, connects concepts to the relationship types.

• Concept To Concept Relationship, connects concepts to the relationship types.

• ConceptsModelComponent IsMemberOf ConceptGroup, collects components to concept groups.

3.3.3 Inter-model links

Between the models in EM there are a number of links that describes how the various concepts and phenomena are inter-related. In our case we will only use the link between the AUM and the CM. This link gives an explicit connection between the AUM and the CM. It is used to define the contents of each flow in the AUM. There is a consistency rule that states that every flow, both material and information, found in the AUM shall be defined using a link into the Concepts model. In the CM the flows can be structured and more carefully defined, than is possible in the AUM.

The semantics of this link is typically refers_to.

3.4 Summary

In this chapter a selection of the sub-models to be used in the rest of this work has been chosen. The selection was based upon a number of criterias. Using of the criterias we have chosen the Activities&Usage model (AUM) and the Concepts model (CM), both taken from F³ EM. The semantics of each construct in the models has been thoroughly described. In table 2 each construct from the two models is shown.

Using the descriptions of the constructs from the AUM and the CM, the next chapter shows the CDIF design done to capture the models.

Table 2: The constructs in the AUM and the CM.

AUM CM

Process Concept

External Process Attribute

Material Set ISA-relationship

Information Set Part-of relationship

Process_has_input/output Material Set Binary relationship Process_has_input/output Information Set Concept_has_Attribute External Process_has_input/output Infor-

mation Set

Concept_from/to_Concept relationship External Process_has_input/output Mate-

rial Set

ConceptsModelComponent_IsMember Of_ConceptGroup

Process has-component Process

Schema Design

4 Schema Design

4.1 Introduction

In the previous chapter the requirements to store enterprise models were stated. The semantics of the different constructs in the models were carefully introduced. In this chapter, we will describe the design that has been developed using these requirements.

As stated earlier the design will be done using the CDIF standard proposals. The design is minimized, i.e. the constructs that are included from CDIF are exactly the once that are needed to handle the F³ Enterprise Models, all other constructs has been left out. This has been done to make the design as clear as possible.

“The exporter shall minimize the use of the extensibility by using standard definitions from the Integrated Meta-model where they exist”

[EIA107, p. 23]

This is stated to make sure that an importer can “understand” as much as possible of a transfer. There is no way of being sure that an importer has “understood” the information that has been exported when the extensibility mechanism has been used. To follow this rule there has been as few extensions made as possible., but in some cases it has been necessary to make extensions to the Integrated Meta-model.

In the process of developing the design a number of decisions has been made. In the description of the design below the different decisions will be described and motivated.

In Appendix B a graphical description of the entire design can be found, in Appendix C the detailed, textual, design developed can be found.

To avoid errors and ambiguities in the mapping of the EM models into the CDIF schema, a mapping procedure has been developed. This procedure is a step by step description of how the constructs from EM should be mapped into the CDIF constructs, the procedure will be described in chapter 5.

els, or models that are in a stage of ongoing development. This chapter is divided in the following way. Section 4.2 describes the subject area created for this work. In section 4.3 the design for the AUM is given, in section 4.4 the design for the CM and in section 4.5 the design developed for the inter-model links is described. In section 4.6 a brief evalua- tion of the developed design is made.

4.2 A new Subject area

As described when introducing CDIF, the standard is divided into a number of subject areas. Each subject area covers different techniques or different parts of the systems development life cycle (SDLC). Since the F³ EM methodology covers a specific part of the SDLC we introduce a new subject area that provides the functionality required by these models.

The subject area developed in this work is called SA_EM (Subject Area Enterprise Mod- eling). The SA_EM is constructed as far as possible from existing constructs from the CDIF Integrated Meta Model, but there are a number of constructs added using the CDIF Extensibility Mechanism. When adding existing constructs to a new subject area, a refer- ence has to be given to the subject area that the construct is taken [EIA107]. There is no need to give the entire design for the construct again. In the SA_EM the constructs mainly comes from the DataFlow modeling subject area and to some extent from the DataModeling subject area. The rest of the constructs are created using the extensibility mechanism.

There is no general name attribute in the CDIF Integrated Meta Model, since this attribute would have different semantics and constraints in the different subject areas [EIA112]. The usage of the Name meta-attribute will be pointed out in the descriptions below.

4.3 Design for AUM

The purpose of the AUM is to provide means for modeling the functions or processes

Schema Design

tional Data Flow diagram. It contains the constructs: Process, External Process, Informa- tion set, Material set and a number of relations between these constructs (see chapter 3.3.1). Below a description will be given of which constructs that has been added to the SA_EM to cover the needs created by the AUM. The meta-model designed for the AUM can be found last in this chapter.

Activities&UsageModel

This is the top level entity in the design for the AUM. It is an abstract entity and shall therefore not be instantiated. It is used in the meta model to define what model from the F³ methodology that is used.

AUMComponent

This is an abstract supertype for all the constructs used in the AUM part of the subject area for F³ EM. Since it is an abstract supertype it shall not be instantiated.

Process

A process in F³ EM is a collection of activities which uses a number of inputs and pro- duces a number of outputs. This construct is available in the CDIF integrated meta model [EIA115] and hence there is no need to add a new construct in the subject area being developed. The Process entity from the DataFlow modeling subject area can be used directly as it is [EIA115]. The construct taken from CDIF is named DFMProcess but it has the same semantics as the AUM Process. Related to the DFMProcess entity there is a definition object named DFMProcessDefinition. This is a reusable object used to define the DFMProcess object [EIA115]. Processes are the only entities in the AUM that can be decomposed. This is not the same as in the DataFlow modeling subject area from CDIF where other constructs also may be decomposed. The decomposition of Processes are described in the mapping procedure in section 5.2.

External Process

An External Process in F³ EM is a process that is external to the focus of the model that is being developed. It either uses inputs or produces outputs. In the Integrated meta

outside the focus of the model [EIA115]. Therefore the External Process entity had to be added using the extensibility mechanism. The new meta-entity is described by the meta- attribute Name which gives the name of the entity and should be set to describe the pur- pose of the entity. In the same way as the DFMProcess entity has an associated definition object a ExternalProcessDefinitionObject has been added. This new definition object has the same functionality as the DFMProcessDefintionObject.

Information and Material set

An Information set is a set of information that flows between processes or external pro- cesses. A material set is the same except that there is something physical flowing between the processes or external processes. In CDIF there is an entity that is called Flow, it does not have the distinction between information and material in the name but in the definition object FlowDefinition the meta-attributes IsMaterial and ISData can be set to true to correspond to the construct from the AUM. By using these meta-attributes there is no need to add two separate constructs, the Flow entity and its corresponding Definition object will cover the requirements. The name of the meta-entity is not the same, but since the semantics are exactly the same the construct from the Integrated meta-model will be used.

Relations

Between the constructs in the AUM there are a number of relationships. These relation- ships specifies from which Process or External Process a flow comes from and in which Process or External Process it ends up. There is a difference in the view of the flows in the AUM and CDIF, in the AUM flows are regarded as connections between compo- nents. In CDIF flows are regarded as meta-entities exactly in the same way as Processes are. Between the meta-entities for a Process and a Flow a meta-relationship is specified which connects them.

In CDIF there are relations that are called Produces, Consumes and ProducesOrCon- sumes. The relationship called ProducesOrConsumes is of no use with the AUM since the flows in this model always has a direction, they flow from one entity to another. The

Schema Design

but for clarity the names has been changed in the SA_EM to HasInput (Consumes) and HasOutput (Produces). This is made possible by the usage of the CDIF extensibility mechanism where the names of meta-entities can be changed by sub-typing them [EIA107].

Other constructs

In the meta-model that has been developed there are a number of constructs that are not directly related to the meta-model of the AUM. These constructs are taken from the CDIF DataFlow modeling subject area and are used to define and connect the entities that are more directly related to the AUM. For a description of the constructs see [EIA115], the usage of these entities will be explained in section 5.2 where the mapping procedure from F³ EM to CDIF is given. The constructs below are very important when creating a CDIF representation. They are however not further discussed in this work. The usage of the constructs is shown in section 5.2. The different constructs that will be used from the Integrated meta-model are:

• ReferencedElement;

• EquivalenceSet;

• FlowProducerConsumer;

• Port;

• FlowPort;

• DataFlowModel;

• ComponentObject;

• FlowDefinition;

• DefinitionObject;

• ReferencedElement.DefinesPath.ComponentObject;

• EquivalenceSet.HasMember.ComponentObject;

• DefinitionObject.Contains.ComponentObject;

• ExternalProcessDefinition.