the rpi semantic development methodology: use cases as starting points for assessing semantic web...

The RPI semantic development methodology: Use cases as starting points for assessing semantic web technologies that achieve project

goals (aka ‘sheesh’)September 21, 2011, Woods Hole, MA

Peter Fox (RPI* and WHOI**) [email protected] and OTHERS!!*Tetherless World Constellation, ** AOP&E

What’s ahead

• Start with a vision

• What’s the goal?

• Attributes in collaboratories/ networks

• Matching with a development methodology– Use cases, and more…– Scale

• Jumping off point … to …

2Tetherless World Constellation

Vision?

• “Our vision is to develop, facilitate, and maintain sustained multi-way engagement of natural and social (?) scientists and practitioners in multi-scale local to global networks” [for X]. – Organization is required so participants (3) can

carry out mission(s)– Those participants (by defn.) may never be in

a single organization -> virtual organization (1)

Goal (2)

• We want to perform X involving all (or as many) stakeholders and we want robust science data presented in forms that various end-users can consume…

• Or similar – a point of discussion – now or later (13)

(1) Virtual Organization

• Outcomes/ values (4)

• Dynamic versus static (5)

• Evolvable/ ecosystem-like (6)

• Heterogenetic tolerance (7)

• Attributes of the organization (8)

• Roles/ responsibilities (9)

• Scale (10) or scalability

Virtual organizations – many defn.

• ‘ …a geographically distributed organization whose members are bound by a long-term common interest or goal, and who communicate and coordinate their work through information technology’ (Ahuja)

Roles and relationships

• ‘These members assume well defined roles and status relationships within the context of the virtual group that may be independent of their role and status in the organization employing them’ (Ahuja et al., 1998).

Virtual organizations as Socio-Technical Systems

Technology

Communication Patterns

OrganizationalStructure

Communication patterns

A key feature of virtual organizations is a high degree of informal communication

Because of a lack of formal rules, procedures, clear reporting relationships, and norms, more extensive informal communication is required

Credit: B. Rouse (BEVO) 2008

Mapping

• (2) goal -> use case• (3) participation -> team(s), vetting,

acceptance• (4) outcomes/ vaue -> goals, metrics,

evaluation, incentives, data/information/ knowledge projects, responses, decisions

• (5) dynamic -> agile working format, small iterations

• (6) evolution -> rapid development, evaluation and iteration (open)

Mapping (ctd.)

• (7) heterogeneity -> information modeling approach

• (8) organizational attributes -> networks (10)• (9) roles/ responsibilities -> actors in the use

case

• Application of social-technical (and socio-ecological) understandings leads to an informatics methodology … but 1st….

(10) Scale(s)

• Multiple modes – spatial, temporal, discipline, etc.

• Scale-free networks– Citation networks– The Web– Semantic networks– Depend on super nodes (11)

• Semantic networks are ones where the nodes and relations are ‘named and typed’

Scale free?

(11) Super nodes

• People (you!)

• Organizations

• Computational infrastructure

• Data and information services

• Roles/ responsibilites and resulting delegation to the smaller nodes around the super nodes

• Ecosystems need diversity, many types

• SO … partnerships, coordination, networks, work, ongoing, etc.

(12) Stimulating the network

What about meaning?

• Sustained?

• Evolved?

Named and typed relationships

And more…

(13) Method

• We also get a lot of other stuff for ‘free’– Provenance (explanation…)– Extensibility– Application integration– Terminology mediation

• Usually at this stage, we start on …– Use case(s), including activity diagram– Information modeling– Evaluation and iteration

Modern informatics enables a new scale-free** framework approach

• Use cases• Stakeholders• Distributed

authority• Access control• Ontologies• Maintaining

Identity

NEFSC ESR

• Goal: Efficient generation of figures and tables representing ecosystem data and information products for the bi-annual (or annual) North-east Fisheries Science Center = NEFSC Ecosystem Status Report (ESR).

• Let’s look at that use case

NEFSC ESR

Systems v. Frameworks

• Rough definitions– Systems have very well-define entry and

