Goal and Scenario Validation: a Fluent Combination Chin-Yi Tsai.

Slides:



Advertisements
Similar presentations
Object-Oriented Software Engineering Visual OO Analysis and Design
Advertisements

State Charts Mehran Najafi. Reactive Systems A reactive, event-driven, object is one whose behavior is best characterized by its response to events dispatched.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Identifying, Modifying, Creating, and Removing Monitor Rules for SOC Ricardo Contreras Andrea Zisman
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Concurrency: introduction1 ©Magee/Kramer 2 nd Edition Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
UML Diagrams Jung Woo. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, business.
UML (Sequence Diagrams, Collaboration and State Chart Diagrams) Presentation By - SANDEEP REDDY CHEEDEPUDI (Student No: ) - VISHNU CHANDRADAS (Student.
IEC Substation Configuration Language and Its Impact on the Engineering of Distribution Substation Systems Notes Dr. Alexander Apostolov.
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Goal-Oriented Requirements Engineering (GORE) “Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring,
Lecture 12: Chapter 22 Topics: UML (Contd.) –Relationship Structural Behavioral –Diagram Structural Behavioral.
Business Process Orchestration
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Modeling State-Dependent Objects Using Colored Petri Nets
Unified Modeling Language(UML) BY
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Models Modelling can help us to understand the requirements thoroughly
Class, Sequence and UML Model.  Has actors and use cases.
INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University Analysis Modeling.
Concurrency: introduction1 ©Magee/Kramer Concurrency State Models and Java Programs Jeff Magee and Jeff Kramer.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Changing Perspective From Structured to Object-oriented.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Model-based Methods for Web Service Verification.
Prepared by Afra`a Sayah. Introduction. Weekly Tasks. Plane Phase. Analysis Phase. Design Phase. Report Rules. Conclusion. 2.
Standards for Mathematical Practice #1 Make sense of problems and persevere in solving them. I can: explain the meaning of a problem. choose the right.
Software development process ธนวัฒน์ แซ่ เอียบ. The development process Process –set of rules which define how a development project. Methodology and.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
A language to describe software texture in abstract design models and implementation.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
UML Use Case Diagramming Guidelines. What is UML? The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
Capturing Web Application Requirements through Goal-Oriented Analysis Presented by Chin-Yi Tsai
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Verification of behavioural elements of UML models using B Truong, Ninh-Thuan and Souquieres, Jeanine In Proceedings of the 2005 ACM Symposium on.
Supporting Scenario-Based Requirements Engineering IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998 A. G. Sutcliffe, N. A. M.
Entity Relationship Diagram. Introduction Definition: Entity-relationship diagram is a data-modeling technique that visualises entities, the attributes.
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
Requirements Validation with Enactable Models of State-based Use Cases Chin-Yi Tsai.
8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Validating Integration Requirements Diagrams for illustrative.
Requirements Engineering-Based Conceptual Modelling From: Requirements Engineering E. Insfran, O. Pastor and R. Wieringa Presented by Chin-Yi Tsai.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
 Engineering Quality Software.  Today o State Diagrams Jerry Kotuba SYST30009-Engineering Quality Software 2.
FDT Foil no 1 MSC Structuring MSCs Using Message Sequence Charts for real systems.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Inferring Declarative Requirements Specification from Operational Scenarios IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
SEESCOASEESCOA SEESCOA Meeting Activities of LUC 9 May 2003.
Fall 2007 Week 9: UML Overview MSIS 670: Object-Oriented Software Engineering.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
M253 Team Work in Distributed Environments Week (3) By Dr. Dina Tbaishat.
Beyond Scenarios: Generating State Models from Use Cases An approach for the synthesis of State transition graphs from Use Cases Supporting Use Cases Based.
Unified Modeling Language. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems,
Model Checking Early Requirements Specifications in Tropos Presented by Chin-Yi Tsai.
Analysis Classes Unit 5.
UML Diagrams By Daniel Damaris Novarianto S..
Object-Oriented Analysis and Design
Activity and State Transition Diagram
UML Diagrams Jung Woo.
Unified Modeling Language
An Introduction to Embedded Software Architecture and Design
Uml diagrams In ooad.
UML Design for an Automated Registration System
Presentation transcript:

Goal and Scenario Validation: a Fluent Combination Chin-Yi Tsai

2 Introduction Scenarios and goal are effective techniques for requirements definition.  Goals are objectives that a system has to meet.  Scenarios are operational examples of system usage Scenario-based specification  MSC (message sequence charts)  UML sequence diagram Goal  Goal tree/graph

3 Introduction (Cont’d) Inferring declarative requirements from operational scenario

4 Introduction (Cont’d) Validation is a key requirements activity. Animation is an effective validation technique.  This paper shows that combining goals with scenarios can results in effective animation  to ensure that they represent what stakeholders actually want. Animation  Step through  Visual  State is implicit? To present a meaningful animation to a stakeholder, the choice of states to visualize must relate to the concern of the stakeholder participating in the animation. System behavior --driven by--- scenario Stakeholder perspective Relates to goal Behavior model

5 Introduction (Cont’d) Use fluent linear temporal logic (FLTL) formulas to express goals that can be formulated in terms of predicates whose values depend on system events. Fluents are abstractions of system state specified in terms of the occurrence of events such as those that appear in operational scenarios.

6 Message Sequence Charts and Behavior Models

7 Message Sequence Charts and Behavior Models (Cont’d) We use LTSs (Labeled Transition Systems) to model the behaviour of communicating components in a concurrent system. A LTS is a state transition system where transitions are labelled. Use LTS synthesis technique to automate the construction of behavior model from MSC.

8 Goals and Fluents We use goals in the spirit of van Lamsveerde’s goaloriented requirements engineering approach  KAOS A pair of sets A set of initiating actions A set of terminating actions

9 Animation Animation is performed by three components: an animator, a visualiser and a participant The animator component uses a behaviour model in the form of a LTS that is the result of the LTS synthesis from the given scenarios. The animator uses the behaviour model to react to events controlled by the animation participants.

10 Specifying Visualisation Using Fluents We associate fluent expressions with visualisation elements by means of showwhen rules. In the context of the LTSA tool, these rules are encoded in XML.

11 Model Checking Goals Animation techniques are effective to support validation and elaboration, they rely on participants exploring system behaviour sufficiently thoroughly as to cover relevant situations. A complementary approach is to use model checking techniques to find traces of particular interest and to use them to direct the animation. The animation can lead participants through uses of the system that need special consideration. Model checking of goals expressed in FLTL (fluent linear temporal logic)

12 Multi-Participant Animation Supporting multi-participant animations These animations allow stakeholders to explore how the behaviors of system entities affects each other.

13 Experience

14

15 Conclusion Visualization can be constructed based on abstract system states  Generality and flexibility  Allow engineers to produce animation that have a concrete relation to the goal scenariogoal validation animation participant