Behaviour Modelling. Focus and Scope Large scale issues – emergence UML Use cases in requirements and design Statecharts.

Slides:



Advertisements
Similar presentations
Use Case Diagrams Damian Gordon.
Advertisements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Use Case & Use Case Diagram
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
1 Model Driven Development. 2 DoDAF/ModAF/ SysML and AP233 Architecture –DODAF MODAF Modelling –UML –SysML Interchange –AP 233AP 233 –XMI.
CS3773 Software Engineering Lecture 03 UML Use Cases.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling.
Lecture 4 Class Responsibility Collaboration Cards
Documenting Requirements using Use Case Diagrams
State charts in SysML. Announcements 15 July 2004 – I-Logix announce that BAe systems are standardising on Statemate for development of Eurofighter TyphoonI-Logix.
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Requirements Analysis 4. 1 Use Case I b504.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Use-Cases.
© Copyright Eliyahu Brutman Programming Techniques Course.
Modelling System Behaviour: 1: Scenarios and Use cases Describing the behaviour of a system Focus Levels of Abstraction Six honest serving men The middle.
Use Case Modeling. Kendall & Kendall© 2005 Pearson Prentice Hall18-2 Commonly Used UML Diagrams The most commonly used UML diagrams are: – Use case diagram,
Chapter 7: The Object-Oriented Approach to Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
USE Case Model.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
Introduction to Sequence Diagrams
Interaction Modeling. Overview The class model describes the objects in a system and their relationships, the state model describes the life cycles of.
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Requirements Analysis Visual Modeling] Lab 02 Visual Modeling (from Visual Modeling with Rational Rose and UML) A way of thinking about problems using.
Requirements Documentation CSCI 5801: Software Engineering.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Slide 12A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Business Analysis with For PG MDI, Gurgaon Kamna Malik, Ph.D.
SWT - Diagrammatics Lecture 4/4 - Diagramming in OO Software Development - partB 4-May-2000.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Scenario A scenario is a sequence of steps describing an interaction between a user and a system. Use case is a set of scenarios tied together by a common.
Systems Analysis and Design in a Changing World, Fourth Edition
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
L16 Scenarios and Use cases. Topics Scenarios Use cases Sequence diagrams Use cases in analysis Tutorial work.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
1 After the scenarios are formulated Find all the use cases in the scenario Describe each of these use cases in more detail Participating actors Describe.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
Chapter 5 – System Modeling Lecture 1 1Chapter 5 System modeling.
CompSci 280 S Introduction to Software Development
Systems Analysis and Design in a Changing World, Fourth Edition
Dynamic Modeling of Banking System Case Study - I
Abstract descriptions of systems whose requirements are being analysed
Service-centric Software Engineering
SAD ::: Spring 2018 Sabbir Muhammad Saleh
Analysis models and design models
Using Use Case Diagrams
Interaction Modeling Extracted from textbook:
Use Case Modeling Part of the unified modeling language (U M L)
Chapter 4 System Modeling.
Presentation transcript:

Behaviour Modelling

Focus and Scope Large scale issues – emergence UML Use cases in requirements and design Statecharts

situation GetUHome’ is a company which provides a breakdown service to its members nationwide. Members pay a yearly subscription to the company. In the event of a breakdown, the distressed motorist phones the call centre where an available operator takes the call. The operator checks that the caller is a paid-up member. If he is, the operator obtains details of the motorist’s problems and location. He then finds the most appropriate mechanic to deal with the problem and calls the mechanic with the new task. The mechanic proceeds to the location of the motorist while the operator reports the expected arrival time to the motorist.

Focus : GetUHome Individual –What happens to a member as they progress from registration, renewal, breakdowns through to death or cancellation – a whole life view Small Group –How the member, the call-centre operator and the mechanic collaborate to assist in a breakdown Organisation –How the organisation is structured to respond to changing needs.. Society –How to predict demand for resources such call-centre operators, mechanics and server power under varying conditions of weather and other circumstances

Models by focus Focus on an individual and what happens to it over the whole life time –Entity Life History, State Chart Focus on a small group of interacting individuals over the period of an ‘incident’ –Scenarios, Use cases, Interaction Diagrams, Activity Diagrams, RAD (Role Activity Diagram) Focus on the massed behaviour of the society –System Dynamics (equational), Discrete Simulation models (probabilistic)

