LeapIn.it uses a REST endpoint for access to the database. This is a design pattern for hypermedia systems, which advocates providing individual resources (e.g., people) with unique URLs, and using those URLs to exchange structured information. HTTP requests can be made to these URLs, where HTTP methods are used to instruct what should happen with attached data, and status codes… Read more →
Throughout implementing the prototypes, we’ve employed a number of testing methodologies to ensure that the product is of a high quality. In this post, we’ll discuss four methodologies we have used: regression testing, code modularity, code quality checking and code metric monitoring. Regression testing After each significant change was made to the code, the prototype would be compiled into an… Read more →
During our development of the LeapIn.it prototype, we have used a number of design patterns, libraries and API’s. This post will give an overview of the most crucial of these. Server The server is responsible for creating a REST interface for database access. As mentioned in our post on architecture, we have chosen to use RedBeanPHP to communicate with the… Read more →
In this post, we will design an ontology to describe LeapIn.it with the Semantic Web technology. Through building an ontology, we can provide mechanisms for other people to interrogate the dataset in meaningful ways. Additionally, annotating the data will be helpful when using SPARQL to do some queries later on. We are using the ontology editing environment, Protege 4.3. Class Hierarchy There are… Read more →
LeapIn.it will allow people to “leap in” to rooms based around niche interests simply by scanning barcodes (or QR-codes) that may be found on relevant material (such as books and posters). However, it is reasonable to expect that one subject may have multiple barcodes. For example, the DVD and Bluray releases of the film Inception may have different barcodes. In this case,… Read more →
The class diagram below illustrates the data structures which will be used on the client and server. These models will be made available over REST, which is discussed here. The Enhanced Entity Relationship diagram below shows the schema of the database. The tables and relationships between the tables are illustrated.
A context-level data flow diagram is used to identify the data flows between the system and its external entities. The data contained in our system comes from two external entities, which are the regular users and the subscribed organizations. Therefore, the system is shown as a single process (or a black box) that exchanges information from its external actors. Figure… Read more →
The following use case diagram is used to illustrate the functions that will be implemented in our social network. This diagram demonstrates who the stakeholders are and what they can do. There are two main stakeholders/actors who can use our project: The regular user who might be a regular viewer/visitor or a room administrator (the first to scan a particular… Read more →