Part One Modeling Frameworks of Enterprise and Information ...

Part OneModeling Frameworks of Enterprise andInformation Systems

1 Introduction to Enterprise and SystemModeling

Abstract The purposes, viewpoints, means, contents, and usages ofmodels are discussed in this chapter. A brief introduction to several modelingmethods families is also presented.

1.1 What Do “Analysis” and “Design” for an EnterpriseMean

An enterprise with its integrated information system is a huge in scale andcomplex system. Therefore, enterprise and information system analysis anddesign can be a big challenge to system designers and developers.

Analysis and design are two very important activities in a system devel-opment project. A perfect analysis will ensure that the project moves alongthe right direction, so will a good design.

“Analysis” is a broad concept with emphasis on the investigation of prob-lems and associated requirements. For instance, if a new Management Infor-mation System (MIS) is under development, questions such as “why shouldit be developed?”, “what are its functions?” and “how will it be used?” mustbe addressed.

“Design” emphasizes a conceptual solution that can conform to therequirements, rather than its implementation. For instance, designing adatabase system means to develop a description of database schema and soft-ware objects. Designs can be implemented, and the implementation (such asprogram and/or related industrial product) expresses the true and completelyrealized design.

Modeling is the major means to analyze and design a system.

1.2 What is a Model

Grady Booch, James Rumbaugh, and Ivar Jacobson, the founders of theUnified Modeling Language (UML), defined a model as a representation ina certain medium of something in the same or another medium. They use a

4 1 Introduction to Enterprise and System Modeling

model to capture the important aspects of modeling targets from a certainangle and simplify or omit the rest [1]. In a word, a model is a representationof the reality.

A system is composed of interfacing or interdependent parts that worktogether to perform a useful function. System parts can be a combinationof anything, including people, information, software, processes, equipment,products, or raw materials.

For a system (physical system, information system, product system oreven enterprise system), a model is a representation of a set of componentsof the system or subject area. It describes what a system does, what controlsit, on what it works, in what way it performs its functions, and what itproduces. The model is developed to understand, analyze, improve or replacethe system.

There are two types of models: (1) Logical models show what a systemis or does. They are implementation-independent, that is, they depict thesystem independent of any technical implementation. (2) Physical modelsreveal not only what a system is or does, but also how the system is physicallyand technically implemented.

Modeling means to formalize the understanding of a system in anunambiguous form to make it understandable and usable by other enter-prise agents. The enterprise agents can be human beings and/or softwareapplications.

A model is expressed through a medium that is conducive to work. Themedium can be a physical entity, drawings/diagrams (Fig. 1.1 shows a controlsystem block diagram and Fig. 1.2 shows a conceptual model of reconfigurableflight control system[4]), CAD (Computer Aided Design) models (as shownin Fig. 1.3), mathematical functions or text documents.

Fig. 1.1. An example of control system block diagram

Enterprise modeling is a generic term which covers the set of activities,methods, and tools related to developing models for various aspects of anenterprise [7].

For enterprise engineering and software engineering, graphical languageshave been developed and are widely used to model enterprises or informationsystems. For instance, as shown in Fig. 1.4, the UML is developed to modela software system under the object-oriented analysis and design patterns.

A modeling method describes an object in an appropriate language, mak-

1.2 What is a Model 5

Fig. 1.2. A conceptual model of a control reconfigurable flight control system

Fig. 1.3. 2-diamentions and 3-diamentations CAD model of a gear wheel

ing it readable and understandable to anybody who knows the language.A modeling language for enterprises and information systems has both

syntax (notation) and semantics, and can take various forms including bothdiagrams and text. This kind of model is supposed to be easier to use forcertain purposes than the final system.

A model embodies the core knowledge required to manage the enterpriseevolution, and it also paves the way for creation or innovation. Therefore, it iswidely used in enterprise engineering, information engineering, management


Fig. 1.4. An example of the UML

engineering, industrial engineering, computer engineering, knowledge engi-neering and so forth. Almost every subject has its own modeling methodsand relative analysis and design methodologies. Models provide convenientways to form a scientific and technical zone.

1.3 Purpose and Usage of Models

Models are used for multiple purposes:(1) To capture and clearly define requirements and domain knowledge so

that all stakeholders may understand and agree on themFor instance, various models of a product define the requirements about

