Behavior Modeling (based on Alistair Cockburn book) PA116 – L11 (c) Zdenko Staníček, Sept 2010.

Slides:



Advertisements
Similar presentations
Use-Cases.
Advertisements

IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Chapters 7 & 9 System Scope
Object-Oriented Analysis and Design
Information System Engineering
Objectives Detailed Object-Oriented Requirements Definitions
A Linguistics-Based Approach for Use Case Driven Analysis Using Goal and Scenario Authoring Vijayan Sugumaran Oakland University Rochester, Michigan, USA.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l.
Documenting Requirements using Use Case Diagrams
Use Case Analysis Chapter 6.
Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements.
Bina Nusantara 7 C H A P T E R MODELING SYSTEM REQUIREMENTS WITH USE CASES.
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
Modeling System Requirements with Use Cases
Use Cases.
Functional Modeling Chapter 6.
Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer
Detailed Object-Oriented Requirements Definitions
Adding the Detail Filling in Use Case Templates. Use Case Template The use case diagram is important for visualizing a system and as a communication tool.
This section has been adapted from Dr. Scott Fleming of U. Memphis Details about Use Cases.
USE Case Model.
Use Case Diagrams – Functional Models Chapter 5. Objectives Understand the rules and style guidelines for activity diagrams. Understand the rules and.
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
UML Use Case Modeling.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Use Cases Descriptions and Use Case Models.
CS499 Use Cases References From Alistair Cockburn Writing Effective Use Cases (Book) - Use Case.
Object-Oriented Analysis - Instructor Notes
1 © 2005 course technology University Of Palestine Chapter 6 Storyboarding the User’s Experience.
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
Intro: Use Case and Use Case Diagram Documentation.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
Approaching a Problem Where do we start? How do we proceed?
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 7 Appendix A Object-Oriented Analysis and Design: Use Cases Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George.
Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Engineering Lab Use Cases Faculty of Information system Technology.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
IS3320 Developing and Using Management Information Systems Lecture 9: Use Cases and Scenarios Rob Gleasure
1 Structuring Systems Requirements Use Case Description and Diagrams.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
Adv. Use cases Actor generalization – general and special actors Use case generalization – general and special use cases Include and extend relationships.
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
CMSC 345 Use Cases. u Describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders, called.
Use Cases Todd S. Bacastow Professor of Practice John A. Dutton e-Education Institute The Pennsylvania State University.
4-1 © Prentice Hall, 2007 Topic 4: Structuring Systems Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Writing Use Cases: Requirements in Context.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Larman chapter 61 Use cases Larman chapter 6. 2 Fig. 6.1.
Chapter 6: Structuring Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Use Cases Discuss the what and how of use cases: Basics Examples Benefits Parts Stages Guidelines.
Chapter 7 Appendix A Object-Oriented Analysis and Design: Use Cases
Chapter 4: Business Process and Functional Modeling, continued
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases Discuss the what and how of use cases: Basics Benefits
Rob Gleasure IS3320 Developing and Using Management Information Systems Lecture 8: Use Cases and Scenarios Rob Gleasure.
Concepts, Specifications, and Diagrams
Unified Modeling Language
Systems Analysis and Design in a Changing World, 6th Edition
Object Oriented Analysis and Design
BPMN - Business Process Modeling Notations
Object-Oriented Software Engineering
Use Case Modeling Part of the unified modeling language (U M L)
Use cases Dr. X.
Presentation transcript:

Behavior Modeling (based on Alistair Cockburn book) PA116 – L11 (c) Zdenko Staníček, Sept 2010

Use Cases Philosophy Principles Recommendations Alistair Cockburn: The Use-Case is a contract for System behavior

U-composite

How to describe contract for system behavior? Diagram Diagram with NL descriptions NL NL constrained by several rules Artificial Language (BPML, BPMN, BPEL, …) What is the best way?

How to describe contract for system behavior NL constrained by several rules …coupled with diagram, if necessary Again in a form of a model … a special model, purposely not included into other models from Diam4

U-composite

Key questions of Use Case writing according to Alistair Cockburn Scope –What is really the system under discussion (SuD)? Primary Actor –Who has the goal? Level –How high- or low-level is the goal?

