|
 |
|
|
[Inspired] [Prod&Svcs] [People] [Associates] [Contact] [Philosophy] [Reference] [Clients] |
|
|
|||||||||
|
Extending UML for Enterprise and Business Process Modeling Graham McLeod, University of Cape Town, Pvt Bag Rondebosch, 7700, South Africa mcleod@iafrica.com, tel +27 21 650 4028, cell +27 82 578 1834
Abstract The Unified Modeling Language (UML) is proposed as an industry standard for Object Modeling. It has a rich base and is very competent in system level modeling. It is lacking, however, in constructs to support enterprise and business process modeling: areas which are vital for a competent technique, especially given the trend for organizations to use object technology to support enterprise engineering. Using enterprise modeling and extended value chain modeling approaches piloted at the Geselschaft fur Matematik und Datenverwerkung (GMD) in Germany and others from David Taylor at Enterprise Engines, the author previously extended the Martin/Odell OOA/D methods to incorporate powerful stakeholder, enterprise, value chain and business modeling techniques. These have proven very effective during the past three years in supporting sustainable business engineering. This paper applies similar techniques to the UML to extend it to cope with enterprise and business process modeling. Introduction All who work in or with industry are aware of the increasing pace of change and the global competition which challenges organizations to become more efficient and nimble in their responses. Taylor identifies three key areas where organizations must excel to remain viable and competitive in the face of these pressures: 1) they must do things faster 2) they must do them better 3) they must do them cheaper. He points out that this implies that we need business processes which are more efficient, produce higher quality products and services and consume less time and resources. Similar trends are noted by many other authors, including [Jacobson, 1994], [Hammer, 1990]. In our observation within corporate consulting clients, these requirements for business process modification now affect up to 70% of systems projects. This implies that any competent systems analysis and design method should provide constructs to facilitate rethinking of business processes and expressing modified processes in a form which can flow smoothly into later stages of a systems development lifecycle.
The Unified Modeling Language (UML) [Rational, 1997], produced by the collaborators (Booch, Jacobson and Rumbaugh) at Rational corporation is emerging as an industry standard for the expression of system level models using object oriented techniques. It is an amalgam of earlier work by the three authors, but also includes innovations from other contributors. UML was approved (late 1997) by the Object Management Group (OMG) as a standard. UML specifies a notation for analysis and design models. It does not prescribe a method or process for how these should be used. UML has powerful techniques for expressing many facets during the analysis and design stages of a project including: ŸDomain knowledge required to support the application (Static Structure/Class Diagram) ŸInteraction of a user with a system to achieve a single goal (Use Cases) ŸSequence of collaboration between objects (Sequence Diagram) ŸResponsibilities for dynamic behaviour within the system (Collaboration Diagram) ŸChanges in state of an object over time (State Diagram) UML latterly also includes an Activity Diagram. This is derived from the work of Odell [Martin & Odell, 1993] where the equivalent is referred to as an event diagram. The notation differs, but the concepts are essentially similar. This is capable of showing processes in a powerful way, including parallel operations, triggering of operations by state changes affecting objects (events) and synchronization. UML recommends that this be used in specifying the implementation of a responsibility within a class, or the detailed implementation of an operation within a use case. There are also component and deployment diagrams which express specific implementation choices.
UML is thus richly endowed with techniques to express the results of systems level modeling and design choices. There is little, however, to express high level views of the organization or processes and to assist a business engineer in choosing among competing alternative processes. [Jacobson, Ericsson and Jacobson, 94] have described the use of use cases in support of business process engineering, but the approach still lacks the semantics to facilitate the above fully. The next section looks at what we require to facilitate such support.
Work by [Frank, 1994] and others at the Geselschaft fur Matematik und Datenverwerkung (GMD) on the "virtual government" project incorporated many state of the art business engineering and enterprise analysis techniques. Specifically, stakeholder models and value chain analysis were adapted to allow powerful business modeling, with extended capabilities to assist the analyst in understanding the organization, its interaction with the environment and the issues and alternatives in choosing between competing methods of achieving the business of the organization. The concepts were incorporated in a methodology (Memo) and implemented in a set of advanced tools, developed in Smalltalk on Sun workstations. These can guide us in listing the requirements for a competent approach supporting business engineering.
Additional semantics which we require to support competent business engineering include: ŸAbility to identify the stakeholders in the environment and how they interact with the organization ŸAbility to identify external stimuli from the environment which trigger business processes to commence and the source of these, which is usually an actor, but could also be another process ŸCompetence in expressing parallel and asynchronous activities ŸIdentifying activities which are performed manually, with automated support, or in a fully automated way ŸVolume of transactions (or stimuli per unit time) ŸResponsibilities of organizational units for activities within the process ŸDurations of operations ŸResources and costs of operations ŸProbabilities that various alternative paths are chosen
Previous Work with Odell notation The author previously incorporated the ideas from GMD, Jacobson and [Taylor, 94] into a method based upon the Martin/Odell OOA/D method [McLeod, 92-97]. This extended the method into business engineering with the use of stakeholder models, value chains and business process models. The latter were evolved into standard Odell style event models, providing a seamless transition from the business engineering view, to a systems view, and finally, a design view. At the design level, a multi-tiered architecture mapping based upon Model-View-Controller concepts (but extended for integration with legacy environments and competent for client server and internet environments) ensured a further smooth transition to implementation level. In teaching, consulting and project work, this has proven to a very successful approach over a period of some three years.
The approach supports the following analyses: ŸBuilding a current and desired view of the business process for comparison purposes ŸDistinguishing between manual, computer supported and automated activities ŸDetermining the relative duration and costs of process alternatives ŸMapping operations within the processes to organizational or geographic locations ŸElimination of non-value adding activities by abstraction of essential effects of operations and recasting these as value adding activities which are performed efficiently ŸAnalysis of parallel activities and asynchronous activities with proper respect for dependencies and preconditions The approach uses a simple notation and has proven easy to use and effective in Joint Application Development (JAD) session with users. Minimal introductory education is required (usually about half an hour) for participants to feel comfortable with the technique. Some devices and notations are introduced and explained as needed. One limitation has been the lack of a suitable CASE tool to capture the models. These have to date been captured in a graphics package with no knowledge of the semantics, and later transferred into more formal tools, including Aris™. In other environments, we have first translated the business models into event models and then captured these in tools such as Paradigm Plus™ and Object Team™. With the prevalence of the UML and its increased support in industry and widespread support in tools, the time is right to attempt a UML version of the approach. This paper focusses on how to extend the UML to support business engineering as described with minimal impact to the existing UML definition. Extending UML The first consideration in extending the UML is to ensure that we are not duplicating functionality which already exists. Secondly, we must chose devices present within UML which most closely resemble the necessary constructs to express the required business process models. Finally, we must ensure that our extensions are sensible, introduce minimal distortions to the UML, are consistent with the overall philosophy and integrate well with the other techniques, particularly refinement into later models.
Jacobson et al have demonstrated that use case diagrams can be used to express similar knowledge to that in a stakeholder model. Within such a picture, we can identify various discrete interactions that external parties may have with the organization. Using use case notation, these can be shown as elipses within the boundary of the organization. It would be possible to decompose any of these bubbles into a set of equivalent processes using the use case technique. While useful, this does not support many of our requirements as previously detailed. For this reason, we chose to use the use case model only at the highest level and then to use other devices for further analysis work.
We examined existing models within UML to determine the most appropriate vehicle for expressing our business process/value chain models. The alternatives included Sequence Diagrams, Collaboration Diagrams, State Diagrams and Activity Diagrams. These are discussed below. We rejected: ŸSequence diagrams, since they are not easy to use with end users in JAD sessions, and do not easily show parallel and asynchronous activity. They also are optimised for showing message sequences between objects, which is a much more detailed "design" view than we often have during business modeling ŸCollaboration diagrams, for some of the same reasons as sequence diagrams. They are best for expressing object interaction at a design level after responsibilities have been chosen for classes ŸState diagrams, since they show the changes in state experienced by a single object type. Business processes inherently affect the state of many different types of objects We chose Activity diagrams for the following reasons: ŸThey easily give a sense of the flow and dependencies of steps in the business process ŸThey can show parallel and asynchronous activity easily, as well as synchronization where required ŸThey can support the definition of where operations take place organizationally or geographically through judicious use of the "swim lane" concept ŸThey easily represent processes that require or generate state changes across multiple domain objects ŸThey are closest to the event model technique which we extended previously in the Odell approach We are aware that we are deviating from the UML advice to use Activity diagrams "for internal design", but we feel that we have valid reasons for so doing. There is as much a requirement to design business processes and to chose amongst alternatives as there is to design internal processes. Extending Activity diagrams to support business modeling We make use of the UML Stereotype mechanism which allows adding notation to the model. Stereotypes may be expressed as a text within guillemets, thus: <<text>> or as an icon. We use these mechanisms to show which activities within a diagram are performed manually, with computerised support (but still requiring human interaction) or in a fully automated fashion. In text form these are shown thus: <<manual>>, <<supported>> and <<automated>>. As icons, they may be shown thus:
The overall activity diagram has properties detailing the volume of this activity per unit time, the current experienced duration (best, average, worst case), the current cost per invocation and the desired target duration and cost. We add properties to the activities to express the following:
Where multiple triggers emerge from activities, we document the state for each path, and the probability that that path is followed. The latter is expressed as a fraction of 1, or as a percentage e.g. .5 or 50%. All of the above extensions are optional. We may use the model to simply express the process and the flow, or add as much detail as desired or available. Obviously, the more detail we add, the richer the understanding of the business process. A fully attributed model can allow sophisticated analyses of competing business process alternatives including:
An Example To illustrate the approach, we will develop models for an insurance application process. The current business process is initiated by an agent or broker with a client; proceeds with submission of the application via a branch office, and concludes with the processing of the application by the head office, which responds with an acceptance or declination letter. Several simplifying assumptions have been made:
Figure 1
Selected properties for the overall and sub-activities are as follows: (NOTE: for simplicity and brevity, we will work with averages in all cases other than for duration) Overall Process By performing the recommended analyses on the current process, we can determine the following:
After business engineering, we may have a very different process, for example: Figure 2
Overall Process Here, we have eliminated the branch office and equipped the representatives with notebook computers, which allow direct capture and completeness checking of applications and then transmit these via cellular telephone link to head office, eliminating the daily polling run. Doctors reports have been streamlined by accepting them via the Internet, with a paper version following later as a confirmation. Contract issuing, advice letters and bank checking have been fully automated. Credit commission has been changed from a daily batch run to a real-time update. These changes yield the following improvements:
We must be careful to balance the system, though, since the arrival rate of transactions at internal services may now increase as a result of removing external "buffering" and delays. There are also many social, political and ethical issues to consider in real-world scenarios. Our purpose here has been merely to demonstrate the efficacy of the proposed technique in identifying areas for analysis and expressing alternatives in such a way as to allow informed decision making. The models produced in this way can be easily and seamlessly expanded to design models. We simply eliminate manual activities and expand computer supported or fully automated activities. For computer supported activities, human-computer interfaces can be prototyped and linked to the models. We can annotate the models to indicate which objects reach which state as a result of each operation. We can also change the swim lanes to reflect class, geographical or platform partitioning of the responsibilities, if required. Conclusion Our earlier approach has proven useful in many organizational contexts. With the wide acceptance of UML and the growing support for the notation in CASE environments, we hope that the extension of UML into business process and enterprise modeling will find support. This, coupled with capable tools and good training will equip analysts and business people to examine business operations in rich and multidimensional ways. Ultimately this can assist organizations in becoming more efficient and effective in better serving their customers and other stakeholders. We hope to further extend the work into providing quality measures for the outputs of business processes and the reengineering of work for better results in terms of products and services in addition to better control of costs, duration and resource usage. We would be interested to correspond with (and perhaps collaborate with) other parties working in similar areas. Bibliography Frank, Ulrich, 1994, in Ege, R; Singh, M; Meyer, B (Hg): Technology of Object Oriented Languages and Systems, Prentice Hall pp 367-380 Hammer, 1990, Re-engineering work: Don't Automate, Obliterate, Harvard Business Review, July-Aug pp 104-112 Jacobson, Ivar; Erissson, Maria & Jacobson, Agneta, 1994, The Object Advantage: Business Process Reengineering with Object Technology, Addison Wesley Kerzner, Harold, 1992, Project Management: A systems approach to planning, scheduling and controlling, Van Nostrand Reinhold Martin, James, 1993, Principles of Object Oriented Analysis and Design, Prentice Hall, Englewood Cliffs, NJ McLeod, Graham, 1992-1997, Advanced Systems Engineering with Objects, Inspired, Box 384 Howard Place 7450 South Africa Rational Corporation, 1997, UML Notation Guide, version 1.0, Rational Corporation Taylor, David, 1994, Business Engineering with Objects, John Wiley
|
