2DAM - M03 - UF6 Curs 2022 - 2023

Pràctica (100% de la nota de la UF)

Instruccions
● Consultar la data límit al Moodle
● Qualsevol projecte que es lliuri amb errors de compilació i/o que no arribi a executar no
serà corregit i tindrà una nota de zero.
● Si dos o més lliuraments presenten similituds que no puguin ser degudament justificades,
passen a considerar-se plagis i tenen un impacte negatiu a la nota, que pot arribar a zero.

Enunciat 1
Requeriments 2
No funcionals 2
Funcionals 3
Disseny visual (UI) 3
Usabilitat (UX) 3
Regles de negoci: 3
Funcions CRUD (Create, Read, Update, Delete): 4
Part 1: Disseny 4
Lliurament 5
Part 2: Implementació 5
Documentació 5
Lliurament 6
Part 3 6
Defensa 6
Coavaluació 6
Treball per grups 6
Avaluació de la prova 7

Enunciat
Ens demanen implementar una aplicació en Java que pugui realitzar CRUD de una BBDD ja existent.
La BBDD anomenada m03uf6_22_23 la heu de generar a partir d’aquest esquema:

Versió del document: 1.0 Pàgina 1 de 7

https://drive.google.com/file/d/1wXLWKD8qJvG1dA35Wg0gKgex8gPyS49Q/view?usp=sharing

Analitzeu atentament les característiques de la BBDD per a saber quina és la PK de cada taula, quines
són les principals restriccions, etc.... Per exemple (però no limitat a), els camps orderNumber i
productCode són autoincrementals i no cal calcular-los a l’aplicació.

IMPORTANT: Sota cap concepte es pot modificar l’esquema de la BBDD. Es corregirà amb una
BBDD idèntica a la subministrada.

Requeriments
No funcionals
RN01: S’ha d’evitar la utilització d’antipatrons
RN02: Utilitzar arquitectura de tres capes.
RN03: S’han d’utilitzar les classes i estructures de la forma adient

Versió del document: 1.0 Pàgina 2 de 7