its appearance, function, strength against force and brisance, cost, and manyother aspects. Relative stakeholders are the product designers, engineers,manufacturers, sellers, and the possible end users.

Different models of an enterprise may capture requirements about its orga-nizational structures, business processes, working patterns, key performanceindicators, and other things. Stakeholders are the boss, managers, consul-

1.4 Content of a Model 7

tants, suppliers, customers and so forth. Various kinds of enterprise modelsare used.

For an information system, models are used to describe its network topol-ogy, hardware configuration, operation rules, etc. The UML is used to definethe software structures and behaviors with multi views and diagrams.

(2) To facilitate the system designA product designer uses models on paper or a computer, or sometimes a

wooden or plastic mock-up to visualize and experiment with possible designs.Creating and modifying models permits creative thought and innovation atlittle cost.

The models of a software system help designers and developers easilyexplore various frameworks and design solutions before coding.

The models of an enterprise help to understand its actuality and relativeproblems, and then to design a new mechanism before starting a reengineeringproject.

(3) To generate usable deliveriesA model of a product can be used to generate various kinds of deliveries,

which include an engineering blueprint, a bill of materials, a manufacturingprocess document, a Numerical Control (NC) program, and a user guidance.

A model of a database system can be used to generate entity declarations,attributes, their relationships, and the data dictionary. It can be transferredto a database system configuration with the supporting of CASE tools.

(4) To facilitate enterprise/system structuring and restructuringTo re-engineer an enterprise or a complex information system, the com-

mon methodology is to model the AS-IS status of the system and then developthe TO-BE model. The workflow technique and business process manage-ment technique can operate TO-BE model in a real information system. Themodel-driven technique is supposed to automatically map from software mod-els to code.

Models may support problem simplification, rapid evaluation of antici-pated performance, etc., at low cost.

1.4 Content of a Model

A modeling method is similar to a language with certain syntax and seman-tics. Modeling methods of enterprise and information system are all formedby graphical units, terms and rules to combine these individual elementstogether.

(1) Syntax and semanticsThe syntax refers to rules by which language elements (e.g., letters and

words) are assembled into expressions (e.g., phrases, clauses, paragraphs).The semantics refers to rules by which syntactic expressions are assigned

meanings.


A model has two major aspects: meaning information (semantics) andsymbol system.

The semantic aspect captures the meaning of an enterprise or an infor-mation system as a network of logical constructs, such as domains, scenar-ios, business activities, junctions, links, entities, relationships, tokens, places,classes, types, kinds, associations, states, use cases, and messages. Semanticelements embody the semantics which belongs to terminology. They can beused for message transformation, code generation, models information map-ping, validity checking and so forth. The semantic aspect is often called asthe model itself.

The notation shows semantic information in a form that can be seen, readand edited. They display a model in a form directly apprehensible to people.

(2) ContextModel is a kind of artifact. It is used within a certain environment (con-

text), which includes the internal constitution of the model, the structureapproach of the model development, a set of rules for element creation andoperation, and a relationship between the model and its background.

A modeling task requires a mechanism with which multiple workinggroups can work concurrently without serious interference. Decomposition isa normal treatment for a large scale complex system modeling job. In anycase, dividing a large system into a hierarchy of well chosen pieces is themost reliable way. If the model is properly structured into subsystems withwell-defined interfaces, a large model can be tractable.

Models also need to record information about its development process,such as, who is the author of a diagram, who reviews the model, and whois authorized to give permission to release the model. Such information isimportant to the model development process, in that it provides a mechanismto trace the whole developing process.

1.5 Viewpoints and Abstract Levels of a Model

It is impossible to describe an enterprise or an information system in a singlebig picture. Isolation and simplification are two principles of treating such acomplicated object.

Models take on different forms for various purposes and appear at differentlevels of abstraction. In order to cover the whole system, suitable standpoints,viewpoints and abstract levels should be selected.

(1) Standpoints selectionBecause an enterprise is a hierarchical system, people from different levels

and departments observe the same system from different standpoints and getdifferent understandings. Models can reflect this kind of difference. For aninformation system development, along the whole lifecycle, end users definerequirements, while designers define the design specification and develop-

1.6 Modeling Methods Families 9

ers prepare the implementation description. Stakeholders identification andstandpoints selection is the initial point for a modeling task.

(2) Viewpoints or purposes selectionStakeholders of an enterprise may observe the same system from dif-

