Systems, Views and Models of UML∗

Total Page:16

File Type:pdf, Size:1020Kb

Systems, Views and Models of UML∗ Systems, Views and Models of UML∗ Ruth Breu, Radu Grosu, Franz Huber, Bernhard Rumpe, Wolfgang Schwerin email: {breur,grosu,huberf,rumpe,schwerin} @informatik.tu-muenchen.de Technische Universit¨atM¨unchen Arcisstr. 21 D-80290 M¨unchen, Germany Abstract In this paper we show by using the example of UML, how a soft- ware engineering method can benefit from an integrative mathemat- ical foundation. The mathematical foundation is given by a mathe- matical system model. This model provides the basis both for inte- grating the various description techniques of UML and for implement- ing methodical support. After describing the basic concepts of the system model, we give a short overview of the UML description tech- niques. Then we show how they fit into the system model framework and sketch an approach to structure the UML development process such that it provides methodological guidance for developers. 1 Introduction – Why Formalization? “The nice thing about graphical description techniques is that everyone un- derstands them, the bad thing, however, is that everyone understands them in a different way.” This often heard quote captures a main property of mod- eling techniques using semi-formal, mostly graphical notations, beginning with the early structured modeling techniques and prevalent until today’s object-oriented methods. The diagrammatic notations used here seem easily comprehensible for everyone dealing with software development. Experience ∗ This paper originates from the SysLab project, which is supported by the DFG under the Leibnizprogramme and by Siemens-Nixdorf. [BGH+98b] R. Breu, R. Grosu, F. Huber, B. Rumpe, W. Schwerin. Systems, Views and Models of UML. In: The Unified Modeling Language, Technical Aspects and Applications. Martin Schader, Axel Korthaus (eds.) Physica Verlag, Heidelberg. 1998. www.se-rwth.de/publications shows, however, that, except from obvious properties, these notations do in fact bear a great number of possible divergent interpretations. To gain a deeper and more exact understanding of the notations used, the need for providing a stringent formal foundation for them has long been recognized and has lead to considerable advances in the recent past. Many of these efforts aim at providing a formal semantics for single notations. Considering the different aspects of a system, described by different notations, captured in a system development process, providing isolated semantics, possibly even using diffent models as a basis, does not seem to be adequate. The complete description of such a system is given only by the assembly of all different views. It is therefore desirable to have a common semantic basis for all no- tations used in a development method. This allows both to provide an exact interpretation for diagrams in a single notation and to inter-relate diagrams in different notations on a common basis. The SysLab method (Breu et al. (1997)b) builds upon such an integrated semantic framework, which we call the System Model. The foundations and the basic mathematical concepts of this system model will be intro- duced in Section 2. The SysLab method, just like the Unified Method, is a view-oriented, integrated, and object-oriented development method. Its description techniques are deliberately similar to those used in the UML. Thus it seems worthwile to apply SysLab’s system model to the UML in order to embed its description techniques into the system model’s mathe- matical framework. What can be gained by this effort is, quite obviously, a deeper understanding of the single notations and, as outlined above, the possibility to more tightly intergrate the UML description techniques on a sound mathematical basis. The benefits hereof can be enormous, especially for tool developers, resp. tool vendors, and methodologists. Tool developers are enabled to provide a much larger set of precise consistency conditions than currently possible by using just the UML Meta Model which basically represents only the abstract syntax of UML’s description techniques. Us- ing the semantic properties of diagrams produced in different stages of a development project and their inter-relationships, transformation tools can be provided, which tranform, either automatically or with a human devel- oper’s assistance, documents from one notation into another. On this ba- sis, methodological guidelines for software developers can be elaborated and eventually implemented in CASE tools. The rest of the paper is organized as follows. In Section 2 we present the basic concepts of the SysLab system model and in Section 3 we give a brief overview of the UML description techniques. We then outline methodolog- ical aspects in Section 4, where we define general properties of a software development method and show how a development process using UML de- scription techniques can be structured and supported by a tool. Finally, an outlook on further steps in formalization and tool support is given in Section 5. 2 Models of Systems In general, a system is a technical or sociological structure consisting of a group of elements combined to form a whole and to work, function or move interdependently and harmoniously. A system model represents certain aspects of systems in a certain way, using certain concepts, e.g. OO-concepts, such as classification, encapsulation etc. One way to formulate system models is to use mathematical techniques (e.g. sets, functions, relations, predicates). This leads to the notion of mathematical system models. In the following we first motivate the use of a system model and then describe the one on which the SysLab method is based and which is also appropriate for UML. 2.1 Motivation of the System Model In the introduction we have motivated, why a formalization of UML descrip- tion techniques is useful. We argued that a precise semantics is important not only for the developer, but also for tool vendors, methodologists (people that create the method) and method experts (people that use the method and know it in detail). We get the following requirements for a formalization: 1. A formalization must be complete, but as abstract and understandable as possible. 2. The formalization of a heterogeneous set of description techniques has to be integrated to allow the definition of relations between them. This does not mean that every syntactical statement must have a formal meaning. Annotations or descriptions in prose are always necessary for documentation, although they do not have a formal translation. They may however eventually be translated into formal descriptions or even into code in the course of a software development process. As soon as one uses description techniques with a fixed syntax and semantics, one no longer describes systems in general but models of systems. Using UML, for example, one models systems in terms of objects, classes etc. To manage the complexity of formalization, we introduce a layer between the syntactic description techniques and pure mathematics as shown in Figure ??. This intermediate layer is the mathematical system model. On this layer, various aspects of systems such as structure, behavior and interaction are formulated by mathematical techniques. We call the representation of a system, formulated solely in terms of the system model, a model of a sys- tem. Furtheron, the set of all models that can be described in terms of a certain system model is called the universe of this system model. Figure ?? illustrates the ideas that are explained below. Sequence diagrams Class descriptions class Account ; owner :: string; amount :: Int; open(o::string, a::Int); credit(a::Int, rec::Account); debit(a::Int, d::Account); endclass State diagrams Class diagrams System Mo del Mathematics Formal F oundation La yered formalization of description tec hniques FigureFigure 1: Layered formalization of description techniques tec hniques oer syn tactical elemen ts that allo w the sp ecication DescriptionDescription techniques offer syntactical elements that allow the specification certain views ie certain asp ects of systems One way to dene a se ofof certain views, i.e., certain aspects, of systems. One way to define a se- tics is to express the meaning of syn tax in terms of a system mo del manmantics is to express the meaning of syntax in terms of a system model. a unique system mo del for a set of description tec hniques results in an UsingUsing a unique system model for a set of description techniques results in an tegrativ e seman tics for the dieren t tec hniques An in tegrativ e seman tics inintegrative semantics for the different techniques. An integrative semantics ws reasoning ab out in terrelations b et ween dieren t views expressed by alloallows reasoning about interrelations between different views expressed by t tec hniques Notions like renement consistency and completeness dierendifferent techniques. Notions like refinement, consistency and completeness b e precisely dened cancan be precisely defined. mathematic al system mo del pro vides terms with a formal seman tics eg AA mathematical system model provides terms with a formal semantics, e.g. and can therefore serv e as a basis for a formal seman tics for a set functionsfunctions, and can therefore serve as a basis for a formal semantics for a set description tec hniques ofof description techniques. the ab o ve denitions one can dene the seman tics of a do cument WithWith the above definitions, one can define the semantics of a document h is a kind of a mo dule on the syn tactical lev el of a giv en description whic(which is a kind of a module on the syntactical level) of a given description hnique as the set of all those mo dels that ha ve the prop erties that are tectechnique as the set of all those models, that have the properties that are in the do cumen t expressedexpressed in the document. a set of mo dels and not a single one as the basis of the prop osed UsingUsing a set of models and not a single one as the basis of the proposed tics has sev eral adv an tages For example renemen t of do cumen ts semansemantics has several advantages.
Recommended publications
  • Xtuml: Current and Next State of a Modeling Dialect
    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
    [Show full text]
  • VI. the Unified Modeling Language UML Diagrams
    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
    [Show full text]
  • Justice XML Data Model Technical Overview
    Justice XML Data Model Technical Overview April 2003 WhyWhy JusticeJustice XMLXML DataData ModelModel VersionVersion 3.0?3.0? • Aligned with standards (some were not available to RDD) • Model-based Æ consistent • Requirements-based – data elements, processes, and documents • Object-oriented Æ efficient extension and reuse • Expanded domain (courts, corrections, and juvenile) • Extensions to activity objects/processes • Relationships (to improve exchange information context) • Can evolve/advance with emerging technology (RDF/OWL) • Model provides the basis for an XML component registry that can provide • Searching/browsing components and metadata • Assistance for schema development/generation • Reference/cache XML schemas for validation • Interface (via standard specs) to external XML registries April 2003 DesignDesign PrinciplesPrinciples • Design and synthesize a common set of reusable, extensible data components for a Justice XML Data Dictionary (JXDD) that facilitates standard information exchange in XML. • Generalize JXDD for the justice and public safety communities – do NOT target specific applications. • Provide reference-able schema components primarily for schema developers. • JXDD and schema will evolve and, therefore, facilitate change and extension. • Best extension methods should minimize impact on prior schema and code investments. • Implement and represent domain relationships so they are globally understood. • Technical dependencies in requirements, solutions, and the time constraints of national priorities and demands
    [Show full text]
  • Object Query Language Reference Version: Itop 1.0
    Object Query Language Reference Version: Itop 1.0 Overview OQL aims at defining a subset of the data in a natural language, while hiding the complexity of the data model and benefit of the power of the object model (encapsulation, inheritance). Its syntax sticks to the syntax of SQL, and its grammar is a subset of SQL. As of now, only SELECT statements have been implemented. Such a statement do return objects of the expected class. The result will be used by programmatic means (to develop an API like ITOp). A famous example: the library Starter SELECT Book Do return any book existing in the Database. No need to specify the expected columns as we would do in a SQL SELECT clause: OQL do return plain objects. Join classes together I would like to list all books written by someone whose name starts with `Camus' SELECT Book JOIN Artist ON Book.written_by = Artist.id WHERE Artist.name LIKE 'Camus%' Note that there is no need to specify wether the JOIN is an INNER JOIN, or LEFT JOIN. This is well-known in the data model. The OQL engine will in turn create a SQL queries based on the relevant option, but we do not want to care about it, do we? © Combodo 2010 1 Now, you may consider that the name of the author of a book is of importance. This is the case if should be displayed anytime you will list a set of books, or if it is an important key to search for. Then you have the option to change the data model, and define the name of the author as an external field.
    [Show full text]
  • A Dynamic Analysis Tool for Textually Modeled State Machines Using Umple
    UmpleRun: a Dynamic Analysis Tool for Textually Modeled State Machines using Umple Hamoud Aljamaan, Timothy Lethbridge, Miguel Garzón, Andrew Forward School of Electrical Engineering and Computer Science University of Ottawa Ottawa, Canada [email protected], [email protected], [email protected], [email protected] Lethbridge.book Page 299 Tuesday, November 16, 2004 12:22 PM Abstract— In this paper, we present a tool named UmpleRun 4 demonstrates the tool usage. Subsequent sections walk that allows modelers to run the textually specified state machines through an example of instrumenting our example system and under analysis with an execution scenario to validate the model's performing dynamic analysis. dynamic behavior. In addition, trace specification will output Section 8.2 State diagrams 299 execution traces that contain model construct links. This will permit analysis of behavior at the model level. II. EXAMPLE CAR TRANSMISSION MODEL TO BE EXECUTED In this section, we will present the car transmission model Keywords— UmpleRun; Umple; UML; MOTL; stateNested machine; substates that and will guard be conditions our motivating example through this paper. It will execution trace; analysis Aalso state be diagram used to can explain be nested Umple inside and a state.MOTL The syntax. states of The the innerCar diagram are calledtransmission substates model. was inspired by a similar model in I. INTRODUCTION LethbridgeFigure 8.18 and shows Lagani a stateère’s diagram book [4] of. anThe automatic model consists transmission; of at the top one class with car transmission behavior captured by the state Umple [1,2] is a model-oriented programming language level this has three states: ‘Neutral’, ‘Reverse’ and a driving state, which is not machine shown in Fig.
    [Show full text]
  • Foundations of the Unified Modeling Language
    Foundations of the Unified Modeling Language. CLARK, Anthony <http://orcid.org/0000-0003-3167-0739> and EVANS, Andy Available from Sheffield Hallam University Research Archive (SHURA) at: http://shura.shu.ac.uk/11889/ This document is the author deposited version. You are advised to consult the publisher's version if you wish to cite from it. Published version CLARK, Anthony and EVANS, Andy (1997). Foundations of the Unified Modeling Language. In: 2nd BCS-FACS Northern Formal Methods Workshop., Ilkley, UK, 14- 15 July 1997. Springer. Copyright and re-use policy See http://shura.shu.ac.uk/information.html Sheffield Hallam University Research Archive http://shura.shu.ac.uk Foundations of the Unified Modeling Language Tony Clark, Andy Evans Formal Methods Group, Department of Computing, University of Bradford, UK Abstract Object-oriented analysis and design is an increasingly popular software development method. The Unified Modeling Language (UML) has recently been proposed as a standard language for expressing object-oriented designs. Unfor- tunately, in its present form the UML lacks precisely defined semantics. This means that it is difficult to determine whether a design is consistent, whether a design modification is correct and whether a program correctly implements a design. Formal methods provide the rigor which is lacking in object-oriented design notations. This provision is often at the expense of clarity of exposition for the non-expert. Formal methods aim to use mathematical techniques in order to allow software development activities to be precisely defined, checked and ultimately automated. This paper aims to present an overview of work being undertaken to provide (a sub-set of) the UML with formal semantics.
    [Show full text]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes
    Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes “The Business Driven Application Lifecycle” Bob Sherman Procter & Gamble Pharmaceuticals [email protected] Michael Sutherland Galactic Solutions Group, LLC [email protected] Prepared for the Telelogic 2005 User Group Conference, Americas & Asia/Pacific http://www.telelogic.com/news/usergroup/us2005/index.cfm 24 October 2005 Abstract: The fact that most Information Technology (IT) projects fail as a result of requirements management problems is common knowledge. What is not commonly recognized is that the widely haled “use case” and Object Oriented Analysis and Design (OOAD) phenomenon have resulted in little (if any) abatement of IT project failures. In fact, ten years after the advent of these methods, every major IT industry research group remains aligned on the fact that these projects are still failing at an alarming rate (less than a 30% success rate). Ironically, the popularity of use case and OOAD (e.g. UML) methods may be doing more harm than good by diverting our attention away from addressing the real root cause of IT project failures (when you have a new hammer, everything looks like a nail). This paper asserts that, the real root cause of IT project failures centers around the failure to map requirements to an accurate, precise, comprehensive, optimized business model. This argument will be supported by a using a brief recap of the history of use case and OOAD methods to identify differences between the problems these methods were intended to address and the challenges of today’s IT projects.
    [Show full text]
  • Modelling, Analysis and Design of Computer Integrated Manueactur1ng Systems
    MODELLING, ANALYSIS AND DESIGN OF COMPUTER INTEGRATED MANUEACTUR1NG SYSTEMS Volume I of II ABDULRAHMAN MUSLLABAB ABDULLAH AL-AILMARJ October-1998 A thesis submitted for the DEGREE OP DOCTOR OF.PHILOSOPHY MECHANICAL ENGINEERING DEPARTMENT, THE UNIVERSITY OF SHEFFIELD 3n ti]S 5íamc of Allai]. ¿Hoot (gractouo. iHHoßt ¿Merciful. ACKNOWLEDGEMENTS I would like to express my appreciation and thanks to my supervisor Professor Keith Ridgway for devoting freely of his time to read, discuss, and guide this research, and for his assistance in selecting the research topic, obtaining special reference materials, and contacting industrial collaborations. His advice has been much appreciated and I am very grateful. I would like to thank Mr Bruce Lake at Brook Hansen Motors who has patiently answered my questions during the case study. Finally, I would like to thank my family for their constant understanding, support and patience. l To my parents, my wife and my son. ABSTRACT In the present climate of global competition, manufacturing organisations consider and seek strategies, means and tools to assist them to stay competitive. Computer Integrated Manufacturing (CIM) offers a number of potential opportunities for improving manufacturing systems. However, a number of researchers have reported the difficulties which arise during the analysis, design and implementation of CIM due to a lack of effective modelling methodologies and techniques and the complexity of the systems. The work reported in this thesis is related to the development of an integrated modelling method to support the analysis and design of advanced manufacturing systems. A survey of various modelling methods and techniques is carried out. The methods SSADM, IDEFO, IDEF1X, IDEF3, IDEF4, OOM, SADT, GRAI, PN, 10A MERISE, GIM and SIMULATION are reviewed.
    [Show full text]
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1
    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • Verification of UML State Diagrams Using a Model Checker
    Verification of UML State Diagrams using a Model Checker A Manuscript Submitted to the Department of Computer Science and the Faculty of the University of Wisconsin-La Crosse La Crosse, Wisconsin by Yiwei Zou in Partial Fulfillment of the Requirements for the Degree of Master of Software Engineering August, 2013 Verification of UML State Diagrams using a Model Checker By Yiwei Zou We recommend acceptance of this manuscript in partial fulfillment of this candidates re- quirements for the degree of Master of Software Engineering in Computer Science. The candidate has completed the oral examination requirement of the capstone project for the degree. Dr.Kasi Periyasamy Date Examination Committee Chairperson Dr.Mao Zheng Date Examination Committee Member Dr.Tom Gendreau Date Examination Committee Member ii Abstract Zou, Yiwei, Verification of UML State Diagrams using a Model Checker, Master of Software Engineering, August 2013. (Advisor: Kasi Periyasamy, Ph.D). This manuscript describes the process of verifying the UML state diagrams by using model checker. A UML state diagram describes the behavior of an object which includes a sequence of states that the object visits during its lifetime. Verification of UML state dia- gram is important because if one state diagram is incorrect, the object’s behavior will not be displayed correctly which leads to incorrect coding and eventually may lead to the possible failure of the system. However, it is hard to verify UML state diagram without the aid of other tools. Therefore, model checker is introduced to verify the UML state diagram. Since model checkers use different syntax, one needs to convert state diagrams from UML tools to the syntax used by the model checker.
    [Show full text]
  • IDEF0 Includes Both a Definition of a Graphical Model
    Faculty of Information Technologies Basic concepts of Business Process Modeling Šárka Květoňová Brno, 2006 Outline • Terminology • A Brief History on Business Activity • The basic approaches to Business Process Modeling – Formal x informal methods of specification and analysis – Verification of the informal defined methods • Software tools for Business Process specification and analysis (ARIS, BP Studio, JARP, Woflan, Flowmake, Oracle BPEL Process Manager, etc.) • Standards of BPM in context of BP Challenges – BPEL, BPMN, BPML, BPQL, BPSM, XPDL, XLANG, WSCI etc. • Mapping of UML Business Processes to BPEL4WS • Conclusions Terminology of BPM • Business Process is a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships. • Business process model – is the representation of a business process in a form which supports automated manipulation, such as modeling or enactment. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated data, etc. • Workflow – is the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Terminology of BPM • Method is well-considered (sophisticated) system
    [Show full text]