Lecture 3: Use case, vocabulary and business modellingwikidyd.iem.pw.edu.pl/attachments/SoftEng/SE1_Lecture3.pdf · 2015-09-23 · Software Engineering by Albert Ambroziewicz Lecture

Software Engineering by Albert Ambroziewicz

Lecture 3: Use case, vocabulary and business modelling

Use case model construction

Use cases, actors, extension points

Business use case model

Activity diagrams

Vocabulary construction

Notions, terms, notion hyperlinks

Software Engineering Slide 3.2 A. Ambroziewicz M. Śmiałek

Reminder - where we are?

We want to create visual models of user requirements.

Visual models facilitate communication!

System vision

System scope

Software requirements

User requirements

Use case descriptions

Notion descriptions


Modelling the system’s functionality

The system knows how to behave in respect to its users or other systems.

ClerkStatistical System

Stolen Car System Office Manager

Car Registration System

I want to register a car!

Please accept car registration

I want to get car registration data!

Please verify the car data


Modelling users and external systems

We need to identify “objects” that communicate with the system: people, machines

Communication can happen through different means: GUI (menus, forms, …) textual UI (commands, menus,

forms, …) other user interface (card

readers, voice recognition systems, sound emitters, …)

programmer’s interface (API, middleware, software services)

Actors! Margaret Black

John Smith

Andrew Brown

C:\>_

Accounting Statistical

Management Statistical


What is an actor?

Actor describes a role that someone or something can play in respect to the considered system.

Actor represents a group of people (or machines) that “talk” to our system in the same way.

A particular person (or machine) can play several roles – can be associated with several actors.

An actor can be compared to a hat that we wear playing a particular role in respect to the system. Margaret Black

John Smith

Andrew Brown

Clerk

Office Manager

Statistical System Accounting Statistical

Management Statistical

ClerkManager


Modelling “pieces” of functionality

We need to identify small chunks of functionality. What can constitute such a small chunk?

A Use Case!

Clerk

MenuItem 1Item 2Item 3

System

The system controls the functionality!


What is a use case?A use case is a description of behaviour of a system communicating with one or more actors.

In order for a behaviour description to constitute a use case three conditions have to be met: The description should start with an actor’s

interaction with the system The description should present messages

exchanged between the system and an actor The description should clearly state the final

goal reached at the end of message passing

After reaching the goal, it should be possible to start another use case (or repeat the current one).

Important: use case usually includes alternative paths of message passing that (try to) lead to the same goal but sometimes fail.

OK!FAIL

Record car data


Use cases show a “black box” view

When describing a use case, we should treat the modelled system as a “black box”.

Use case descriptions should concentrate on the behaviour that is visible to the actors. All the “machinery” inside the system should be hidden.

The system is described as a “white box” only when we start to design it’s architecture.

Use cases with human actors describe only the user interface and certain business effects of the system’s behaviour (no information about passing data from clients to servers, storing data in database tables, starting new threads etc.).


Denoting relationships of use cases and actors

Relationship between an actor and a use case is denoted with an association (a line).

Two types of relationships are possible: Primary actor for a use case: the actor

starts the use case and the system tries to reach the use case’s goal for this actor

Secondary actor: the system asks the actor to help in reaching the use case’s goal; communication with the secondary actor is done before the use case ends (during communication with the primary actor)

Primary and secondary relationships are denoted with appropriate arrows.

Clerk

Stolen Car System

Record car data

Verify cardocumentation


Relationships between use cases

Sometimes it is necessary to show that during execution of a use case, some other use case could be executed.

Execution of another use case can be caused by user intervention, evoked by some condition of the system or performed unconditionally.

The evoked use case should be a “normal” use case. All the interactions of the evoked use case are inserted into the main use case.

Show car list Change car data

OK!

OK!


Denoting relationships between use cases

Sometimes it is necessary to denote that a use case should be invoked from within another use case.

UML has two types of invocation dependencies: <<include>> and <<extend>>.

These two dependencies cause a lot of confusion!


<<include>> and <<extend>> ambiguity (1)

Source: http://openlearn.open.ac.uk


<<include>> and <<extend>> ambiguity (2)

Source: http://openlearn.open.ac.uk


Denoting relationships between use cases

