Development of an Integrated Methodology for Enterprise Engineering
Cheol-Han Kim, Information System Engineering, Taejon University, Korea,
[email protected] Richard Weston, MSI Research Institute, Manufacturing Engineering, Loughborough University, UK,
[email protected] Hoon-Shik Woo, Dept. of Information Systems Engineering, Taejon University, 96-3 Yongun-dong Tong-gu Taejon, 300-710 S. Korea, Tel.: +82-42-280-2564, Fax: +82-42-280-0109, E-mail:
[email protected]
1 of 31
Development of an Integrated Methodology for Enterprise Engineering Abstract Existing public domain enterprise engineering methodologies provide a backbone of modelling concepts designed to maintain consistency between common engineering concerns during different life phases of enterprise systems. The literature reports industrial examples of the use of such a backbone of modelling concepts to formally structure and support large-scale systems engineering. This has led to improved problem decompositions and improved reuse of models (and hence knowledge) describing large-scale systems integration issues, mainly within a single business. Generally, however, existing enterprise engineering methodologies and modelling backbones cover less well the development and reuse of models of collaboration and interaction between business units. This makes them less well suited to modelling certain dynamic aspects of partner interactions both between businesses and within a single business. Therefore there arises a need for an extended backbone of enterprise engineering methods and modelling concepts. This paper describes the Integrated Methodology for Enterprise Engineering (IMEE) which has been developed to meet key aspects of modelling multi-partner enterprises. IMEE incorporates two complementary kinds of modelling concept, namely (1) process oriented modelling in support of enterprise requirements capture and analysis, centred on ‘function’, ‘activity’ and ‘dynamic systems’ modelling and simulation approaches and (2) object-oriented modelling in support of the conceptual design of multiple business systems, centred on ‘function’, ‘information’ and ‘behaviour’ modelling. Where practical, existing and well proven concepts have been selected and integrated into the IMEE modelling backbone, the purpose being to improve the completeness, acceptability and practicability of its approaches to business integration.
1. Introduction To achieve mass customisation on a global scale, partnership enterprises are required. Partnership enterprises comprise consortia of interacting businesses that need to operate coherently despite their geographical distribution [Browne et al 1994, Messina 1997]. One approach to achieving coherence is to agree upon common definitions of terms related to business, engineering, logistical and manufacturing processes and for all partner businesses to deploy their human and technical resources so that they realise an agreed set of roles and responsibilities that collectively enact the common process definitions [Weston 1999a]. Table 1 gives examples of common enterprise activities classified by an ISO TC184/WG1 that can be resourced by people and technical systems. 2 of 31
Plan and build phase (e.g. before sell/buy title transfer)
‘What’ activities • Develop goals • Define strategy • Define product needs
‘How’ activities • Develop requirements • Define concept • Design product • Plan to produce product • Plan to support product • Define use requirements • Define support requirements
Use and operate phase • Define support needs (e.g. after sell/buy title • Define use transfer) Dispose & recycle phase • Define recycle/ • Define recycle/ (e.g. after product is no dispose needs dispose requirements longer useful) Table 1 Example what, how and do enterprise activities (after ISO 14258:1998)
‘Do’ activities • Procure parts • Produce product • Test product • Ship product • Use the product • Support product • Recycle product • Dispose product
However, because of extremely high levels of complexity and uncertainty inherent within any system of interacting businesses, global markets and environmental conditions, the partnership enterprise must be inherently ‘change capable’. Indeed a partnership enterprise should be able readily to achieve process change so that its operations can remain coherent and effective despite changing requirements and conditions. Further it should be able to re-systemise its use of resources across partner businesses so that specified process change can be enabled in a timely and cost-effective manner. A generalised and process-oriented representation of partner businesses (co-operating in the life-cycle engineering of a range of products) was developed by an ICEIMT’97 (International Conference on Enterprise Integration and Modelling Technology) working group [Weston et al 1997]. generalised model is illustrated by Figure 1.
This
This process-oriented model exemplifies important
features of many multi-partner global businesses, albeit at a high level of abstraction. Firstly, it emphasises the need to design and realise appropriate ‘process streams’ and ‘organisation streams’. With respect to process streams, units of enterprise activity (that typically cross organisation boundaries) need to be logically and temporally ordered so that product realising operations result in products of acceptable quality, at the right place and on time. Whereas for the organisation stream, evidently the use of human and technical resources available to partner businesses must be systematically and repetitively assigned responsibilities for one or more instances of unitary enterprise activities.
It follows that units of enterprise activity must be specified and realised at a level of
granularity that facilitates management, control and change within multiple process streams. It also follows that the representation, communication, sharing and ongoing reuse of knowledge about business unit collaboration issues can be of major concern to a partnership enterprise.
3 of 31
organisation stream
sub-process (or activity) nodes n1
n3
process stream
n6 n7 n8
n 11
n 13n 1 4 n 15
product application 1 product application 2
product application 3
product application 6
product application m
company a
company b
company c
company d
company e
Figure 1 Process Stream and Organisation Stream Concepts The foregoing illustrates in an abstract way the combined use of process-oriented and object-oriented modelling paradigms. It shows how multiple instances of value adding activity chains (i.e. processoriented models of enterprise requirements) can be represented to target an organised assignment of groups of resources (i.e. organised systems of resources or enterprise objects with competencies, capabilities and capacities to realise value adding activities) to activities on a repetitive basis bearing in mind a need for multiple process streams and a shared but organised use of a finite resource set. As in general such a partnership enterprise will be subject to ongoing and uncertain change, the realisation of the process must be achieved in an integrated and flexible way. Flexible integration is therefore essential if a partnership enterprise is to have an inherent capability to respond competitively as change occurs in product requirements, product orders, mixes of products, business and production processes, available resources, partnership arrangements, as new forms of competition arise, and so forth. A prime goal of enterprise modelling (EM) is to analyse business operations and thereby to improve the deployment of resources by for example recommending strategic, tactical and operational improvements [Vernadat 1996]. A survey of proprietary EM tools found that there are in excess of a hundred commercial vendors of general-purpose enterprise modelling tools, with an estimated annual market of US$79 billion [Goranson 92, ICEIMT 92]. However normally industry and its vendors and consultants use these tools in a fragmented manner [Weston 1999a]. This situation remains despite the 4 of 31
availability of public domain specifications of Enterprise Engineering (EE) frameworks and methodologies such as IDEF [US Air Force 1981, FIPS 183, FIPS 184], GRAI-GIM [Vallespir et al 1991], ARIS [Scheer et al 1994], CIMOSA [CIMOSA Association 1996], PERA [Williams 1992] and IEM [Spur et al 1996]. Fundamental to many of these EE approaches is the use of a backbone of modelling concepts that underpin the representation of enterprise activities and objects from different viewpoints, at different levels of granularity, generality and abstraction and during different life phases. Typical modelling viewpoints include function, activity, control, process, behaviour, organisation, information, resource and cost. Potentially such a backbone of modelling concepts can unify the use of EM tools within a virtual enterprise engineering environment [Weston 1999b]. It can also facilitate the design of change-capable, flexibly integrated systems of resources. However, as yet, focus of current generation EE frameworks and methods has been on modelling (and hence reusing knowledge about) a constrained set of technical issues within a business, but provides limited support for modelling external issues such as aspects of the co-ordinated interworking of partner businesses. Hence the IMEE (Integrated Methodology for Enterprise Engineering) developed in this study seeks to build upon and extend existing backbone modelling concepts in such a way that improved modelling coverage is achieved with respect to co-ordination and interaction issues within partnership enterprises characterised by Figure 1.
2. IMEE 2.1 Overview of IMEE Integrated Methodology for Enterprise Engineering (IMEE) development reported in this paper was undertaken to extend the capability of existing public domain architectures and methodologies in respect to partnership enterprises. IMEE has not been developed as yet another methodology and architecture, rather it builds well on proven public domain enterprise modelling concepts so that knowledge about inter-process between companies and intra-process of partner companies can be shared and reused amongst partner businesses. Necessarily, like the architectures and methodologies from which it is derived, IMEE remains incomplete in that it has been designed primarily for certain classes of use.
However, its structured approach to enterprise modelling is extendible and
customisable. Essentially IMEE modelling capability was developed to structure, support and unify two types of modelling, namely: (1) top-down process-oriented modelling and (2) bottom-up or middle-up-down 5 of 31
object-oriented modelling. To gain an improved understanding about existing functionality available to each company in a partnership enterprise, top-down analysis is facilitated to reveal primary functional capabilities of partners.
Modelling constructs underpinning function, organisation, resource, and
information models are deployed using a matrix analysis approach. Models built using the modelling constructs and relationships among these models are stored in the IMEE repository that manages the outputs of IMEE modelling phases. Function models are represented using an extended form of the IDEF0 notation. This modelling approach is largely function oriented but also enables formal links to be established between function modelling constructs and corresponding descriptions of data, resources, organisations and activities. To organise information components of IMEE models, a data dictionary is defined using ICO (Input, Control, Output) data related to the function models. The elements of the repository are used to structure the design of process models, the execution of which will respectively be initiated and terminated by start and end events. The process models so created are translated into Petri-Net based simulation models in order to visualise, exercise and analyse process behaviours. Object-oriented modelling is also a key part of the IMEE approach and is used to describe information and function problem perspectives as an integral object view.
This enables object
components and relationship between object components to be described. Object components were classified into two main groups, viz.: ‘functional objects’ and ‘entity objects’. Functional objects describe functional capabilities contained in a system, while entity objects describe supporting information. To maintain consistency of use of IMEE models during system implementation, coherent representations of modelled components are developed using UML diagramming notations.
2.2 Process modelling 2.2.1 Requirements Analysis Phase Often it has proven effective to begin by modelling functional requirements of an enterprise so that associated information requirements, etc can be derived [Vernadat 1996, Toh 1999]. Hence in the IMEE requirements analysis phase a prime focus is on function modelling. Also in IMEE, results generated during requirements analysis are verified by using a matrix analysis approach. The prime purpose of the matrix analysis is to identify instances of insufficient and/or redundant information. Table 2 illustrates the main phases, procedural steps and artefacts involved during the requirements analysis phase of IMEE.
6 of 31
Phases
Function Analysis
Organisation Analysis
Resource Analysis
Procedural Steps 1. 2. 3. 4. 5. 6. 7. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4.
Select participant companies Define functional areas and their function Create a context diagram Define context diagram with extended IDEF0 Deduct activity list using map Decompose functions until all sub functions correspond to unit functions Describe entities from ICO data Define the companies and organisation Decompose organisation into a unit organisation Identify unit organisations require interaction Define interactions between organisation units Define organisation and entity matrix Define organisation and function matrix Define and classify resources for each function Attribute resources to companies and functions Define resource capacity Analyse resource utilisation
Artefacts . Functional area and company table . Context diagram . Function Definition . Activity list map . Functional diagram . Data dictionary . Organisation table . Organisation vs. organisation matrix . Organisation vs. entity matrix . Organisation vs. function matrix
. Resource table . Resource vs. function matrix
Table 2 Overview of IMEE requirements analysis phase 2.2.1.1 Function analysis During function analysis the primary functional areas of partner businesses are defined relative to the main business processes shared by the partnership enterprise. To begin to facilitate communication between personnel with various responsibilities in the different partner companies, a context diagram is developed that identifies functional areas. Each functional area of the context diagram is modelled using the extended IDEF0 notation shown in Figure 2. Modelling constructs provided by the extended form of IDEF0 include constructs to represent ICO data with respect to units of function and related information, resource, organisation, time, cost, and combination logic entities. Because Input and Control data related to each IDEF0 function block can be derived from either an internal or external function, an appropriate information source must be defined to avoid confusion. In IMEE this is achieved by attributing source function codes to input and control arrows. Mechanisms provided by standard IDEF0 notation are detailed into resource and organisation component views, because these two components of mechanism have different roles. Here resource models were deemed to be required to describe competences, capabilities and capacity, while organisation models describe relationships combining groupings of human and technical resource needed to perform activities. Time and cost modelling is used in IMEE to develop generic measures of process efficiency. Combination logic is used to map corresponding elements of a transfer function model to an equivalent process model. Here the time-based combination logic operators SAND (Synchronised AND) and AAND (Asynchonised AND) are used in conjunction with conventional OR and XOR logic functions to encode timing requirements in support of IMEE methods.
7 of 31
control (source function code}
input
output function name
(source function code}
output combinations
(function code}
time
eg O1(I1 SAND I2), O2 (I1 OR I3), O3(I2 XOR I3)
cost
resource
organisation
Figure 2 Function Descriptions As top-down modelling requires significant conceptual effort and a broad base of knowledge about a partnership enterprise that generally will be vested in many people within the different enterprises. Therefore it is not a trivial matter to identify a suitable decomposition of a partnership enterprise into an effective set of processes and subsystems.
Further complexity arises when mapping from a
requirements definition to a high-level design description and then onto a real implementation description [Cantamessa 1998, Edwards et al 1998]. IMEE supports a combined use of top-down and bottom-up modelling approaches to help deal with the high levels of complexities involved. Prior to decomposition a mind map method [Kim 1999] is used to identify and collect an activity set. Activities can be deducted at random through brainstorming and outcomes can be structured and represented in the form of a map, such as that shown in Figure 3.
investigate current production plan investigate current stock levels make production plan revise production plan confirm the production plan
investigate part items
process the BOM
investigate part inventory
make or buy
do production planning
receive order
order fulfillment
negotiate with supplier purchase parts
negotiate order do order processing confirm order
investigate suppliers release order
trace parts purchasing
make works order check inventory levels
control shop floor
schedule production
8 of 31
Figure 3 Activity list map An activity list expressed in a mind map style can readily be modified by rearranging activities contained within the map. The map can then automatically be converted into a decomposed function diagram using Dyna-IDEF notation [Simtech 1998b, Kim 1999] as illustrated in outline by Figure 4. By adding arrows to the diagram, the function diagram can be completed.
Date
Reader:
Author:
Used at:
Context:
make make aa production production plan plan A31 process process
the the BOM BOM
A32
make make or or buy buy
A33
investigate investigate
the the supplier supplier
A34
Node: A3
Title: production planning
Number: 4
Figure 4 prototype of function diagram In a partnership enterprise all functions can be related directly or indirectly to activities needed to produce a product or provide a service. Typically this information has unique meaning to actors (i.e. people, machines and software systems) participating in the business process. Business entities can be derived from descriptions of business functions. A key output of a business function is information that can be derived from a model of functionality of the partnership enterprise. It is possible to aggregate output data items and rearrange them into a composite entity. Because an output must be created by only one function, in order to guarantee integrity and because all entities are objects of a business process, a model of an existing entity within the business environment can be captured by this approach. There may be many companies and their relevant groupings of personnel that participate in such a process of defining information entities. Each company may typically have its own naming rules and conventions. Therefore, to facilitate the capture of a single integrated data model, a clear definition of individual entities is required by subject area or function area for each company. Table 3 shows a data dictionary form that was developed for use as part of IMEE. In this form, organisation means the owner who creates data. Type means the data type such as integer, character, and numeric, etc. If an attribute 9 of 31
is a primary key or candidate key, the key column is PK. If an attribute is a foreign key, the key column is FK and the related entity name is put into the remark column. Relationships may be defined according to functional relationships. In which case input data and control data are related to output data. Entity name: Description Alias name Attribute name
Output function name
Description
Organisation Type
Date Key
Remark
Table 3 Data dictionary
2.2.1. Organisation analysis Because the focus of IMEE is on partnership enterprises, there will be a number of organisations involved in developing models of business processes. The objective of organisation analysis is to define organisation relationships that bind the functionality of individual companies and their constituent departments. An IMEE organisation table such as that shown in Table 4 can be developed by aggregating modelled elements contained in the context diagram and the function definition.
Organisation Functional Area Forecasting Market - ing
Dept. A O
.... Product planning
Company A Dept. Dept. B C
... Dept. D
Dept. A
Company n Dept. Dept. B C
Dept. D
O O
… Purchasing Produc -tion
O
Planning
O
....
O
Organisation code
AA1
AB2
NB3
Table 4 Organisation table Through referencing and manipulating entries, such a table can be used to represent and inform the reorganisation of a virtual organisation by removing unit organisations that do not actually contribute
10 of 31
usefully to value adding business processes. In IMEE a unit organisation in a virtual organisation is assigned an organisation code comprising a company code, department code, and unit code. By combining entities of the function and organisation views an organisation vs. function matrix can be developed, such as the Table 5 example. This matrix is used in IMEE to decide who owns functions. It is also useful in identifying workflows at an abstract level. In IMEE every function has an owner (O) and/or an assistant (A). An owner has responsibility to perform a function and thereby realise an activity (which generally will be part of a business process). While an assistant supports owners when performing their functions. If several organisations own a functional capability in IMEE, the main owner must be defined and other organisation units reconfigured as collaborating assistants. Organisation code Function F1
AA1
AA2
A
A
.
.
.
NAN
O
O
F2 ….
A
Fn Table 5 Organisation vs. function Matrix
2.2.1.3 Resource analysis In IMEE the objective of resource analysis is to define those resource elements required to realise specified activities. IMEE classifies resources within three groups, namely: ‘manufacturing machines’, ‘computing’ and ‘human’. Manufacturing machine resources possess capabilities to automate or semiautomate the production of products, while computing resources are tools or software applications that possess capabilities to support business and product realising activities such as planning, control and management. Human resources are people that possess competances to carry out business and product realising activities with or without computing resources. IMEE methods were devised to assign responsibilities (for management, control and utilisation of resources) to companies, departments and other units that have the necessary competences, capabilities and capacities to discharge responsibilities assigned. Table 6 lists properties of resources in conformance with the IMEE approach. In Table 6, manufacturing and human resource are attributed with a resource capacity. Here the term ‘resource capacity’ is used as a measure of the time that a given resource capability or cmpetance needs to be assigned in order to realise a particular unit of activity. In IMEE, resource capacity is measure in hours. For example, to achieve an action 1 it may be that 3 units of machine A capacity and 1 unit of
11 of 31
person X capacity is required. IMEE regards computing resources as mechanisms that realise or help realise activities whilst placing modelling limits on capacity. During the design life phase of IMEE, knowledge about resource competences, capabilities and capacities can be used to determine the composite capability required to realise all activities comprising a given business process. Property Name Resource 1
Type
Company
Function
Capacity
UoM
Table 6 Resource table By aggregating elements contained in the function and resource views of IMEE a resource vs. function matrix can be created. This matrix is used to check the capabilities available to functions. Table 7 illustrates this point where the number denotes the capacity of a resource. If a resource is shared by several functions and therefore its capacity is limited, a function can use the resource only when the resource is available. Other functions may therefore need to wait for resource availability. This matrix is useful in support of simulation modelling. Resource Function F1 F2 . Fn
Machine 1
Machine 2
Server 1
. . .
3 1
Human 1 1
Table 7 Resource vs. function Matrix
2.2.2 TO_BE Design Phase An initial task in the TO_BE design phase of IMEE is to build a repository that stores information about components that will be used during design analysis. Models of unit functions contained within this repository can be extracted and converted into an equivalent IDEF3 UoB (Unit of Behaviour) description when configuring and assigning resources to a business process. Table 8 illustrates in overview the TO_BE design phase. Steps Repository Design Process Design
Procedures 1. Define E-R model that describes component relationships analysed. 1. Match unit functions described in the repository to each event and end event. 2. Using a tracing mechanism, find unit function blocks for each end event.
12 of 31
Artefacts E-R diagram IDEF3 Process flow diagram IDEF3 OSTN diagram.
Simulation model
Behavioural Design
3. Convert unit functions into an equivalent IDEF3 UoB model. 4. Define resource and organisation entities as a referent object. 5. Translate the ICO combination logic of unit functions into UoB junctions and links. 6. Connect UoBs according to the junctions and links defined. 1. Convert IDEF3 modelled elements into components of petri-Net as shown in Figure 11. 2. Add place and transition elements with reference to the following rules. • Add transition if an arc connects a place to another place. • Add a place where transitions are directly connected. 3. Add resource places because UoBs require resources to perform their function. Put the resource place in front of the UoB place. 4. Add an arc that returns to the resource place. 5. Remove resource places that have unlimited capacity because these resources do not need inclusion with the simulation model. 1. Define method. 2. Define message interaction.
Petri-Net model
. Method table . Message interaction table . Message description table
Table 8 Overview of IMEE procedures followed during the design life phase
2.2.2.1 Repository Design So that the output of the analysis phase can be used to design a new business process, the elements to be modelled and their relationships must be defined in conformance with a meta-model that establishes semantic meaning and facilitates knowledge sharing. Figure 5 shows the E-R diagram describing the main IMEE elements modelled and their relationships. A description of these elements and their relationships can be retrieved from the database repository during process design.
13 of 31
major process n m
company
m
n
functional area
1
n
1
n
organisation
control data
n m
n
1
unit function m
1
m 1
output data
n
n
input data
n
resource
entity
m
n
subject area
1
Figure 5 E-R diagram describing relationships between modelled components 2.2.2.2 Process Design 2.2.2.2.1 Extraction of activity sets Any business process comprises a set of the activities with a specific temporal and logical ordering. An activity in IMEE requires capabilities of a specific type of business function. At the lowest level of granularity atomic activities are modelled and their functional capability requirements defined with reference to non-decomposable unit functions. Because functionality requirements of smaller granularity, sub-atomic functions cannot be completely and uniquely described in IMEE potentially sub-atomic functions may receive more or less information than required and produce information that goes unused. Similar top-down modelling phenomena were observed by Cantamessa 1998, and Edwards 1998. To avoid this problem, a complementary bottom–up design approach was developed as part of IMEE based on facilitating the aggregation and organisation of sub-atomic functions into unit functions. All unit functions required to enact a new business process must be organised with reference to their time and order of use. The IMEE method developed to achieve this begins by describing a start event that initiates each sub-process and an end event related to its termination. The modelled events and their relationships are then represented and stored in the repository. Function blocks are extracted from the repository and grouped along with new function blocks illustrated conceptually by Figure 6. Information sources related to unit functions will already have been defined. Thereby control and data flows, related to activities comprising a business process, can be defined and exercised by connecting
14 of 31
relevant models of unit functions and by invoking the use of an IMEE tracing mechanism [Kim et al 1997].
target process end event
start event
direction
repository
Function vs Resource
unit function
Organisation vs Entity Organisation vs Function Entity vs function
E-R model
[matrix]
Figure 6 Process Design Concept
2.2.2.2.2 Logical connections between activity sets By using the IDEF3 notation unit functions are modelled in IMEE as UoBs while associated data, resource and organisation entities are converted into reference objects. To complete the process design the sequential ordering of selected groupings of unit functions needs to be defined. This requirement is met in IMEE by using combination logic defined previously during function definition. Precedence relationships connecting unit functions must be made clear. To achieve this OR operators may be replaced by a combination of XOR and AND operators [Yim 1999]. IMEE only makes use of IDEF3 XOR and AND operators. Junction AND can be divided into two types to define time relations, the types being SAND and NAND. When process changes must be made, activities can be extracted from the repository interconnected using these logical operators and new operational sequences can be exercised by using the IMEE tracing mechanisms. This provides means of flexibly defining connections and hence can be instrumental in providing a process change capability. The IDEF0 model shown in Figure 7 describes a generalised example of order negotiation and order booking. In this case there are two types of order, namely (1) orders for a new product type and (2) orders for an existing product type, i.e. one that has already been designed and produced by the manufacturer concerned. IMEE modelling notations can convert models of this type into an equivalent process flow diagram nd an equivalent object state transition network. This is illustrated by Figures 8 and 9 respectively. 15 of 31
spec. I2 (A2-321)
develop the spec. (A2-321)
required order (A3-111)
inventory C1 (B3-31) production plan C2 (B3-42)
propose order (A1-221)
order I1 (A1-221) adjusted spec.
adjust order (B3-11)
proposed order O1
adjusted order
adjusted order O2 SAND (I1, I2)
confirm order (B3-12)
booking order
X(O1, O2)
Figure 7 Example IDEF0 model representing order negotiation and order booking activities
object/ order
X
propose order 1
4
A1-222
&
&
adjust order 3
X
confirm order
B3-11
suggest spec. 2
A2-321
Figure 8 Illustrative use of the IDEF3 Process Flow diagram
16 of 31
X
B3-12
UOB/ request
UOB/ propose
required
UOB/ confirm
received
booking
object/ order
UOB/ adjust
Figure 9 Illustrative use of the IDEF3 OSTN
2.2.2.3 Simulation model Process models expressed in IDEF3 essentially describe no more than a sequential flow of activities related to a UoB. To further develop this model in terms of performing a capability assessment prior to implementing a new process or making a process change, the operation of the process model needs to be simulated. Simulation models developed to support IMEE methods model activity sequences and relate these to resource capabilities. The aim here is to facilitate resource allocation and resource capability and capacity analysis in the manner indicated by Tables 6 and 7. Sequences relating UoBs (activities) will previously have been modelled using IDEF3 notations. To develop equivalent simulation models, a Petri-Net modelling capability was developed as part of the IMEE approach. As IDEF3 models can be converted directly into an equivalent Petri-Net model as illustrated by Figure 10. This approach to simulation was taken because proven Petri-Net modelling tools already exist for process analysis under conditions where resources are shared by activities [Peterson 1981]. Whereas use of the IDEF3 notation proved to be suitable as a means of underpinning IMEE simulation methods.
17 of 31
&
transforms to
&
transforms to
&
transforms to
X
transforms to
UOB
transforms to
Figure 10 Mapping between IDEF and Petri-Net modelling notations
In general a Petri-Net is formally defined by descriptions of four elements, namely P, T, I, and O. P is a finite set of places p, T is a finite set of transitions t, O is a mapping as an output place from transition t and I is a mapping to an input place of transition t. UoB junctions and objects (i.e. resources) expressed in IDEF3 can be converted into equivalent elements of a Petri-Net. Figure 11 shows a Petri-Net model that is equivalent to the earlier IDEF3 model illustrated by Figure 8.
p1
t1
p3
t3
t4
p6
p5 p2
t2
p4
Figure 11 Petri-net model corresponding to the IDEF3 model of Figure 8 2.2.2.3 Behavioural Design In this study the term behaviour is used to refer to some dynamic feature of a modelled element, such as a method. Behaviour is considered both in terms of its definition and usage. From the definition
18 of 31
viewpoint, a method is assumed to describe the operation of an activity. Table 9 indicates how methods of UoBs are described in IMEE. This table describes those methods in terms of an ‘entity class’ and ‘function class’, as explained in the next section. Method name
Parameter
Invoked Condition
UoB1 UoB2 . . . UoBn Table 9 IMEE development of a Method Table
From a usage viewpoint in IMEE, two kinds of behaviour are characterised, namely: internal and external behaviour. The internal behaviour of a system element does not affect other system elements. However it can change their status or data values associated with them. Generally internal behaviour can be defined independently of external issues. Therefore it is relatively easy to define a method describing internal behaviour. Only a UoB and its related objects (mainly entity and resource objects expressed in IDEF3) need to be defined. A simple operation, such as an ‘update’ or ‘delete’ operation, corresponds to an example change in internal behaviour. Interactions between UoBs must be considered because precedence relationships and triggering sequences relating UoBs must be defined. The nature of such interactions should be reflected in the external behaviour of UoBs such as by sending a message or receiving a message to/from other system elements to invoke an operation. To define external behaviour, messages between UoBs must be defined. In IMEE this is done by developing further matrices that encode sequencing, content and routing of messages. Importantly also IMEE message matrices provide a useful ‘front end’ for the development of activity diagrams in UML.
2.3 Object-Oriented Modelling A key advantage of using an O-O approach when modelling in a EI environment is that it can eliminate data duplication as well as establishing a link between a business model and a system model [Jacobson 1995]. Focus in IMEE is not on IT technology issues related to implementation but on the conceptual design of OO models.
2.3.1 Object-oriented Approach
19 of 31
2.3.1.1 Components According to Jacobson components are an occurrence of a system object or system entity that can contain information and can offer behaviour [Jacobson 1995]. It follows that enterprise components are an occurrence of enterprise system entities that can contain information and offer means of achieving activities. Further these activities can be ordered into business processes. Based on this reasoning Sims explains that enterprise components can be mapped onto components called ‘business objects’ [Sims 1994]. During the analysis and design phase of enterprise engineering projects, unit functions of a UoB can be described in terms of activities and information entities in an enterprise. To represent these two enterprise views within composite objects, in the manner illustrated by Figure 12, function class and entity class concepts can be used.
I1 I2 I3 E3
A1
R1
Or1
O1
A1 I1 : E1 I2 : E2 -- -In : En
E2 E1 I1
[function class A] [entity class] Figure 12 function class and entity class Function class elements can be used to describe the functionality offered by business objects and the functionality needed to realise individual activities comprising business processes. Descriptions of unit functions and configurations of unit functions can therefore be used to inform the design of systems of business objects that have the capability to match specified functional requirements of business processes. Objects defined during the design phase of enterprise projects include entity, resource and organisation object types that form members of an entity class. Based on these ideas IMEE methods were developed centred on the use of function and entity classes. Examples of these classes that can be observed in Figures 9 and 11 are shown in Figure 13.
20 of 31
proposed-order
adjusted -order
order-number date part-id part-name quantity delivery unit-price supplier-name
date order-number product-id product-name quantity delivery unit-price customer-name
booked-order order-number product-id product-name quantity delivery unit-price invoice-number customer-name
adjust-order
order-spec
product-inventory:inventory production plan:plan order:proposed-order spec:order-spec output1:adjust-order output2:proposed-order
order-number part-id part-name spec-id drawing-number authorizer
refer( ) release( ) adjust( ) Figure 13 Example function and entity classes
2.3.1.2 Relationships between enterprise components In IMEE two kinds of relationship between enterprise components are considered, namely: hierarchical relationships and heterarchical relationships.
Hierarchical relationships are used to underpin
categorisation within classes. A class can be classified as a member of a specific set. Member and group relationships are in fact hierarchical relationships. Such a relationship comprises aggregation and generalisation relationships that describe hierarchical structures connecting classes. A generalisation relationship can describe an ‘is-a’ hierarchy that supports an inheritance mechanism, i.e. everything that applies to a class also applies to its subclass. Aggregation relationships describe ‘ispart-of’ relationships and are useful when describing a complex structure such as a product. Heterarchical relationships need to be described in terms of their association and interaction. Associations are made via a physical or conceptual connection (link) between classes, while interaction concerns functional relationships between classes and descriptions of these relationships can be used during dynamic modelling. IMEE diagramming notations that conform to OMT concepts [Rumbaugh 1991] are illustrated by Figure 14.
21 of 31
Because IMEE was developed to organise and facilitate the modelling of dynamic relationships between partner businesses, it recommends the optional use of modelling formalisms that describe the interaction types classified by Figure 14. Essentially aggregation, generalisation, and association are static relationships related to entity classes whereas interaction concerns dynamic relationships related to function classes. The purpose of an interaction model is to specify properties of communication paths between a set of interacting instances that perform a specific task. An interaction is defined within the context of a collaboration i.e. the collaboration defines the context in which the interaction takes place. Interaction relationships can be classified according to message direction (uni-direction and bi-direction) and timing (synchronous and asynchronous). Message direction describes the flow of interaction and timing related to the activation of events. If a class receives a uni-directional and asynchronous message the class will perform an operation only. Figure 15 illustrates interactions between objects listed in Figure 13.
interaction association
synchronous & bi-directional
interaction generalization
synchronous & uni-directional
aggregation
asynchronous & bi-directional
interaction interaction asynchronous & uni-directional
Figure 14 IMEE Notations used to describe relationships
22 of 31
adjusted-order propose-order
adjust-order
confirm-order
order-spec
Figure 15 Example interactions between classes
2.3.2 UML conversion UML is a widely used de facto standard object-oriented modelling language [OMG 1999, Eriksson 1998, Quartrani 1998]. UML is also to be used as a basis for the emerging UEML (Unified Enterprise Modeling Language) proposed by IFAC/IFIP Task Force [Vernadat 1999]. In UML, there are three types of model, namely: use case models, static models, and dynamic models. Use case models describe the required system from user’s viewpoints. Static models are class diagrams that describe elements of the system and their relationships. Dynamic models describe the behaviour of a system over time.
2.3.2.1 Use cases and use case diagrams The elements of a use-case model are use cases, actors and the system modelled. Use cases are shown graphically as a named oval. This represents system functionality in terms of ‘tasks’ that can be done with support from the system. An actor is usually shown as a stick person and is not a part of the system. The actor represents anyone or anything that must interact with the system. An actor is a type (a class) not an instance of a class. The actor notion is used to represent a role, not an individual user of the system. The actor communicates with the system by sending and receiving messages. An actor that sends a message to a system always initiates a use case. Use case diagrams show interfaces with the environment. In a typical structured method the context diagram does a similar thing to use case diagrams. 23 of 31
In the analysis phase of IMEE enterprise engineering projects, the context diagram and system functions are defined from organisation, resource and data perspectives. By using a context diagram and 0-level functional diagram, equivalent IMEE use case diagrams can be defined. For example in IMEE a context diagram modelled in IDEF0 notation to illustrate functional requirements of a system, can be converted into an equivalent use case diagram. Whereas 0-level functions of the context diagram are converted into an equivalent use case. Arrows can be used to indicate interactions between the external environment and roles played by actors. The input and control data has an information source. If an information source function has its owner or resource, this can play the role of an actor because input or control data associated with a function can activate a generation of output data.
2.3.2.2 Class Diagram A class diagram describes a static view of a system in terms of classes and relationships amongst classes. In IMEE previously defined function and entity classes are remodelled in UML notation. Function and entity classes are stereotypes used to specify the semantics of elements. UML descriptions of relationships may be applied to a function class and entity class because association, generalisation and aggregation relationships follow OMT standards definitions, also expressed using UML [Eriksson 1998]. A dependency indicates a semantic relationship between two (or more) modelled elements. It indicates a situation in which a change to the target element may require a change to the source element, because of the dependency relationship. Dependency relationships exist between function classes and entity classes because the attributes of the function class are derived from the entity class.
2.3.2.3 Dynamic modelling Objects in an enterprise system communicate with other enterprise objects. Communication amongst enterprise objects can be represented by a dynamic model defining the behaviours of objects. Behaviour is initiated as a message sent from one object to another. In UML notation the four message types available are those shown in Figure 16. As these types are similar to the interaction types of Figure 14, in IMEE the proposed notation can readily be converted into an equivalent UML message notation. UML provides four kinds of dynamic diagram, namely state, sequence, collaboration and activity diagrams. State and activity diagrams provide a structural description, while sequence and collaboration diagrams provide a behavioural description related to object execution. If the state of an object is important, use of a state transition diagram is recommended as part of the IMEE approach. If 24 of 31
time or sequence is the most important aspect, then the use of a sequence diagram is recommended. If context is the most important aspect, then use of a collaboration diagram is preferred. If the sequence of activity flows is the most important aspect, then use of the activity diagram is recommended.
synchronous
synchronous
with immediate return
asynchronous
simple
Figure 16 Message types permitted in UML notation
State diagram A state of an object is one of the possible conditions it can reach. Typically state changes occur over time. Use of a state diagram complements the use of a class description. It shows all the possible states that objects of the class can reach and which events cause the state to change. An event can occur as a result of a state change at another related object. The OSTN notation of IDEF3 can be used to encode state transition diagrams because OSTN is designed to show object states and related behaviour. Object states described in OSTN can be translated into equivalent object states of a state transition diagram. Whereas behaviour can be expressed in terms of events that cause the state transitions. Figure 17 illustrates a state transition diagram that corresponds to the interaction diagram shown in Figure 15.
order created
confirm
required
propose
received
adjust
Figure 17 Example object state transition diagram
Activity diagram Activity diagrams are designed to graphically represent activity co-ordination and therefore can be used to describe activities that form part of an operation. Common elements of an UML activity diagram 25 of 31
include activity, transition, synchronisation bar, decision diamond and start and stop markers. IDEF3 notation can also be used to encode activity diagrams, as both activities and transition modelling constructs exist within IDEF3. The decision point of a UML activity diagram is analogous to an XOR junction in IDEF3. Concurrency can be depicted in UML activity diagrams in an analogous way to the use of AND junctions in IDEF3. Figure 18 shows a UML activity diagram generated from Figure 15.
propose
adjust
order
spec.
confirm
Figure 18 Activity diagram from Figure 17
Collaboration diagram There is a common requirement for collaboration between a set of objects in a particular context. Elements of UML collaboration diagrams include objects, links and actors. In addition to showing objects and their relationships (sometimes referred to as the context), the collaboration diagram shows message interchange (called interaction). Message arrows are drawn between objects to indicate the direction of flow of messages between objects. A collaboration diagram can be derived from information encoded jointly by a UML use case diagram and an IDEF3 model. From the use case diagram actors can be defined, while an object can be derived from IDEF3 referents. Referents defined for use as part of IMEE are entity, organisation and resource. UoB definitions are central to a process description in IDEF3 diagrams, while objects are central to collaboration diagrams. Message sequence is determined by the order of UoB activation. IDEF links and junctions equate to links in the collaboration diagram.
Sequence diagram
26 of 31
A sequence diagram can be used to describe dynamic aspects of collaboration between a number of objects. This diagram focuses on message sequences over time. A sequence diagram has two dimensions. A vertical dimension represents time. A horizontal dimension represents the state of objects involved in a collaboration. The sequence diagram can be described using an extended form of IDEF0. In the extended IDEF0 notation input and output data can be translated into an equivalent object of an entity class and have time relationships determined by the time-based behaviour of associated functions.
2.3.2.4 Component analogy drawn between IMEE and UML As discussed in the previous section, IDEF diagrams created when applying the IMEE approach can be converted into equivalent UML diagrams. Table 10 characterises the primary conversions involved. UML interaction relationships derived from IDEF diagrams are useful in support of dynamic modelling. For example they encode information that can be reused to define collaboration diagrams describing interactions between objects. However, in general 1 to 1 mapping or conversion will not be meaningful, as the modelling viewpoint will be linked to its purpose and therefore the semantics will not be the same. UML modelling Static
Dynamic
Model Class diagram
Components Class, Relationship
Use case diagram
Use case Actor System
State diagram
Object, state, transition, event
Activity diagram
Activity, object, transition, decision diamond, Synchronisation bar Object, link, actor
Collaboration diagram
Sequence diagram
Object, time
IMEE Model Components Object Class relationship Relationship diagram Context diagram, Functional area, 0-level functional Function, diagram External interface data OSTN Object, state transition, behaviour IDEF3 UoB, Junction and link, Referent IDEF0, IDEF3, Objectrelationship diagram IDEF0
Table 10 Analogy between IMEE and UML modelling concepts
3. Comparison between IMEE and CIMOSA
27 of 31
Link, Referent, External interface data, relationship Input and output arrow, processing time,
Use of the IMEE approach can also be compared with that of CIMOSA [AMICE Consortium 1991, Tham 1999]. By following similar reasoning to that used by Kosanke to compare modelling methodologies [Kosanke 1996] differences between the methodologies can be observed, both in respect to support they provide for enterprise life phases and the set of modelling constructs they provide. It is important to stress however that IMEE was not designed to cover all of the lifecycle defined by GERAM [GERAM 1999] and that CIMOSA methodology provides a broader based coverage. Hence, only life cycle aspects covered by IMEE are compared in this paper. Table 11 shows results drawn from such a comparison. Modelling View
Function View - static view
Function View - dynamic view
CIMOSA Constructs Enterprise Domain Domain Process Enterprise Function I/O Activity & Functional Control I/O Operation Resource I/O Process Event
IMEE Constructs Context Diagram Functional Area I/O/C Data Information Source Function Combination Logic Time and Cost Process UoB, Referent, Junction and Link Transition, Place and Trigger
Organisation View
Organisation Cell/Unit
Organisation Table
Resource View
Capability Set (Functional entity)
Resource Table
Table 11 Comparison drawn between the focus of use of CIMOSA and IMEE modelling constructs Some IMEE modelling constructs can be mapped directly onto equivalent modelling constructs of CIMOSA. However generally the emphasis when modelling will be different because IMEE focuses on functional interaction issues of prime concern when integrating partnership enterprises. CIMOSA on the contrary was conceived primarily to model integration issues within a single business albeit that some CIMOSA concepts can also be used to model integration issues in multi-business systems. The function view of IMEE was designed to explicitly encode information that cannot be readily modelled using CIMOSA modelling constructs and use of IMEE modelling constructs is of greatest potential benefit when modelling functional relationships between companies. Further, when compared with CIMOSA the information view of IMEE encodes additional attributes of entities (or objects) that naturally facilitate the modelling of partner interaction in a global environment. For example IMEE information modelling constructs can readily describe key aspects of the structure and content of distributed data that is manipulated and stored by partner businesses.
28 of 31
4. Conclusion By building upon and extending capabilities of pre-existing approaches, IMEE is an enhancement of previous enterprise-modelling methodologies aimed at modelling collaboration and interaction between partner businesses. IMEE provides analysis and design methods that can be applied to both the process stream and organisation stream of the generalised model proposed by ICEIMT [Weston et al 1997]. IMEE incorporates component-based systems engineering concepts. It follows that IMEE has potential application in the design of Business to Business (B2B) environments, where there is a common need to specify and develop processes shared by partner companies.
REFERENCES AMICE Consortium, 1993, CIMOSA: Open System Architecture for CIM, Second revised and expanded edition, Springer-Verlag, Berlin. Booch, G., 1994, Object-oriented analysis and design with applications (Benjamin/Cummins). Cantamessa, M. and Paolucci, E., 1998, Using organizational analysis and IDEF0 for enterprise modeling in SMEs, International Journal of Computer Integrated Manufacturing, 11(5) pp.416-429. Ceri, S. and Pelagatti, G., 1984, Distributed Databases: Principles and Systems, (McGraw-Hill). CIMOSA Association, 1996, CIMOSA Technical Baseline. CIMOSA Association e.V., Stockholmer Str.7. D-70734 Boeblingen, Germany, April. Tham, D, 1999, Web page, http://www.eil.utoronto.ca/entmethod/cimosa/cim.html Edwards, J.M., Aguiar, M.W.C., and Coutts, I.A., 1998, A top down and bottom up approach to manufacturing enterprise engineering using the function view, International Journal of Computer Integrated Manufacturing 11(4): pp.364-376. Eriksson, H.-E. and Penker, M., 1998, UML Toolkit (John Wiley & sons, Inc,). FIPS 183, 1993, Federal Information processing Standards Publication 183, FIPS 184, 1993, Federal Information processing Standards Publication 184, GERAM, 1999, Generalized Enterprise Reference Architecture and Methodology by IFIP-IFAC Task Force. Goranson H.T., ‘The CIMOSA Approach as an Enterprise Integration Strategy’, Enterprise Integration Modelling Proceedings of the First International Conference edited by C.J.Petrie, The MIT Press, 1992 Jacobson I., Ericsson M., and Jacobson A., 1995, The Object Advantage (Addison-Wesley). Browne J., Sackett P. and Wortmann H., 1994, Industrial requirements and associated research issues in the extended enterprise, IMSE’94 Proceedings, Grenoble, France, organised by INRIA, pp.9-16 Kim, C., Woo, H., Kim, J., and Yim, D., 1997, Functional Modeling Methodology for CALS– IDEF0 Extension, CALS Expo 1997 International Proceedings CD ROM, Tokyo, Japan
29 of 31
Kim, C., Woo, H., Kim, J., 1999, Business Function Modeling Using Mind-map and IDEF0, CALS/EC Korea '99, Seoul, Proceedings of International Conference, Vol. 1, pp.207-213. Kosanke K, Comparison of enterprise modeling methodologies, in Information infrastructure system for manufacturing, pp.115-127, edited by Jan Goossenaerts, et al. Chapman & Hall, 1997 Martin, J., 1991, James J.Odell, Object-oriented analysis and design (Prentice-hall). Messina, S. and Reyneri C., 1997, Exception Handling in CIMOSA: The MAGNETI MARELLI Application’ 30th International Symposium on Automotive Technology & Automation, pp109-117 OMG, 1999, OMG UML Specification ver 1.3 Peterson, J.L., 1991, Petri net theory and the modeling of systems (Prentice-hall). Quatrani T., 1998, Visual modeling with rational rose and UML (Addsion-Wesley). Rumbaugh, J., Blaha, M. and Premerlani,W., 1991, Object-oriented modeling and design (Prenticehall). Scheer, A.W. and Kruse, C., (1994), ‘ARIS – Framework and Toolset. A Comprehensive Business Process Reengineering Methodology.’ Proc. 4th Int. Conf. on Automation, Robotics & Computer Vision (ICARCV 94), Singapore 8-10 Nov., pp327-331. Simtech, 1998 b, Dyna-IDEF manual. Spur, G., Mertins, K. and Jochem, R., 1996, Integrated Enterprise Modelling, Beuth Verlag, Berlin. Toh, K.T.K., 1999, Modelling architectures: a review of their application in structured methods for information systems specification, International Journal of Production Research, 37(7) pp.1439-1458. US Air Force, 1981, ‘ICAM Architecture Part II, Vol. VI - Dynamics Modeling manual (IDEF2), Wright-Patterson, Vallespir, B., Chen, D., Zanettin, M & Doumeingts, G., 1991, ‘Definition of a CIM Architecture within the ESPRIT Project ‘IMPACS’’. Computer Applications in Production Engineering: Integration Aspects, G. Doumeingts, J. Browne and M. Tomljaprovich (Eds.), Elsevier, Amsterdam, pp731-738. Vernadat, F.B., 1996, Enterprise Modelling and Integration: Principles and Applications, Chapman & Hall, London, ISBN 0 412 60550 3. Vernadat, F.B., 1999, A vision for future http://www.cit.gu.edu.au/~bernus/taskforce/archive/
work
of
the
task
force(IFAC-IFIP),
Williams, T.J., The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC (1992). Weston RH, delaHostria, E., Kosanke, K., Noxon, E.R., 1997, Business Benefits from Enterprise Integration, Workshop 5, Working Group 1., Proc. of ICEIMT’97 Int. Conf. on Enterprise Integration and Modelling Technology. Enterprise Engineering and Integration, ESPRIT Research Reports, Project 21.859, E1-IC, Vol.1, Springer, ISBN 3-540-63402-9. pp152-162. Weston, R.H., 1999a, ‘Reconfigurable, Component-Based Systems and the Role of Enterprise Engineering Concepts’, Special Issue of Computers in Industry on CIMOSA. Ed. F. Vernadat and K. Kosanke. Volume 40, Number 2-3, November. Weston, R. H., 1999b, ‘A model-driven, component-based approach to reconfiguring manufacturing software systems’ in Special Issue on Responsiveness in Manufacturing of Int. J. of Operations and Prod. Management, Vol.19, No.7.
30 of 31
Yim, D., Kim,C., Woo, H., Kim. J., 1999, Process Modeling Methodology for CALS, The Journal of Korean Institute of CALS/EC, 3(2), pp. 141-159.
31 of 31
