Class Exercise I: Use Cases

1

Class Exercise I: Use Cases

Deborah McGuinness

Semantic eScience 2012

Week 2, September 10, 2012

1

Contents

• Questions on reading?

• Round the room reading highlights

• Use case introduction

• Elements of use case documentation – make sure to include semantic aspects

• Two use case presentations

• Class exercise – use cases in real-time if time

22

3

Developed for NASA TIWG and modified for class

Roles and skill-sets needed

• Facilitator *** (usual key skills, knows method)

• Domain experts (literate, knows resources; data, applications, tools, etc.)

• Modelers (to extract objects)• Software engineers (architecture, technology)• Scribe (to write everything down)• The social aspect is key - it is a team effort

4

Developed for NASA TIWG

Roles and skill-sets• Facilitator – you may not be ready to play this role but

you will need to ‘pretend’• Engage some domain experts (they are literate, know

the resources; data, applications, tools, etc. and you can share this role)

• You will be the modeler (to extract objects, triples)• You may play the role of a software engineer

(architecture, technology) but you can also ask someone for help with this

• Write as much as you can down• Be prepared to be social - it is a team effort• Acknowledge in your assignments what was team and

what was individual5


Note

• Your roles and what is/ is not expected of you

• Be prepared to draw on the white board• Keep your scoping in mind as you are

proceeding– Identify objects, processes, actors/roles,

organizations (or nouns, verbs, adjectives)

6


For Ref: Long form of a Use Case

• http://wiki.esipfed.org/index.php/SolutionsUseCase_Template

Our web page has a shorter version that also highlights some aspects that are important for this class – focused on question, answers, use of semantics, use of provenance

7

Use Case … is a collection of possible sequences of interactions

between the system under discussion and its actors, relating to a particular goal.

The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly.

Any system behavior that is irrelevant to the actors should not be included in the use cases.is a prose description of a system's behavior when interacting

with the outside world.is a technique for capturing functional requirements of

business systems and, potentially, of an ICT system to support the business system.

can also capture non-functional requirements 8

Use Case

Must be documented (or it is useless)Should be implemented (or it is not well

scoped)Is used to identify: concepts ~ resources,

processes, roles (aka actors), relations, requirements, etc.

Should iterate with your end-user on wording and details at least once

(and in this class, there may be a proxy user)9

Use case mythsNeed lots (10s - 100s) of use cases to build

what is needed

Need to be very general to get general functionality

Need to know ‘computer science’ to create them, or the diagrams

Have to get them perfect the first time

Are only used for software development

Many more …10

Use Cases Expose System Requirements: small ex. with Mt. St.

Helens planning

Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts

And … semantics, terms, concepts and their relations

11


Use Case Examples:

• Provide browse and quick look access to a broad variety of climate, weather and ocean data.

12


Use Case Examples:

• A US 9th grade teacher is preparing a lesson plan aimed at getting students to learn more about the ‘northern lights’, addressing content standards in earth science. The teacher wants the students to learn the scientific terminology, where the phenomena occurs and retrieve some data or graphics for a recent occurrence. The goal of the lesson plan is the engage students, using authentic data from the aurora, as part of an inquiry-based program.

13

Real use cases:Marine habitat - change

Scallop,number,density

Scallop, size,shape, color,place

Scallop,shellfragment

Rock

What is this?

Flora or fauna?

Dirt/ mud; one person’s noise is another person’s signal

Several disciplines; biology, geology, chemistry, oceanography

Several applications; science, fishing, habitat change, climate and environmental change, data integration

Complex inter-relations, questions

Use case: What is the temperature and salinity of the water and are these marine specimens usual or part of an ecosystem change?

Src: WHOI and the HabCam group

14

NEFSC ESRGoal: Efficient generation of figures and tables

representing ecosystem data and information products for the bi-annual (or annual) NEFSC Ecosystem Status Report (ESR).

Let’s look at that use case

15

Use case format

Use case nameGoalSummaryTriggersBasic flowAlternate flowPost conditionsActivity diagramPreconditions in tabular formNotes

16

Use case format?

Short (in document) format for:Exploratory phase of a project where

you want to collect a lot of use cases

An example for others to useIncluding in a proposalFor activities like this!

17

Name and goalConcise name, enough to be recognizable –

avoid jargon or acronyms but allow be as specific as possible

State the goal concisely (we’ll have some examples shortly)

As you iterate with the summary the goal may change… this is okay!

18

Scoping• Focus initially on:• Core functionality• What it takes to implement the use case,

