Software EngineeringSoftware Engineering

Object-Oriented Analysis (Use Cases)James Gain

(jgain@cs.uct.ac.za)http://people.cs.uct.ac.za/~jgain

ObjectivesObjectives1. Outline the history and concepts of Object-

Oriented Analysis2. Introduce the Unified Modelling Language (UML)3. Study the process and notation associated with

Use-Cases4. Provide a case study and exercise on Use-Cases in

action

[1] Analysis Process[1] Analysis Process The steps taken in order to complete an analysis (the

algorithm) The OOA process landscape:

Booch: evolutionary process encompassing both a ‘macro’ and ‘micro’ development process

Rumbaugh: OMT (Object Modeling Technique) producing object, dynamic and functional models

Jacobson: OOSE (Object Oriented Software Engineering) emphasises Use-Cases

Coad and Yourdon: Viewed as one of the easiest Wirfs-Brock: No clear distinction between analysis and design

BUT All are similar with small annoying differences Booch, Rumbaugh and Jacobson now combined (into

Objectory - a heavyweight life-cycle model)

Generic ProcessGeneric Process Most OOA processes have the following steps in

common:1. Elicit customer requirements2. Identify scenarios or use-cases3. Extract candidate classes4. Identify attributes and methods5. Define a class hierarchy6. Build an object-relationship model7. Build an object-behaviour model8. Review the OO analysis against the use-cases9. Repeat as required

Modelling LanguageModelling Language A modelling language is a means of specifying,

visualizing and documenting the artifacts of a software systems

These models are the primary means of communication between users and developers

Modelling languages specify a notation It is important that they be standardized

[2] Unified Modelling Language[2] Unified Modelling Language A notational System (including syntax, semantics and

pragmatics for its notations) that is principally graphical and aimed at modelling systems using object-oriented concepts.

UML is not a process, methodology or proprietary Combines the notations of Booch, Rumbaugh and Jacobson Standardized by the OMG (Object Management Group) Defines a notation and a meta-model (defining the notation

using the notation) Consists of:

Views (shows different faces of the system and links with the process, e.g. user, structural, behavioural, etc.)

Diagrams (graphs that describe the contents of a view) Model elements (concepts used in a diagram)

Analysis = Process + ModelsAnalysis = Process + Models

Process Model Output1. Elicit customer

requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model

Class Diagram

4. Build an object-behaviour model

Interaction Diagram

[3] Use Cases[3] Use Cases A view of a system that emphasizes the behaviour as it appears

to outside users. Partitions system functionality into transactions (‘use cases’)

that are meaningful to users (‘actors’). Consists of scenarios - typical interaction between a user and a

computer system (a thread of usage of a system) Properties:

Captures some user-visible function Achieves a discrete goal for the user No attempt to represent order or number of times actions are executed

Captured by talking to a typical user and discussing what they want to achieve with the system.

Use-cases can be used to derive structural and behavioural models and construct test cases.

[3] Use Case Diagrams[3] Use Case Diagrams Graphically shows use-cases, actors and their

relationships.

Use CaseCommunication

Relationship

Actor

Analyze Risk

Trader

Price Deal

Capture Deal

Valuation

Limits Exceeded

<<extends>>

<<uses>>

<<uses>>

Uses Relationship

Extends Relationship

Use CasesUse Cases Fundamentally a system transaction Arranged in a hierarchy.

At the top level a system box can enclose the use-cases

At lower levels each use-case isdecomposed into several moredetailed use-cases

Use cases often start with a verb in order to emphasize that they are processes (Buy Items, Price Deal)

Valuation

Share Trade System

ActorsActors actors represent roles people or devices play as the system

functions. They communicate with the system and are external to it.

users can play a number of different roles for a given scenario. Example: an operator on a production line might have many roles

(programmer, tester, monitor, troubleshooter). Each of these would represent an actor in the use-case

A single actor may perform many use-cases; a use-case may have several actors performing it

System (non-human) actors should only be shown when they are the ones that need the use case Example: If the system generates a file that is later picked up by the

accounting system then the accounting system is a relevant actor.

Trader

RelationshipsRelationships Communication:

Flow of data and control between an actor and use-case

Uses: Use uses when you are repeating yourself in two or more separate