Summary definitions (A. Cockburn) Use Case: a contract for the behavior of the SuD Actor: anyone or anything with behavior Stakeholder: someone or something with a vested interest in the behavior of the system under discussion (SuD) Primary actor: the stakeholder who or which initiates an interaction with the SuD to achieve a goal

U-composite

Summary definitions (cont.) (A. Cockburn) Scope: identifies the system that we are discussing. Preconditions: what must be true before the use case runs Guarantees: what must be true after the use case runs

U-composite

Summary definitions (cont.) (A. Cockburn) Main success scenario: a case in which nothing goes wrong Extensions: what can happen differently during that scenario Numbers in the extensions refer to the step numbers in the main success scenario at which each different situation is detected (e.g. steps 4a and 4b indicate two different conditions that can show up at step 4) When a use case references another use case, the referenced use case is underlined

U-composite

Use Case Template (A. Cockburn) Context of Use: Scope: Level: Primary Actor: Stakeholders and Interests: Preconditions: Minimal Guarantees:

Use Case Template (cont.) Success Guarantees: Trigger: Main Success Scenario: Extensions: : Related Information:

Readings Alistair Cockburn: Writing Effective Use Cases … there you will find lot of examples and explanations …

U-composite Interests Behavior Actors

Actors=Agents and Stakeholders A Stakeholder has interests An Actor or generally an Agent has behaviors The Primary Actor (the Agent from its perspective the Use Case is described) is also a Stakeholder

Behavior and Interactions as composite Goal-oriented Behavior consists of Responsibilities, Goals, and Actions The Private Actions we write are those that forward or protect the interests of Stakeholders. Interactions connect the Actors=Agents. Several Agents can participate in an Interaction. Interactions decompose into Use Cases, Scenarios, and Simple Messages.

U-composite Interests Behavior Actors BehavioralE lements DO NOT FORGET !!!

The Writing Process (A. Cockburn) 1.Name the system scope and boundaries. Track changes to this initial context diagram with the in/out list. 2.Brainstorm and list the primary actors. Find every human and non-human primary actor, over the life of the system. 3.Brainstorm and exhaustively list user goals for the system. The initial Actor-Goal List is now available. 4.Capture the outermost summary use cases to see who really cares. Check for an outermost use case for each primary actor.

The Writing Process (cont.) (A. Cockburn) 5.Reconsider and revise the summary use cases. Add, subtract, or merge goals. Double-check for time-based triggers and other events at the system boundary. 6.Select one use case to expand. Consider writing a narrative to learn the material. 7.Capture stakeholders and interests, preconditions and guarantees. The system will ensure the preconditions and guarantee the interests. 8.Write the main success scenario. Use steps 3 – 9 to meet all interests and guarantees.

9.Brainstorm and exhaustively list the extension conditions. Include all that the system can detect and must handle. 10.Write the extension-handling steps. Each will end back in the MSS, at a separate success exit, or in failure. 11.Extract complex flows to sub use cases; merge trivial sub use cases. Extracting a sub use case is easy, but it adds cost to the project. 12.Readjust the set: add, subtract, merge, as needed. Check for readability, completeness, and meeting stakeholders’ interests. The Writing Process (cont.) (A. Cockburn)

Reminders (A. Cockburn) Write something readable ! Work breadth-first: from lower precision to higher precision –Precision level 1: Primary actor’s name and goal –Precision level 2: The use case brief, or the main success scenario –Precision level 3: The extension conditions –Precision level 4: The extension handling steps

Reminders (cont.) (A. Cockburn) For each step: –Show a goal succeeding –Capture the actor’s intention (not the user interface details) –Have an actor pass information, validate a condition, or update state –Write between-step commentary to indicate step sequencing (or lack of) –Ask “why” to find a next-higher level goal

Reminders (cont.) (Z. Stanicek) For data description: –Precision level 1: Names of entity sorts involved –Precision level 2: Definitions of entity sorts –Precision level 3: The conceptual model –Precision level 4: Descriptive attributes Think in systematic top-down manner –E.g. using Diam4 – Diam1

RSDO