Engineering and Design

Posts detailing thoughts, plans and decisions on subjects relating to the technical and visual aspects of the project

Future functionality

Niko Leave a comment

Version 1 of ‘LessonPlan’ will be released as a full functioning platform, but due to time constraints more advanced features will be implemented in future versions.
Some of the planned features are detailed below. The extra features simplify and make more robust some of the functionality of the platform, but all said functionality is completely operational in version 1 without them.

  • Suggestion algorithm
    One of the main goals of ‘LessonPlan’ is to facilitate module selection, allowing students to make more informed choices when selecting optional modules. This is based on the premise that providing students with information apart from the limited details of the module overview pages – and especially feedback on the practical applications of the module descriptions – will allow them to have a clearer picture of the module’s learning outcomes and requirements. In the initial release of the platform this is largely based on the inferences that each student can make from the feedback, comments and discussions that other students have posted. Implementing a suggestion algorithm would offer some automation on this task: The algorithm will be able to notice patterns in module selection and relate them to satisfaction. It will then be able to offer those observations as suggestions. For example, if a student A has rated Module X and Module Y as very interesting in Semester 1, and rates Module Z as very interesting in Semester 2, there’s a probability that students that have also found Modules X and Y interesting will have an interest in Module Z as well.

 

  • Posts’ ratings
    As detailed in the post about Trust here, implementation of ratings for comments and discussion posts is intended in the future. This would allow users to up-vote a post that they found particularly helpful, useful or interesting. That would provide new users with an instant indication about the validity of the post, while encouraging users to post more responsibly.

 

  •  Flags for abusive content
    For the initial release of ‘LessonPlan’ it was decided that no active monitoring or moderation of posts was needed to keep content clean and clear. From studies of Graph Theory on Online Social Networks it has been noted that an accentuated characteristic of a network shapes the behaviour of its members. Since members of the platform will be University students, with their credentials logged into the system, it is a safe assumption that the majority of them will behave ethically, in line with the Acceptable Use policies. This then, as a network effect, constrain potentially deviant behaviour from other members. This assumption is re-enforced by what is detailed in the post about Trust: Where social capital and trust exist, members can rely on informal fairness rather than constant active monitoring and exhausting rules of provenance.
    Nevertheless, future versions of ‘LessonPlan’ can address this issue if need be. The feature will allow users to flag up abusive posts. Posts that gather a certain amount of flags, will be marked for inspection. And after a certain amount of flagged up posts, prevention policies could be set in place (for example, warnings, suspension or even deletion from the system).

Testing

Sam 1 Comment

To help ensure an easy to use system for all users, which will in turn reduce support costs for our business, we will conduct thorough testing. Such testing will take place at various stages in the project lifecycle:

Unit Testing

Unit tests can be written for each of the functional requirements in LessonPlan 2.0. Each time a function has been developed, it will be tested by both developers and end user. The process will be iterative and users will be involved in all processes of software development life cycle. This will decrease the chances of later requirements modification, which is costly. Tools like JUnit will be used by developers for unit testing to ensure the correctness of a unit’s implementation in relation to requirement specifications.

Integration Testing

When developing several units and functions that supposed to work together, integration tests will be created to ensure interoperability of the components and to prevent error regression.

Prototype Acceptance Testing

When a design prototype is produced, potential users will be asked to try out the prototype system. They will provide feedback that can then be used to prevent usability problems and inform feature decisions.

Pre-release Testing

Select users will be offered the opportunity to try new updates and features before general release. This testing allows us to catch any potential bugs and usability problems before all users of the system are introduced to them.

This style of testing will happen repeatedly, mostly after new features have been developed and are ready to be released.

Wireframe Design

Tun-Ya Yu Leave a comment

A Wireframe design is a screen blueprint of application, and the wireframe could help understand the vision of application. And the design is shown below.

1. index page:
Because the system allow user view the rating and review without login, the search function does not require user to login. But user could also choose to login to use the system, and the button at top would show as “MyAccount”.

1-1 index page without login

1-2 index page with login

2. Search result: The result would show the course name, and the school name will shown below.

2-1 search result without login

2-2 search result after login

 

3. The description of module page: A module page has three parts: Description, Rating, and communication.

3-1 Description page. without login

3-2 Description page after login. If the user has enrolled the course, the page would should the “communication” tab.

4. The Rating of module: if a user

4-1 The Rating page with a enroll user. There would be a “Rate this course” button shown.

4-2 Rating page without login

4-3 A logon user but not enroll would see the page similar with user without login.

5. Rate a course:

5. A enroll user could rate the course.

6. communication: The system allow user to post and make comments with their classmates.

 

6-1 Communication page, would see all the posts on it. And user could view their post or add post.

6-2 Add a new post.

6-3 inside the post. user could make comments

6-4 user could view all their posts.

7. Account: this page include the profile and courses taken.

7-1 the profile tab would show where user login from and their nickname.

7-2 user could edit their shown name.

7-3 The course page would show all the courses taken

 

Security analysis of system requirements and design

Nengjie Zhang Leave a comment

Overview:

  • Assess likely risks of the system and specific cost by analysing the requirements and design.
  • Identify drawbacks or improper security requirements.
  • System operation security.

For LessonPlan 2.0, as it is a social media platform for module reviews, the effective operation of the system is extremely important and the main secure factors are about the design and structure of the system, including the database that used to store the useful and updated information. The detailed contents of the system architecture design were posted by one of our group members (AHMED AL-BRASHDI) on April 27, 2015. Here is the flow chart of security analysis.

security

