Execution qualities

Document Sample
Execution qualities Powered By Docstoc
					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.


                                                  Adopt
                                Leverage        Technology Science/Expert
 Open World:       Rapid      Technology         Approach Review & Iteration
Evolve, Iterate, Prototype   Infrastructure
  Redesign,
  Redeploy
                                                                         Use Tools


                                                Analysis
                  Use Case


                                 Small Team,                      Develop
                                                                                 4
                                 mixed skills                      model/
                                                                  ontology
                   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        Characteristics Description                Owner           Source System
Resource
(dataset   Remote, e.g. Ğno cloud Short description of the      USGS, ESA,      Name of the
name)      In situ, cover         dataset, possibly including   etc.            participating
                                  rationale of the usage                        system which
           Etc.                   characteristics                               supports
                                                                                discovery and
                                                                                access




Model      Owner        Description     Consumes                Frequency       Source System
(model     Organization Short          List of data consumed    How often the   Name of the
name)      that offers  description of                          model runs      participating
           the model    the model                                               system which
                                                                                offers accessto
                                                                                the model




                                      Developed for NASA TIWG
                      Preconditions -
                     event/application
Event    Owner         Description                               Relevant        Source System
                                                                 subscription
(Event   Organization Short description of the event             List of         Name of the
name)    that offers                                             subscriptions   participating
         the event                                               (and owners)    system which
                                                                                 offers this
                                                                                 event

Application/ Owner          Description                                           Source
DSS                                                                               System

(Application Organization Short description of the application                    Name of the
name)        that offers                                                          participating
             the                                                                  system
             Application                                                          which offers
                                                                                  this event




                                     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
                      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:
                                                       54
  –   Notes
• 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 latitude-
  longitude 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                       61

  questions.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:16
posted:7/27/2012
language:English
pages:61