![TU Kaiserslautern
Process Modeling
© Dr. Jürgen Münch 2002-2007Slide 73
5.8 ETVX
• Development by IBM [Radice] beginning of 1980s
• Notation for description of activities
• Entry Task Verification eXit
– Entry criteria– must be satisfied before a set of tasks can be performed
– Tasks – set of tasks to be performed
– Verification & validation - The means to determine that the tasks are
completed properly
– eXit criteria - criteria for task completion](https://image.slidesharecdn.com/pmchapter5b1slide-150501175005-conversion-gate02/85/IDEF0-and-Software-Process-Engineering-Model-9-320.jpg)
IDEF0 and Software Process Engineering Model
- 1. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 65 5.7 IDEF0 • Integration Definition for Function Modeling (IDEF0) • Federal Information Processing Standards Publication 183 • Initial document: – Air Force Wright Aeronautical Laboratories Integrated Computer Manufacturing (ICAM) Architecture, Part II; Volume IV - Function Modeling Manual (IDEF0), June 1981 • Function modeling – Systems – Company (Process modeling) • Based on SADT (Structured Analysis and Design Technique)
- 2. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 66 Background of IDEF0 • Project – USAF ICAM (Integrated Computer Aided Manufacturing) – 1975 - 1980 – IDEF = ICAM DEFinition Language • Three languages – IDEF0 (What do I do?) “function model” – IDEF 1-1x (What do I need to know to do what I do?) “information model” – IDEF2 (When do I need to know what I need to know to do what I do?) “dynamics model”
- 3. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 67 Characteristics of IDEF0 • Simplicity of process documentation • Advantages – Comprehensive graphical representation – Simple notation – Supports human communication – Widely applied in practice → Prescriptive models (especially organization-specific reference models) – Tool support
- 4. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 68 • Boxes - Function – Function name (Verb) – Number • Arrows - Data / Objects – Straight-line arrow segment – Curved-arrow segment (corners are rounded with 90 degree arcs) – Forking arrows – Rejoining arrows Develop Model 1 Syntactical Elements of IDEF0
- 5. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 69 Syntax Rules of IDEF0 • Boxes – Boxes shall be sufficient in size to insert box name – Boxes shall be rectangular in shape, with square corners – Boxes shall be drawn with solid lines • Arrows – Arrows that bend shall be curved using only 90 degree arcs – Arrows shall be drawn in solid-line segments – Arrows shall be drawn vertically or horizontally, not diagonally – Arrow ends shall touch the outer perimeter of the function box and shall not cross over into the box – Arrows shall attach at box sides, not at corners Ref: Draft Federal Information Processing Standards Publication 183
- 6. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 70 Perform Detailed Design Design Engineer MFG/A632 Preliminary Design Data Design Requirements Recommended Detailed Design Each side of a box has a specific meaning a) Input: left side b) Control: upper side c) Output: right side d) Mechanisms: upwards, lower side e) Usage of a mechanism: downwards, lower side A “squiggle” ( )is used for connection of names to arrows when clear positioning is not possible 2 Connecting Arrows, Boxes and Names
- 7. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 71 Perform Detailed Design 2 Design Engineer MFG/A632 Preliminary Design Data Design Requirements Recommended Detailed Design QA/A-0 TOP LEVEL PURPOSE: Designing the software system VIEWPOINT: Design Team Diagrams create a decomposition hierarchy! Diagram
- 8. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 72 Criterion Natural representation - Support of quality management - Adaptability of model - Formality O Understandability + Interpretability (execution & enactment) - Flexibility - Traceability + Evaluation of IDEF0
- 9. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 73 5.8 ETVX • Development by IBM [Radice] beginning of 1980s • Notation for description of activities • Entry Task Verification eXit – Entry criteria– must be satisfied before a set of tasks can be performed – Tasks – set of tasks to be performed – Verification & validation - The means to determine that the tasks are completed properly – eXit criteria - criteria for task completion
- 10. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 74 Basic Schema in ETVX Exit Criteria Tasks Verification & Validation Entry Criteria
- 11. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 75 Entry PPrroodduucctt ssttrruuccttuurree iiss aass ddeettaaiilleedd aass tteecchhnniiccaallllyy ppoossssiibbllee.. Task PPrreecciisseellyy ddeeffiinnee ssttaannddaarrdd ooff mmeeaassuurreemmeenntt.. EEssttiimmaattee ssiizzee ooff eeaacchh eelleemmeenntt.. SSuumm ssiizzee ooff eeaacchh eelleemmeenntt.. AAppppllyy ccoonnttiinnggeennccyy ffaaccttoorrss.. Validation / Verification CCoommppaarree ttoo hhiissttoorriiccaall ddaattaa ooff ssiimmiillaarr ttyyppee // ccoommpplleexxiittyy.. CChheecckk ffoorr ccaallccuullaattiioonn eerrrroorrss.. eXit EEssttiimmaattee hhaass bbeeeenn vveerriiffiieedd aaggaaiinnsstt hhiissttoorriiccaall ddaattaa.. CCaallccuullaattiioonnss hhaavvee bbeeeenn cchheecckkeedd.. EEssttiimmaattee hhaass bbeeeenn aaddddeedd ttoo hhiissttoorriiccaall ddaattaa.. DDeettaaiilleedd ssiizzee eessttiimmaattee pprroodduucceedd.. Example ETVX: Size Estimation • Top-level description
- 12. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 76 Estimation ETVX • Advantages – Intuitive understanding of tasks – Detailed enough for the implementation of processes for many purposes – Can be used for delegation of tasks (prescriptive models) • Disadvantages – Becomes complex very fast – General flow difficult to understand
- 13. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 77 Criterion Natural representation - Support of quality management - Adaptability of model - Formality O Understandability + Interpretability (execution & enactment) - Flexibility - Traceability O Evaluation of ETVX
- 14. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 78 5.9 SPEM • Software Process Engineering Model • Released 2005 by the Object Management Group (OMG) – Based on UML notation (UML 1.4) – Uses parts of UML metamodel – Defined as a subset of UML • Metamodel for description of software development processes (or a family of processes) and their components • Intended for development and adoption of processes – Planning and execution of processes (in a project) is not part of metamodel
- 15. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 79 Roles, Activities, Work Products • Activities are performed by roles on work products • Different roles work together by exchanging work products and initiating activities
- 16. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 80 Basic Types of SPEM • Work products – Can be consumed, produced, modified – Can have different states – Can be composed of other work products (aggregation) – Can formally be defined as deliverables • Work product state machine: • Guidance – Special type of products (are not work products) – Cannot be produced or modified (e.g., technique, template, checklist,…) • Process roles – Define responsibilities for work products – Perform activities created drafted reviewed approved
- 17. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 81 Basic Types of SPEM • Activities – Done by a single process role – The process role executing the activity is its owner, others can be assistants – Can be refined into activity steps – Entry and exit criteria by preconditions and goals • Work breakdown structure – Process can be described on different levels of detail: → Activity → Work definition: composite set of activities → Iteration: composite work definition with a minor milestone → Phase: time span between two milestones (entry, exit criteria) → Lifecycle: complete process
- 18. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 82 Example SPEM: Activity <<Activity>> Find Actors and Use Cases /performer: System Analyst /assistant: Customer /assistant: Architect
- 19. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 83 SPEM Diagrams • Process models can be visualized using standard UML diagrams – Class diagram – Package diagram – Activity diagram – Use case diagram – Sequence diagram – State chart diagram • As in UML, process models can be structured using packages – Discipline: specialization of package used to categorize activities according to a common theme – Process component: self-contained, internally consistent piece of process description
- 20. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 84 Example SPEM: Activity Diagram
- 21. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 85 Criterion Natural representation + Support of quality management O Adaptability of model - Formality O Understandability + Interpretability (execution & enactment) - Flexibility - Traceability O Evaluation of SPEM
- 22. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 86 5.10 Little-JIL • Little-JIL – Agent coordination language – Process divided into small units of work: steps – Steps can be assigned to agents • JIL vs. Little-JIL – JIL: complex process language → Text-based → Based on ADA → Many complex functions – Little-JIL: coordination language → Subset of JIL → Only essential functions → Graphical representation for every function
- 23. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 87 Agents and Steps • Agent – Autonomous entity – Can be human or automated – Each agent has one or more agendas with work (i.e., steps) assigned to it – When work is done, the agent has to report success or failure • Step – Basic building block – Represents a unit of work – Can be decomposed into sub-steps – Every Little-JIL program is represented by its root step, which is decomposed to describe the process
- 24. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 88 States of a Step Started Posted Completed Terminated Retracted Opted-Out • Posted – Step is posted to the agenda of the agent • Started – Start is indicated by the agent • Completed – Completion is indicated by the agent • Terminated – Step failed to complete (e.g., after an exception was thrown) • Retracted – Step is removed from agenda without being started (can be reposted to another agent) • Opted-Out – Step is an optional step and agent decides not to start it
- 25. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 89 Graphical Representation of a Step • Step is annotated with badges – Every badge provides additional information or specifies the control flow • Sub-steps are drawn below parent step – Connected with arcs to sequencing badge of parent step
- 26. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 90 Step Badges • Sequencing badge – None: → Step is not decomposed – Sequential: → Sub-steps are executed from left to right, each one starting after previous sub-step is completed – Parallel: → Sub-steps are executed concurrently – Choice: → Only one of the sub-steps is executed – Try: → Try sub-steps from left to right until one sub-step succeeds
- 27. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 91 Step Badges • Interface badge – Resource declaration → Defines resources used by the step → Products produced by other steps and agents can also be needed resources – Parameter declaration → Defines parameters used by the step → Types: In, Out, In/Out, Locals → For object exchange between parent step and sub-steps – Channel declaration → Specifies all channels the step can write into or read from → Communication between two arbitrary steps – Exception declaration → Specifies all exceptions that can be thrown by the step → Exceptions can be thrown to show that a process did not complete correctly – Message declaration → Defines all messages that can be sent by the step → Messages can be sent during execution of the step (automatically or by the agent)
- 28. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 92 Step Badges • Pre- /Post-requisite badge – Define pre- and post-conditions for the execution of the step – If the step is started / terminated and the condition fails, an exception is thrown • Reactions badge – Every reaction defines a step for a certain message – If the step is in state ‘started’ and the message is sent by some other step, the reaction step is executed immediately (parallel to other active steps) • Handler badge – Every exception handler defines the types of exception he handles and the steps executed when the exception occurs – If an exception occurs and no handler is defined for this exception, the step is terminated and the exception is thrown to the parent step
- 29. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 93 Example Little-JIL: Simple Process
- 30. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 94 Example Little-JIL: Process with Exceptions and Messages
- 31. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 95 Criterion Natural representation + Support of quality management - Adaptability of model O Formality + Understandability + Interpretability (execution & enactment) O Flexibility O Traceability O Evaluation of Little-JIL
- 32. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 96 Appl/A Funsoft Nets MSL Statemate MVP-L IDEF0 ETVX SPEM Little-JIL Naturalness - O - - + - - + + Support of quality management - - - O + - - O - Adaptability of model O O O - - - - - O Formality O + + O O O O O + Understandability - O O + O + + + + Feasibility (execution & enactment) + + + + + - - - O Flexibility - - + - + - - - O Traceability - - O + O + O O O Overview of Process Modeling Languages Interpretability
- 33. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 97 5.11 Further Notations • Software Process Modeling Notations – UML (e.g., Activity Charts) – Tool-specific notations • Business Process Modeling Languages – ARIS: Notation for Business Processes, uses Event-driven Process Chains – BPML (Business Process Modeling Language)
- 34. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 98 Future Research Tasks • Definition of a comprehensive and consistent terminology • Relationships to languages in workflow management systems • Concepts for process and product variability • Concepts for process instantiation for project planning • Concepts for re-planning for process enactment
- 35. TU Kaiserslautern Process Modeling © Dr. Jürgen Münch 2002-2007Slide 99 Summary • Several process modeling languages exist for prescriptive and descriptive modeling • Different criteria have been introduced to assess process notations • There is no universal process modeling language • The suitability of a language essentially depends on the application purpose • Concepts of abstraction must be available for descriptive modeling