UML vs. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING
Ovidiu Noran School of Computers and Information Technology, Griffith University Nathan (Brisbane) QLD 4111 Australia
Keywords: Expressive power, modelling language, business modelling, UML, IDEF, ontologies, metamodels, modelling methodologies, Object-Oriented Analysis and Design.
Abstract: The UML and IDEF sets of languages characterize typical modelling approaches of software engineering and computer integrated manufacturing, respectively. This paper presents a comparative analysis of these languages based on their ontologies and in view of their use in business modelling. A brief introduction to UML and IDEF is followed by a high-level comparison taking into account underlying paradigms and language structure. This is followed by a comparative assessment of the expressive power of the two groups of languages, based on the ontologies of their relevant components. The analysis is structured using a set of views deemed appropriate for the modelling domain (i.e. business). The key findings of this paper aim to provide an insight into the suitability of UML ’versus’ that of IDEF in business modelling.
1 INTRODUCTION1 languages for developing business models. Also, the often-perceived failure of the software system to ac- The survival of businesses in today’s demanding curately reflect the business that it supports has re- global market greatly depends on their agility, i.e. sulted in calls for the same set of languages to be their capability to respond adequately and timely to used in modelling both the business and its informa- changes in the environment. Agile businesses typi- tion system. cally thrive on such changes by implementing their This paper makes a contribution towards an own, continuous internal transformation processes. ontology-oriented comparison of the suitability and Business models help promote a deep understand- expressive powers of two candidate sets of languages 2 ing of the business and can support its operation .A for the purpose of business modelling, namely the business model is based on an ontology of changeand Unified Modelling Language (UML) and the Inte- as such it is an enabler of business agility. Busi- grated DEFinition (IDEF) family of languages. Both ness modelling aims to produce models that accu- sets of languages may be used to model aspects of a rately reflect aspects of the business required for the business, although they provide different degrees of intended use of the models, and which are understood support for the various views involved in the business by the target audience. Thus, the models must strike modelling effort. This comparative analysis intends to a balance between complexity and expressiveness, re- help the enterprise architect understand the available flected in the choice of modelling frameworks, lan- options, and thus make an informed choice of mod- guages and methodologies involved in the modelling elling languages for a specific business engineering effort. task. The complexity of the modelled targets often brings about the necessity to use a set of candidate
1the full version of this paper with additional compari- son aspects and a proposed assessment framework may be obtained from the author ( http://www.cit.gu.edu.au/˜noran) 2e.g. by means of model-based control
674 Noran O. (2004). UML vs. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING. In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 674-682 DOI: 10.5220/0002629306740682 Copyright c SciTePress UML VS. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING
2 INTRODUCTION TO IDEF AND 2.2 UML UML The Unified Modelling Language (UML) originates in three modelling method streams, represented by 2.1 IDEF Booch (Booch, 1991), Jacobson (Jacobson, 1994) and Rumbaugh (Rumbaugh et al., 1991). UML has The IDEF (originally an acronym for ICAM DEF- been subsequently complemented by the Unified Pro- inition) family of languages has its origins in the cess (Jacobson et al., 1999) - a software develop- 1970’s US Air Force Integrated Computer Aided ment methodology based on an iterative development Manufacturing (ICAM) program, which aimed to cre- paradigm. ate computer-implementable modelling methods for The UML is a set of essentially graphical languages analysis and design (Menzel and Mayer, 1998). As expressed as diagrams. The component languages shown in Table 1, after the initial project which (refer Table 2) reflect the history of UML: created by yielded IDEF0 (NIST, 1993a; IEEE, 1998), IDEF1 unification, rather than competition 5. Despite their and IDEF2, there have been another two initia- syntax and semantics being defined in a set of meta- tives that have produced IDEF1X (IDEF1 eXtended) models (Rumbaugh et al., 1999) and associated se- (NIST, 1993b), and IDEF3 (Mayer et al., 1993), mantics (OMG, 1999b), the languages composing the IDEF4 and IDEF5, respectively. UML are not completely formalised, and hence sub- The current efforts within IDEF are focused on the ject to interpretation6. A comprehensive description refinement and integration3 of the existing languages, of UML is beyond the purpose of this paper 7. and the development of few others (see Table 1). The currently most used IDEF languages are IDEF0, IDEF1X and IDEF3. A complete introduc- Table 2: UML language components tion to the IDEF family of languages is beyond the UML Diagram Purpose Comments scope of this paper, but comprehensive IDEF infor- Class Structure modelling 4 mation is available . Structure (particular) Derived from Object modelling Class Use Case Function modelling High-level Table 1: The IDEF languages (based on (Cho, 2000)) Equiv to Sequence Behaviour modelling Project Language Purpose Collaboration Equiv. to st IDEF0 Function (activity) Modelling Collaboration Behaviour modelling 1 Generation Sequence (Original ICAM IDEF1 Information modelling State(chart) Behaviour modelling Project ) IDEF2 Simulation Modelling Use subset for Behaviour / Function nd Activity function 2 Generation. modelling modelling (USAF Integrated IDEF1x Data modelling Info Support Software- Component Implementation modelling System Project) specific 3rd Generation Behaviour modelling Environment (config.) Software- IDEF3 Deployment (USAF Integrated .(Process description capture) modelling specific Information for IDEF4 Object-oriented design Concurrent IDEF4++ C++ Object-oriented design Engineering Project) IDEF5 Ontology description capture IDEF6 Design Rationale Capture 3 A HIGH-LEVEL COMPARISON IDEF8 Human-System Interaction Design In Development IDEF9 Business Constraint Discovery IDEF14 Network Design 3.1 Evolution IDEF7 Information System Auditing Both sets of languages have appeared at a suitable IDEF10 Implem. Architecture .Modelling 8 Envisaged IDEF11 Information Artifact Modelling time and have had industry endorsement, either via IDEF12 Organizational Design Method 5e.g. it has been argued that some of the UML languages IDEF13 3-schema Archit Design Method are somewhat redundant or overlapping in their scope. 6precise UML (pUML, http://www.puml.org) is one ini- 3hence the IDEF acronym shift from ICAM DEFinition tiative that aims to address such issues. to Integration DEFinition 7for more information refer (Rumbaugh et al., 1999) 4white papers on IDEF languages and methods are cur- 8IDEF has answered a need for computer implementable rently available on www.idef.com and www.kbsi.com. Analysis and Design modelling methods/languages in man-
675 ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
government specification (IDEF) or merging of mod- (Rumbaugh et al., 1991). Thus, the IDEF family gives elling methods through developer, and end user par- the user flexibility in the choice of the analysis and de- ticipation in a consortium (in the case of UML). IDEF sign languages and modelling methods (although cur- has preceded UML by nearly a decade, and while rently, IDEF’s OO extensions are not widely used or as such it has had more time to mature, it has also supported by modelling tools). needed to adapt to historic changes in modelling re- The IDEF family of languages offers components quirements. The ICAM project developing IDEF has (languages with associated methods) which allow tak- initially produced three languages aiming to model ing a holistic approach to business modelling (such as the static, informational and dynamic aspects. How- representing business artifacts in the context of life ever, various changes in the usage of analysis and de- cycle phases). On the UML side, the Unified Process sign paradigms (such as a shift from Data- and Func- may also provide a life cycle modelling methodology. tion Driven to Object-Oriented) has prompted a re- finement of existing languages and the addition of 3.3 Language Structure several new members to the IDEF family. Currently, the IDEF suite numbers 16 languages, A set of integrated languages must be based on a com- of which 6 are actively used. It appears that some mon metamodel that guarantees the consistency of its languages have subsumed the scope of others (e.g. components. The syntax and semantics of the IDEF 9 IDEF3 has obsoleted IDEF2 and contains IDEF5 el- languages are separately described in their associated ements; IDEF4 contains IDEF6 elements, and IDEF9 documentation; however, IDEF developers have not appears to have included most of IDEF6’s scope). published a common metamodel underlying the com- UML has started with a total of 9 diagram types ponent languages. This is an significant drawback, (languages), which have received minor revisions. A as typically the modelled business views are mutually formal constraint language has been developed for- dependent. For example, the inputs / outputs of an and included with UML. This has opened the way activity modelled in IDEF0 may be further detailed in towards removing some of its original ambiguities, an IDEF1X data model. Activities modelled in IDEF0 which also plagued its metamodel description. A may also appear as Units of Behaviour (UoBs), or as modelling process has been developed for the UML triggers for changes of states in IDEF3 process flow users, and several extensions have been developed by and state transition models respectively. As there ap- third parties for specific domains such as business pears to be no formal metamodel to enforce consis- modelling, user interface design, etc, in effect creat- tency between the IDEF languages, a tool or set of ing extended modelling languages of which UML is tools implementing several IDEF components (e.g. a common subset. Notably, several such customiza- IDEF0, IDEF1X and IDEF3) would have to provide tions are based on ontologies of the IDEF family of its own internal constraints to ensure coherence be- languages (such as e.g. the IDEF0-based extension tween the views modelled in these languages11. to the UML activity diagram for function modelling In contrast, UML does have a common framework (Eriksson and Penker, 1999)). underlying its languages and binding together the dia- grams describing the various views constructed using 3.2 Modelling Approach these languages. The component languages are de- scribed in metamodels organised into a collection of UML is based on the Object-Oriented Analysis and packages, which together form a unified UML meta- Design (OOAD) (Shlaer and Mellor, 1988) method; model. Thus, a modelling tool claiming UML com- this strongly suggests the UML user to follow an OO pliance should be based on the UML metamodels and design method. semantics, as detailed in (OMG, 1999b). In IDEF, the business architect may choose to use The UML specification allows for its extension and IDEF0, IDEF1/IDEF1X, IDEF3 and IDEF5 for Data- customization, which, when performed according to a and/or Function-driven analysis and design, or to use structured process recommended by the Object Man- such languages in order to enhance an OOAD per- agement Group 12, leads to UML profiles tailored for formed in IDEF410 (Mayer et al., 1995), which is a particular domain. This feature provides flexibility similar to Rumbaugh’s Object Modelling Technique but must be used with caution. Any extension to the UML is in fact modifying its metamodel and hence, ufacturing, while UML has addressed calls for an integrated OOAD set of languages in software engineering. 11a few modelling tools (e.g. Computer Associates’ ER- 9IDEF3 covers features of IDEF2, such as simulation Win/BPWin) do allow some integration of IDEF0, IDEF1X 10IDEF4 allows the migration of existing IDEF analysis and IDEF3 models. / design models to an object-oriented form. 12OMG is the UML custodian, at www.omg.org
676 UML VS. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING
its meaning to the intended audience. Thus, any such simple constraints such as cardinality / participation) modification must be properly documented and sup- for an ontology, although it may reach its expressive ported by a glossary, metamodel and preferably have power limits13. Axioms, complex constraints and in- its semantics defined by a First Order Logic (FOL) ference rules must then be defined using an FOL lan- language; this will ensure that the models created with guage. the customised language are still comprehensible to UML does not provide a dedicated language for the target audience. ontology capture. However, UML class diagrams (with or without extensions) can be used to par- tially represent ontologies14 (Cranefield and Purvis, 4 A VIEW-BASED COMPARISON 1999), while the Object Constraint Language (OCL) (OMG, 1999a; Warmer and Kleppe, 1998) may be employed to represent the axioms and more com- 4.1 Choice of Views plex constraints. Similarly, IDEF1 / IDEF1X may be used for the purpose of partial ontology capture (with Typical modelling views proposed by the software en- limitations similar to UML class diagrams), com- gineering discipline (Si-Alhir, 1998) include Struc- plemented by an FOL language such as Conceptual tural, Behavioural, User, Implementation and Envi- Graphs (Sowa, 1998) or UML’s OCL. ronment. IDEF5 is a specialised set of languages for the cap- ture and construction of ontologies (Gruber, 1993). Table 3: Possible mapping of the views proposed by Soft- This IDEF component uses a schematic language (re- ware Engineering and Manufacturing sembling an information modelling language) for a first-cut ontology capture, and a more precise FOL Manufacturing Software Engineering elaboration language (based on the Knowledge Inter- Function change Format (Genesereth and Fikes, 1992)) for de- (Activity, Decision, Behavioural / User scribing axioms, constraints and inference rules. The Behaviour) IDEF5 specification also includes a methodology for Information Structural capturing ontologies (Mayer et al., 1994). In conclusion, IDEF5 raises the expressive power Resource Structural of the IDEF family for the purpose of ontology mod- Organisation Structural elling, while on the UML side formal extensions such - Environment as ontology capture profiles may enhance UML’s ca- - Implementation pacity to capture ontologies. 4.3 Information / Data Manufacturing and industrial automation propose their own specific views, such as Function, Infor- Information is an essential and well-understood as- mation, Resources, Organisation, Manufacturing vs. pect of business modelling. Information/data15 mod- Control, Human vs. Non-human and Software vs. elling is typically performed at several levels (such Hardware (ISO/TC184/SC5/WG1, 2000). as conceptual, logical, physical16) before the result- The main requirement in the final selection of busi- ing models are implemented in the information sys- ness modelling views (shown in the left-hand side tem supporting the business. The comparative analy- of Table 3) has been that together, the chosen views sis of IDEF and UML for information modelling pur- should be able to produce models usable by an analy- poses must take into account such modelling levels, sis and design process. the implementation and final purpose of the data mod- els, and other environmental constraints (such as the 4.2 Ontology Capture supporting infrastructure).
13 Capturing the ontology of a domain (e.g. business) conversely, an ontology capture language may be used to model information / data, albeit in a less efficient manner. is a crucial step towards its effective modelling. Note 14 that generally, an ontology can be defined either to be UML is already used in database schema and knowl- edge models design (Schreiber, 1999) just a terminology (described e.g. by a meta-schema), 15in this context, data is seen as objective facts compos- or to contain a theory (composed of terminology, ax- ing the Universe of Discourse, while information is the sub- ioms, constraints and inference rules) and operational jective meaning associated to the data by users. semantics. Thus, an information / data modelling lan- 16presently there is no unanimously accepted terminol- guage may be employed to capture terminology (and ogy describing data modelling levels.
677 ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
Data modelling may be performed in UML using traced back to the conceptual level. its OO-based class diagrams, which contain entities Both UML class diagrams and IDEF1X have ex- that may also encapsulate operations. Within IDEF, pressiveness and consistency drawbacks. For exam- the IDEF1 (information capture and modelling) and ple, the IDEF1X notation meaning is dependent on especially IDEF1X (data modelling) languages, both the context (with potential ambiguity and complex- based on the Entity Relationship (ER) model (Chen, ity consequences18). The UML class diagrams on 1999) and early relational work by Codd (1970), have the other hand allow distinct Object IDs for dupli- traditionally been used to model information and data. cate objects, which may create data redundancy prob- Specific concepts of IDEF1X and UML class di- lems19. Both UML class diagrams and IDEF1X are agrams (such as primary/foreign keys, weak entities restricted to expressing binary relations / associations, and relationships vs. object surrogate keys (OIDs), but since a ternary and higher order relation can al- qualified and basic associations) reflect their different ways be turned into an ’objectified’ entity or class, underlying paradigms, but provide equivalent expres- this does not limit the expressive power of either sive power to the two languages. A specific feature of UML or IDEF1X. the UML class diagrams (owing to the OO paradigm) is their ability to express functional aspects of the entities (classes) represented. This capability allows Table 4: Information / Data view comparison class diagrams to be more expressive than IDEF1X if Language Advantages Shortcomings needed, e.g. to represent constraints and triggers. For a relational database application, IDEF1X may IDEF1 / Data Driven, wide Notation may be be used to model data at conceptual and logical lev- IDEF1X use for RDBM S confusing to users els; any special constraints can then be represented by text or an FOL language. The resulting model Expressive, bridge Relation to IDEF4 Link / may then be represented at physical level in a rela- for ER to OO or IDEF1X not relationship tional data definition language (such as the Structured hybrid straightforward Query Language - SQL) and implemented in the rela- Surrogate keys, Expressive, wide tional database. If UML class diagrams have to be in- UML Class bundles data and volved in modelling the conceptual and logical levels, use for OO DB function an OO to relational mapping should take place at log- ical level, so that the result can still be implemented in the relational database. The IDEF4 Static models contain relationships For an OO database application, the use of UML and links diagrams which are similar in meaning to class diagrams at the conceptual and logical levels IDEF1X, However, IDEF4 static models also contain would facilitate the implementation of the resulting inheritance and sub-typing diagrams which are simi- model(s) in an OO data definition language. In this lar to the UML class diagrams concepts (and thus pro- OO-constrained scenario, IDEF1X may also be used vide an object-oriented modelling mechanism with for modelling at conceptual and logical levels; how- a comparable expressive power). Thus, the struc- ever, the result must be subjected to a relational to OO ture of IDEF4 static models (based on both the OO mapping17, resulting in an UML class diagram (or an- and relational models) and the connection to IDEF1 other OO modelling language) model at logical level. / IDEF1X allows it to also be employed in hybrid In the relational implementation scenario, UML’s (object-relational) database development. In addition, additional expressiveness is not fully utilised; thus, IDEF4 facilitates the mapping of ER data models de- IDEF1X may be a better choice, since it would not veloped in the analysis/design phases to OO designs require any additional mappings. Constraints (such (while all necessary models are contained and ex- as referential integrity) will be represented in an pressed in IDEF4). IDEF1X implementation by stored procedures and Scope and space limitations do not allow a discus- triggers. In the OO implementation alternative, UML sion in depth of all aspects involved in modelling busi- class diagrams are an obvious choice since no addi- ness information and data. tional mappings are needed and classes (and function- ality) implemented in the OO database may be easily 18e.g. in IDEF1X different symbols for a relationship’s optionality are used depending on its cardinality; thus, a 17attempts to define object-oriented extensions for symbol cannot represent independently the optionality and IDEF1X, ((Bruce, 1992), IDEF1X97) towards the purpose cardinality of the entity next to it, but rather their combina- of facilitating a transition from ER to OO have had little tion (Hay, 1995) impact, in view of the development of UML and IDEF4. 19for further details refer to (Ettlinger, 1999)
678 UML VS. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING
4.4 Function Analysis Design Technique (Ross, 1987). IDEF0 di- agrams contain Activities, which take ICOMs (In- In the context of this paper, Function modelling is un- puts, Outputs, Controls and Mechanisms) and can be derstood to subsume Activity and Behaviour (or Pro- decomposed in further IDEF0 diagrams. However, cess) modelling, whereby the behavioural aspect fur- IDEF0 lacks decision points and the possibility of ex- ther details and enriches the activity perspective (e.g. pressing roles (Arnesen and Krogstie, 2002); in addi- with temporality, sequencing, states, etc). tion, some elements of its graphical notation may be confusing21. 4.4.1 Activity Such specific features of IDEF0 and UML activity diagrams may enhance the expressiveness of a busi- This view of the business aims to describe the activ- ness model produced within a specific modelling sce- ities involved in the business (the ’what’), seeking to nario, depending on the particular expressive power abstract from the temporal aspect (i.e. succession, du- needs. ration, concurrency, etc). It is a well-understood and researched aspect which appears in the large majority 4.4.2 Behaviour of analysis and design methods. Behaviour is expressed in business modelling via processes - ordered sequences of events aiming to Table 5: Activity view comparison achieve a business outcome, usually within a sce- Language Advantages Shortcomings nario. UML provides use case diagrams for the high-level Decomposable, Notation may be IDEF0 definition of scenarios, and activity diagrams to de- ICOMs confusing tail them. Sequence, Collaboration and State(chart) Decomposable, Low expressive power. diagrams may then be used to further specify be- UML Use Low complexity, Needs detail and/or havioural models. In UML, dynamic behaviour may Case comprehensible extensions also be modelled in other diagrams; e.g. a class di- UML Decision points, Only subset usable agram may contain invariants for active classes (or Activity roles (disable timing features) for the whole model), pre-post conditions on opera- tions of active classes, concurrency properties of op- erations, or signal reception specifications. Signifi- Note that the decisional aspect of a business may be cant semantic variation points in the UML are related considered a specialisation of the activity sub-view. to dynamic behaviour (such as statechart event queue Thus, an activity modelling language may be used to handling). Sequence and collaboration diagrams are model decisions. Specialised languages, more expres- semantically equivalent (depict object cooperation in 20 sive for the purpose of decisional modelling do exist a behaviour (Fowler and Scott, 2000)). , however they are beyond the scope of this paper. Behaviour is modelled in IDEF via IDEF3, which The UML component which is typically used to de- captures precedence and causality relations between tail the activity view of a business is the use case. Use situations and events; a process is a structured collec- cases may be further decomposed and detailed (or tion of activities related to one another by the tem- extended) to increase their expressive power (which poral constraints. IDEF3 contains decomposable Pro- may, however, also result in high complexity). A sub- cess Flow Descriptions (PFDs, process-centric) and set of the UML activity diagram may also be used Object State Transitions Descriptions (OSTDs, an for activity modelling, provided that it contains no object-centric model of behaviour). An IDEF3 PFD timing-related features (such as synchronization or diagram usually covers a single use case scenario, explicit sequencing). Activity diagrams may be ar- which is consistent with the typical coverage of an ranged into ’swimlanes’ so that they can be attributed UML sequence or collaboration diagram. This cover- to ’roles’ (performers). Moreover, hybrid diagrams age equivalence facilitates a meaning-based (Larson, are possible in UML (e.g. showing outputs for activ- 1998) translation of an IDEF3 diagram to an UML se- ities). Such features enhance the UML diagrams ex- quence or collaboration diagram and viceversa. The pressivity, although they should be properly explained IDEF4 Dynamic model provides state diagrams and to the users and used in a consistent manner. client-server diagrams, which are similar to the UML The IDEF component used for activity modelling state diagrams and collaboration diagrams, respec- is IDEF0. Its ontology originates in the Structured 21such as the difference between Inputs and Controls, or 20notably, GRAI Grids / Nets (Doumeingts et al., 1998) the meaning of tunnelled and bundled ICOMs
679 ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
tively. The IDEF4 and UML state diagrams use com- tivity diagrams). IDEF3 OSTDs allow the representa- mon concepts, such as events (to trigger state transi- tion of the triggering activities as IDEF3 UoBs, en- tions) and messages (to depict object collaboration). abling a direct connection to the IDEF3’s Process IDEF4 also provides a specialised behaviour diagram, Flow Diagrams. Thus, IDEF3 PFDs and OSTDs can describing implementation of messages in methods of represent activity-centric and object-centric views of objects. Its notation is similar to the IDEF4 inheri- the modelled business behaviour within the same use tance diagrams and can thus be confusing. case. IDEF4 state diagrams can describe synchronous UML activity diagrams are closest in their meaning / asynchronous messages but also object communica- to the IDEF3 Process Flow Diagrams. Both languages tion, similar to UML sequence and collaboration dia- allow for decision points and synchronization. IDEF3 grams. Table 6 synthesises these findings. PFD’s Units of Behaviour are decomposable, allow- ing the modeller to achieve a balance between expres- 4.5 Resources siveness and model complexity suited to the specific modelling purpose. Business resources may be either information or other UML collaboration / sequence diagrams and artefacts - abstract (e.g. organisational unit), or phys- IDEF4 client-server diagrams express essentially the ical (human or non-human, e.g. items). same concept, i.e. how objects work together within The expressive power of UML class diagrams may a given scenario. IDEF4 client-server diagrams can be enhanced for resources modelling by standard represent object roles and attributes, while UML se- extensions like stereotypes (e.g. <
e Functional g Ontology a Behaviour Junctions, UOB Complex for large u capture Activity IDEF3 OSTD g Process State n references use cases a Class, Use Case, Activity, Sequence / L UML State g Extensions Activity Collaboration n
Synch, object Potentially confusing i l IDEF4 State l IDEF3 PFD, IDEF4 IDEF3 e IDEF3, communication notation d IDEF IDEF0 Behaviour, Client- OSTD, o IDEF5
M Server IDEF4 State Decomposable, Complex for large UML State history, variables, Dom ain / View use cases Organi- Life Modelling e Information Resource
triggers, activities g sation Cycle Method a
u Use Case, g Unified n
a UML Class Class Class, -
L Process Extns UML state diagrams, IDEF3’s OSTDs and IDEF4 g n i
l IDEF1, IDEF1, l Included in state diagrams are all based on the Harel State Charts e IDEF1X, IDEF1X, IDEF6, d IDEF IDEF8 Language o IDEF4 Link / IDEF4 Link / IDEF9
(Harel, 1987). UML state diagrams can repre- M Specs Relational Relational sent triggered or triggerless transitions and atomic, composite- and history states22. In addition, UML states can contain embedded variables and activities (usable to connect to corresponding UML timed ac- 4.6 Organization
22i.e. composite states that remember their active sub- The organisational aspect of businesses is typically states when the object them (Rumbaugh et al., 1999). not as well-understood as e.g. its functional, or in-
680 UML VS. IDEF: AN ONTOLOGY-ORIENTED COMPARATIVE STUDY IN VIEW OF BUSINESS MODELLING
formational facets. This makes organizational design the extended language should also be constructed and of a business a non-trivial exercise, which requires used in order to ensure the consistency of the models expertise and substantial effort. To assist in this en- created, while FOL languages may need to be used deavour, various organisational patterns, essentially to define their semantics. Other factors also need to representing reusable organisational reference mod- be taken into account when creating language exten- els, (Eriksson and Penker, 1999; Keidel, 1999) have sions, such as user acceptance and training in the ex- been developed. tended language. Typically, the business organisation view may be In the case of IDEF, consistency between the mod- obtained by mapping the resources (the who) on the els produced using its various languages has to be pro- activities of the business (the what) This view may vided by the modelling tool or the user . UML may be even be considered a specialisation of the resources used for business modelling as-is, with the standard view (where only resources that can do things are extensions, or involving proprietary constructs (such represented).The organization model aims to show re- as described in (Eriksson and Penker, 1999)). UML- source allocation, reporting methods and task assign- provided extensions may reach their limits when ments. modelling a complex business, while dedicated exten- Thus, business organisation may be modelled by sions bring about the necessity of glossaries, rigorous using UML class / object diagrams, or IDEF1X and metamodel control and FOL languages for semantics IDEF4 static diagrams, where for example classes (or definition. entities) are stereotyped to (or named as) organiza- Using the same set of languages to model the soft- tional units. IDEF12 (as shown in Table 1) is a mem- ware system and the business it supports is attractive ber of IDEF family specialised for organisational de- for two reasons. Firstly, if an accurate business model sign23; as for the UML, generic or specialised exten- can be used to derive the requirements for its infor- sions may be used to enhance organisational models. mation system (Marshall, 1999), then these require- A relational patterns repository may be modelled us- ments are likely to closely reflect the actual needs of ing e.g. IDEF1X, while a knowledge base containing the business. Secondly, if the same set of tools is used facts and rules (representing patterns) may be mod- in modelling the information system and the business, elled using UML class diagrams. then consistency may be easier to enforce across the Other business organization aspects such as or- models, and users’ training can be effectively focused ganizational behaviour, or the structure of decision on the set of tools which is actually used. centres24 may be modelled by representing organi- zational units in the Behaviour view, or the Activity view respectively. REFERENCES
5 CONCLUSIONS Arnesen, K. and Krogstie, J. (2002). Comparing Languages for Enterprise Modeling using a Language Quality This paper has performed an ontology-oriented anal- Framework. Norwegian University of Science and ysis of the IDEF and UML sets of languages for the Technology, Norway. 25 purpose of business modelling . Booch, G. (1991). Object-Oriented Design With Applica- The expressive power of languages greatly depends tions. The Benjamin/Cummings Publishing Company, on the theoretical models underlying their compo- Redwood City, CA. nents. Some such models are limited 26 in their ex- Bruce, T. (1992). Designing Quality Databases with pressive power by their focus on a particular aspect of IDEF1X Information models. Dorset House. the Universe of Discourse. Chen, P. (1999). The entity-relationship model - towards a Extending a language with constructs and rules unified view of data. ACM Transactions on Database suitable for specific modelling areas is likely to aug- Systems, 1:9–36. ment its expressive power. However, such extensions Cho, H. (2000). IDEF Overview. Manufacturing Systems must be properly documented, to ensure an unam- Integration Lab, Department of Industrial Engineer- biguous meaning to the end user. A metamodel of ing, Pohang University of Science and Technology. Codd, E. (1970). A relational model for large shared data 23the future of IDEF12 is not clearly defined as yet banks. Communications of the ACM, 13:397–434. 24 organizational units seen from a decisional perspective Cranefield, S. and Purvis, M. (1999). Uml as an ontology 25(Noran, 1999) holds a case study based on this analysis modeling language. In Proc. of the Workshop on In- 26such ’limitation’ may in fact help avoid unnecessary telligent Information Integration, 16th Int. Joint Con- model complexity. ference on AI.
681 ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
Doumeingts, G., Vallespir, B., and Chen, D. (1998). GRAI NIST (1993b). Integration definition for information mod- grid decisional modelling. In Bernus, P., Mertins, K., elling (IDEF1X). Technical report, Computer Systems and Schmidt, G., editors, Handbook on Architectures Laboratory, National Inst of Stds and Technology. of Information Systems, pages 313–339. Springer, Noran, O. (1999). Business modelling: UML vs. IDEF. Heidelberg. Technical report, School of Computers and Informa- Eriksson, H.-E. and Penker, M. (1999). Business Modelling tion Technology, Griffith University, Brisbane, Aus- with UML. John Wiley & Sons, New York. tralia. Available at http://www.cit.gu.edu.au/˜noran. Ettlinger, B. (1999). IDEF1X vs. UML: A comparative OMG (1999a). Object Constraint Language Specification, analysis. Technical report, Information Technology version 1.3. Framingham, MA. Division, N.Y. Power Authority, White Plains, NY. OMG (1999b). UML Semantics v1.3. Framingham, MA. Fowler, M. and Scott, K. (2000). UML Distilled. Addison- Ross, D. (1987). Structured analysis (sa): A language for Wesley, Reading, MA. communicating ideas. IEEE Transactions on Software Genesereth, M. and Fikes, R. (1992). Knowledge inter- Engineering, 3:16–34. change format version 3.0 - reference manual. Report Rumbaugh, J, ., Jacobson, I., and Booch, G. (1999). Logic-92-1, Logic Group, Stanford University, CA. The Unified Modelling Language Reference Manual. Gruber, T. (1993). A translation approach to portable on- Addison-Wesley, Reading, MA. Knowledge Acquisition, 2 tologies. , 2:199–220. Rumbaugh, J., Blaha, M., Premerlani, F., Eddy, F., and Harel, D. (1987). Statecharts: A visual formalism for com- Lorensen, W. (1991). Object-Oriented Modeling and plex systems. Science of Computer Programming, 8. Design. Prentice-Hall, Englewood-Cliffs, NJ. Hay, D. (1995). A comparison of data modelling tech- Schreiber, G. (1999). Knowledge Engineering and Manage- niques. The Database Newsletter, 23. ment. MIT Press. IEEE (1998). Standard for function modelling language - Shlaer, S. and Mellor, S. (1988). Object-Oriented Systems Syntax and semantics for IDEF0, IEEE 1320.1:1998. Analysis: Modeling The Real World in Data. Prentice- ISO/TC184/SC5/WG1 (2000). ISO/IS 15704: Industrial Hall, Englewood-Cliffs, NJ. automation systems - Requirements for enterprise- Si-Alhir, S. (1998). UML in a Nutshell. O’Reilly, Se- reference architectures and methodologies. ISO/IS. bastopol, CA. Jacobson, I. (1994). Object-Oriented Software Engineer- Sowa, J. (1998). Conceptual graphs. In Bernus, P., ing: A Use Case Driven Approach. Addison-Wesley, Mertins, K., and Schmidt, G., editors, Handbook on Reading, MA. Architectures of Information Systems, pages 287–311. Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Uni- Springer, Heidelberg. fied Software Development Process. Addison-Wesley, Warmer, J. and Kleppe, A. (1998). The Object Constraint Reading, MA. Language: Precise Modelling with UML. Addison- Keidel, R. (1999). Seeing Organisational Patterns. Berrett- Wesley, Reading, MA. Koehler Publishers, Inc, San Francisco, CA. Larson, M. (1998). Meaning-Based Translation: A Guide to Cross-Language Equivalence. University Press of America, Inc. Marshall, C. (1999). Enterprise Modelling with UML - De- signing Successful Software Through Business Analy- sis. Addison-Wesley, Reading, MA. Mayer, R., Benjamin, P., Menzel, C., Fillion, F., deWitte, P., Futrell, M., and Lingineni, M. (1994). IDEF5 ontol- ogy capture method report. Technical report, Wright- Patterson AFB, Wright-Patterson AFB, OH. Mayer, R., Keen, A., Browne, D., Harrington, S., Marshall, C., Painter, M., Schafrik, F., Huang, J., Wells, M., and Hisesh, H. (1995). IDEF4 object-oriented design method report. Technical report, Wright-Patterson AFB, Wright-Patterson AFB, OH. Mayer, R., Menzel, C., Painter, M., deWitte, P., Blinn, T., and Benjamin, P. (1993). IDEF3 process descrip- tion capture method report. Technical report, Wright- Patterson AFB, Wright-Patterson AFB, OH. Menzel, C. and Mayer, R. (1998). The IDEF family of languages. In Bernus, P., Mertins, K., and Schmidt, G., editors, Handbook on Architectures of Information Systems, pages 209–241. Springer, Heidelberg. NIST (1993a). Integration definition for function modelling (IDEF0). Technical report, Computer Systems Labo- ratory, National Institute of Stds and Technology.
682