ferent viewpoints including system targets, element sets, functional struc-tures, organizational structures, information frameworks, resource configura-tions, decision mechanism, business processes, system performance, productstructures, and so forth. For an information system, the viewpoints canbe class structure, state transformation, operation consequence, communica-tion/collaboration structure and so forth.

Modeling methods focus on a limited set of system aspects and clearlyignore those that are not directly related to the task. Modeling methods arenot supposed to evaluate or represent every possible aspect of the systemunder discussion.

One modeling method always embodies a certain kind of viewpoint. Forinstance, IDEF0 and DFD (Data Flow Diagram) are for function modeling;ERD (Entity-Relationship Diagram) and IDEF1X for data modeling; IDEF3,EPC (Event-driven Process Chain), RAD (Role Activity Diagram), Petri net,Gantt chart, PERT net for process modeling; IDEF4 and the UML (UnifiedModeling Language) for object-oriented software development; IDEF5 forontology capture; GRAI method for decision modeling.

(3) Abstract levels selectionWhen people observe and review a system, the thinking routine belongs

to either top-down mode or bottom-up mode. For top-down mode, with aglance of the system and then through decomposition step by step, detailedinformation about the system will be represented. In bottom-up mode, someisolated and limited data are collected and then their relationships are minedbefore the whole system structure can be formed. Along the thinking routine,different modeling methods embody different abstract levels. For instance,A value-added Chain is always used to model the strategic process of anenterprise at the top level and a Petri net is used to model the operationprocess of the same enterprise at the bottom level.

1.6 Modeling Methods Families

For the complicated system cognition, many kinds of modeling methodsand modeling languages are developed. The frequently mentioned ones inthis field include SADT (Structured Analysis and Design Technique), Ganttchart, PERT chart, IDEF0, IDEF1X, IDEF3, EPC, Petri net, BPMN (Busi-ness Process Modeling Notation) and so forth. Some of them are groupedtogether to form some modeling methods families such as IDEF series mod-eling methods, ARIS (Architecture of Integrated Information System) andthe UML.


IDEF modeling methods stemmed from the ICAM (Integrated ComputerAided Manufacturing program). During the 1970s, the U.S. Air Force soughtto increase manufacturing productivity through systematic application ofcomputer technology. In order to improve communication among experts andengineers involved in system integration projects, the ICAM program iden-tified that it was necessary to develop some analysis and design techniques.As a result, a series of techniques known as the IDEF (ICAM Definition)techniques were developed [2]. At that time, IDEF techniques included thefollowing:• IDEF0 for function modeling. It helps to develop a structured represen-

tation of the functions, activities or processes within the modeled systemor subject area.

• IDEF1 for information modeling. It represents the structure and seman-tics of information within the modeled system or subject area.

• IDEF2 for dynamics modeling. It represents the time-varying behavioralcharacteristics of the modeled system or subject area.In 1983, the U.S. Air Force Integrated Information Support System pro-

gram enhanced the IDEF1 information modeling technique to form IDEF1X(IDEF1 Extended), a semantic data modeling technique.

In 1992, the Air Force Information Integration for Concurrent Engineer-ing (IICE) program released the Integration DEFinition (IDEF) method forprocess description capture (IDEF3). In 1994, a new version was updated byKBSI (Knowledge Based Systems, Inc).

Furthermore, in 1992, KBSI published the Information Integration forConcurrent Engineering (IICE) object-oriented design method IDEF4 report.In 1995, a new version was updated by KBSI.

IDEF5 for ontology capture was developed at the same time.Now, KBSI is developing the IDEF series methods as a whole family, as

shown in Fig. 1.5.(1) IDEF0: Function Modeling(2) IDEF1X: Data Modeling(3) IDEF2: Simulation Model Design(4) IDEF3: Process Description Capture(5) IDEF4: Object-Oriented Design(6) IDEF5: Ontology Description Capture(7) IDEF6: Design Rationale Capture(8) IDEF7: Information System Auditing(9) IDEF8: Human-System Interface Design –User Interface Modeling(10) IDEF9: Business Constraint Discovery – Scenario-Driven IS Design(11) IDEF10: Implementation Architecture Modeling(12) IDEF11: Information Artifact Modeling(13) IDEF12: Organization Design and Organization Modeling(14) IDEF13: Three Schema Mapping Design(15) IDEF14: Network DesignIDEF0 and IDEF1X techniques have been widely applied in government


