Phase 2 - Design Part 4 - Pattern & Architecture

After a hour spent on modularisation (influenced by struts2 architecture) I've dedicated a chapter to the mapping between URLs and methods' call. In those added chapters I've studied how the system should be divided, and for each part what is needed and which are the roles entitled to use it. In the pattern chapter there is also a part about Authorisation. Authentication will be discussed later on.

Deliverables Hub - Pattern Study

Phase 2 - Design Part 3 - GUI + DB

This afternoon I made a study on the one that will be the graphical interface for the program. Furthermore, along with GUI studies, I've designed also the first edition of the database, with some diagrams.

Deliverables Hub - GUI + DB

Phase 2 - Design Part 2

Here it comes the second part of the design phase. Activity diagrams for all the actors and most of the actions doable by them. Today I will also focus on the development of the views (HTML only).

Deliverables Hub - Design part 2

Phase 2 : Design Part 1

After a brief requirement study, comes the design phase. I've started this second phase with some simple use cases diagrams. This is the output

Deliverables Hub - Design Part 1

Phase 1: requirements

Deciding what to do or not, I found the idea for my project in another university. In particular my work will refer to the one published in the course of software engineering @ PoliMi. These are the specifications:

Manage Project Homework (MPH) is an application used by professors and students to facilitate the

organization of university courses with project deliveries. The students work together in teams

composed by 1, 2 or 3 participants and access the system through username and password. Each

student autonomously registers to the system and has a profile containing his/her information (name,

last name, id, profile picture, etc.). Moreover, he/she accesses to the information and functionalities

associated to the group he/she belongs to.

Professors (who are registered into the system by the system administrator) use the system to publish a

project description and to define the set of the corresponding deliverables, which are characterized by a

name and a specific deadline (i.e. “Delivery of design document” on 15 November at 23.59).

Moreover, professors can see the list of all registered teams and the students composing it.

Each team can submit a deliverable (i.e. a single file) by uploading it into the system until the deadline;

after that, it is still possible to upload new versions of the deliverable, but these are marked and

highlighted as late submissions and cause a penalty to be applied to the score associated to that

deliverable.

Each professor can download the delivered files through two views. The first one organizes the

deliverables per group (thus, for instance, it is possible to download, all deliverables produced by group

12), the second one per deliverable type (thus, for instance, it is possible to download the RASD

documents produced by all groups). Moreover, the professor, through an appropriate input form, can

evaluate the deliverables of each group with a score between 1 and 10 (works not delivered are

automatically scored with 1 while late deliverables get a final score equals to the score defined by the

professor minus the penalty that is proportional to the delay time). After the professor assigns a score,

then the corresponding group can visualize it. The system also takes care of computing the final score

obtained by each group as the average of all the intermediate scores.

Finally, a professor can use the system to enable some simple information sharing between groups. In

particular, he/she selects the group that should have visibility on the deliverables produced by another

group. Of course, this will result in the fact that the first group will have available some extra

functionality that enables the access to the deliverables produced by the second groups.

I've decided to rename the work in "Deliverables Hub".
For this first phase I made a study of the requirements. This is the first output:

Deliverables Hub - Requirements Study