resist early generalizations• May (will) have to iterate on use case and

requirements

• Acknowledge other important issues such as:• Required vs. optional• Non-functional requirements• Available personnel (skills) and resources

19

Summary• For semantics, this is the MOST important

part of the use case

• State the business case (why)

• Describe the background

• Describe the goal in more detail

• Include success and failure scenarios, with measures of each, consequences

• Mention actors (roles, responsibilities)

• Describe how things function

• Describe a successful outcome20

Triggers• Are conditions that initiate the use case, i.e.

come prior to the first step in the normal flow

• Can be scheduled, triggered by an event or person (could be one of the actors if they are inside the use case)

• Often start with one and think of others later

21

Actors• The initial analysis will often have many human

actors

• Begin to see where these can be replaced with machine actors – may require additional encoding

• If you are doing this in a team, take steps to ensure that actors know their role and what inputs, outputs and preconditions are expected of them

• Often, you may be able to ‘run’ the use case (really the model) before you build anything

22

Actors

• Real people (round heads) and computers (block heads)

• E.g. Data provider, end-user, data manager, alert service

• Primary – initiate (act on)• Secondary – respond (acted upon)

23

What’s a pre-condition?

• defines all the conditions that must be true (i.e., describes the state of the system) for the trigger to meaningfully cause the initiation of the use case.

24

Preconditions

• Often the preconditions are very syntactic and you may not understand how they fit in the implementation

• Some level of modeling of these preconditions may be required (often this will not be in your first pass encoding which focuses on the main process flow, goal, description, etc.)

• Beware of using another entities data and services: policies, access rights, registration, and ‘cost’

25

Preconditions - data/model

26

Preconditions - event/application

27

Post-condition?

• describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.

28

Success scenarios

• A re-statement of how the use case via its flows and actors and resources results in achieving the result

• Describe artifacts produced

• Describe impacts and metric values

• (part of Summary)

29

Failure scenarios

• A statement of how the use case via its flows and actors and resources did not result in achieving the result

• Describe role of actors in failure• Describe role of resources in failure• Describe what artifacts were and were not

produced• Describe impacts of failure and any metric

values• (part of summary) 30

Normal (process) flows

• A basis step of (usually) distinct steps that result when the use case is triggered (commences)

• Steps are often separated by actor (name them) intervention or represent modular parts of the flow (can encapsulate activities)

• Can have loops

• Should end with the final goal achieved

31

Process flow• Each element in the process flow usually denotes

a distinct stage in what will need to be implemented

• Consider the activity diagram (and often a state diagram) as a means to turn the written process flow into a visual one that your experts can review

• Make sure the artifacts and services have an entry in the resources section

• This is often the time you may do some searching (web searching…)

32

Alternate (process) flows

• Variations from the main flow, often invoked by valid but non-usual (or rules)

• Activity diagrams are useful in representing this part of the document

• Do not usually represent exceptions/ error flows

• Can often help to identify general patterns in the use case via similarities with the normal flow

• While many are possible, usually only include one - illustrative 33

Non-Functional requirements

• (from Wikipedia): Non-functional requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

• This should be contrasted with functional requirements that specify specific behavior or functions.

• In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. 34

Functional/ non-functional

• (from Wikipedia): Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements".

• Qualities, (non-functional requirements), can be divided into two main categories.• Execution qualities, such as security and usability, are

observable at run time.

• Evolution qualities, such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system. 35

Artifacts

• Add artifacts that the use case generates to the resources list in the table

• It is often useful to record which artifacts are critical and which are of secondary importance

• Be thinking of provenance and the way these were produced, i.e. what went into them and produce suitable metadata or annotations

• Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution)

36

Reviewing the resources• Apart from the artifacts and actor resources, you

may find gaps• Define/ find the authoritative sources for data,

information, metadata, configuration• Your encodings can also be a resource, make it a

first class citizen, e.g. on the web give it a namespace and a URI

• Sometimes, a test-bed with local data is very useful as you start the implementation process, i.e. pull the data, maybe even implement their service (database, etc.)

3737

When someone asks: “What is your use case”?

• Treat it like your ‘elevator pitch’

• Know them, especially the ones you have implemented

• Tell them how you used it to develop a solution for use

38

Diagrams

39


Use Case Examples:

• A US 9th grade teacher is preparing a lesson plan aimed at getting students to learn more about the ‘northern lights’, addressing national science and education standards (SNES) content standards in earth science. The teacher wants the students to learn the scientific terminology, where the phenomena occurs and retrieve some data or graphics for a recent occurrence. The goal of the lesson plan is the engage students, using authentic data from the aurora, as part of an inquiry-based program.

