Extending CDIF to Support Enterprise Modeling

Transcription

1 Extending CDIF to Support Enterprise Modeling Per Burman Submitted by Per Burman to the University of Skövde as a dissertation towards the degree of M.Sc. by examination and dissertation 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

2 Abstract In recent years organizations developing information systems have started to demand that 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 methodology 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 standardized 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 mapping between the representations. Finally we discuss the functionality of a tool capable of supporting the work with the models.

3 Contents 1 Introduction Background Introduction Meta models CDIF Introduction to CDIF CDIF graphical notation The CDIF Architecture The extensibility mechanism F3 Enterprise Modeling Introduction Way of working with F3 EM F3 EM and the SDLC Perspective of EM Sub-models in EM Explicit links between the sub-models (inter-model links) Mapping between F3 EM and CDIF Introduction Mapping Tool support for Enterprise Modeling Introduction Tool functionality Summary EM Requirements Introduction Selection of sub-models Selection criterias Arguments for selection F3 EM requirements The Activities and Usage Model Concepts model Inter-model links Summary Schema Design Introduction A new Subject area Design for AUM Design for CM Design for Inter-model links Evaluation of design Summary Mapping EM to CDIF

4 5.1 Introduction Overview of the mapping Mapping the AUM Mapping of CM Mapping of inter-model links An example Mapping of AUM components Mapping of CM components Mapping of inter-model links Summary Tool Functionality Introduction F3 EM in Requirements Engineering Elicitation Representation Validation Required functionality Elicitation Representation Validation Other functionality Summary Summary Introduction Achievements F3 EM sub-models Design of CDIF meta-model Mapping from F3 Enterprise Models to CDIF Tool functionality Open issues Future work References List of Figures List of Tables Appendix A Appendix B Appendix C Appendix D

5 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 specification 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 development project should be maintained and carefully managed through the different subprocesses of the development life-cycle. One method that has been designed with this goal in mind is the F 3 methodology [Bub94]. Within this methodology a method was developed called Enterprise 1 Modeling (EM 2 ) which supports the Requirements Engineering process. As stated above the information generated during this process is highly complex. Experience 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 3 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 1. The concept Enterprise is used in a wide sense in this work. 2. If F 3 EM is used, it means Enterprise Modeling. This is the process, any other use is indicated in the text, e.g. the F 3 EM methodology. 3