Actually, the main security analysis of the system will focus on the technology. The system can be divided into two parts: Front-end and Backend. For the Front-end, normally, the system can be used in a public network, such as the computer room in university, when one student log in the system successfully, the second one can not enter it when using the computer that has the same IP address, so the second one will not view the status of the module option for the previous. This is one point about users’ interaction.
For the Module Review Database, as the related information of modules is too much and it may cause confusion between several modules, such as the module leader, module place, module time, etc. Managing well the database is very essential for the system operates in a correct way.

Since the system has a login and user profile information, we think about how to overcome any vulnerabilities associated with each page.
As a web application, the main possible vulnerabilities as in OWASP top ten 2013 [1]:
1- Injection: will focus more on SQL Injection here. The login form and any other form has to prevent such attach. The danger comes when the attacker can trick sql statement and gets over authentication and authorization. He /she can then login as an admin and harm the entire application or database. Also, injecting delete or drop sql statement will remove table records or remove the entire table with its structure and definition. To overcome this, we should use parametrized interface or statement like using PrepareStatement in JDBC. Another way is to escape special characters using DBMS. Third option is to use stored procedure instead.
2-Cross-Site Scripting: if the user input has not been escaped correctly, the site might be vulnerable to cross-site scripting. To overcome this, we need to escape all untrusted data and use libraries like OWASP’s AntiSamy.

The other vulnerability might not have the same weight as these main two in LessonPlan 2.0. However, the proper prevention strategy will be applied in all of them to ensure the highest security possible. This include hashing session ids, using secure HTTP and hashing user password [2].

——–
[1] The OWASP Foundation, “OWASP Top 10 for 2013″, 2013
[2] Provided by Ahmed Al-Brashdi, 2015

User Experience

Ahmed Al-Brashdi Leave a comment

To add the value for game theory and interface design, some elements for user experience and engagements are considered when developing LessonPlan 2.0. These elements will include for example:

  1. Simplicity and speed of loading and navigation. By designing a simple landing page, the browser will load the page for the user very quickly.
  2. Use of customized and representative logo and brand for LessonPlan 2.0.
  3. Progress bar for the percentage of completion of reviews and engagement in module.
  4. Using eye-tracking technique and following F shape style [1], the main navigation for ratings, review, courses are set on the first horizontal line of F. The main contents will be on the left side on the main panel as users spend 69% of their time of the left side of a page [2]
  5. Each time a user complete a review, he/she will get a score. When scores gets to certain level, a batch will be awarded to the user.
  6. Using RSS and letting the students subscribe for fees.
  7. Search box at the start with drop down list for registered courses.

By doing so, we ensure user engagement with rich experience in LessonPlan 2.0. Some of these elements are illustrated clearly in mockup figures.

———–

[1] Nielson Jakob, “F-Shaped Pattern For Reading Web Content”: http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/, Apr 17, 2006 [Apr. 29, 2015].

[2] Porter, Joshua, “Testing the Three-Click Rule”: http://www.uie.com/articles/getting_confidence/, Apr 16, 2003 [Apr. 29, 2015]

Main User (Student) Use Case Diagram v1.0

Ahmed Al-Brashdi Leave a comment

One of the main feature of a system is the interactivity between it and its users. The interaction is illustrated by using use case diagram. Here we represent the main actor of the system where the entire system is mostly used and interacted with by this user, student actor.

The diagram shows how the student will interact with module review social network and what actions he/she will perform. The other actors are not included in this version of use case diagram because at this point their interactivity with the system is very limited at this stage. These actors are the lecturer who can comment on review or reply on a comment. The system which analyze the student input as preferences and generate a suggestions or a list of suitable module based on student grade, pre-set preferences, rating and difficulty level of a module.

UseCase

Entity Relation Diagram

Ahmed Al-Brashdi Leave a comment

Entity Relation Diagram is used to illustrate a unified view of a system data [1]. This entity relation diagram shows the main entities in LessonPlan application and how these entities relate to each others. By ensuring the correct entities data types and relation, we enforce the integrity of the database. The relationship between two tables is ensured by referencing its primary key like userid in Module_Feedback table which reference the user id who provided that feedback. If a user id does not exists in user table, it can not be stored in any other table which reference it. This is to enforce the referential integrity in database. To enforce the entity integrity, a primary key in each table has been identified. These primary key might be single attribute like userid in users table or composite primary key (consists of multiple attributes together) like mode_program table.

In ERD, U stands for unique in that table and N stands for nullable (can be null). To ensure that an email address is not used by two or more users, the attribute constraint is set to be unique. Same for school name, module name and program name as we can not have the same name which represent two schools, modules or program. The grade in user table is set nullable so the user will have the ability to choose between giving it or not.

These tables represents only LessonPlan database without the integration with university database in which the system can query from using remote procedure calls.

ModuleReview

 

———-

[1] Chen, P. P. S. (1976).The entity-relationship model toward a unified view of data. ACM Transactions on DatabaseSystems (TODS), l(1), 9-39.

Class Diagram v1.0

Ahmed Al-Brashdi Leave a comment

The class diagram of LessonPlan 2.0 social network illustrate the structure of this application by illustrating the classes and their attributes and operations.

LessonPlan 2.0 project consists of multiple classes in which some of them depend on others. The main class User is a generalization for both students and lecturer/module leaders. Both of them (student class and lecturer class) have something in common which is represented in User class. The other attributes and operations that distinguish student from lecturer are set in student class, same for lecturer.

The dependencies between classes are represented with doted arrows. Each class represent class name, number of attributes which set to be private by assigning – sign before them, and public constructors and operations with plus + sign before them.

Social Network Class Diagram