Use Case:
Collecting data types from the thermodynamic data and registering those at the DCO data portal.
Point of Contact Name: Apurva Kumar Sinha (sinhaa2@rpi.edu)
Use Case Name
Give a short descriptive name for the use case to serve as a unique identifier. Consider goal-driven use case name.
Collecting data types from the thermodynamic data (legacy literature) and registering those at the
DCO data portal.
Goal
The goal briefly describes what the user intends to achieve with this use case.
Register data type at the DCO data portal and associate the data type with a registered
thermodynamic dataset.
Summary
Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal and
principal actor.
Scientist wants to associate his/her dataset with any existing data type at the DCO dataset
browser. When he/she could not find an appropriate data type available at the DCO dataset
browser, he/she tries to register the required data type. This use case focuses on identifying data
types in the thermo dynamic datasets (several papers related to thermo dynamic features of
chemicals and minerals) and registering those data types at the DCO data portal.
Every dataset would be associated with one or more data types by using an object property
dco:hasDatatype.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
1
Actors
List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary
actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary
actor and briefly describe role.
Primary actor: Scientist
Secondary actor: DCO Data portal, Data Type Registry, DCO Data portal site admin
Preconditions
Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about
other systems can also be stated here, for example, weather conditions. List all preconditions.
Scientist is logged into DCO data portal.
Scientist has a dataset that he/she wants to publish at DCO data portal.
Scientist is able to register new data types on the DCO data portal.
DCO dataset browser should automatically show the scientist all the registered data types related
to his/her dataset.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
2
Triggers
Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can
be single events or when a set of conditions are met, List all triggers and relationships.
Scientist searches for the data type that is not registered yet and so he wants to register that data
type.
Basic Flow
Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to
follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the
document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)
1)
Scientist browses the registered data types present in a facet at the DCO dataset browser.
2)
Scientist could not find any relevant data type to associate with his/her dataset.
3)
Scientist navigates to the form for registering data type (Datatype browser).
4)
Scientist enters a label for his/her data type and gives other important information related to that
data type like description, expected uses, source standard, and provenance information.
5)
Scientist browses the existing properties present in a facet and either selects an existing property
or enters the property name in the same facet. He/she repeats this step until all the required
properties are associated the data type.
6)
After submitting the form, Data Type Registry searches for any similar data type both within and
outside DCO and alerts the scientist of any similar existing data type.
7)
8)
Data Type Registry registers that data type and generates a persistent identifier.
Persistent identifier should now be present with that data type along with the creation time of that
data type (populated by the system).
9)
DCO Data Portal Site Admin can register a data type or modify an already registered data type. In
addition to these, DCO Data Portal Site Admin also has the privilege to remove the registered
data types.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
3
Alternate Flow
Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.
1)
Step 6 results in Data Type Registry retrieving similar data types and displaying those at DCO
Datatype browser.
2)
Scientist can select a data type retrieved by the Data Type Registry instead of registering his/her
data type.
3)
Scientist should not be able to edit any registered data type that was registered by someone else.
4)
Scientist cannot ignore to associate his/her dataset with data type as data type would be enforced
as a mandatory field while publishing dataset.
Post Conditions
Here we give any conditions that will be true of the state of the system after the use case has been completed.
That registered data type should be displayed in a facet of the DCO dataset browser screen.
Another facet in the same screen should show all the properties associated with that data type.
That registered data type can be searched at DCO data portal by its label and its associated DCO
ID. DCO dataset browser should show all the registered data types for a data set. DCO dataset
browser should list down all the datasets associated with a data type.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
4
Activity Diagram
Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case.
However often a picture speaks a 1000 words.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
5
Notes
There is always some piece of information that is required that has no other place to go. This is the place for that information.
DCO – Deep Carbon Observatory
Resources
In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured.
These resources include data and services, and the systems that offer them. This section will call out examples of these
resources.
Data:
Data
Type
Characteristics Description
Owner
Source System
Modeling Services
Model
Owner
Description
Consumes
Frequency
Source System
Event Notification Services
Event
Owner
Description
Subscription
Source System
Application Services
Application
Owner
Description
Source System
Other resources
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
6
Resource Owner
UseCase- -Template
Description
Availability
Source System
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
7