exit points. A user tends to know when they are using one. Options for extensions are limited and usually require engineering

– Frameworks have many entry and use points. A user often does not know when they are using one. Extension points are part of the design

Tetherless World Constellation 25

Questions so far?

Developed for NASA TIWG

Team: Roles and skill-sets needed

• Facilitator *** (usual key skills, knows method)• Domain experts (literate, knows resources; data,

applications, tools, etc.)• Modelers (to extract concepts, etc.)• Software engineers (architecture, technology)• Scribe (to write everything down)• The social aspect is key - it is a team effort

Analysis

Information Modeling

• Conceptual

• Logical

• Physical

31

Information Models

• Conceptual models, sometimes called domain models, are typically used to explore domain concepts and often created – as part of initial requirements envisioning efforts

as they are used to explore the high-level static business or science or medicine structures and concepts

– as the precursor to logical models or as alternatives to them

• Followed by logical and physical models

32

Object oriented design

• Object-oriented modeling is a formal way of representing something in the real world (draws from traditional set theory and classification theory). Some basics to keep in mind in object-oriented modeling are that:– Instances are things.– Properties are attributes.– Relationships are pairs of attributes.– Classes are types of things.– Subclasses are subtypes of things.

33

Logical models

• A logical entity-relationship model is provable in the mathematics of data science. Given the current predominance of relational databases, logical models generally conform to relational theory.

• Thus a logical model contains only fully normalized entities. Some of these may represent logical domains rather than potential physical tables.

34

Logical models

• For a logical data model to be normalized, it must include the full population of attributes to be implemented and those attributes must be defined in terms of their domains or logical data types (e.g., character, number, date, picture, etc.).

• A logical data model requires a complete scheme of identifiers or candidate keys for unique identification of each occurrence in every entity

35

Physical models

• A physical model is a single logical model instantiated in a specific information system (e.g., relational database, RDF/XML document, etc.) in a specific installation.

• The physical model specifies implementation details which may be features of a particular product or version, as well as configuration choices for that instance.

36

Tools

• CMAP Ontology Editor (concept mapping tool from IHMC - http://cmap.ihmc.us/coe )– Drag/drop visual development of classes, subclass

and property relationship– Read and writes OWL– Formal convention (OWL/RDF tags, etc.)

• Mindmapping– http://en.wikipedia.org/wiki/

List_of_mind_mapping_software

• White board• Piece of paper … you get the idea…

38

Review

These come later

• Technology assessment

• Leverage infrastructure

• Rapid prototyping

• Evaluation

• Open world, iteration

Use case!

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.

– can also capture non-functional requirements

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

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 …

Use Cases Expose System Requirements

• Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts

• And … semantics, terms, concepts and their relations

Real use cases:Marine habitat - change

Scallop,number,density

Scallop, size,shape, color,place

Scallop,shellfragment

Rock

What is this?

Flora or fauna?

Dirt/ mud; one person’s noise is another person’s signal

Several disciplines; biology, geology, chemistry, oceanography

Several applications; science, fishing, habitat change, climate and environmental change, data integration

Complex inter-relations, questions

Use case: What is the temperature and salinity of the water and are these marine specimens usual or part of an ecosystem change?

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


Use case format

• Use case name• Goal• Summary• Triggers• Basic flow• Alternate flow• Post conditions• Activity diagram• Preconditions in tabular form• Notes


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!

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

51


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?

• 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

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

54


Preconditions - data/model


Preconditions - event/application


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

• 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

• 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

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

61


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


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.


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

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

65


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

• Try reverse engineering • Start with a personal example

e.g. balancing your checkbook

67


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

Questions?

Now

• You start on use cases, i.e. filling in the document

• Idea is to get a rough draft of the full document – proceeding ~ linearly through the sections, with moderate detail

• Complete accuracy is nice but optional

• Generate 2 or 3 use cases

Tomorrow

• We’ll review some of your use cases and conduct a ‘few’ of the next steps– Use case scoping and refactoring– Generating activity diagrams– Analysis and information modeling

(depending on how far we get)

the rpi semantic development methodology: use cases as starting points for assessing semantic web...

Documents