40


Schematic

41


Resources

• http://alistair.cockburn.us/index.php/Use_cases,_ten_years_later• http://www.digilife.be/quickreferences/pt/functional%20requirements%20and%20use

%20cases.pdf• http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases

• http://alistair.cockburn.us/Usecasesintheoryandpractice180.ppt• http://alistair.cockburn.us/Agileusecases1dy.ppt• http://alistair.cockburn.us/index.php/Structuring_use_cases_with_goals• http://www.foruse.com/publications/bibliographies/usecases.htm• http://en.wikipedia.org/wiki/Use_case• http://www.ddj.com/dept/architect/184414701

• Omnigraffle (Mac) www.omnigroup.com/applications/omnigraffle/ or

• Cmap http://cmap.ihmc.us/

42

Developed for NASA TIWG modified for SeS

Notes

• Tactics - users are alien to this process• Facilitator is the key role• The social aspect - brief everyone on their

role and what is expected of them (and what is not)

• UML4US – simplied Universal Modeling Language (arrow, box, stick fig., text)

• Learn how to identify objects, processes, actors/roles, organizations (or nouns, verbs, adjectives) 43

Hint

• Write name, and goal and start on summary• Review goal• List actors, preconditions, trigger, normal

flow• Review summary to make sure these are

well described• Review goal• Review actors, preconditions, trigger, normal

flow, list post-conditions, alternate flows, resources 44

Now

• Use cases!

45

46

Developing a service ontology

• Use case: find and display in the same projection, sea surface temperature and land surface temperature from a global climate model.

• Find and display in the same projection, sea surface temperature and land surface temperature from a global climate model.

46

47

Developing a service ontology• Use case: find and display in the same projection,

sea surface temperature and land surface temperature from a global climate model.– Name:– Goal:– Summary:– Actors:– Preconditions:– Triggers:– Normal flow:– Alternate flow:– Post condition:– Activity diagram:– Notes

47

• Find and display in the same projection, sea surface temperature and land surface temperature from a global climate model.

4848

49

Reminder: Services• Ontologies of services, provides:

– What does the service provide for prospective clients? The answer to this question is given in the "profile," which is used to advertise the service. To capture this perspective, each instance of the class Service presents a ServiceProfile.

– How is it used? The answer to this question is given in the "process model." This perspective is captured by the ServiceModel class. Instances of the class Service use the property describedBy to refer to the service's ServiceModel.

– How does one interact with it? The answer to this question is given in the "grounding." A grounding provides the needed details about transport protocols. Instances of the class Service have a supports property referring to a ServiceGrounding.

49

50

Service ontology• Climate model is a model• Model has domain• Climate Model has component representation• Land surface is-a component representation• Ocean is-a component representation• Sea surface is part of ocean• Model has spatial representation (and temporal)• Spatial representation has dimensions• Latitude-longitude is a horizontal spatial representation• Displaced pole is a horizontal spatial representation• Ocean model has displaced pole representation• Land surface model has latitude-longitude representation• Lambert conformal is a geographic spatial representation• Reprojection is a transform between spatial representation• ….

50

51

Service ontology• A sea surface

model has grid representation displaced pole and land surface model has grid representation latitude-longitude and both must be transformed to Lambert conformal for display

51

52

Summary• Use cases are a powerful tool for

implementing real semantic e-science applications based on what someone needs to DO!

• Use case should drive the functional requirements of both your ontology and how you ‘build’ one

• Small team, mixed skills: starting to learn this is the nature of your next assignment

52

53

Assignments

• Assignment 2: Use-case Driven Knowledge Encoding Part I

• Reading: Ontology Tool Summary, Pellet, OWL-S, SAWSDL, Wine Agent

• Note: Use file name convention on all files and in the subject line of any associated email

53

Assignment 2• Use-case Driven Knowledge Encoding Part I:

– Develop a use case, ‘on your own’ – to do this you may engage domain experts and other team members.

– You will perform the analysis, describe the ontology modeling and knowledge encoding using the methods and tools you have learned to date and document them.

– You may leverage an existing knowledge base and/or ontologies making it clear what you used, modified and created yourself.

– You will also ask and answer questions about the encoding.

• Part II - You will present your use case, using the document format, in class and answer questions. You will have an ontology class and assignment before part II

5454

Documents

Class Exercise I: Use Cases