1. The RPI semantic development methodology: Use cases as starting points for assessing semantic web technologies that achieve project goals February 13, 2013, St. Petersburg, FL Peter Fox (RPI* and WHOI**) pfox@cs.rpi.edu and OTHERS!!pfox@cs.rpi.edu *Tetherless World Constellation, ** AOP&E

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

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

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

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

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

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

8. Virtual organizations as Socio-Technical Systems Technology Communication Patterns Organizational Structure

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

10. Credit: B. Rouse (BEVO) 2008

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

14. 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 1 st ….

15. (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’

16. Scale free?

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

18. Ecosystems need diversity, many types SO … partnerships, coordination, etc. (12) Stimulating the network

19. What about meaning? Named and typed relationships

20. And more…

21. (13) Method We also get a lot of other stuff –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

22. Modern informatics enables a new scale-free** framework approach Use cases Stakeholders Distributed authority Access control Ontologies Maintaining Identity

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

24. NEFSC ESR

25. 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 Constellation25

26. Questions so far?

27. Team

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

29. Analysis

30. Use Cases Expose System Requirements Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts And … semantics, terms, concepts and their relations

31. Goal of Analysis Get the team a shared understanding of who is in the use case, what they do and interact with, and what the stages of the use case, and relations are To get an informal visual representation of the use case that begins to sync up with the written material The order in which to do this is dependent on the team

32. Model

33. Data-Information-Knowledge Ecosystem 33 DataInformationKnowledge ProducersConsumers Context Presentation Organization Integration Conversation Creation Gathering Experience Curators

34. Information Modeling Conceptual Logical Physical 34

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

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

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

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

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

40. For example for relational DBs 40 FeatureConceptual Logical Physical Entity Names ✓✓ Entity Relationships ✓✓ Attributes ✓ Primary Keys ✓✓ Foreign Keys ✓✓ Table Names ✓ Column Names ✓ Column Data Types ✓

41. One more example 41

42. 42

43. Physical Information Models PIMs are used to –design the internal schema (e.g. of a database, or file), –depict the structured information (e.g. tables), –specify the layout of those structures (e.g. columns of those tables) –specify the relationships between the structures (e.g. primary keys). 43

44. Steps in modeling Identify entity types Identify attributes Apply naming conventions Identify relationships Apply model patterns Assign relationships Normalize to reduce redundancy (this is called refactoring in software engineering)** Denormalize to improve performance** 44

45. Not just an isolated set of models They handle errors, evolution, … NOT to the physical model Sometimes to the logical model Prefer to the conceptual model? Relating to and/ or integrating with other information models? –General rule – integrate at the highest level you can (i.e. more abstract) –Remember the cognitive aspects, i.e. less detail 45

46. Tools for modeling.. Concept mapping - http://cmap.ihmc.us/ http://cmap.ihmc.us/ Models - http://www.datamodel.org/ http://www.datamodel.org/ –MSDN: http://msdn.microsoft.com/en- us/library/bb399249.aspxhttp://msdn.microsoft.com/en- us/library/bb399249.aspx Schema –differs in basic concept from other schema languages –not based on grammars but on finding tree patterns in the parsed document –approach allows many kinds of structures to be represented which are inconvenient and difficult in grammar-based schema languages. –http://www.schematron.com/http://www.schematron.com/ 46

47. Tools

48. CMAP Ontology Editor (concept mapping tool from IHMC - http://cmap.ihmc.us/coe )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 _softwarehttp://en.wikipedia.org/wiki/List_of_mind_mapping _software White board Piece of paper … you get the idea… 48

49. Review

50. These come later Technology assessment Leverage infrastructure Rapid prototyping Evaluation Open world, iteration

51. Use case!

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

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

54. 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 …

55. Use Cases Expose System Requirements Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts And … semantics, terms, concepts and their relations

56. Real use cases: Marine habitat - change Scallop, number, density Scallop, size, shape, color, place Scallop, shell fragment 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

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

58. Developed for NASA TIWG Use case format Use case name Goal Summary Triggers Basic flow Alternate flow Post conditions Activity diagram Preconditions in tabular form Notes

59. Developed for NASA TIWG 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!

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

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

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

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

64. 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’ 64

65. Developed for NASA TIWG Preconditions - data/model

66. Developed for NASA TIWG Preconditions - event/application

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

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

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

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

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

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

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

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

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

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

77. If you have not developed one Try reverse engineering Start with a personal example e.g. balancing your checkbook 77

78. 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.pdfhttp://www.digilife.be/quickreferences/pt/functional%20requirements %20and%20use%20cases.pdf http://alistair.cockburn.us/index.php/Resources_for_writing_use_cas eshttp://alistair.cockburn.us/index.php/Resources_for_writing_use_cas es http://alistair.cockburn.us/Usecasesintheoryandpractice180.ppt http://alistair.cockburn.us/Agileusecases1dy.ppt http://alistair.cockburn.us/index.php/Structuring_use_cases_with_go alshttp://alistair.cockburn.us/index.php/Structuring_use_cases_with_go als 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/ orwww.omnigroup.com/applications/omnigraffle/ Cmap http://cmap.ihmc.us/coehttp://cmap.ihmc.us/coe

79. Questions?

80. Tomorrow… 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

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