Three levels of abstraction in Behaviour modelling Mission statements, goals and targets –The abstract goals of an organisation, independent of methods and plans to achieve those goals Logical Processes –Logical descriptions of methods and plans to achieve goals, independent of their realisation in physical entities and hence of such physical constraints –Business Process Modelling, Rule-based models Physical Processes –the domain of people, communication services, data flows and programs –Roles assigned to individuals, processes located on processors

Scope What is the scope of ‘the system’ –The Rescue organization The operator and mechanic are inside this system boundary –The Computer System The operator and mechanic are outside this system boundary Under different circumstances either may be appropriate but the boundary must be defined The essence of an information system is that it contains a computer-based representation of the domain (the Rescue Organization) –Mechanic in the Real world are represented by mechanic-objects in the computer system –So many UML diagrams can be used to model The computer system (individuals are objects) The business system (individuals are people..)

Emergent Issues As humans we find this layering of focus and scope useful – but the fallacy of misplaced concreteness stalks us Emergence –Layers are generally not independent Scarce resources (time, people, processing power) in the physical layer cause behavioural disturbances to percolate up the layers, generating ‘unpredictable’ consequences Knowledge is not bounded by layers, so a person’s knowledge of a goal allows the person both to extemporise new plans when pre-conditions fail, or find ways to execute the plan but thwart the goal –Many-many mapping A process may support several goals, a goal require multiple processes to realise it A person may carry out many roles, a process require many people and other resources whose schedules may conflict 8 neighbours

Background to UML UML (Unified Modelling Language) has emerged as the dominant set of graphical notations for use in Object- oriented Software Development Current version is UML 2.0 with 14 different diagram types UML is unavoidable - widely used and written about UML is enthusiastically being extended into non-software domains : business processes and systems engineering (SysML) Whilst UML is just a set of notations, it is linked to a software development approach (life-cycle) called RUP (Rational Unified Approach) which is also being extended into other areas (RUP SE) There are dissenting voices.

UML Notations Use case Diagram –Showing the actors involved in a use case Interaction Diagram –Showing the sequence of steps in the interaction between actors and the system Activity Diagram –Showing how data flows from one process to another Class Diagram –Showing the classes in the system State Chart –Showing how an object changes over time as a result of events + others

Use-cases and scenarios Classification –Focus – small group –Level of abstraction – conceptual –Prescriptive/graphical-textual/early analysis Use cases include the actions of users as part of that interaction –Use cases set requirements into context of use –Use cases also point to ‘requirements’ on users for using the system – systems knowledge, training, level of education…

General to Specific A generalised use-case: –Is described in terms of roles: 'an operator’ –Covers a number of possible paths. –Danger that the reader will import their own stereotype – white, male, English first language A specific, concrete scenario or ‘story’: –Is described in terms of specific instances: 'Paul the operator, a 2nd Year business studies student from London who works part time at GetUHome to finance his studies and clubbing'. –The story describes exactly what happened, not several possible outcomes. Stories favour insight into the problem situation and may reveal unanticipated assumptions about the situation and the nature of the actors. Use cases provide grounds for formal requirements for the system but also informal requirements for the knowledge and capabilities of the actors

Use case Uses a template to structure the information Is named for the goal of the principal actor: –Name: Get help –Primary Actor: Motorist Describes normal use case (‘good day’) and alternative situations arising from ‘normal’ variations Supported by a Use-case diagram showing one or more use cases May be elaborated into an interaction diagram

Use Case Diagram Get help MotoristOperator Mechanic

Sequence diagram MotoristOperatorMechanic Call for help Request member info Member info Check member Request location & problem Location and problem Request OK and ETA OK and ETA ETA Vehicle proceeds to location Select appropriate vehicle

Use cases in problem analysis Information Requirements · What information is required to identify a member? · What information is required to identify the problem and location? · How do we choose the most appropriate vehicle to send? · Who provides the ETA? The operator, the rescue driver or both in consultation? How is it calculated? Variations · What happens if the membership has expired? · What happens if the motorist can’t remember his id? · What if the motorist has ‘borrowed’ someone else’s id? · What if the motorist doesn’t know where they are? · How does the rescue driver find the motorist? Performance · What is an acceptable time to wait for an operator? · What is an acceptable time to wait for a rescue vehicle

