FDT Foil no 1 MSC Structuring MSCs Using Message Sequence Charts for real systems.

Slides:



Advertisements
Similar presentations
Sequence diagram How to. Guards Sequence diagram with combined fragments and messages Sequence diagram based on figure of UML specification It.
Advertisements

System and Software Engineering Research 1 Motorola 2003 Integrated Application of MSC Clive Jervis Rapporteur Q15 Motorola UK Research Labs.
Design by Contract.
Conformance Testing of MOST based Applications Towards Effective System Testing André Baresel, Michael Schmidt - DaimlerChrysler AG Contact:
Lei Bu Message Sequence Chart. MSCs Message sequence chart (MSC) is a graphical and textual language for the description and specification of the interactions.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Goal and Scenario Validation: a Fluent Combination Chin-Yi Tsai.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Winter 2007SEG2101 Chapter 41 Chapter 4 SDL – Structure and Behavior.
Chapter 18 Object-Oriented Systems Analysis and Design Using UML
Structuring SDs Normally a use case scenario is too long and complex to fit on a single (A4?) SD. We need to hierarchically structure SDs and decompose.
Model Checking. Used in studying behaviors of reactive systems Typically involves three steps: Create a finite state model (FSM) of the system design.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Understanding Entity Relationship Diagrams.
Slide 1 MSC and SDL. Slide 2 Relationship of MSC to SDL An MSC describes one or more traces of an SDL system specification. An entity in MSC may map to.
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Modeling.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
F. Khendek, G. Robert, G. Butler and P.Grogono Concordia University Montreal, Canada Implementability of Message Sequence Charts.
Karolina Muszyńska Based on: S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
Timed UML State Machines Ognyana Hristova Tutor: Priv.-Doz. Dr. Thomas Noll June, 2007.
CS3773 Software Engineering
IAY 0600 Digital Systems Design
מידול התנהגותי 1. Today’s Session Sequence Diagrams State Machines 2.
1 CSC 450 Slides adapted from slides created by Robert B. France UML Behavioral Models.
The Architecture of Secure Systems Jim Alves-Foss Laboratory for Applied Logic Department of Computer Science University of Idaho By, Nagaashwini Katta.
FDT Foil no 1 Overall Methodology – from Engineering RT Systems through TIMe; to RAM. Covering the full development cycle Supporting the whole company.
Systems Analysis and Design in a Changing World, 6th Edition
Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding.
SDS Foil no 1 Process Algebra Process Algebra – calculating with behaviours.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
 A software application is like a city  Modeling = Architecture  OOP = Civil Engineering  UML Classes = Blueprints of Buildings  UML is a common.
Chapter 2, Modeling with UML, Part 3 UML 2 Hightlights
Conceptual Modelling – Behaviour
Winter 2007, rev. 2008SEG Chapter 21 Chapter 2 Basic Principles.
Chapter 2, Modeling with UML: UML 2 Hightlights
Documenting Software Architectures 1.Uses and Audiences for Architecture Documentation Architecture documentation serves as a means of education Architecture.
© 2005 Prentice Hall9-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 Interaction and Communication Diagrams Patrick Bailey Keith Vander Linden Calvin College.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Modelling Class T07 Conceptual Modelling – Behaviour References: –Conceptual Modeling of Information Systems (Chapters 11, 12, 13 and 14)
SDS Foil no 1 V&V&S Verification, Validation and Synthesis: doing away with defects Verification, Validation and Synthesis: doing away with defects.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 5 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN: AN AGILE, ITERATIVE APPROACH CHAPTER.
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
Context Process0. student Data Flow Diagram Progression.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Chapter 3: Introducing the UML
Science and Technology Norwegian University of NTNU Rolv Bræk, January Domain Modelling and requirement specifications by Rolv Bræk NTNU.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
Specifying the Interactions Builds on agent types and scenario descriptors Interaction Diagrams( IDs) involve –Replacing each functionality with the agent.
Communication Diagrams Lecture 8. Introduction  Interaction Diagrams are used to model system dynamics  How do objects change state?  How do objects.
FDT Foil no 1 Basic SDL Specification and Description Language Basic SDL.
Database Design, Application Development, and Administration, 6 th Edition Copyright © 2015 by Michael V. Mannino. All rights reserved. Chapter 5 Understanding.
Sequence diagrams Lecture 5. Main terms  Interaction  Life line  Activation  Executable behavior and derived behavior  Messages  Trajectory  Frame.
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 4: Business Process and Functional Modeling, continued
Use Case Modeling - II Lecture # 27.
Systems Analysis and Design in a Changing World, 6th Edition
Structural style Modular design and hierarchy Part 1
Chapter 8: Modelling Interactions and Behaviour UML Activity Diagram
Structural style Modular design and hierarchy Part 1
Systems Analysis and Design in a Changing World, 6th Edition
Interaction Diagrams A Lot of UML!
An Introduction to Software Architecture
Message Sequence Charts
Presentation transcript:

