Modelling System Behaviour: 1: Scenarios and Use cases Describing the behaviour of a system Focus Levels of Abstraction Six honest serving men The middle ground – Scenarios and use cases

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

Three focus settings 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 –Data flow?, System Dynamics, Simulation models

Levels of abstraction Conceptual data models describe structures – mapped into RDBMS or XML We distinguish at least 3 levels of abstraction in data structuring: –The user’s view - a Database virtual view or the output of an XSLT transformation –The conceptual model – the logical structure expressed in an ER model –The logical model specific to a kind of data model - XML, RDBMS, Object Oriented –The physical files required to support a datamodel As far as possible, we want to bridge these levels automatically e.g. –QSEE transforms a conceptual model into a RDBMS schema, with some designer guidance (which database..) –XSLT engine guided by a style sheet generates a user view from the logical model –An SQL view defines a mapping from an RDBMS schema to a users schema

Three levels of abstraction in describing behaviour User Logical –Business Process Modelling, Rule-based models Physical –Web service, data flow in a batch system, programs

“I keep six honest serving men (They taught me all I knew): Their names are What and Why and When And How and Where and Who” How the system is intended to work –prescriptive How the system does work –Descriptive Why the system works this way –The design rationale What is the system trying to achieve –The goals

six honest serving men What - Subject – what is being modelled –What domain of the total system –What aspect of a system Why - Purpose - why are we modelling –Communication – external –Analysis - internal How – – what format - physical, diagrammatic, textual, mathematical.. When – at what stage of the lifecycle –Requirements –Analysis –Design –Maintenance Who – – makes the model – uses the model – controls the notation? Where – –Back of a fag packet –Powerpoint presentation –On a central computer database?

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…

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.

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 Examples –The following example use case is at the organizational level –Latter these would be refined to computer system use cases

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

Additions Symbols –Different symbols in the diagram for different types of actors Use case matrix –Diagram is unworkable for large numbers of use cases - matrix of use cases by actor (perhaps indicating the role) is more informative Relations between Use cases : Extends and Uses –Uses – a smaller unit of functionality which is used by several larger units – e.g. check member info –Extends – variations to use cases require additional behaviour in special cases – these ‘extend’ the original use case

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.

Problem Domain Modeling Nature of problem domain is only tacitly reflected in the development process –“An airplane overshot the runway when attempting to land. The runway was wet, and the plane's wheels were aquaplaning instead of turning. The plane's guidance system thought, in effect, "I'm on the ground, but my wheels aren't turning. So I must not be moving," and would not allow the pilot to engage reverse thrust. Aquaplaning, a very relevant property of the real world, was not considered by the developers when they created the guidance system. The consequence is a plane in a ditch past the end of the runway, instead of safely docked in the terminal.”

Language in the Problem Domain Terminology of the problem domain is used without analysis in use cases –In a railway system, the word ‘train’ has multiple meanings for different groups: –“To some of them, a "train" was a particular collection of rolling stock (a locomotive and all the cars it pulled). To others, a "train" was just the locomotive. To others, a "train" was a regularly scheduled run, as in "I'll catch the 6 o'clock train to Boston". To others, a "train" was a specific instance of a regularly scheduled run, so that the train that left for Boston today at 6 o'clock, and the train that left for Boston yesterday at the same time, are two different trains.”