Mis-use and abuse cases Identify –Treats and attacks Attempt to acquire customer list –Deliberate misuse by humans Use of a stolen membership card –System failure Loss of telephone lines Loss of communication channel to mechanic

Use-cases and Design Concrete Scenarios –Write a concrete scenario for each use case to flesh it out Brain storming –One group identify problems with scenario –Other group suggest solutions Role playing –Testing out a proposed solution using role playing

Use cases in.. Testing –Use cases generate test situations –Tests can be written in advance for use in test-driven development Training –Use cases are the scenarios in which users will need to be educated or trained to use the system

Dissenting Voices Uncertainly about what a use case is, how big, how general, what boundary, when to stop finding use cases. A project may have many hundreds of use case so computer support necessary to manage and to restructure ( find all for an actor…), trace requirement to use cases. Relationship between use-case and requirements is many-many so mapping requires additional work and traceability. Uses case may be poor at surfacing so-called ‘non- functional requirements’. Scope of use-case is too narrow – often at the level of an interaction over a small period of time – what about the long-running processes with the scope of the whole period of membership? Focus is on system boundary, not directly on the problem domain.

Statemate A state machine design tool based on David Harel’s state charts (incorporated into UML) Allows –Simulation – what would happen if the following sequence of events occurred. –Analysis – prove that the system can never lock up –Code generation – to C for loading into embedded processors

Basic State Machine The basic concepts in this notation are: –state A mode of the object/component/sub-system –transition A change of state caused by an event or input, perhaps back to the same state –event the input which causes a transition to occur –action An action which occurs when a transition is made

Exercise 1.1. What sequence of noises does it make when the sequence ABACAC is in put? 1.2 What about BABAAC? 1.3 What kind of error in the machine does the sequence ACCBA reveal? 1.4 What kind error in the machine does the input BABC reveal? 1.5 What kind of error does the sequence ABAXAC reveal? 1.6 Give other examples of good and bad input.

State tables States ↓ Inputs →ABC initial final

JavaScript Simulator Local Simulator Web Simulator

Another Simulator This simulator takes an XML definition of a statechart and builds a model which can be executed or visualized. Web Simulator

Noise machine model print "boing" print "clack" print "clang" print "hiss" print "bang" print "pong" print "ping"

Physical devices Mechanical devices can be modelled with FSMs too

Exercise 3 A vending machine can accept 5, 10 and 20p coins up to a total value of 30p. There is one dispense button. When pressed, the machine issues a cold drink can and pockets the 30p. Define a suitable state machine. Note that the amount entered so far must be described only in the state of the machine, not in a separate counter.

Harel Statecharts guardspre-conditions on transitions nested statesone state may be composed of many substates. The superstate defines common behaviour such as transitions which are the same for all sub-states. entry and exit actionswhich occur on state entry and exit. activityon-going activities in a state event signallingcausing an internal event to be sent to another object concurrent statesparallel states in which state changes occur independently synchronisation and splitting to define the flow of control within parallel states timeouttransition triggered by a timeout counter set on state entry

Chinese clock Operating for clock Time display:- The normal display of Hour Minute and Month day are alternate move. Time setting:- 1) push S1 once, display shows MONTH, push S2 to advance month 2) push S1 twice, display shows DAY of MONTH, push S2 to advance DAY 3) push S1 third, display shows hour and AM/PM indicator. Push S2 to advance hour 4) push S1 fourth time, display shows MINUTES. Push S2 to advance MINUTES 5) push S1 fifth time, display shows normal running mode 6) push S1 One more time, display will alternate TIME and DATE each 2 seconds

Statecharts and ELHs Entity Life History models serve a similar purpose to statecharts –Higher order constructs – sequence, iteration selection in ELH, ‘goto’ in statecharts –Nodes are states in Statechart, Events in ELH –Equivalent, but some ELHs are more complex as a statechart

ELH versus StateChart

Enactable Processes State charts as the basis for enactable process model – –Analyst defines the model –General process support environment executes the program Describing academic processes –e.g. the process of exam moderation –Web SimulatorWeb Simulator