FDT Foil no 1 MSC Structuring MSCs Using Message Sequence Charts for real systems

FDT Foil no 2 Features Inline expressions – for alternatives, loops, exceptions and options MSC references – such that MSCs may be referenced within other MSCs MSC expressions – combining MSCs to express alternatives, parallel merge and loops Gates – flexible connection points between references/expressions and their surroundings HMSC – High level MSC for better better overview of MSC documents Substitution – generalizing MSCs wrt. message, instance and MSC names General ordering – when neither strict order nor no order is the situation MSC Document – declaring a collection of MSC and their data Inline expressions – for alternatives, loops, exceptions and options MSC references – such that MSCs may be referenced within other MSCs MSC expressions – combining MSCs to express alternatives, parallel merge and loops Gates – flexible connection points between references/expressions and their surroundings HMSC – High level MSC for better better overview of MSC documents Substitution – generalizing MSCs wrt. message, instance and MSC names General ordering – when neither strict order nor no order is the situation MSC Document – declaring a collection of MSC and their data

FDT Foil no 3 Simple MSC in a nutshell User AC System msc User_accepted Code Door unlocked Idle OK Card out diagram frame heading condition output event input event instance Unlock message message to environment instance end

FDT Foil no 4 MSC references UserAC System msc Auto_Door Opened AutomaticDoor User_Accepted Idle Unlock Door open actual gate msc reference

FDT Foil no 5 MSCs in MSC document

FDT Foil no 6 High level MSC - HMSC msc AC_System_Overview IdleDoor unlocked User_acceptedUnlocked_resetUnlocked_timeoutUnlocked_unclosedUser_rejected hmsc start connection point alternative restrictive condition msc reference loop

FDT Foil no 7 Restrictive conditions only for HMSC conditions only for global (initial and final) conditions conditions may have a set of names msc AC_System_Overview Idle Door unlocked User_accepted Unlocked_resetUnlocked_timeout Unlocked_unclosed User_rejected

FDT Foil no 8 Reference expression msc AC_System_Overview IdleDoor unlocked User_accepted Unlocked_unclosed alt Unlocked_reset alt Unlocked_timeout User_rejected reference expression

FDT Foil no 9 Gate application explicitly named gates implicitly named gate

FDT Foil no 10 Gate definition

FDT Foil no 11 Inline expressions door alt msc Unlocked_Idle User AC System Door unlockedIdle door Lock Push door Opened door alt door Alarm Error Lock Closed door alternative either this or this expression frame operand separator operator gates propagate

FDT Foil no 12 Exception and Option door exc msc Unlocked_Idle User AC System Door unlockedIdle door Lock Push door Opened door exc door Alarm Error opt Pull door Lock Closed door exception either this or continue the main road option either this or nothing

FDT Foil no 13 Loop msc AC_System_Overview User AC System Idle loop alt User_acceptedUnlocked_IdleUser_rejected infinite loop

FDT Foil no 14 Parallel merge User_accepted subst User by User1 User_accepted subst User by User2 msc TwoUsersAccepted Two parallel behaviours

FDT Foil no 15 General order in one instance msc User_accepted Coregion User AC System Code decomposed Door unlocked Idle OK Card out Unlock General order symbol

FDT Foil no 16 Incomplete messages Lost message

FDT Foil no 17 Substitution UserAC System msc Auto_Door Opened AutomaticDoor User_Accepted Idle Unlock Door open User AC System msc Simple_Accepted Unlock Idle PushButton Door unlocked Auto_Door subst User_Accepted by Simple_Accepted msc SimpleDoor

FDT Foil no 18 Summary ways to achieve overview: HMSC for over viewing large specifications Inline expressions for over viewing small variations ways to combine MSCs: MSC references MSC gates MSC reference expressions improved generalization mechanisms: Substitution of MSCs, message names, and instance names ways to achieve overview: HMSC for over viewing large specifications Inline expressions for over viewing small variations ways to combine MSCs: MSC references MSC gates MSC reference expressions improved generalization mechanisms: Substitution of MSCs, message names, and instance names

FDT Foil no 19 Remaining issues MSC 2000 issues: Document diagrams Data Imperative conditions (when) Better decomposition rules UML 2.0: Essentially the same Slightly different syntax MSC 2000 issues: Document diagrams Data Imperative conditions (when) Better decomposition rules UML 2.0: Essentially the same Slightly different syntax

FDT Foil no 20 1 objects properties context content 1 MSC is used to: 1.Precisely define behaviour properties such as: use cases interface behavior cases, protocol sequences service behaviors 2.Partially synthesise designs 3.Verify that designs satisfy specified behaviour properties 4.Describe test cases 5.Document simulation traces 6.Generally improve understanding and communication about interaction problems 1.Precisely define behaviour properties such as: use cases interface behavior cases, protocol sequences service behaviors 2.Partially synthesise designs 3.Verify that designs satisfy specified behaviour properties 4.Describe test cases 5.Document simulation traces 6.Generally improve understanding and communication about interaction problems 4,