6 Introduction 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 distinguishes it from a traditional database system. One of the more important is a metamodel 3 which is a schematic and semantic description of the contents of the database [For89a]. CDIF 4 is an evolving family of standards that is being developed by the EIA 5 [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 extensibility 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 standardization 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 3 that: We strongly suggest that the CDIF standard is considered for F 3 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 support 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 CASE Data Interchange Format 5. Electronic Industries Association 4

7 Introduction To produce a CDIF extension capable of capturing the high-level enterprise information obtained using the F 3 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-ambiguous, will be designed using a systematic mapping of each construct. Finally, a procedure for mapping the F 3 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 3 EM methodology. To describe the functionality of a tool that is capable of browsing the models captured 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 3 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 3 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 discussion of achievements and a description of possible future work in this area is done. 5

8 Background 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 discussed. This is done to establish the work in a broader context of research in this particular 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 technique 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 3 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 3 EM methodology. 2.2 Meta models CDIF contains a complex meta-model that is aimed at describing the information generated during the systems development process. In this section an introduction to the concept 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 can be instantiated to describe a particular model. Meta-models are used to describe 6

9 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. Level Meta-meta schema Example Constructs allowed in the Meta schema, e.g. Objects, Roles, Classes. Meta schema ER, DFD, EER. (Instance of the Metameta schema.) Model ER schema of a manufacturing system, i.e. an instance of a meta-schema Production Data 100, Dog, Red, SAAB Table 1: The four level architecture. With this addition we can see the models described by four levels. The first level contains 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 meta-meta model which was introduced above. 7

10 Background 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 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 provides 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 format 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 information schema of a repository. 8

11 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 Using this mechanism any information needed by a user can be defined and in a transfer no difference 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 architecture is the same as the one defined in section 2.2. Using this meta-hierarchy the semantics 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 CDIF graphical notation It is also specified how the extended meta-models shall be described graphically. This is the same notation that is used to describe all models created in CDIF. 9

12 Background 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 variants 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 CollectableMetaObject 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 inheritance of meta-relationships is shown in the AttributableMetaObject hierarchy, which is represented in text with indents to show super/subtype hierarchies. 10

13 Background 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 metamodels 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 metameta-model is shown. It is this meta-meta-model that sets the rules for all other models developed using CDIF. Figure 1: The CDIF Meta-meta model, adapted from [EIA107]. However, although the meta-meta-relationships are restricted to being binary, it is possible to express more complex relations using the meta-entities that are defined in the different subject areas. Because of the inherent inheritance in the meta-meta-model all meta-meta-entities inherits all meta-meta-attributes from the MetaObject. The most 11

14 Background 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 metameta-model and hence CDIF is defined in means of itself. The two most important subject areas are Foundation Subject Area and the Common Subject Area. They are necessary 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-models 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 metarelationship IsRelatedTo. RootObject RootEntity 0:N IsRelatedTo 0:N Figure 2: The CDIF FoundationSubjectArea, adapted from [EIA111] 12

15 Background Common Subject Area In the Common Subject Area the primitive Foundation Subject Area is refined by defining 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. Figure 3: The CDIF CommonSubjectArea, adapted from [EIA112] The extensibility mechanism The body working with the standardization of CDIF has realized that it is impossible to know what needs different users will have. Different users may want to transfer different information between their tools. To give users the maximum flexibility an extensibility 13

16 Background mechanism is introduced in the standard. The extensibility mechanism gives the possibility 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 specified 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 standardized 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 reusing 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 necessary 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 information 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 principle 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. 14

17 Background 2.4 F 3 Enterprise Modeling 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 information 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 3 ) [Bub94] a set of models, techniques and tools were developed which were aimed at supporting 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 3 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 3 Enterprise Modeling (EM). In this work we will only use the Enterprise Model, the other models in F 3 will not be further discussed here Way of working with F 3 EM The F 3 EM methodology provides a certain way of working that is iterative. When working with F 3 EM all sub-models are being developed in parallel and the work is issuedriven [Bub94]. The work is carried out by populating the different sub-models simultaneously, 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 3 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 concern for this dissertation. 15