Because of this ambiguity issues and other problems with <<include>> and <<extend>> we will use just one dependency (newly invented): <<invoke>>.

Invoke means that interactions of the invoked use case are inserted (conditionally or unconditionally) into the invoking use case.

Show car list

Change car data

Show car details

Print car data

<<invoke>>

<<invoke>>

<<invoke>>

<<invoke>>


Digression – what does <<…>> mean?

If a model element is denoted with a “guillemot” (French) brackets it means it has a stereotype.

Stereotype gives an additional (more specific) meaning (semantics) to the given element.

Adding a stereotype might cause the element to change its graphical shape (like changing into some other icon) or colour.

Stereotypes are good means to extend the modelling language!

<<invoke>>

<<external system>>SC System

SC System

<<business use case>>Register a car

BRegister a car


What is an extension point?

Inside the use case description there can be several points where other (<<invoked>>) use case can be started.

These points are called extension points. This is because they denote places where the main use case is extended with the functionality of other use cases.

Extension point can be: Unconditional: invoked use case is

always inserted into the main one. Conditional: invoked use case is

inserted under a certain condition.

Change car data

Show car details

Print car data

Show car list

OK!

(if the printer is ready)


Denoting extension points

Extension points can be shown inside the use case icon. Below a line we list all the extensions – their names and conditions (if any).

Conditions are written in square brackets ‘[‘ and ‘]’.

The above notation is useful if we don’t show other use cases. When we draw a full use case diagram, the extension points are obvious from the <<invoke>> dependencies.

We only need to add the conditions (in square brackets).

Show car listExtension points:Show the car: [button press]Print the car: [button press; printer ready]

Show car list

Print car data

<<invoke>>

<<invoke>>Show car details

[button press]

[button press;printer ready]


Writing use case descriptions

When describing a use case on the User requirements level we usually need to specify: Use case name – a name that tells about the goal Actor (or actors) – a single primary actor and possibly secondary

actors Use case story – a couple of paragraphs of text describing the

message flow inside the use case. Extension points – as described on the previous slides

Note that all the above elements except for the “story” is available in diagrams – we don’t need to copy this information into text!

When writing Software Requirements, use cases will get described in more detail – we will then (next month) write detailed scenarios with screenshots.


Putting it all together – use case model

Full use case model contains: Use case diagrams Use case textual descriptions

Show car detailsPrint car data

<<invoke>><<invoke>>

<<invoke>>

<<invoke>>

[button press;printer ready]

Show car list

Change car data

Clerk

Verify car documentationStolen Car System

Get car registrationstatistics

Statistical System

Office Manager Assign a clerk to a job

Print car data:The clerk starts with…

Change car data:When the clerk presses…Assign a clerk to a job:

When Office Manger wants to…

Get car registration stats.:A Statistical System starts by passing a message…

Record car data

[printer ready]<<invoke>>


Use case model denoting system’s functional scope

System’s functional scope is a set of all the use cases. On this basis we can calculate the cost of development.

Clerk

Statistical System

Stolen Car System

Office Manager


Show car list

Verify car documentation

Get car registrationstatistics

Assign a clerk to a job

Record car data


Precedence of use cases – how to do it?

Very often, it is necessary to show that some use cases should be called after some other use cases.

This precedence of use cases depends on the business and describes some business process.

To show that a use case can be called only after some other use case we might write a pre-condition – we write them in curly braces ‘{‘ and ‘}’. Precondition might also describe some other constraints.

Sometimes, the calling order of use cases depends on some conditions. This also has to be shown!


Record car data

Login

Show car list

Change car data

Print car data

Finished!

{Pre: car documentation has to be verified first}

Start

<<invoke>>

[the ownerfinds errors]

<<invoke>>


Activity diagrams

To denote ordering of use cases we can use an activity diagram.

This diagram can also include activities that are purely business ones – those that do not denote system use cases.

Activity diagram consists of: Initial and final nodes Action nodes Control flows Conditions Other elements…

(Owner) Submit cardocumentation

(Clerk) Verify cardocumentation

(Clerk) Inform aboutregistration denial

(Clerk) Recordcar data

(Clerk) Issuelicense plates

[Stolen]

(Clerk) Login

[OK]

[notlogged-in]

(Clerk) Printcar data

