1 Class Exercise I: Use Cases Deborah McGuinness and Peter Fox (NCAR) CSCI Week 4, 2008

Contents Use case introduction Elements of use case documentation Class exercise – use cases in real-time Assignment reading: Ontology Tool Summary, Pellet, OWL-S, Wine Agent 2

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. Use Case Small Team, mixed skills Analysis Adopt Technology Approach Leverage Technology Infrastructure Rapid Prototype Open World: Evolve, Iterate, Redesign, Redeploy Use Tools Science/Expert Review & Iteration Develop model/ ontology

4 Ontology Spectrum Catalog/ ID Selected Logical Constraints (disjointness, inverse, …) Terms/ glossary Thesauri “narrower term” relation Formal is-a Frames (properties) Informal is-a Formal instance Value Restrs. General Logical constraints Originally from AAAI Ontologies Panel by Gruninger, Lehmann, McGuinness, Uschold, Welty; – updated by McGuinness. Description in:

Developed for NASA TIWG 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 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 e_Templatehttp://wiki.esipfed.org/index.php/SolutionsUseCas e_Template Start with the Plain Language Description –Short DefinitionShort Definition –PurposePurpose –Describe a scenario of expected useDescribe a scenario of expected use –Definition of SuccessDefinition 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 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 ActorsPrimary Actors –Other ActorsOther 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

Developed for NASA TIWG Preconditions - event/application

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)

Developed for NASA TIWG Actors Data provider End-user Data manager

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

Developed for NASA TIWG Resources 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

35 Use Case analysis/ model Plot the neutral temperature from the Millstone-Hill Fabry Perot, operating in the vertical mode during January 2000 as a time series. Objects: –Neutral temperature is a (temperature is a) parameter –Millstone Hill is a (ground-based observatory is a) observatory –Fabry-Perot is a interferometer is a optical instrument is a instrument –Vertical mode is a instrument operating mode –January 2000 is a date-time range –Time is a independent variable/ coordinate –Time series is a data plot is a data product

36 Class and property example Parameter –Has coordinates (independent variables) Observatory –Operates instruments Instrument –Has operating mode Instrument operating mode –Has measured parameters Date-time interval Data product

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

38 Developing ontologies Use cases and small team (7-8; 2-3 domain experts, 2 knowledge experts, 1 software engineer, 1 facilitator, 1 scribe) Identify classes and properties (leverage controlled vocab.) –Start with narrower terms, generalize when needed or possible –Data integration - often requires broader terms –Adopt a suitable conceptual decomposition (e.g. SWEET) –Import modules when concepts are orthogonal Minimal properties to start, add only when needed Mid-level to depth - i.e. neither top-down nor bottom-up Review, review, review, vet, vet, vet, publish - (experiences, results, lessons learned, AND your ontologies AND discussions) Only code them (in RDF or OWL) when needed (CMAP, …) Ontologies: small and modular

39 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

40 Assignments for Week 4 Note; next week (4) is the use case exercise Reading: Ontology Tool Summary, Pellet, OWL-S, Wine Agent No Assignment

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

Diagrams

Developed for NASA TIWG Table of Contents ==Plain Language Description== ===Short Definition=== ===Purpose=== ===Describe a scenario of expected use=== ===Definition of Success=== ==Formal Use Case Description== === Use Case Identification=== ===Revision Information=== ===Definition=== ===Successful Outcomes=== ===Failure Outcomes=== ==General Diagrams== ===Schematic of Use case=== ==Use Case Elaboration== ===Actors=== ====Primary Actors==== ====Other Actors==== ===Preconditions=== ===Postconditions=== ===Normal Flow (Process Model)=== ===Alternative Flows=== ===Special Functional Requirements=== ===Extension Points=== ==Diagrams== ===Use Case Diagram=== ===State Diagram=== ===Activity Diagram=== ===Other Diagrams=== ==Non-Functional Requirements== ===Performance=== ===Reliability=== ===Scalability=== ===Usability=== ===Security=== ===Other Non-functional Requirements=== ==Selected Technology== ===Overall Technical Approach=== ===Architecture=== ===Technology A=== ====Description==== ====Benefits==== ====Limitations==== ===Technology B=== ====Description==== ====Benefits==== ====Limitations==== ==References== ==Diagrams== ===Use Case Diagram=== ===State Diagram=== ===Activity Diagram=== ===Other Diagrams=== ==Non-Functional Requirements== ===Performance=== ===Reliability=== ===Scalability=== ===Usability=== ===Security=== ===Other Non-functional Requirements=== ==Selected Technology== ===Overall Technical Approach=== ===Architecture=== ===Technology A=== ====Description==== ====Benefits==== ====Limitations==== ===Technology B=== ====Description==== ====Benefits==== ====Limitations==== ==References==