Transcript Class Exercise I: Use Cases Deborah McGuinness and Peter Fox CSCI-6962-01 Week 4, September 28, 2009

Class Exercise I: Use Cases
Deborah McGuinness and Peter Fox
CSCI-6962-01
Week 4, September 28, 2009
1
Key Points Regarding Flu
Epidemics
•
Wash your hands often, especially after shaking hands with others (use hand
disinfectants if there is no access to soap and water).
•
Avoid close contact with people who are sick
•
Cover your mouth and nose with a tissue when coughing or sneezing. If you don't
have a tissue, use the inside of your elbow.
•
Do not touch your eyes, nose, or mouth, especially after contact with shared
keyboards, microscopes, instruments, or other people.
•
STAY HOME-If you have flu-like symptoms (i.e., fever (100 degrees F [37.8
decrees C] or higher, cough, sore throat, runny or stuffy nose, body aches,
headache, chills, fatigue).
•
For more information http://www.rpi.edu/about/flu/ .
Contents
•
•
•
•
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
3
Semantic Web Methodology and
Technology Development Process
•
•
Establish and improve a well-defined methodology vision for
Semantic Technology based application development
Leverage controlled vocabularies, et c.
Rapid
Open World:
Evolve, Iterate, Prototype
Redesign,
Redeploy
Leverage
Technology
Infrastructure
Adopt
Science/Expert
Technology
Approach Review & Iteration
Use Tools
Analysis
Use Case
Small Team,
mixed skills
Develop
model/
ontology
4
Use Case
• is a collection of possible sequences of
interactions between the system under
discussion and its Users (or 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.
Developed for NASA TIWG
Use Case
• 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 IT system to support the
business system.
Developed for NASA TIWG
Use Case
• Must be documented (or it is useless)
• Should be implemented (or it is not well
scoped)
• Is used to identify: objects ~ resources,
processes, roles (aka actors), requirements,
etc.
• Should iterate with experts on wording and
details at least once
Developed for NASA TIWG
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
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
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)
Developed for NASA TIWG
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.
Developed for NASA TIWG
Use Case Examples:
• Provide browse and quick look access to a
broad variety of climate, weather and ocean
data.
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
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
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.
Developed for NASA TIWG
Elements of a Use Case
• http://wiki.esipfed.org/index.php/SolutionsUseCas
e_Template
• Start with the Plain Language Description
–
–
–
–
Short Definition
Purpose
Describe a scenario of expected use
Definition of Success
Developed for NASA TIWG
Short Definition
• Define the use case in plain sentences
• Wherever possible avoid specifying technical
solutions or implementation choices
• Concentrate on the application aspects of the
intended scenario
• Also note when the use case may be applicable
to more than one application area
Developed for NASA TIWG
Purpose
• A plain language description of
– why this use case exists,
– what the problem is to be solved, and
– what a successful outcome, and
– what the impact may be.
• Often termed the ‘business case’
Developed for NASA TIWG
Scenario of expected use
• A verbose (more detailed) description of one instance of a
problem to be solved
–
–
–
–
what resources are generally needed (if known)
what a successful outcome and impact may be
who might be expected to do the work or provide the resources and
who might be expected to benefit from the work.
• List any performance or metric requirements for this use
case and any other other considerations that a user would
expect.
Developed for NASA TIWG
Definition of Success
• Quick test that would show whether or not
the case is working as described.
Developed for NASA TIWG
At this stage
• Use case modelers should have a good sense of
what the use case goal is.
• They proceed on to the next stage to extract details.
• They may contact other team members, e.g.
domain experts, one-on-one for additional
information.
Developed for NASA TIWG
Formal Use Case
Description
•
•
•
•
•
Use Case Identification
Revision Information
Definition
Successful Outcomes
Failure Outcomes
Developed for NASA TIWG
General Diagrams
• Schematic of Use case
• How to draw diagrams:
–
–
–
–
Stick figures for actors (person or computer)
Boxes to denote resources
Arrows to denote process flow
Concept maps are a useful tool
Developed for NASA TIWG
Diagrams
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.
Developed for NASA TIWG
Schematic
Developed for NASA TIWG
Use Case Elaboration
• Actors
– Primary Actors
– Other Actors
•
•
•
•
•
•
Preconditions
Postconditions
Normal Flow (Process Model)
Alternative Flows
Special Functional Requirements
Extension Points
Developed for NASA TIWG
Diagrams
•
•
•
•
Use Case Diagram
State Diagram
Activity Diagram
Other Diagrams
Developed for NASA TIWG
Non-functional requirements
•
•
•
•
•
•
Performance
Reliability
Scalability
Usability
Security
Other Non-functional Requirements
Developed for NASA TIWG
Alternate form
•
•
•
•
•
•
•
•
Use case name
Summary
Activity diagram
Preconditions in tabular form
Triggers
Basic flow
Alternate flow
Post conditions
Developed for NASA TIWG
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 t o
the model
Description
Consumes
Developed for NASA TIWG
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
Developed for NASA TIWG
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
Which format to use?
• 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
– In an assignment (hint)
• Long (on wiki) format for:
–
–
–
–
Detailed documentation of the use case
Life cycle documentation for implementation
Asynchronous/ collaborative development
Part of a group assignment (another hint)
Developed for NASA TIWG
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
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
35
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)
Developed for NASA TIWG
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.
Developed for NASA TIWG
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’
38
What’s a 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.
Developed for NASA TIWG
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
Developed for NASA TIWG
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
Developed for NASA TIWG
Normal (process) flows
• A basis step of (usually) distinct steps that
result when the use case is triggers
(commences)
• Steps are often separated by actor
intervention or represent modular parts of
the flow (can encapsulate activities)
• Can have loops
• Should end with the final goal achieved
Developed for NASA TIWG
Process flow
• Each element in the process flow usually denotes
a distinct stage in what will need to be
implemented
• Often, actors mediate the process flow
• 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
(no, not soul searching – web searching…)
43
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 Developed for NASA TIWG
Functional/ non-functional
• (from Wikipedia): 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.
Developed for NASA TIWG
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, aka. 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.
Developed for NASA TIWG
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)
47
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.)
48
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
Developed for NASA TIWG
If you have not developed one
• Try reverse engineering
• Start with a personal example
• E.g. balancing your checkbook
50
Resources
•
•
•
•
•
•
•
•
•
•
•
•
http://alistair.cockburn.us/index.php/Use_cases,_ten_years_later
http://members.aol.com/acockburn/papers/AltIntro.htm
http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases
http://alistair.cockburn.us/images/Usecasesintheoryandpractice180.ppt
http://alistair.cockburn.us/images/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) or
Cmap
wiki template
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)
• Functional versus non-functional requirements and
how to tell the difference
Developed for NASA TIWG
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.
53
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
54
• Find and display in the same projection,
sea surface temperature and land surface
temperature from a global climate model.
55
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 56
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
….
57
Service ontology
• A sea surface model has grid representation displaced pole
and land surface model has grid representation latitudelongitude and both must be transformed to Lambert
conformal for display
58
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
59
Assignments for Week 4
• Assignment 2: Use-case Driven Knowledge
Encoding Part I (part II is class presentation,
in class 6, due TUESDAY Oct. 13. 1pm ET)
• Reading: Ontology Tool Summary, Pellet,
OWL-S, SAWSDL, Wine Agent
60
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.
61