Fig. 1.5. IDEF methods family

departments, industries and other situations, supporting modeling efforts ina wide range of enterprises and application fields.

In 1991, the National Institute of Standards and Technology (NIST)received support from the U.S. Department of Defense, Office of Corpo-rate Information Management (DoD/CIM), to develop one or more FederalInformation Processing Standards (FIPS) for modeling techniques. The tech-niques selected were IDEF0 for function modeling and IDEF1X for informa-tion modeling. Now IDEF0 is also an IEEE standard.

ICAM Definition languages have been renamed as Integration DEFinitionlanguages and the abbreviation IDEF remains unchanged.

With the development of object-oriented techniques, several modelingmethods were developed to support them. In 1997, Grady Booch, JamesRumbaugh, and Ivar Jacobson combined their efforts together and the doc-ument was added to the list of OMG (Object Management Group) adoptedtechnologies in November 1997 as UML 1.1. Several versions of UML havebeen released as shown in Fig. 1.6. Now UML is the standard of ISO (Inter-national Standard Organization) and is widely used in software design anddevelopment. It is also a widely used method for meta-model constructingand computer aided software engineering.

The UML is a graphic modeling language used to identify, visualize, struc-ture, organize and document the artifacts of a software system. It includessemantics, notation, and guidelines. It aims at supporting most currentobject-oriented development methodologies.


Fig. 1.6. OMG UML evolution

At the top level, views of UML can be divided into following aspects:structural classification, dynamic behavior, physical layout, and model man-agement. Table 1.1 shows the UML views and their diagrams, as well as themain concepts relevant to each view [1].

Table 1.1. UML views and diagrams

Major Area View Diagram Main Concepts

structural

static view class diagram association, class, depen-dency, generalization, inter-face, realization

design view

internal structure connector, interface, part,port, provided interface,role, required interface

collaboration dia-gram

connector, collaboration,collaboration use, role

component diagram component, dependency,port, provided interface,realization, required inter-face, subsystem

use case view use case diagram actor, association, extend,include, use case, use casegeneralization

dynamic

state machineview

state machine dia-gram

completion transition, do ac-tivity, effect, event, region,state, transition, trigger

activity view activity diagram action, activity, control flow,control node, data flow,exception, expansion region,fork, join, object node, pin


ContinuedMajor Area View Diagram Main Concepts

interactionview

sequence diagram occurrence specification,execution specification,interaction, interaction frag-ment, interaction operand,lifeline, message, signal

communication dia-gram

collaboration, guard condi-tion, message, role, sequencenumber

physical deploymentview

deployment diagram artifact, dependency, mani-festation, node

modelmanagement

model man-agement view

package diagram import, model, package

profile package diagram constraint, profile, stereo-type, tagged value

The structural classification describes things and their relationships toeach other in a system. The Classifiers used to model things in the systeminclude class, use case, actor, node, collaboration, and component. Structuralviews include static view, design view, and use case view.

The dynamic behavior describes the behavior of a system. A behavior canbe described as a series of changes of the snapshots of the system embodiedby static view. Dynamic behavior views include state machine view, activityview, and interaction view.

The physical layout describes the computational resources in the systemand the deployment of artifacts on them. It includes deployment view.

The model management describes the organization of the models them-selves. The package is the generic organizational unit for models. A modelis a package hierarchy that provides a semantically complete abstraction ofa system from a particular viewpoint. The model management view crossesthe other views and organizes them for development tasks and configurationscontrol [1].

Some modeling applications support many kinds of models development.For instance, the ARISTM can help to develop EPC (Event-Driven ProcessChain), Function Allocation Diagram, Information Flow Diagram, EventDiagram, Value Added Chain Diagram, Rule Diagram, CommunicationDiagram, Classification Diagram, Class Diagram and so forth [8]. The SATM

(System Architecture) can also provide kinds of modeling methods [9].Microsoft Visio� is a widely used drawing tool irrespective of certain sys-tem architecture.


1.7 Model Based System Integration and Model DrivenArchitecture

