Software Engineering Fall 2005
Ontology Management System
Software Requirements Specification
Version <1.4
2/16/2006
CS 4310 Fall 2005 / OntologySRSv1.4.docOntology Management System
Document Control
Approval
The Guidance Team and the customer will approve this document.
Document Change Control
Initial Release: / December 20, 2005Current Release: / February16, 2006
Indicator of Last Page in Document: /
Date of Last Review: / TBD
Date of Next Review: / TBD
Target Date for Next Update: / TBD
Distribution List
This following list of people will receive a copy of this document every time a new version of this document becomes available:
Guidance Team Members:
Dr. Ann Gates
Dr. Thamar Solorio
Elsa Tai
Customer(s):Dr. Randy Keller
Leonardo Salayandía
Software Teams:
EngineSoft
Eisen Corp
Mexsys Corporation
Hades Inc
Solution Developers Inc.
CompuGlobalHyperMegaNet
Intelligent Software Systems
Gemini Software Development
Change Summary
The following table details changes made between versions of this document
Version / Date / Modifier / Description1.0 / 12/20/2005 / E. Tai / Section 1 and 2: Combining information from teams’ SRS
1.1 / 1/26/06 / Ann Gates and Leo Salayandía / Section 2: Cleaning use case diagram, Section 3: Cleaning and adding requirements.
1.2 / 1/31/06 / Ann Gates and Leo Salayandía / Section 2: UC Diagram, Browse and Query merged into Retrieve.
1.3 / 2/7/06 / Ann Gates and Leo Salayandía / Section 2: Completed
Appendices A and B edited, diagrams are still pending
Section 3: Cleaning and adding requirements.
1.4 / 2/15/06 / Ann Gates and Leo Salayandía / Section 3.1.1.2: Completed
Subsections for actors, use cases, and scenarios
Corrected grammar and text in Section 1.
Table of Contents
Document Control
Approval
Document Change Control
Distribution List
Change Summary
1.Introduction
1.1.Purpose and Intended Audience
1.2.Scope of Product
1.3.Definitions, Acronyms, and Abbreviations
1.3.1.Definitions
1.3.2.Acronyms
1.3.3.Abbreviations
1.4.Overview
1.5.References
2.General Description
2.1.Product Perspective
2.2.Product Features
2.2.1.Actors
2.2.2.Use Cases
2.2.3.Scenarios
2.3.User Characteristics
2.4.General Constraints
2.5.Assumptions and Dependencies
3.Specific Requirements
3.1.External Interface Requirements
3.1.1.User Interfaces
3.1.2.Hardware Interfaces
3.1.3.Software Interfaces
3.1.4.Communications Interfaces
3.2.Behavioral Requirements
3.2.1.Same Class of User
3.2.2.Related Real-world Objects
3.2.3.Related Features
3.2.4.Stimulus
3.2.5.Functional
3.3.Non-behavioral Requirements
3.3.1.Performance Requirements
3.3.2.Qualitative Requirements
3.3.3.Maintainability
3.3.4.Portability
3.3.5.Security
3.3.6.Design and Implementation Constraints
3.4.Other Requirements
Appendix A. Diagrams
A.1 Ontology OMT Diagram
A.2 Data Flow Diagrams
i.Scenario #1: Retrieve
ii.Scenario #2: Contribute
iii.Scenario #3: Validate
A.3 State Charts
iv.Scenario #3: Contribute
v.Scenario #4: Validate
Appendix B. OWL format
B.1 OWL Base Ontology
B.2 Concept Name Tag
B.3 Annotation Tag for Resource URI
Ontology Management System / CS 4310 Fall 2005 / Version: 1.42/16/2006 / Page 1Software Requirements Specification
1.Introduction
1.1.Purpose and Intended Audience
The purpose of the Software Requirements Specification (SRS) is to give the customer a clear and precise description of the functionality of the proposed Ontology Management System (OMS). The SRS divides the system requirements into two parts, behavioral and non-behavioral requirements. The behavioral requirements describe the interaction between the system and its environment. Non-behavioral requirements relate to the definition of the attributes of the product as it performs its functions. This includes the level of security, efficiency, reliability, maintainability, portability, capacity, and the standards of compliance of the product. The intended audience of the SRS is the Geology Department at The University of Texas at El Paso (UTEP) and the development team. This document serves as an agreement between both parties regarding the product to be developed.
1.2.Scope of Product
GEOsciences Network (GEON) is an NSF-funded IT research program to conduct fundamental research towards developing a cyber-infrastructure for the earth science community. The goal of GEON is to provide advanced information technologies that support intelligent searching, integration, visualization, analysis, and modeling of datasets. In addition, GEON provides high performance computing platforms required to analyze and model such datasets; thus, facilitating the interdisciplinary collaboration of earth science community efforts.
The University of Texas at El Paso Departments of Computer Science and Geology Department are collaborating to develop a service-oriented Ontology Management System (OMS) that will maintain ontologies about the resources available on the GEON Network. The OMS will be integrated into the GEON cyber-infrastructure as a service such that other applications or services can use the OMS functionality. GEON resources are broadly classified as data, methods, and products, and are distributed geographically and organizationally across the GEON Networkpartner sites[3].The purpose of the ontologies is to maintain knowledge about the GEON resources in order to facilitatetheir discovery and integration.The OMS will manage the ontologies and provide client applications with the following services:
- Retrieve thatwill allow users to navigate through the available ontologies in search of concepts and corresponding resources as well as search for concepts and corresponding resources based on keyword queries.
- Contribute that will allow contributors to create new ontologies and/or propose modifications to existing ontologies.
- Validate that will allow domain-experts to control the contribution process of ontologies by providing functionality to accept and rejectnew contributions.
1.3.Definitions, Acronyms, and Abbreviations
1.3.1.Definitions
The definitions in this section are given in the context of the product being developed. This intention is to assist the user in their understanding of the requirements for the system.
TERM / DEFINITIONCheck-Box / A graphical user interface object that can be clicked to turn an option on or off.
Clear-text / Computer Security term used to refer to text that is not encrypted.
Client Application / A software application external to our system that a user will utilize to interact with the OMS.
Command Button / A graphical user interface object that can be clicked on to confirm or cancel the option.
Concept / It is represented as a class, a concept facilitates the description of a domain of knowledge [9].
Contribution / It refers to either a newly created ontology, or a modified existing ontology.
Data-grid field / A graphical user interface object that allows data to be presented in a spread-sheet style, i.e., the user is able to navigate through cells by rows and columns.
Dictionary / Dictionary that maintains relationship name, synonym, description of the relationship, and inverse relationship name.
Domain Concept / For a relation R(x,y), the domain concept is signified by x.
Implied relationship / A relationship that is inherited from a parent concept; also referred to as a child relationship.
List Box / A graphical user interface object that can be used to display data vertically in an ordered format.
Metadata / Information that describes another set of data. For ontology, the metadata is the information stored in the Metadata Table.
MySQL / Open source relational database management system [13].
Network-addressable resource / A resource that can be referenced through a URI.
OMS repository / It refers to the repository that the OMS currently accessed at the moment of user request.
Ontology / It refers to the explicit description of concepts in a domain closure and relations among them [9].
Plug-in / A component that provides a certain type of functionality within the context of a host application. The component is configured into the system at deployment time, which implies that the plug-in component can be installed and un-installed on/from the host application.
Portal / It is a web site that provides a starting point or gateway to other resources on the Internet or an intranet.
Portlet / A reusable web component that displays relevant information to Portal users.
Protégé / An open source ontology editor and knowledge-base framework developed at Stanford university.
Radio Button / A series of related and mutually exclusive circular buttons of which only one can be clicked to select a specific option.
Range / Allowed classes for slots of type instance are the range of a slot [9].
Range Concept / For a relation R(x,y), the range concept is signified by y.
Relationaldatabase / Data that is stored in a relational model and manipulated by relational algebra operators that are typically in the form of SQL.
Repository / A storage place where an ontology and dictionary are stored.
Resources / Classification of concepts into data, methods, and products.
Taxonomical hierarchy / Hierarchy of classes (concepts) represented as superclasses and subclasses [9].
Text Box / A graphical user interface object that allows text to be inputted through a keyboard.
User / The superset of the following types of user: general, validator, and contributor.
Web Service / Also called application services, they are services (usually including some combination of programming and data, but possibly including human resources as well) that are made available from a business's Web server for Web users or other Web-connected programs.
1.3.2.Acronyms
Acronym / DescriptionDAML / DARPA Agent Markup Language
DBMS / Database Management System
DFD / Data Flow Diagram
GEON / Geosciences Network
HTML / Hyper Text Mark-Up Language
HTTP / Hyper Text Transfer Protocol
OIL / Ontology Interchange Language
OMS / Ontology Management System
OMT / Object Modeling Technique
OWL / Ontology Web Language
OWL-S / OWL-based Web service ontology
RDF / Resource Description Framework
SNOBASE / Semantic Network Ontology Base, [14]
SOA / Service-Oriented Architecture
SOAP / Simple Object Access Protocol
SQL / Structured Query Language
SRS / Software Requirements Specification
TBD / To Be Determined
URI / Universal Resource Identifier
UTEP / The University of Texas at El Paso
XML / Extensible Markup Language
WSDL / Web Services Description Language
1.3.3.Abbreviations
ABBREVIATION / MEANINGcf. / Confer (or Compare)
e.g. / For example
i.e. / Such as
info. / Information
1.4.Overview
The SRS is divided into three major sections: Introduction (Section 1), General Description (Section 2), and Specific Requirements (Section 3).
Section 1 includes five subsections. Section 1.1 provides the purpose and intended audience of the document. Section 1.2 describes the scope of the product. Section 1.3 provides the definitions, acronyms and abbreviations. Section 1.4 provides the organization of the document. Section 1.5 lists the references used in this document.
Section 2 includes five subsections. Section 2.1 contains a description of the product, its overall structure, and its functionality. Section 2.2 summarizes the main features of the OMS. Section 2.3 identifies each type of users of the system. This is accomplished through a summary of actors, use-cases and scenarios. Section 2.4 states existing general constraints. Section 2.5 gives the assumptions and dependencies of the OMS.
Section 3 includes four major subsections. Section 3.1 contains requirements that are related to the external interface. Section 3.2 contains the functional requirements that are organized in the following categories: same class of user, related real-world objects, stimulus, related features, and limits and default settings. Section 3.3 contains non-behavioral requirements consisting performance and qualitative requirements, as well as design and implementation constraints. Section 3.4 outlines database, operations and site adaptation requirements.
1.5.References
[1]CompuGlobalHyperMegaNet, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[2]Eisen Corp, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[3]EngineSoft, “Ontology Management System, Interview Report,” version 2.1, Fall 2005.
[4]EngineSoft, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[5]Gemini Software Development, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[6]Guidance Team, “Requirements Definition Document”, El Paso, University of Texas at El Paso, August 26, 2005.
[7]Hades, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[8]Mexsys Corporation, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[9]N. Noy and D. McGuiness, “Ontology Development 101: A Guide to Creating Your First Ontology,”
[10]S. Bechhofer, F. Harmelen, J. Hendler, I. Horrocks, D. McGuinness, P. Patel-Schneider, L. Stein, “OWL Web Ontology Language Reference”, January 16, 2006.
[11]Solution Developers, “Software Requirements Specification,” University of Texas at El Paso, December 2005
[12]“WS-I Organization’s Website,” January 16, 2006,
[13]“MySQL Website,” January 18, 2006,
[14]“SNOBASE Website,” January 19, 2006,
Software Requirements Specification / CS 4310 Fall 2005 / Version:1.42/16/2006 / Page1
Software Requirements Specification
2.General Description
2.1.Product Perspective
The system described in this document is called the Ontology Management System (OMS), and it is designed to maintain ontologies aboutgeoscience resources. The system will provide functionality to allow geoscientists to manage concepts and related geoscience resources, and to allow other users and applications to browse and query the ontologies to enhance resource discovery and integration.
IBM has developed a system called Semantic Network Ontology Base (SNOBASE) [14] that shares similarities to the OMS. Like OMS, SNOBASE is a framework for creating, modifying, querying, and storing ontologies. In contrast, the OMS provides additional functionality that supports concurrent ontology creation and modification by including an ontology browsing mechanism and a validation process for edits. The OMS also allows network-addressable resources to be linked to ontology concepts in order to facilitate resource discovery and integration in cyber-infrastructure efforts like GEON. Finally, client interaction with the OMS does not depend on platform-specific API’s or connectors, but rather utilizes standardized service-oriented technologies that allow client applications to use its functionality across different platforms.
2.2.Product Features
Figure 1 presents a use case diagram that provides the representation of the OMS from a user’s perspective.The figure sticks represent the external actors that interact with the OMS, and the ovals represent the use cases supported by the OMS; these components are described next.
Figure 1.Use Case diagram
2.2.1.Actors
The OMS classifies actors into the following groups:
- General User: This actor represents a client application that performs “non-administrative tasks”. The General User actorprovides the ability to its human user to search for concepts or resources of interest by browsing the ontology structure or by performing queries based on keywords and search types.
- Contributor: This actor represents a client application that provides its human user with the ability to propose new ontologies or modifications to existing ontologies. Through the Contributor actor, the human user has the ability to propose modifications to ontology structure by adding new concepts, relations,and setting links between concepts and network-addressable resources.
- Validator:This actor represents a client application that provides its human user with the ability to accept or reject proposed contributions. Through the Validator actor, the human user (typically a domain expert) has the ability to review new contributions, provide feedback to the contributor, and accept or reject the contributions proposed.
- Data Store: This actor represents the permanent storage of the OMS. The Data Store includes a DBMS and a file system. The DBMS maintains metadata, dictionary, and user access levels. The file system hosts ontology files represented in OWL.
2.2.2.Use Cases
The OMS supports the following use cases:
- Retrieve:The OMS provides General User actors with the ability to request ontologies bybrowsingor by performing queries. The General User actors are responsible for providing a buffer space for the retrieved ontology and provide an adequate representation for its human user (e.g., graphical).
- Contribute:The OMS provides Contributor actors with the ability to enter new ontologies to be verified by an expert and propose modifications to existing ontologies.With respect to existing ontologies, this use case assumes that a Retrieve use case is usedin order to identify the ontology portion of interest. New and modified ontologies are verified for appropriate OWL format, are flagged as pending validation, and are queued for validation. The OMS acknowledges the Contributor actor once the new or changed ontology has been processed.
- Validate: The OMS provides Validator actors with the ability to validate proposed and modified ontologies. The OMS provides a list of ontologies that are flagged as pending validation;the Validatoractor submits a selection from the list;the OMS provides the original ontology, along with the proposed changes; the Validator actor presents both versions to the human user in appropriate format (e.g., a visual representation of the original ontology with the proposed changes highlighted); the Validator actor submits the results of the validation process;the ontology is flagged accordingly and the contributing author is notified of the outcome.
2.2.3.Scenarios
Each user interacts with the OMS through some specialized client application that supports the operations that are of interest to the class of user. The following scenarios describe the interaction between users, their client applications, and the OMS.
Scenario for Retrieve Use Case
Description: The user retrieves an ontology from the OMS.
Actors: General User, Data Store
Precondition: A connection between the OMS and the client application has been established.
Trigger Condition: The user initializes the retrieve functionality of the client application.
- The client application supports the Browse retrieval option and the user selects it.
- The client application sends an initial request for Browse to the OMS.
- The OMS receives the initial request for Browse and responds by sending the list of available ontologies (i.e., ontology unique ID, ontology name and ontology description).
- The client application displays the ontology list in appropriate format for user presentation (e.g., HTML).
- The user selects a particular ontology from the list.
- The client application requests the selected ontology from the OMS by sending the ontology’s unique ID.
- The OMS retrieves the selected ontology from the data store in OWL format and sends it to the client application.
- The client application transforms the OWL ontology into an appropriate format for presentation to the user (e.g., graphical).
- The user selects a particular concept from the ontology that is linked to a resource’s URI.
- The user selects the resource’s URI link and is redirected to it.
- End of use case.
Alt1: Step1: The client application supports the Query retrieval option and the user selects it.