RN05: El codi ha de ser optimitzat, eficient i sense redundàncies
RN09: L’estructura del projecte ha de ser de tipus Maven
RN11; El projecte ha de ser de tipus JavaFXML
RN13: Totes les capçaleres de mètodes i classes han d’estar degudament comentats:
○ Veure https://netbeans.apache.org/kb/docs/java/editor-codereference.html “Creating Javadoc
Stubs”)
○ Per a crear una capçalera, escriure /*** just sobre el nom del mètode i fer intro.

Funcionals
Disseny visual (UI)
- RF11: Colors, icones, marges, agrupació coherent d’elements a la pantalla. Atenció a la
diversitat (discapacitats visuals, motrius, etc…)
- RF15: Responsive
- RF17: A cadascuna de les funcionalitats, l’usuari ha de poder visualitzar per pantalla tota la
informació disponible.
- RF18: Existencia d’un sistema per escollir l'opció desitjada. P.ex (però no limitat a) menús
desplegables, pestanyes, botonera, etc…

Usabilitat (UX)
- RF19: Facilitat d’ús. P.ex (però no limitat a) les funcions han d’estar agrupades d’alguna forma
que faciliti la seva selecció com per concepte, entitat, etc…
- RF20: Totes les situacions anòmales i errors han de ser informades a l’usuari de forma
comprensiva via missatges per pantalla.
- RF21: Coherència i comprensió ràpida de les funcionalitats disponibles i no disponibles en cada
moment. P.ex. (però no limitat a) si no hi ha articles a la BD, no permetre que l’usuari pugui
accedir a la funció “Alta comanda”.

Regles de negoci:
RF30: Per a iniciar l’aplicació ha d’existir al menys un registre a la taula appConfig (la taula appConfig
NO cal que tingui un manteniment a l’aplicació i es pot omplir manualment).
RF32: El valor del camp defaultQuantityInStock s’ha de mostrar com a valor per defecte a la
funcionalitat de donar d’alta un producte.
RF34: El valor del camp defaultCreditLimit s’ha de mostrar com a valor per defecte a la funcionalitat
de donar d’alta un client.
RF36: El valor del camp defaultQuantityOrdered s’ha de mostrar com a valor per defecte a la
funcionalitat de donar d’alta una comanda.
RF38: El valor del camp defaultProductBenefit és el marge de benefici per defecte quan s’aplica al preu
de venda d’un producte a la funcionalitat de donar d’alta una línia de comanda.
RF40: No es pot donar d’alta una comanda amb zero línies de comanda
RF42: No es pot donar d’alta una comanda amb una diferència d’hores entre la data de la comanda i la
data prevista de lliurament menor que el valor del camp minShippingHours
RF44: No es pot donar d’alta un client amb menys edat que el valor minCustomerAge
RF46: No es pot donar d’alta una comanda amb més línies de comanda que el valor de
maxLinesPerOrder

Versió del document: 1.0 Pàgina 3 de 7

RF48: No es pot donar d’alta una comanda amb més import que el valor de maxOrderAmount.

Funcions CRUD (Create, Read, Update, Delete):

Ha d’haver una funcionalitat per a:

RF50: Donar d’alta un client.

RF52: Donar de baixa un client.
RF54: Modificar un client.
RF56: Consultar tots els clients de la BBDD.
RF58: Donar d’alta un producte.
RF60: Donar de baixa un producte.
RF62: Modificar un producte.
RF64: Consultar tots els productes de la BBDD.
RF58: Donar d’alta una comanda. Una comanda és també les seves línies de comanda i els seus
productes relacionats. L’usuari ha de poder veure l’import total de la comanda. L’import total = la suma
de la quantitat de cada article pel preu de venda.
RF60: Donar de baixa una comanda.
RF62: Modificar una comanda. L’usuari ha de poder veure l’import total de la comanda.
RF64: Consultar les comandes entre dues dates.

Part 1: Disseny
En aquesta fase s’ha de lliurar un document que inclogui el següent:

● Portada, índex. Atenció a l'ortografia, al vocabulari tècnic i a la claredat expositiva en tot el

document.
● Planificació de les tasques previstes per a cada membre del grup.
● Esquema visual o mockup de cada pantalla de la GUI, incloent el menú principal. L’esquema ha
d’incloure tots els aspectes visuals, funcionals i possibles interaccions de l’usuari i s’ha de
relacionar amb la llista de funcionalitats (recordeu que un mockup NO CAL que sigui quelcom
al detall). Es pot utilitzar qualsevol eina de mockup disponible. P.ex: https://balsamiq.cloud/
● Breu explicació de les funcionalitats CRUD que es volen implementar en forma de casos d’ús.

Exemples:

Cas d’ús Alta de Comanda

Precondicions Ha d'existir un o més registres a la taula customers

Ha d’existir un o més registres a la taula de productes

Postcondició S’ha afegit un nou registre a la taula orders

Existeix un o més clients
Existeix un o més articles

Propòsit Fer una comanda

Versió del document: 1.0 Pàgina 4 de 7

 Resum L’usuari introdueix les dades de la comanda, les seves línies i confirma.

Cas d’èxit: 1. Es selecciona l’opció “Alta de comanda”

2. Apareix un selector de clients
3. Es selecciona un client
4. S’introdueixen les dades inicials de la comanda (dates, etc…)
5. Es selecciona un article i s’introdueix un preu i una quantitat.
6. Es retorna al pas anterior o bé es confirmen les dades
7. El sistema informa de que la comanda ha sigut desada a la BD

Cas erroni 1: 1. Es selecciona l’opció “Alta de comanda”

2. Apareix un selector de clients
3. Es selecciona un client
4. S’introdueixen les dades de la comanda (dates, etc…)
5. El sistema informa a l’usuari que la data de lliurament és massa
propera a la data actual (segons RF42).
6. L'usuari manté les dades en pantalla per a poder modificar-les

Lliurament
● Abans de la data límit, a la tasca de Moodle, pujar un fitxer PDF amb el demanat.
● Ho ha de pujar un sol membre del grup

Si no es supera aquesta fase amb una qualificació de “FET” no es pot superar la pràctica.

Part 2: Implementació
Implementar una aplicació que cobreixi els máxims dels requeriments funcionals i no funcionals
planificats a la fase de disseny. Qualsevol desviació no justificada respecte al document de disseny
tindrà un impacte negatiu a la nota. Consultar la rúbrica.

Documentació
En aquesta fase s’ha de lliurar un document que inclogui el següent:

- Portada, índex. Atenció a l'ortografia, al vocabulari tècnic i a la claredat expositiva en tot el

document.
- Enllaç al projecte del Git. IMPORTANT: Afegir a manel.oros@copernic.cat com a mantainer
del vostre projecte.
- Llistat dels requeriments on ha participat cada membre del grup i el temps aproximat invertit.
Aquesta informació ha de ser coherent amb els commits realitzats al Git.
- Instruccions (si procedeix) per a executar el vostre projecte.
- Tots aquells aspectes que cregueu oportú esmentar per a tenir en compte a la correcció.

Versió del document: 1.0 Pàgina 5 de 7

Lliurament
● Abans de la data límit, a la tasca de Moodle, pujar un fitxer ZIP del projecte fent Archivo →
Exportar Fichero → ZIP.
● El nom del projecte ha de ser M03UF6PracM/T (M o T en funció si és grup de matí o de tarda)
i el nom del grup. Per exemple: M03UF5PracTK
● El ZIP l’ha de lliurar un sol membre del grup. Pot ser qualsevol.

Si no es lliura aquesta fase no es pot superar la pràctica.

Part 3
Aquesta part es realitza a l’aula quan el professor ho comunica i es divideix en dues parts: defensa i
coavaluació.

Defensa
Cada alumne realitza una defensa INDIVIDUAL de la seva contribució al projecte. Aquesta defensa
dura uns 5 minuts i es revisa el següent:
- Revisió de tasques realitzades segons la documentació lliurada a la part 2
- Comparació de les tasques realitzades amb les tasques planificades
- Comparació de les tasques realitzades amb els commits del Git
- Coneixement del codi i la funcionalitat de les tasques relaitzades

La no superació d’aquesta té un impacte negatiu a la nota

Coavaluació
Cada grup avalua alguns aspectes de la resta de projectes dels seus companys/es.
Cada grup reb una part de la nota fruit de la l’avaluació de la resta dels seus companys/es.
Si un grup avaluador es desvia clarament de la realitat sobre un o més dels grups que avalua, pot rebre
una penalització.
Si un grup avaluador s’ajusta exactament a la realitat sobre tots els grups que avalua, pot rebre una
bonificació.

Treball per grups

Qualsevol alumne que no estigui inclòs a un grup al moment de tancar primera fase de la pràctica
(consultar les dates a la tasca del Moodle) no podrà optar a fer la pràctica.
Qualsevol grup que no lliuri la primera fase no podrà optar a la segona fase.

Totes les persones del grup reben la mateixa puntuació, excepte que sigui evident i demostrable
objectivament i per escrit (p.ex via commits, via llistat de tasques realitzades o via correu privat al

Versió del document: 1.0 Pàgina 6 de 7

professor) que el temps de dedicació d’aquesta persona hagi esdevingut anormalment baix o
anormalment alt. En aquest cas concret, es puntuarà de forma diferent.

Avaluació de la prova
● Cada requeriment o apartat té una puntuació (positiva o negativa)
● Consultar la puntuació a la rúbrica al Moodle

Versió del document: 1.0 Pàgina 7 de 7