(Owner) Check forerrors in data

[OK]

(Clerk) Changecar data

(Clerk) Showcar list

[errorsfound]


Digression – colours usage on UML diagrams

UML diagrams are meant to be drawn in any tool so specs define plain, simple line-drawings as a notation.

The UML shapes (like use cases, classes, packages) can be filled with any colour (or even replaced with images - stereotypes), but:

they have to be recognisable

they do not need to be flashy (eye-tiring, unaesthetic)

The same goes for font style and size, also elements size. All of this is tool-, not language-, specific!

Colours can be used to pass secondary information like:

priority

task assignment

additional emphasis needed for some of a model parts


Business System =Car/Driver Registration Office

Business use cases

System use cases and other actions form a process (activity diagram).

This process can be defined as a business use case, having very similar features as a system (“normal”) use case: starts with business actor

interaction with the business system

defines a dialog between the actor and the system

leads to a specific goal

Clerk

OK! FAIL

Car RegistrationSystem

Car owner


Business use case model

Full business use case model contains: Business use case diagrams Activity diagrams for business use cases National Statistics Office

Car owner

Car/Driver Registration Office

Register a car

Receive informationabout registration fees

Ministryof Finance

Prepare specializedregistration info

Change car details

Issue a driver’s licenseCar driver


System and business use case models – how to keep them coherent?

What needs to be coherent? System use case descriptions Business use case activities

What can cause contradictions? Contradictory definitions of the

same terms (homonyms) – different notions

Contradictory names used for the same notion (synonyms) – different terms

How to prevent contradictions? Use a consistent vocabulary!

Record car data

Print car information

(Owner) Submit cardocumentation


Car data means car details,…

…where car information is: car details,…

Car documentation i.e. papers…

…where car documentationmeans data…


Vocabulary makes models consistent

Keep a separate vocabulary.

Make vocabulary notions synchronized with use case descriptions.

Record car data

Print car data

(Owner) Submit carpaper documentation


Car data (synonym: car information) – contains all the car details that pertain its registration from the legal point of view (…)

Car paper documentation – includes all the paper documents and their electronic facsimile submitted by the owner (…)

Car documentation – denotes all the data elements copied from the car paper documentation that (…)

Bank details – (…)

Direct owner – (…)


Making vocabulary visual

Every vocabulary entry (notion) can be denoted as a class in a class model.

Notions usually use other notion names in their descriptions. This creates an association between two classes that represent these two notions. Car data (synonym: car information) –

contains all the car details that pertain its registration from the legal point of view (…)

Car paper documentation – includes all the paper documents and their electronic facsimile submitted by the owner (…)

Car documentation – denotes all the data elements copied from the car paper documentation that (…)

Owner – a person that submits car paper documentation in order to register the car data (…)

Owner Car data

Car documentation Car paperdocumentation


Vocabulary model denoting system’s data scope

Vocabulary notions denote data that need to be handled by the software system.

Remember also to define the actors – they are also elements of the vocabulary


National Statistics Office

Car owner

Ministryof FinanceCar driver

Owner Car data

Car documentation Car paperdocumentation


Managing complexity

Divide your use cases into “chunks”. Each chunk is a set of logically related requirements (use cases).

The same goes for vocabulary elements.

Entity that is a container in UML:

a package

User RequirementsModel

„Packaged” User RequirementsModel

1 2

3

12

344


Packages

Packages allow logical division of sets of requirements.

Packages allow creation of tree hierarchy within requirements specification

Notation for package: a folder icon.

namename


Summary – scoping the system

Scope of the system determines its size – this gives us the means to make an important cost and time estimates.

The more use cases and notions, the more costly the system will be – it is that simple (well, almost…)

Description of the system’s scope has to be very consistent! Consistency between use cases, activities and business use cases Consistency between use case descriptions, notions and notion

descriptions

To scope the system, it is enough to write a short description of the use case flow, and short descriptions of the notions.

Business process description (activity diagrams) give an additional link to the system vision – allow to estimate system’s influence on the business.

Documents

Lecture 3: Use case, vocabulary and business modellingwikidyd.iem.pw.edu.pl/attachments/SoftEng/SE1_Lecture3.pdf · 2015-09-23 · Software Engineering by Albert Ambroziewicz Lecture