As Vernadat [7] state: the enterprise integration is concerned with facilitatinginformation, control, and material flows across organizational boundaries byconnecting all the necessary functions and heterogeneous functional entities inorder to improve communication, cooperation, and coordination within thisenterprise so that the enterprise can behave as an integrated whole, thereforeenhancing its overall productivity, flexibility, and capacity for managementof change. Heterogeneous enterprise functional entities to be integrated areinformation systems, devices, applications, and people [7].

To realize the enterprise integration through information techniqueimplementation is a complicated systematic engineering. For such a hugescale system, ARC Advisory Group presented the Collaborative Manufactur-ing concept. As shown in Fig. 1.7, an application system integration frame-work is manifested [5].

Fig. 1.7. Collaborative manufacturing management model

ARC treats an enterprise as a ball in which enterprise hierarchy, life-cycle and value chain are the three axes and all system integration-relatedapplications are allocated in different positions in the ball. The enterpriseintegration will meet problems concerning different levels of the enterprise,different phases of product lifecycle, and different aspects on inter enterprisescollaboration, as shown in Fig. 1.7. In such a system, design, development,operation, maintenance, reconfiguration, and extension will all meet greatchallenges.

1.7 Model Based System Integration and Model Driven Architecture 15

In order to solve the systematic complexity, experts from Germanydeveloped the Si-Frame, as shown in Fig. 1.8. It includes a double-cycle simi-lar to a model reference adaptive/reconfigurable system. In the frame, whena task arrives, process modeling, analysis and optimizing will be operatedfirst. Then the optimized model is transferred to the online system and run.During the operation, the model system monitors the system’s performanceand collects data for further analysis and optimization. It can adjust the pro-cess in a run time system. This mechanism can realize system improvementcontinuously.

Fig. 1.8. Si-Frame

OMG is developing a new software development methodology, the ModelDriven Architecture (MDA). Its core idea is that software developing processis driven by models. In MDA, models are products of software developmentprocesses rather than supporting tools, and modeling language is a “pro-gramming language” rather than a design language [6].

In MDA, there are two kinds of models: business model and softwaremodel. A business model models a business or an enterprise (or part ofit), but does not involve the software system in the enterprise. This kindof model is named as Computational Independent Model (CIM). When theenterprise business management is supported by an information system, asoftware model should be created to describe the software. The requirementfor a software comes from the business system (or part of it) supported by it.

In MDA, software model includes two kinds: Platform Independent Mod-els (PIM) and Platform Specific Models (PSM). PIM has high abstractionand independence from realization techniques. It does not include any


information about special software. PSM includes technical informationabout the realization on a special platform. It is customized for certainrealization.

Business analysts develop Computation Independent Models (CIM) thatdescribes the business, as shown in Fig. 1.9 [6]. Then architects and designerssubsequently create Platform Independent Models (PIM) to illustrate theorganization’s architecture, without reference to any specific implementation.Later, developers and testers use tools to generate specific software designsfrom the PIM architecture and then use their Platform-Specific Models (ordesigns) to generate code.

Fig. 1.9. Levels or types of MDA models

MDA is still under development. It provides an opportunity for modelbased system development and reuse.

References

[1] Rumbaugh J, Jacobson I, Booch G. The Unified Modeling LanguageReference Manual, Second Edition. Addison-Wesley, 2004.

[2] Mayer R J, Crump J W, Fernandes R. Information Integration for Concur-rent Engineering (IICE) Compendium of Methods Report. KBSI, 1995.

[3] Marca D A, McGowan C L. SADT Structured Analysis and Design Tech-nique. McGraw-Hill Book Company, 1988.

[4] Li Q. Analysis And Simulation Of Control Mixer Concept For A Control-reconfigurable Aircraft. Transactions of Nanjing University of Aeronautics& Astronautics, 12(2): 180 – 184, 1995.

References 17

[5] ARC Advisory Group. Collaborative Manufacturing Management Strate-gies. ARCweb.com, 2002.

[6] OMG. MDA Guide, Version 1.0.1. http://www.omg.org/docs/omg/03-06-01.pdf.

[7] Vernadat F B. Enterprise Modeling and Integration: Principles and Appli-cations. Chapman & Hall, 1996.

[8] IDS Scheer AG. ARIS Methods, Version 4.1. Saarbrucken, 1999.

[9] Popkin Software. System Architect 2001 Tutorial. Popkin Software Co., 2001.

Part One Modeling Frameworks of Enterprise and Information ...

Documents

Transcript of Part One Modeling Frameworks of Enterprise and Information ...