Guia PES

Models

The diagrams you need, with one complete example

Agile does not revolve around models, but some of them add a lot and are part of the documentation. Every example comes from the same made-up app that complements Bicing with Open Data BCN data.

Required · Fag-2 and sprints

Conceptual model (UML class diagram)

The main concepts of the problem, independent of architecture and technology. Creative concepts of your own count, not just the ones in the open dataset.

Useremail: Stringname: StringjoinedOn: DateTripid: Naturalstart: DateTimeend: DateTimekm: RealStationid: Naturalname: Stringlocation: CoordinatefreeBikes: NaturalBadgename: Stringdescription: Stringpoints: Natural1*makes ▸*1origin*0..1destination**earns ▾**favouritesIntegrity constraintsIC1. Keys: (User, email), (Station, id), (Trip, id)IC2. end > startIC3. km >= 0IC4. The destination, if any, differs from the originComes from open dataNew concept of the team
Notice: only Station comes from the open data. Trip and Badge are the team's own concepts, and that is where the product's value lies.
Integrity constraints always go under the diagram, numbered: keys and rules the diagram cannot express.
Optional · recommended

Domain layer class diagram

The solution logic inside a three-layer architecture, with design patterns and operations already applied. Explain which patterns you use and why.

StationService- cache: Station[*]+ nearby(p: Position): Station[*]+ refresh()«interface»StationSource+ getStations(): Station[*]OpenDataBcnAdapter+ getStations(): Station[*]CsvAdapter+ getStations(): Station[*]FakeSource+ getStations(): Station[*]1Adapter pattern: the domain does not depend on the open data format. Swapping the source (API, CSV, mock) leaves StationService untouched.
Required · Fag-2 and sprints

Physical diagram (architecture)

The nodes and subsystems: app, server, database, external services and the service you build for another team. A sketch at the inception that you refine every sprint.

ClientsExternal servicesMobile appFlutter · Android · iOSAdmin web appFlutter WebTeam Cconsumes our serviceGoogle Maps · Sign-InSDKs inside the appFIB NATnattech.fib.upc.edu:40330 → VM :8080Cloudflare TunnelHTTPS (optional)HTTP · JSONvirtech · FIBUbuntu virtual machine · OpenNebulaDocker ComposeNginx:8080 · reverse proxyREST APINode.js + Express:3000 · /api/v1 · /docsRediscache and sessionsPostgreSQL + PostGIS:5432uploads/ volumeuser images:8080/apiSQLGitHub Actions runner (self-hosted)git pull · docker compose up -ddeploysNo backups: everything must be rebuildable from GitHubOpen Data BCNBicing (GBFS) · JSONTeam B serviceREST · we consume itFirebase Cloud Messagingpush notificationsGETRESTpushpush notificationGitHubfront and back repos · CIoutbound:the runner polls for jobsrequest (HTTP, SQL)CI/CD and deploymentpush notification
Optional

Component diagram (UML)

A simplified view of the whole system and of how its components relate.

«subsystem» App«UI» Map«UI» Profile:RestClient«subsystem» REST API:Stations:Trips:Authentication«subsystem» External services:Open Data BCN:Team B service/api/v1
Required · sprints

Database schema

A class diagram describing the schema. In relational databases, underline the primary key and put foreign keys in brackets (FK). In NoSQL, use composition for embedded documents and association for references.

userPKemail VARCHARname VARCHARjoinedOn DATEtripPKid SERIALFKemail VARCHARFKorigin INTFKdestination INT NULLstart TIMESTAMPend TIMESTAMPkm NUMERICstationPKid INTname VARCHARgeom GEOGRAPHY(Point)freeBikes INTuserbadgePKemail VARCHARPKname VARCHARdate DATEbadgePKname VARCHARdescription TEXTpoints INTPKprimary keyFKforeign key →
The schema will change every sprint: manage its evolution with SQL create and alter files or with a migrations framework (Liquibase, Django or Laravel migrations, mysql-migrations for Node). More technical aspects →

Common mistakes in the models