ebook img

Business Modelling: UML vs. IDEF PDF

53 Pages·2003·3.58 MB·English
Save to my drive
Quick download
Download
Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.

Preview Business Modelling: UML vs. IDEF

Griffith University School of Computing and Information Technology Domain: Advanced Object Oriented Concepts Business Modelling: UML vs. IDEF available electronically at: http://www.cit.gu.edu.au/~noran © Ovidiu S. Noran Table of Contents. 1 Introduction....................................................................................................1 1.1 The objectives of this paper..............................................................................1 1.2 Motivation.........................................................................................................1 1.3 Some Important Terms.....................................................................................2 1.3.1 Models...............................................................................................................2 1.3.2 Business Process Models..................................................................................2 1.3.3 Information Systems Support............................................................................3 1.3.3.1 The Business Model as a Base for Information Systems..........................3 1.3.3.2 'Legacy' Systems.......................................................................................4 1.3.4 Business Improvement vs. Innovation...............................................................4 1.4 Business Concepts...........................................................................................4 1.4.1 Business Architecture........................................................................................5 1.4.2 Business Rules..................................................................................................5 1.4.2.1 Derivations.................................................................................................5 1.4.2.2 Constraints.................................................................................................5 1.4.2.3 Existence...................................................................................................5 1.4.3 Business Views..................................................................................................5 1.4.3.1 Vision.........................................................................................................6 1.4.3.2 Process......................................................................................................6 1.4.3.3 Structure....................................................................................................6 1.4.3.4 Behaviour...................................................................................................6 1.5 Software Architecture vs. Business Architecture..............................................6 1.5.1 Software Architecture........................................................................................7 1.5.2 Software Architectural Views.............................................................................7 1.5.3 From Business To Software Architecture..........................................................7 2 The Unified Modelling Language (UML)........................................................9 2.1 Basics..............................................................................................................9 2.2 UML Diagrams.................................................................................................9 2.2.1 Class Diagram...................................................................................................9 2.2.2 Object Diagram................................................................................................10 2.2.3 Statechart Diagram..........................................................................................10 2.2.4 Activity Diagram...............................................................................................10 2.2.5 Sequence Diagram..........................................................................................11 2.2.6 Collaboration Diagram.....................................................................................11 2.2.7 Use Case Diagram..........................................................................................11 2.2.8 Component Diagram........................................................................................11 2.2.9 Deployment Diagram.......................................................................................11 2.3 Extension Mechanisms..................................................................................12 2.3.1 Stereotypes......................................................................................................12 2.3.2 Tagged Values.................................................................................................12 2.3.3 Constraints.......................................................................................................12 2.4 Business Modelling with UML.........................................................................12 2.4.1 Components of UML used in Business Modelling...........................................13 2.4.2 Business Rules................................................................................................13 2.4.3 The Eriksson-Penker Business Extensions.....................................................13 2.4.4 Business Patterns............................................................................................14 3 The IDEF Family of Languages...................................................................16 i 3.1 Basics............................................................................................................16 3.2 IDEF0.............................................................................................................16 3.3 IDEF1 / IDEF1x..............................................................................................17 3.3.1 IDEF1...............................................................................................................17 3.3.2 IDEF1x.............................................................................................................18 3.4 IDEF2.............................................................................................................19 3.5 IDEF3.............................................................................................................19 3.5.1 Process Flow Description................................................................................20 3.5.2 Object State Transition Description.................................................................20 3.6 IDEF4.............................................................................................................21 3.7 IDEF5.............................................................................................................22 3.8 IDEF6 to IDEF14............................................................................................22 3.9 Conclusion to IDEF methodology...................................................................23 3.10 A Simple Analogy.....................................................................................23 4 A Simple Business Example........................................................................24 4.1 Description.....................................................................................................24 4.2 The UML model..............................................................................................25 4.2.1 The Goals........................................................................................................25 4.2.1.1 Goal Model..............................................................................................25 4.2.1.2 Conceptual Model....................................................................................26 4.2.2 Business Processes........................................................................................27 4.2.3 Resources and Organization...........................................................................28 4.2.4 Organisational Model.......................................................................................30 4.2.5 Interaction Analysis..........................................................................................31 4.2.6 Support Systems.............................................................................................32 4.2.7 Functional / Information Requirements............................................................33 4.3 The IDEF model.............................................................................................35 4.3.1 IDEF0...............................................................................................................35 4.3.1.1 The Level 0 Diagram (A-0)......................................................................35 4.3.1.2 The Level 1 Diagram...............................................................................35 4.3.1.3 Level 2 Diagram.......................................................................................37 4.3.1.4 The Level 3 Diagram...............................................................................39 4.3.2 The IDEF1 and IDEF1x Models.......................................................................41 4.3.2.1 IDEF1.......................................................................................................41 4.3.2.2 IDEF1x.....................................................................................................42 4.3.3 The IDEF3 Model.............................................................................................43 4.3.3.1 The Process Flow Diagram.....................................................................43 4.3.3.2 The Object State Transition Diagram......................................................44 A. The IDEF4 Model...................................................................................................44 4.3.3.3 The Static Component.............................................................................45 4.3.3.4 The Behavioural Model............................................................................46 4.3.3.5 The Dynamic Model.................................................................................46 4.4 A Comparison................................................................................................47 5 Conclusions.................................................................................................49 6 References..................................................................................................50 ii Business Modelling: UML vs. IDEF Introduction 1 Introduction. 1.1 The objectives of this paper. Objectives of this paper are: • to provide a short primer for the Unified Modelling Language (UML) and the Integration DEFinition (IDEF) family of languages and identify the potential similarities and connections IDEF - UML; • investigate the suitability of the UML (and extensions) for business modelling; • attempt to model a business process using IDEF and UML and document any difficulties encountered in the mapping; It is first necessary to introduce some basic concepts about UML and IDEF, so that the reader may understand the more advanced issues in the subsequent chapters. We can then move on to investigate the business modelling extensions provided for the UML and some recent achievements in using the UML for modelling systems other that software. A short review of the IDEF family of languages will follow, with emphasis on the IDEF languages relevant to this particular task. We will then take a simple set of business processes and attempt to model them using both UML extensions and the IDEF languages. This may be equivalent, at some level, to a mapping of corresponding UML elements to the applicable IDEF languages. Finally, we will draw some conclusions regarding the work accomplished and highlight trends in the development of UML and IDEF. 1.2 Motivation. This paper attempts to approach the domain of business modelling. The process of business modelling is employed in order to create an abstraction of an otherwise complex business. This will enable business stakeholders (owners, customers, management, etc) to gain a better understanding of the business functions and also promote business improvements and/or innovation. Further elements on business modelling are provided in the Conclusion What is the connection between business and software modelling ? In order to survive in today's competitive world, businesses have to continuously review their products, services, and relations with the environment (suppliers, competitors, clients, laws, etc). To assess the quality of their products and effectiveness of their services, businesses rely on the information systems. Initially only a support component, the information systems have now become an integral part of the businesses. The business itself must define the requirements for the information system. Unfortunately, very often the software system does not properly support the business. The causes may be: lack of accurate requirements definition, deficiencies in proper business understanding by the software design team, or even the nature of the business (which may change so often that the software simply cannot follow). 1 Business Modelling: UML vs. IDEF Introduction Software modelling is an accepted way of designing software systems. By applying the modelling approach to the business itself, accurate requirements may be achieved for the subsequent software design activity. This concept was taken even further by the idea of using the same modelling language for both software and business modelling. One example of a language that could model both the business and the software system belonging to the business is the Unified Modelling Language, the UML. Many developers are already familiar with UML from modelling software systems. Using one single language across the business and software modelling would promote consistency and communication among modellers and also take advantage of a whole range of modelling tools that support the UML. Several extensions and special constraints are needed in order to use the UML for business modelling. They will be described in the following chapters, as needed. The IDEF family of languages is strongly linked to the Integrated Computer Aided Manufacturing (ICAM), which aimed to use the then emerging (1970's) computer technology in order to improve the manufacturing productivity. These languages cover a large area (IDEF0 up to IDEF14), from function modelling to information, simulation, object-oriented analysis and design and knowledge acquisition. Intuitively there are similarities between the UML and the IDEF languages. As a matter of fact, several UML 'business customisations' are based upon principles borrowed from the IDEF family or used by both modelling methods. By spelling out the similarities and differences and attempting to use both alternatives (i.e. UML and IDEF) on a business process, this paper attempts to further clarify the current achievements in business modelling and to hint towards its future. 1.3 Some Important Terms. 1.3.1 Models. A model is basically a simplified abstract view of the complex reality. It may focus on particular views, enforcing the 'divide and conquer' principle for a compound problem. In the business domain, a model represents a concept on how the business functions and therefore will inevitably include goals, visions, efficiency and other important factors. Business stakeholders may have slightly different views of the business. Therefore, a commonly agreed upon business model would enable all stakeholders to work towards a common solution and understand each other's concepts. A business model may of course (and should) serve as a basis for the information systems model, ensuring consistency and accurate requirements being passed on to the software design. By using a model, developers may improve their understanding of the business and awareness of the business enhancement opportunities. Last but not least, a model must have a purpose. For a business, this may be understanding its structure, improving it or re-engineering it. The shape and detail of the model will largely depend on the model objective(s). Models may consist of views, diagrams (for structure or behaviour), objects and processes (functions in the business). 1.3.2 Business Process Models. A few stages may be identified in the process of business modelling. • business goals are set, resources allocated by the owner; 2 Business Modelling: UML vs. IDEF Introduction • the business structure and its processes are created by the business modeller; • according to the previous step, the system developer designs and develops the suitable information systems to support the business. Organization charts have been the traditional way to document a business. Business models enhance this method by also providing business processes, resources, goals, execution rules and other additional information. A business model may also express the future view of the business. In this case, there is always a degree of uncertainty as to what may happen during the model realisation. Even in this case, the model will provide benefits. Some of them are: • clearly specify people's roles and tasks in the organization; • provide accurate requirements for a subsequent information system supporting the business; • model level benchmarking - i.e. trying new / different business concepts at the model level and study the results. 1.3.3 Information Systems Support. It is nowadays recognised that the effective use of computer systems will benefit almost any business. Computer systems are able to handle vast amount of information accurately and make better use of the existing resources. The new possibilities offered by the Internet for example can also be taken advantage of via a properly designed and implemented information system. 1.3.3.1 The Business Model as a Base for Information Systems. As previously mentioned, the current information systems have various problems, such as unreliability, ineffective business support, and complexity. Writing the software for the computer systems is still a specialised job; therefore the requirements for the information systems are often written by the same people that make design decisions. The consequence is a technology-driven rather than a business-driven information system (i.e. concentrating on issues like the user interface or specific implementation techniques, rather than on what the business really requires from the system). 3 Business Modelling: UML vs. IDEF Introduction Fig. 0. 1 Business model - information system requirements relation (Ref.6, p.10) A business model may hold the basis for all the information systems within a business (refer Fig. 0. 1). There are several benefits in basing the information system requirements on the business model, although not all of the objects or processes within the business may be directly mapped onto the information system. Object oriented analysis and design may assist the use of the business model concepts and structures on the information system. If more information systems are to support the business, there is also a high probability that some modules may be reused between the various software systems. 1.3.3.2 'Legacy' Systems. Depending on the business size and age, there may exist older information systems already implemented, which need to be taken into consideration as the object of improvement or removal. There are several approaches towards modelling such systems. They may be modelled as a single entity, or be reverse engineered in order to obtain a more detailed model of the existing system. 1.3.4 Business Improvement vs. Innovation. One of the main declared purposes of a business model is to identify areas of improvement and better understanding of the business. There are two main approaches towards the changing of a business: • the business process improvement (BPI) • the business innovation (BI), with its 'radical' form, the business process re- engineering (BPR). The main difference between the two approaches has to do with the pace, depth of change and the implications of these concepts. The BPI approach is incremental change based on a business model. The changes are applied in small continuous steps so that the (possible negative) impact on the business is minimised. The BI approach is more radical - the business model and processes are considerably changed - and may bring substantial improvements but also implies a higher risk of failure. BPR - the process re-engineering - takes this approach even further, aiming to double / triple the business efficiency. By questioning every aspect of the existing business, BPR implies a high risk and task difficulty. BPR may encounter strong resistance from the human resources and even fail because of this reason (or others, such as inappropriate redesign of the business functions). Information systems are a key element in whatever business change approach is used, but have a special meaning in the context of BPR - where it can help reduce the risk of re-engineering failure. However, in order to properly support the improvement / innovation processes, the information system must reflect and sustain the envisaged business model, and not the current, obsolete model. Otherwise, the information system will be not an incentive for change but yet another impediment against it. 1.4 Business Concepts. This section will enable the reader to understand several fundamental business concepts. Some of these concepts have been commonly used in software systems design, but they may also be applied to business modelling, of course recognising the applicable particularities and differences. 4 Business Modelling: UML vs. IDEF Introduction 1.4.1 Business Architecture. A business architecture may be loosely defined as a set of elements and the well- defined relations between them that form a whole defined by its functionality (Adapted from Ref.2). A well-documented business architecture which includes the situations, structures and behaviour represents a valuable business strategic asset. It will enable and assist the identification of new business opportunities / areas of improvement and baseline the information systems that support the business. A good architecture must represent the business as accurately as possible. There may be different levels of abstraction for architectures, depending on the purpose, the processes and the structure modelled. A good architecture must be adaptable and also be accepted as a common view by both the business stakeholders and the workers. Last but not least, a good architecture must be easy to understand by its users and promote communication among them. The relation between business and software architectures is further described in Section V of this Chapter. 1.4.2 Business Rules. Business rules ensure that the business is run in accordance with external or internal restrictions and/or goals. Very often, the rules are regarded as facts, although there is a difference between a fact (which when asserted, represents knowledge) and a rule (which may be used to infer new knowledge, e.g. in expert systems). Rules may be defined at all necessary levels, from e.g. high strategic level down to detailed requirements on an information system. Rules represent a common area of business and software modelling because software design may use a large proportion of the information contained in business rules. Business rules may be structured in categories according to various criteria. Current developments in business modelling (Ref.6) identify four main categories of rules: 1.4.2.1 Derivations. Derivation rules define how knowledge or information in one form may be transformed into another form. Derivation rules may be computational (calculate a value) or inference rules (if-then form). 1.4.2.2 Constraints. Constraint rules are an important mechanism in integrity preservation, in processes such as object creation and relationship modification. Constraint rules may be of the structural (static), operational (dynamic) and stimulus/response (event based) types. 1.4.2.3 Existence. Existence rules act when a specific object exists. They may be used in pre- and post conditions for object creation / deletion, etc. 1.4.3 Business Views. Businesses are complex systems. The concept of views may be employed in order to tackle this complexity. The development of the views (which show particular aspects of the business) should be accomplished not in isolation, one by one, but rather incrementally for the whole set of views. As more information about the business is 5 Business Modelling: UML vs. IDEF Introduction collected, the views evolve. Recent developments in business modelling (Ref.6) propose a set of four business views, as follows: 1.4.3.1 Vision. The vision depicts the goal structure for the company and the obstacles that have to be overcome in order to reach the goals. This view contains some vital concepts for the business, such as: the mission, objectives (specific, 'schedulable' goals), strengths, weaknesses, threats to the business (e.g. competitors), critical factors for success, strategies, core competencies, roles, key processes, etc. The business vision view also includes identifying future trends from customer / competitor market analysis. The vision view may employ several analysis methods, such as strategy definition, conceptual modelling (model level) and goal / problem modelling (user model level). 1.4.3.2 Process. The Process view relies on the goals defined in the Vision view in order to describe the processes needed to achieve a specific objective. This view has to model the core processes of the company (critical for the existence of the business). The processes act as models (classes), while a process execution is a process instance (object). Process modelling may be achieved using various approaches. This paper will only describe the UML extensions and the IDEF1-4 approaches, which imply concepts such as goal, input, output, supply, control. 1.4.3.3 Structure. The structure view represents the resources, products/services, and the information in the business. This type of view is also used by reference architectures (Ref.11). Information modelling has a special meaning - information is a special type of resource that may sometimes govern the business. Therefore it is modelled separately and it actually represents the base for the information system storage definition (refer IDEF1 vs. IDEF1x later on in this document). Organization is a case of resource modelling where the resources are allocated to organisational units. A process may stretch over more organisational units. The organization model aims to show the resource allocation, reporting methods, task assignments and management. The trend is to move away from hierarchical, to flexible and dynamic (project-based) organization. 1.4.3.4 Behaviour. The Process view describes the behaviour of the resource objects. The Behaviour view goes into further detail by analysing possible states, behaviours in each state and transitions between states. The state modelling is based on concepts such as states, events (causes of a state transition) and actions. The interaction modelling addresses the relations between processes and resources. 1.5 Software Architecture vs. Business Architecture. This section aims to emphasize the connection and dependencies between the business architecture and the supporting software architecture. As previously stated, there are several incentives towards constructing a robust business architecture. One 6 Business Modelling: UML vs. IDEF Introduction of the advantages listed was the capability to derive accurate software requirements from the business model. Modern software modelling and architecture concepts as such have appeared before business modelling. Software modelling has already been used for some time in order to construct good software architecture. As a direct consequence, there is a pool of experienced software modellers and software modelling tools available. One of the purposes of this paper is to investigate how the existing software modelling tools and skills may be used to model businesses, and also to assess the suitability of the current attempts towards business modelling. The main concept is: Use software development tools and human skills to develop the business model. Subsequently, use this model to derive requirements and accurately construct the supporting information system architecture. 1.5.1 Software Architecture. The definition of business architecture (Section IV, A) may be also applied to software architecture, the only difference being the nature of the system (software in this case). Aspects of a software architecture are as follows: • functional aspect: refers to the functions required and the system capability to perform these functions. The functional requirements should be derived from the business model; • non-functional aspect: does not refer to a specific function, but it affects the whole system (e.g. security, performance); • development aspect: more specific, refers to reusability, cost, modifiability, etc. 1.5.2 Software Architectural Views. Software architectural views aim to represent a particular aspect of the system in order to reduce overall complexity. The software architectural views are: • use case: the view of the user. It is the ultimate goal of the software system and therefore may drive the development of the other views; • logical: this view shows classes, packages, states, behaviour and collaboration; • deployment: described the system topology (physical nodes containing processes and components) • implementation: defines the code modules, both source and executables; • process: defined processes and threads, startup / shutdown of the system, etc. 1.5.3 From Business To Software Architecture. Translating the business model into a software model is not a straightforward process. Not all the classes and objects defined in a business architecture may be mapped directly to a software model (nor should they be mapped an a one-to-one basis). The business model may be used in the software development process in order to: • make a decision regarding the information system best suited for the business (new, standard, legacy); • define functional requirements: the set of use cases / functions the software system should supply to the business; • define non-functional requirements (affecting the whole system); 7

See more

The list of books you might like

Most books are stored in the elastic cloud where traffic is expensive. For this reason, we have a limit on daily download.