18 Background F 3 EM and the SDLC Software Engineering is defined as [Lou95, p. 6]: Software engineering is a systematic approach to the development, operation, 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 Software Development Life Cycle (SDLC) model that is taken from [EIA106] as an example, (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 3 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 performance of the software to be developed. The interface of software to other systems 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. 16

19 Background Planning Requirements Analysis Logical Design Physical Design Implementation Testing Maintenance Figure 4: An example of a Systems Development Life-cycle (SDLC). F 3 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 organization 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 3 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 3 EM is very useful. One more use for the information generated by the F 3 EM process is the creation of a Enterprise Knowledge Repository (EKR) [Bub96]. An EKR is a collection of the knowledge available in the organization. Among many other areas of use it could be used in the systems development process. Since the knowledge of how the organization works and what objectives there are within the organization is collected in a way that is easily 17

20 Background accessible, the work of eliciting this knowledge from the people working in the organization can be reduced. The connection, as we see it, between EM and the SDLC is described in figure 5. Problem definition, Business analysis. Performed with, among other methods, F 3 EM. Systems development Other actions Planning Requirements Analysis Organizational changes, Marketing activities, etc. Logical Design Physical Design Implementation Testing Maintenance Figure 5: Our view of the connection between EM and traditional SDLC Perspective of EM There are quite a large number of commercially exploited methods for systems development 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 18

21 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 importance 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 supposed to do, this in distinction from how it should be doing it. However the F 3 methodology 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 system is to exist in. The main objective of F 3 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 3 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? 19

22 Background 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. Objectives motivate IS-Requirements motivate Concepts refer to Activities perform are responsible for are responsible for Actors Figure 6: The sub-models used in EM and the minimal inter-model links between these [Per97] Sub-models in EM The Enterprise Model consists of five different sub-models. These models are interrelated (see figure 6). The models are represented graphically and described using natural language modeled in semantic networks [F394a]: The Objectives Model (OM) describes the motivation or reason for different activities and concepts in the enterprise. It addresses the above discussed why perspective of the enterprise. The concepts 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 are motivates and influences. 20

23 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 represented using an ER like notation [Che76]. The main component used in the CM is Concept. Mechanisms for generalization (ISA) and aggregation (Part-Of) are provided. The Activities and Usage Model (AUM) describes the organizational activities, i.e. the functions and processes of the enterprise. External agents outside the scope of the current activity are identified. Information 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, Organizational 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 Requirement. 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. 21

24 Background CM AUM CM CM AUM AUM CM CM AUM Figure 7: Schematic picture of how the inter-model links between the AUM and the CM can be seen 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 3 EM is the explicit and firm connection 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 22

25 Background enterprise and the information system development and thereby evolution of the organization 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 3 EM and CDIF Introduction In the previous sections we have introduced CDIF and F 3 EM. The aim of this work is to create a CDIF design capable of capturing the information generated when using F 3 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 Mapping When developing the meta-models in CDIF capable of capturing Enterprise Models we will use a meta-model over F 3 EM and from that derive which constructs that are necessary. The developed meta-model will then be verified by the development of a procedure 23

26 Background 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 combinations of constructs. This is true to some extent, but since we have systematically developed 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 3 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 3 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 3 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 3 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 Introduction As we stated above it has been shown that there is a need for automated tool support when working with F 3 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 specifically developed to support F 3 EM can be used. There has been some attempts to create a tool for the F 3 EM methodology [F394b], but the tool support is relatively weak [Per96]. It has also been stated that a critical factor for 24

27 Background successful use of the F 3 EM methodology is a powerful tool to support the development and maintenance of the models [Per96]. The creators of the F 3 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 3 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, drawing, 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 3 EM methodology. This makes a tool that supports 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 Tool functionality The models developed using the F 3 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 chapter 6. These processes will be used as a framework for the discussion of tool functionality. In chapter 6 there are a number of requirements for tool functionality outlined. Some of this functionality is not best supported by a tool, it may require support from an underlying repository system. However, we will not make this distinction between what should 25

28 Background 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 specifically needed by the models of F 3 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 specific 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 3 Enterprise Modeling technique was introduced. CDIF will be used to capture the models used in F 3 EM. A brief introduction was made of how the mapping between the two different 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 3 EM methodology is made. The constructs used in the selected models are then carefully analyzed. 26

29 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 3 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 3 EM methodology will be analyzed and described. The inter-model links used in F 3 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 discussed 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 information. To do this we have chosen the EM part of F 3. This model consists of five different 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 relevant subset of the sub-models 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. 27

30 EM Requirements 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 3 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 covers the content of the F 3 EM models as it is. And in doing this investigate whether it is possible to use CDIF to capture the inter-model links Arguments for selection The CM and the AM is defined using the same constructs. It is the semantics of the components 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 constructs are represented. The ISRM and OM will be omitted since they contain constructs that are specific to the F 3 EM methodology and hence there is no support at all in the current 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 3 EM requirements The F 3 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 3 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 together create a large integrated model. 28

31 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 3 EM methodology but we will not discuss these. The description of the models is taken from [F394a] 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 enterprise 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. 29

32 EM Requirements ExternalProcess01 Subscriber is con nected Switch polarity Process01 Activate terminal equpment No. Info Process02 Detect signal sequence Switch polarity Process03 End transmission of number info. Signal Process04 Send ringsignal Figure 8: Example of an Activities&Usage model depicting number transmission in a telephone network. 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 activities 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 process is a collection of activities which uses a number of inputs (information or mate- 30

33 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 Process 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/information 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 transported 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 Process/External Process. Each Material set must appear as a concept in the CM. The Material 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 process. Process has_output (0:N) Material, connects the material flows out from a Process. Process has_input (0:N) Material, connects the material inputs into a Process. 31