Handling Semantic Data for Software ProjectsData ManagementCSE G674 – SW Engineering Project

Agenda

•What we learned•Major Requirements•Legacy Code and Documentation•New Features•What’s Done•Major Difficulties•Advice to next group

What we learned

• Software Engineering• RDF/XML• Semantic Web• Web Ontology Language (OWL)• Jena

Software Engineering

•Scrum Process▫Eclipse Process Framework (EPF)▫Scrum Roles

Product owner, Scrum Master, Scrum Team▫Work Products

Product Backlog, Sprint Backlog, Potentially Shippable Products

▫Scrum Activities Initial Release Planning, Sprint Planning,

Backlog Prioritization

Software Engineering Cont’d• Development Tools

▫ Subversion, Google Code, Wikis, Eclipse, RSM/RSA, dotProject

• Documentation▫ Component, Class, Activity, Sequence diagrams▫ Final Specs.

• Collaboration and Communication▫ Negotiating Requirements, Blackboard

• Testing▫ Specs and J-Unit

• Legacy Artifacts▫ Deciphering old code and documentation

RDF/XML• Resource Description Framework (RDF)– Representation of metadata – a method of

modeling data– Most of us were fairly unfamiliar with RDF

which provides the basis for the 3 primary technologies exposed in this project:

• Semantic Web• Web Ontology Language• Jena

Semantic Web• Semantic Web– A representation of data enabling computers to

better handle information on the web– Relationships among data are represented by

ontologies– Builds on XML and RDF's approach to

representing data– Web Ontology Language (OWL) one of the

foundations of the Semantic Web

OWL• Web Ontology Language (OWL)– Explicitly represents relationships between

data This explicit representation is known as the ontology

– Uses XML and RDF as its foundation– OWL Family (3 Semantics): OWL Full, OWL DL, OWL

Lite– OWL DL and OWL Lite are the most commonly used

because they are the easiest to understand and implements

– OWL Full is a full representation of RDF Schema which is much more loosely defined and more difficult to fully implement

Jena• Jena– Java implementation of semantic web

applications– Built-in inference model “infers” relationships

between data based on the specified data provided and the relationships between that data provided by the ontology

– Provides database support for persistent data and the ability to query the stored data

Adler Requirements• The Adler shall receive requests via a Java interface. • The Adler shall provide an interface for inserting new projects. • The Adler shall provide an interface for replacing existing

projects. • The Adler shall provide an interface for removing projects. • The Adler shall provide an interface for obtaining the list of

existing projects. • The Adler shall provide an interface for querying an existing

project using the SPARQL query language. • The Adler shall support a MySQL backend database. • The Adler shall make available a local API. • The Adler shall allow the user to configure the database name,

username, password and location. • The Adler shall support the following formats for data insertion:

"RDF/XML", "N-TRIPLE", "N3".

Authentication Requirements

•Register an authorized user in the system (an authorized user is a student who knows the secret code)

•Store the information about the user.•Allow the user to access his/her user record•Allow the user to access and control his/her projects•Protect system against unauthorized access•Allow user to reset the portal password

Legacy Code and Documentation• Mainly implemented following features:• Using Jena to interact between database and Adler.• Using RMI as remote communication and expose two

API on that.• Realizing the functions as inserting single projects,

submitting certain query and getting expected feedback.• Supporting MySQL and MSSQL databases.

• Poor documentation management:• Only instructions on how to setup Adler.

• Test not applied properly.• Lacked the ability for extensions.

Adler New Features

• Improvement of Functions and features.• A new interface for replacing existing projects. • A new interface for removing projects. • A new interface for obtaining the list of existing projects. • Eliminated RMI and redesigned the whole project as a web-

based project.• Multi-project support.

• Improved Documentation Management.• Well managed and organized Wiki.• Detailed UML Diagrams• Clear Instructions and user manual provided. • Javadoc for documentation.

Authentication New Features

•Secret code: Match the secret code before create new user.

•Retrieve password: instead of JMS we implemented this function using PHP.

Adler – What’s DoneFunctions and Features:

• API for Inserting new projects. • API for Querying an existing project using the SPARQL query

language. • Replacing existing projects. • Removing projects. • Obtaining the list of existing projects.• Multiple Project support. • MySQL backend database support. • Database name, username, password and etc configurable. • Multiple formats for data support.• Improve error handling• J-Unit test suite for Adler• Improved documentation and project management.

Authentication – What’s Done

•Register: Save all the user information into DB.•Login: Check the user record against on the DB. If DB

has the record set the session and pass the username to Entry page.

•Logout: invalidate session and send redirection to Login page.

•Forgot password: Check the username and password based on the email address. If has the record then send an email with the username and the reset password to the user.

Adler - Major DifficultiesSemantic Web Concepts and Technologies 

• Unfamiliar Topic and Techniques.▫ The majority of the team was quite unfamiliar with the Semantic Data.

• Heavily relying on Jena, an open source tool. ▫ We needed to verify that it would work for us early on. We did this and

mitigated the risk early on. Component Integration and System Testing 

• Integration. ▫ No high-level code reviews performed among the three teams which

might have flushed out any misconceptions about the interfaces.• Communication and collaboration.

▫ We spent too long working in our own development areas and in turn waited too long to integrate with each other’s code.

• Formal testing occurred late. ▫ Testing should have been addressed earlier in the project so a test plan

and cases could be developed in parallel.

Authentication – Major Difficulties

•Session: Where to create the session and how to close it.

•Short deadlines/scheduling•Fixing software errors (time consuming)•Software functionality issues vs. customer

requirements (unable to meet the customer requirements due to functionality issues)

Advice to Next Group• Set a clear direction early

▫ If Prof. Kokar asks for proposals, give him some!• Don’t spend too little/too much time on documentation• Define specific responsibilities and grading policies• Use 1 week sprints with very very specific deliverables defined in

a planning tool• Meet as a class every week

▫ Use this as your planning meeting• Use a common work area as early as possible• Create a backlog, prioritize, and deliver each week• Testing is not an afterthought• Pay attention to deadlines• Talk to the other teams!