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:
This User Interface Prototype 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. The overview of the interface elements must include a presentation of the behavior 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 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 and the definition of the database user-defined functions. 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 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 can not 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.
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.
For resources that need SQL, a reference is included to the corresponding SQL statement in A9 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 should be based on the LBAW Framework and include work on all layers of the architecture of the solution to implement: user interface, business logic and data access.
Instructions on installing and deploying the framework are provided at Developing the project with Docker, Laravel & PostgreSQL.
The code of the prototype is kept in the GitLab repository in an independent branch (named
The prototype is available, inside the FEUP VPN, at http://lbaw18GG.lbaw-prod.fe.up.pt.
This artefact presents the main accesses to the database, including the transactions.
For each transaction, the isolation level must be explicitly stated and read-only transactions must be identified to improve global performance. For each identified access, the SQL code and the reference of web resources (A7) must be presented. A given database access can be used in more than one resource.
|[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|