Role Activity Diagrams

Slides:



Advertisements
Similar presentations
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Advertisements

Nested state diagrams:Problems with flat state diagram
Software and Systems Engineering Seminar Winter 2011 Domain-specific languages in model-driven software engineering 1 Speaker: Valentin ROBERT.
Software Design Process A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output. Inputs Outputs Design Process.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Software Engineering COMP 201
Activity Diagrams [Arlow and Neustadt, 2005] CS 425 / 625 Seminar on Software Engineering University of Nevada, Reno Department of Computer Science & Engineering.
Introduction to UML Part 2 Behavioral Modeling. Sequence (event) diagram Describes object interaction Typically captures behavior of a single use case.
1 © Wolfgang Pelz UML2 UML Part Two. 2 © Wolfgang Pelz UML2 Chapters Four & Twelve Interaction Diagrams.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
NJIT Drawing System Sequence Diagrams Chapter 10 Applying UML and Patterns Craig Larman Presented by Anuradha Dharani.
Activity Diagrams Derived from several techniques: Event diagrams of Jim Odell SDL state modeling techniques Workflow modeling Petri nets Especially useful.
SE-565 Software System Requirements More UML Diagrams.
© Richard Welke 2002 CIS 4120 Fa13: Define/Innovate BP’s Richard Welke Director, CEPRIN Professor, CIS Robinson College of Business Georgia State University.
Software Design Processes and Management
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
程建群 博士(Dr. Jason Cheng) 年03月
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 21. Review ANALYSIS PHASE (OBJECT ORIENTED DESIGN) Functional Modeling – Use case Diagram Description.
1 SAD2 - UML 2 nd Lecture Sequence Diagram and other dynamic views Lecturer: Dr Dimitrios Makris
UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna,
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 5 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN: AN AGILE, ITERATIVE APPROACH CHAPTER.
DEAS2005Michael Shin Copyright1 Connector-Based Self-Healing Mechanism for Components of a Reliable System Michael E. Shin Department of Computer Science.
Activity diagrams M Taimoor Khan
Systems Analysis and Design in a Changing World, Fourth Edition
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 26. Review UML behavioral Diagrams – Sequence diagram.
Chapter 14: Activity Diagrams November 2015 [Arlow and Neustadt, 2005] CS 425/625 Senior Projects University of Nevada, Reno Department of Computer Science.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
UML Activity Diagrams.
Chapter 3: Introducing the UML
Business Process and Functional Modeling
Analysis Classes Unit 5.
Information Delivery Manuals: Process Mapping
Chapter 4: Business Process and Functional Modeling, continued
Week 11: UML Overview IFS410: UML Models Spring 2007
Systems Analysis and Design in a Changing World, 6th Edition
Evolution of UML.
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Diagramming Techniques
Chapter 11: Collaboration Diagram - PART1
Diagramming Techniques
Activity and State Transition Diagram
Visit for more Learning Resources
Business System Development
UML Activity Diagrams.
Sequence Diagrams.
Princess Nourah bint Abdulrahman University
UML Activity Diagrams & State Charts
Informatics 121 Software Design I
Princess Nourah bint Abdulrahman University
Process Modeling: Activity/Swimlane Diagrams
Systems Analysis and Design in a Changing World, 6th Edition
CS 425/625 Software Engineering Architectural Design
Week 12: Activity & Sequence Diagrams
Introduction to UML.
Chapter 14: Activity Diagrams
Unified Modelling Language
BPMN - Business Process Modeling Notations
Other UML Diagramming Techniques
Chapter 14: Activity Diagrams
Chapter 14: Activity Diagrams
Petri nets.
Appendix 3 Object-Oriented Analysis and Design
Chapter 4 Sequence Diagrams
Presentation transcript:

Role Activity Diagrams -- Introduction / Examples – (only for internal use) © Josef Schiefer, IBM Watson

Outline

Introduction Original paper Ould & Roberts (1986) Formal semantics. Similar to Petri Nets. Can be mapped to other formal notations Widely used. Promoted by Praxis (Ould, Huckvale & others) & Coordination Systems (Roberts) Applied to a number of domains, e.g., Software Engineering, finance, Retail and Construction

3 Types of Processes

Important Business Process Constructs Interactions? Parallel / concurrent threads? Choices? Iteration?

RAD Notation

Roles and RADs Business depicted in terms of roles Roles are types - e.g., they describe the behaviour of a class of individuals A Role is independent of other roles, but communicates through interactions Instances of roles therefore act in parallel, with the interaction between roles being their only synchronisation mechanism

Basics: Role Activity Diagram (RAD)

Role Behavior: Actions An action is an activity which the role carries out in isolation Carrying out an action moves the role from its present state to the next state

Basics: Role Activity Diagram (RAD)

Roles have State Not required to explicitly label the states of a role, though some authors prefer to do so. Labeling states (with circles or ellipses) helps the semantics of the role become clearer Labels make explicit the pre-conditions, pre-actions and consequences (post-conditions) of each activity. Sometimes need to separate parallel threads into separate (or main and sub) roles… Diagram becomes larger and this may hamper understanding

Basics: Role Activity Diagram (RAD)

Example: Design Project

Behavior: Interactions An activity carried out at the same point as another activity (or other activities) in another role (or roles). A shared event. The consequence of an interaction is that all of the roles involved move from their current state to their next state. Interaction must be initiated by some (driving) role. Interactions are synchronous

Interactions

Control Thread of control in a role need not proceed sequentially Choice or case-refinement. There may be any number of alternative threads but only one of the threads (or cases) may be chosen Concurrent threads or part-refinement. Each thread represents part of the path. The threads all join together again after the split denoting that all paths have been completed

RAD: Control Alternative Paths, Case Refinement Concurrent paths, Part Refinement

“AND” & “OR” Connectors

Example: Design Project

Iteration Iteration is where a state may be revisited. Shown by: Drawing a loop back to a previous point on the role. Having the post-state of an action as a previously named state. Typically used when there is some checking or control mechanism to be modeled

Example: Design Project

“TOKENS”

RAD Literature Martyn A. Ould: Business Processes: Modeling and Analysis for Re-engineering and Improvement RAD Visio Stencils: http://www.the-old-school.demon.co.uk/veniceresources.htm