Class exercise i use cases
This presentation is the property of its rightful owner.
Sponsored Links
1 / 60

Class Exercise I: Use Cases PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on
  • Presentation posted in: General

Class Exercise I: Use Cases. Deborah McGuinness and Joanne Luciano with Peter Fox and Li Ding CSCI-6962-01 Week 4, September 27, 2010 Presented by Peter Fox. Contents. Use case introduction Elements of use case documentation Class exercise – use cases in real-time

Download Presentation

Class Exercise I: Use Cases

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Class exercise i use cases

Class Exercise I: Use Cases

Deborah McGuinness and Joanne Luciano

with Peter Fox and Li Ding

CSCI-6962-01

Week 4, September 27, 2010

Presented by Peter Fox


Contents

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


Semantic web methodology and technology development process

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.

Adopt Technology Approach

Leverage Technology Infrastructure

Science/Expert Review & Iteration

Rapid Prototype

Open World: Evolve, Iterate, Redesign, Redeploy

Use Tools

Analysis

Use Case

Develop model/ ontology

Small Team, mixed skills


Use case

Developed for NASA TIWG

Use Case

  • A 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.


Use case1

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.


Use case2

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


Roles and skill sets needed

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


Roles and skill sets

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


Class exercise i use cases

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)


Use case examples

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.


Use case examples1

Developed for NASA TIWG

Use Case Examples:

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


Use case examples2

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


Use case examples3

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


Use case examples4

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.


Elements of a use case

Developed for NASA TIWG

Elements of a Use Case

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

  • Start with the Plain Language Description

    • Short Definition

    • Purpose

    • Describe a scenario of expected use

    • Definition of Success


Short definition

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


Purpose

Developed for NASA TIWG

Purpose

  • A plain language description of

    • why this use case exists,

    • what the problem is to be solved,

    • what a successful outcome, and

    • what the impact may be.

  • Often termed the ‘business case’


Scenario of expected use

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.


Definition of success

Developed for NASA TIWG

Definition of Success

  • Quick test that would show whether or not the case is working as described.


At this stage

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.


Formal use case description

Developed for NASA TIWG

Formal Use Case Description

  • Use Case Identification

  • Revision Information

  • Definition

  • Successful Outcomes

  • Failure Outcomes


General diagrams

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


Diagrams

Diagrams


Use case examples5

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.


Schematic

Developed for NASA TIWG

Schematic


Use case elaboration

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


Diagrams1

Developed for NASA TIWG

Diagrams

  • Use Case Diagram

  • State Diagram

  • Activity Diagram

  • Other Diagrams


Non functional requirements

Developed for NASA TIWG

Non-functional requirements

  • Performance

  • Reliability

  • Scalability

  • Usability

  • Security

  • Other Non-functional Requirements


Alternate form

Developed for NASA TIWG

Alternate form

  • Use case name

  • Summary

  • Activity diagram

  • Preconditions in tabular form

  • Triggers

  • Basic flow

  • Alternate flow

  • Post conditions


Preconditions data model

Developed for NASA TIWG

Preconditions - data/model


Preconditions event application

Developed for NASA TIWG

Preconditions - event/application


Which format to use

Developed for NASA TIWG

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)


Scoping

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

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


Actors1

Developed for NASA TIWG

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)


What s a pre condition

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.


Preconditions

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’


What s a post condition

Developed for NASA TIWG

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.


Success scenarios

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


Failure scenarios

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


Normal process flows

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


Process flow

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…)


Alternate process flows

Developed for NASA TIWG

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


Functional non functional

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.


Functional non functional1

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, (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.


Artifacts

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)


Reviewing the resources

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.)


When someone asks what is your use case

Developed for NASA TIWG

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


If you have not developed one

If you have not developed one

  • Try reverse engineering

  • Start with a personal example

    e.g. balancing your checkbook


Resources

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/

  • wiki template


Notes

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


Developing a service ontology

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 sameprojection, sea surface temperature and land surface temperaturefrom a global climate model.


Developing a service ontology1

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


Class exercise i use cases

  • Find and display in the sameprojection, sea surface temperature and land surface temperaturefrom a global climate model.


Reminder services

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.


Service ontology

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

  • ….


Service ontology1

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


Summary

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


Assignments for week 4

Assignments for Week 4

  • Assignment 2: Use-case Driven Knowledge Encoding Part I (Part II is class presentation, in Class 6, due TUESDAY Oct. 12. 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 assiciated email


Assignment 2

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.


  • Login