1. Handling Semantic Data for Software Projects Data Management CSE G674 – SW Engineering Project

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

3. What we learned Software Engineering RDF/XML Semantic Web Web Ontology Language (OWL) ‏ Jena

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

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

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

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

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

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

10. 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".

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

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

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

14. Authentication New Features Secret code: Match the secret code before create new user. Retrieve password: instead of JMS we implemented this function using PHP.

15. Adler – What’s Done Functions 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.

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

17. Adler - Major Difficulties Semantic 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.

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

19. 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!