use cases and you want to avoid repetition

Extends: Use extends when you are describing a carefully controlled

variation on normal behaviour Useful for identify core and extended functionality Needs to have extension points (specific aspects that are extended)

Generalizes A casual description of a variation on normal behaviour

<<uses>>

<<uses>>

<<Extends>>

Use Case Narratives Use Case Narratives For each use-case provide a narrative document For example:

Use Case: Buy Item

Actors: Customer, Cashier

Description:

- The use case begins when the customer arrives at a checkout with items to purchase.- The Cashier records each item. If there is more than one of an item, the Cashier can enter the quantity as well.- The system determines the item price and adds the information to the running sales transaction. The description and price of the current item are presented.- On completion of item entry, the cashier indicates that item entry is complete.- The system calculates and presents the sale total.

Developing a Use CaseDeveloping a Use Case Ask yourself these questions:

What are the main tasks or functions that are performed by the actor?

What system information will the the actor acquire, produce or change?

Will the actor have to inform the system about changes in the external environment?

What information does the actor desire from the system?

Does the actor wish to be informed about unexpected changes?

Modelling TipsModelling Tips Make sure that each use case describes a significant chunk

of system usage that is understandable by both domain experts and programmers

When defining use cases in text, use nouns and verbs accurately and consistently to help with later derivation of objects.

A use case diagram should contain only use cases at the same level of abstraction include only actors who are required

Try to describe use cases independent of implementation A common mistake is to use chains of uses and extends to describe

internal details A use case can have many scenarios (threads of execution)

[4] Case Study: Use Cases[4] Case Study: Use Cases Reminder:

Convert a photographic image into a simulated mosaic with square tiles

Tiles must follow curves but still be closely spaced

User Interface:1. Select image2. Draw contours3. Set parameters (e.g. tile size)4. Initiate simulator

High-Level Use Case NarrativeHigh-Level Use Case NarrativeUse Case: Mosaic Builder

Actors: Imager, Draftsman, Designer

Description:

1. Imager selects a reference picture in electronic image format.

2.

a) Draftsman draws edges onto a transparent contour image aligned with the reference picture OR

b) System automatically detects edges in the reference picture, places these edges into the contour image. The Draftsman then cleans up the results - strengthening or erasing edges.

3. Designer flood-fills coloured regions onto a region image to distinguish tile sizes. Designer associates coloured regions with tile sizes.

4. Designer specifies number of tiles, colour palette and tile spacing.

5. System generates and displays the mosaic.

High-Level Use Case DiagramHigh-Level Use Case Diagram

Refined Use Case NarrativeRefined Use Case Narrative Refine each stage as necessary producing separate

Use-Cases:Use Case: 2a - Draw Edges

Actors: Draftsman

Description:

1. A transparent overlay image is placed over the original reference picture.

2. The draftsman draws black edges of a consistent thickness onto the overlay using the mouse.

3. The draftsman is also able to erase edges that are incorrect.

4. The draftsman can save the overlay as a black and white image with the same resolution as the reference picture.

[5] Exercise [5] Exercise Example: Home Security System (SafeHome) Project Brief (provided at the start of the project):

Build a micro-processor based home security system that will protect against and/or recognize a variety of undesirable situations such as illegal entry, fire and flooding.

The product will use appropriate sensors to detect each situation, can be programmed by the homeowner and will automatically telephone a monitoring agency when necessary.

Components:

homeowner (the user) sensors (devices attached to the system) monitoring and response subsystem (central station that monitors

SafeHome) Interactions:

Enters a password to allow all other interactions. This password needs to be validated by the system

Inquires about the status of a security zone which relies on the status of a combination of sensors

Inquires about the status of a sensor Presses the panic button in an emergency Activates/deactivates the security system

Components and Interactions Components and Interactions

Low-level Use Case NarrativeLow-level Use Case NarrativeUse Case: Activates System

Actors: Homeowner

Description:1. The homeowner observes the control panel to determine if the system is

ready for input. If the system is not ready, the homeowner must physically close window/doors so that the ready indicator is present [a not ready indicator implies that a sensor is open].

2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

3. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors. Away activates all sensors.

4. When activation occurs, a red alarm light can be observed by the homeowner.

Task: Create the corresponding Use-Case Diagram