Transcript Class Exercise I: Use Cases Deborah McGuinness Semantic eScience 2011 - CSCI-6962-01 Week 4, September 26, 2011 Presented by Peter Fox.

Class Exercise I: Use Cases
Deborah McGuinness
Semantic eScience 2011 - CSCI-6962-01
Week 4, September 26, 2011
Presented by Peter Fox
1
Contents
•
•
•
•
•
Questions on reading?
Use case introduction
Elements of use case documentation
Class exercise – use cases in real-time
Assignment reading: Ontology Tool
Summary, Pellet, OWL-S, SAWSDL,
Wine Agent
2
3
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
5
Developed for NASA TIWG
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
Developed for NASA TIWG
For Ref: Long form of a Use Case
• http://wiki.esipfed.org/index.php/SolutionsUseC
ase_Template
7
Developed for NASA TIWG
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.
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
9
Use case myths
Need 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
Volcano
Atmosphere
Environment
<hastopic>
Exposes goals,
outcomes, actors/
roles, resources,
preconditions, process
flow, artifacts
And … semantics,
terms, concepts and
their relations
Custom Data
Products and
Services
<reports to>
<uses>
Familiar
Application
Tools
<accesses>
Custom Data
Products and
Services
<incorporates>
Hazard
Authority
Hazard
Planner
Summary
Reports
CAP-ready
and other
templates
<uses>
<incorporates>
<curates><uses>
<uses>
<uses>
Data on MSH Volcano,
Local and regional
Atmospheric and
Environment
Agency
Specialist
ISO, FGDC,
OGC, GEO
Standards for
metadata
OGC and
OPeNDAP
Standards for
transport
Summary
Reports
<generatedby>
Science and
Non-specialist
Terminology
<uses>
Hazard
Planner
Hazard Portal
<archivedto>
<uses>
Agency Data Service
USGS, NWS, EPA
<available from>
Science
Terminology
Nonspecialist
Terminology
<based on>
<uses>
<curates>
Data on MSH
Volcano,
Phenomenon
Agency
Specialist
Domain
Vocabulary/
Ontology
Mapping to
Science
Terminology
11
Agency Monitoring
Service USGS,
NWS, EPA
<operates>
Agency
Use Case Examples
• Make a collection of *any data format* model
run datasets available for internet access with
web browsing to find suitable data and
access to the data via Matlab.
12
Developed for NASA TIWG
Use Case Examples:
• Provide browse and quick look access to a
broad variety of climate, weather and ocean
data.
13
Developed for NASA TIWG
Use Case Examples:
• Install an OPeNDAP Hyrax server with
THREDDS cataloging on the front-end to
support netCDF and HDF4 data sets on the
back-end and allow aggregation based on
NcML and authentication of user access
14
Developed for NASA TIWG
Use Case Examples:
• Provide high-performance data transfer of
specific climate model data products into the
climate diagnostics and analysis tool (CDAT)
for analysis, independent of their storage
format, organization or location on the
internet
15
Developed for NASA TIWG
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 NSES
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.
16
Developed for NASA TIWG
Real use cases:
Marine habitat - change
Several disciplines; biology,
geology, chemistry,
Scallop,
oceanography
number,
density
Rock
Scallop,
shell
fragment
Several applications; science,
fishing, habitat change, climate
and environmental change, data
integration
Complex inter-relations,
questions
Flora or fauna?
Use case: What is the
temperature and salinity of the
What is this?
water and are these marine
specimens usual or part of an
ecosystem change? Scallop, size,
shape, color,
17
place
Dirt/ mud; one person’s noise is another person’s signal
Src: WHOI and the HabCam group
NEFSC ESR
Goal: 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
18
Use case format
Use case name
Goal
Summary
Triggers
Basic flow
Alternate flow
Post conditions
Activity diagram
Preconditions in tabular form
Notes
19
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 use
Including in a proposal
For activities like this!
20
Name and goal
Concise 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!
21
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
22
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 outcome
23
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
24
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
25
anything
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)
26
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.
27
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’
28
Preconditions - data/model
Data
Type
Resource
Characteristics Description
Owner
Source System
(dataset
name)
Remote, e.g. – no cloud Short description of the
cover
dataset, possibly including
In situ,
rationale of the usage
Etc.
characteristics
USGS, ESA,
etc.
Name of the
participating
system which
supports
discovery and
access
Model
Owner
Frequency
Source System
(model
name)
Organization Short
List of data consumed
that offers
description of
the model
the model
How often the
model runs
Name of the
participating
system which
offers access to
the model
Description
Consumes
29
Preconditions - event/application
Event
Owner
(Event
name)
Organization Short description of the event
that offers
the event
Application/ Owner
Description
Description
DSS
(Application Organization Short description of the application
name)
that offers
the
Application
Relevant
subscription
Source System
List of
subscriptions
(and owners)
Name of the
participating
system which
offers this
event
Source
System
Name of the
participating
system
which offers
this event
30
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.
31
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)
32
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)
33
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
34
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…)
35
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
36
one - illustrative
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.
37
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.
38
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)
39
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.)
40
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
41
Diagrams
42
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 NSES
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.
43
Developed for NASA TIWG
Schematic
44
Developed for NASA TIWG
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/
45
Developed for NASA TIWG
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 (arrow, box, stick fig., text)
• Learn how to identify objects, processes,
actors/roles, organizations (or nouns, verbs,
adjectives)
46
Developed for NASA TIWG
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
47
Now
• Use cases!
48
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.
49
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
50
• Find and display in the same projection,
sea surface temperature and land surface
temperature from a global climate model.
51
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 52
ServiceGrounding.
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
….
53
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
54
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
55
Assignments for Week 4
• Assignment 2: Use-case Driven Knowledge
Encoding Part I (Part II is class presentation,
in Class 6, due TUESDAY Oct. 11. 1pm ET)
• 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
56
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, 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.
• You will present your use case, using the
document format, in class and answer
questions.
57