Master in Informatics and Computing Engineering
Database and Web Applications Laboratory
This component groups the artefacts related to the Requirements Specification of the system to be developed during the project. These artefacts are usually included in the Requirements Document of a system [IEEE98] developed in the initial phase of analyses, by a team that includes all project stakeholders.
This artefact introduces the context and motivation and briefly describes the web information system to be developed. It includes the goals of the project and lists the features that should be supported, together with the identified access groups.
This artefact contains the specification of the actors and their user stories, serving as agile documentation of project requirements.
An Actor models a type of role played by an entity that interacts with the system being specified. This may include persons (not just the end-user), and other entities external to the system. Actors are always external to the system being modelled; they are never part of the system [Ambler04] .
A User Story is a high-level definition of a requirement containing only the necessary information so that the developers can produce a reasonable estimate of the effort required to implement it [Ambler04] . A user story, a brief description of a potential interaction with the system by one of its users, focuses only on interaction requirements and not on the technical aspects of the design of the system. The user stories have a priority (high or essential, medium or conditional, and low or optional) indicating the need to be included in the design implementation stages and project. A team of expert analysts also includes an estimate of the effort required for its implementation.
Each user story must follow the template [Dennis10] :
“As a [user], I want [function], so that [value]”
The Supplementary requirements are also presented in an Annex to A2.
This annex contains business rules, technical requirements and other restrictions on the project:
The User Interface Prototype artefact has the following objectives:
Since an User Interface Prototype (or horizontal prototype) allows for a much faster implementation than the final product, it allows to easily test and validate the design at an early stage of the development, enabling empirical testing, such as usability testing and in situ observations of the design being used by real users. It also permits to quickly iterate on the design of the interface, implementing the results from the initial tests.
This artefact should include three elements:
The user interfaces must be implemented using HTML, CSS, JS. You can also use PHP includes to reduce code repetition (e.g. headers, navigation, footer). The overview of the interface elements must include a presentation of the behaviour of the interfaces in small screen devices such as smartphones. This artefact includes screenshots of the interfaces, alongside with a link to a web page for each interface implemented. This artefact also includes, as annexes, digitized copies of the materials developed, specifically the hand-made wireflows.
This component groups the artefacts to be made by the development team in order to support the storage requirements and retrieval of the information identified in the requirements specification.
The Conceptual Domain Model contains the identification and description of the entities of the domain and the relationships between them.
At this stage of the project we are mainly interested in the database specification, thus the Conceptual Domain Model is simplified to include only concepts (entities and relationships) of the domain that are stored in the database. In this artefact the data requirements of the system are detailed.
The Conceptual Data Model is obtained by using a UML class diagram containing the classes, associations, multiplicity and roles. For each class, the attributes, associations and constraints are included in the class diagram. Business rules not included in the class diagram are described by words or using OCL (Object Constraint Language) included as UML notes.
This artefact contains the Relational Schema obtained by mapping from the Conceptual Data Model.
The Relational Schema includes the relation schemas, attributes, domains, primary keys, foreign keys and other integrity rules: UNIQUE, DEFAULT, NOT NULL, CHECK.
Relation schemas are specified in the compact notation:
|Table1(id, attribute NN)|
|Table2(id, attribute → Table1 NN)|
|Table3(id1, id2 → Table2, attribute UK NN)|
|Table4((id1, id2) → Table3, id3, attribute)|
UK means UNIQUE and NN means NOT NULL.
The specification of additional domains can also be made in a compact form, using the notation:
|Today||DATE DEFAULT CURRENT_DATE|
|Priority||ENUM ('High', 'Medium', 'Low')|
To show the domains of the attributes and the CHECK constraints of attributes and tuples, in addition to this representation, the relational schema is also presented in SQL.
To validate the Relational Schema obtained from the Conceptual Model, all functional dependencies are identified and the normalization of all relation schemas is accomplished. Should it be necessary, in case the scheme is not in the Boyce–Codd Normal Form (BCNF), the relational schema is refined using normalization.
This artefact contains the physical schema of the database, the identification and characterization of the indexes, the support of data integrity rules with triggers, the definition of the database user-defined functions, and the identification and characterization of the database transactions. This artefact also includes the complete database creation script, including all SQL necessary to define all integrity constraints, indexes, and triggers.
The physical schema of the database contains a study of the predicted system load (database load), including an estimate of tuples at each relation and the Physical Schema of the database. The database load includes the most important queries (SELECT) and their frequency, important changes (UPDATE, DELETE) and their frequency, and the required performance for these queries and updates.
Should it be necessary to improve the performance of the queries, indexes of the convenient type (B-tree, Hash, GiST and GIN) are introduced. As last resource, controlled redundancy may be introduced (de-normalisation). It is also needed to decide the clustering of an index.
The system being developed must provide full-text search features supported by PostgreSQL. Thus, it is necessary to specify the fields where full-text search will be available and the associated setup, namely all necessary configurations, indexes definitions and other relevant details.
To enforce integrity rules that cannot be achieved in a simpler way, the triggers are identified and described by presenting the event, the condition, and the activation code.
User-defined functions and trigger procedures that add control structures to the SQL language, or perform complex computations, are identified and described to be trusted by the database server.
Every kind of function (SQL functions, Stored procedures, Trigger procedures) can take base types, composite types, or combinations of these as arguments (parameters). In addition, every kind of function can return a base type or a composite type. Functions can also be defined to return sets of base or composite values.
The database transactions are needed to ensure the integrity of the data in the presence of concurrent accesses.
For each transaction, with a proper justification, the isolation level must be explicitly stated and read-only transactions must be identified to improve global performance. For each identified transaction, the SQL code is presented.
This component groups artefacts related to the architecture specification of the information system to be developed and the (vertical) prototype implemented to validate the architecture.
This artefact presents an overview of the web resources to implement, organized into modules. Also included in this artefact are the permissions used in the modules to establish the conditions of access to resources.
For each module identified in the artefact, a catalogue of web resources that are part of the module, including possible APIs, must be presented. For each resource, the expected URL, HTTP methods and parameters supported as well as possible responses should be included. For resources with a user interface, a reference (link) is included to the corresponding graphical interface defined in A3 artefact.
The Vertical Prototype includes the implementation of two or more user stories (the simplest) and aims to validate the architecture presented, also serving to gain familiarity with the technologies used in the project. It must be based on the LBAW Framework (see the template-lavavel) and include work on all layers of the architecture of the solution to implement: user interface, business logic and data access.
The US implemented must be specific of the group's project. Adapting the provided authentication system is required but not considered part of those US. The US must include at least a form, an action, an AJAX request, and a search or update of the database.
The instructions on installing and deploying the framework are provided at Developing the project with Docker, Laravel & PostgreSQL.
When the image is uploaded to DockerHub, the prototype is available, inside the FEUP VPN, at http://lbaw20gg.lbaw-prod.fe.up.pt.
This component includes the artefacts related to the delivery of the final product.
This artefact is the result of the implementation of the information system designed in the earlier stages, using PHP and the Laravel Framework for producing dynamic web pages, and PostgreSQL as a database management system.
The product includes: instructions for installation and use and access credentials.
The product version considered for evaluation is the one available on the group's Docker Hub account by the artefact's delivery deadline.
That container will be made available at
http://lbaw20gg.lbaw-prod.fe.up.pt and will be used, from that URL, for the demonstration (A10).
No update to the image will be available after the submission deadline.
The product should also describe the type of assistance supported by the web application (context-sensitive help, notifications, help pages, etc.), describe and briefly justify the revisions introduced to the initially defined requirements and architecture and identify the development status (in %) of each of the requirements (user Stories) initially set in A2.
To evaluate the product, by observing the operation of the developed web application and the delivered code, the following items will be assessed:
This artefact includes the promotion, a presentation, and the demonstration of the product and a discussion of the developed features. The promotion should include a short video of 2 minutes showcasing the main features of the product.
For the presentation, the group must follow a presentation script (not to be delivered), and demonstrate the product accessing the official URL at the production machine: https://lbaw20gg.lbaw-prod.fe.up.pt. The web application will be available until the grades are published.
|[Ambler04]||Scott Ambler, The Object Primer, Cambridge University Press, 3rd Edition, 2004, ISBN: 978-0-521-54018-6|
|[IEEE98]||IEEE Computer Society, IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998, 1998, DOI: 10.1109/IEEESTD.1998.88286|
|[Dennis10]||Steve Dennis, How to write meaningful User Stories, subcite.com Articles & Tutorials, 2010|