UDG – ENGINYERIA INFORMÀTICA

Projecte Enginyeria del Software

Gestió i monitorització de restaurants d’alt nivell

Cristian Álvarez Sánchez - Rubén Amaro Parrado - Nicolás Joel Giacconi Fernández – Óscar Simón Castillo

22/05/2012

2

3

Índex 1 - Pla de Projecte ................................................................................................................ 5

1.1 – Introducció ........................................................................................................ 5

1.2 – Recursos utilitzats .............................................................................................. 5

1.3 – Planificació ........................................................................................................ 7

1.4 – Diagrama de Gantt ............................................................................................. 8

2 – Requeriments i Cassos d'Ús ............................................................................................ 9

2.1- Introducció als requeriments ..................................................................................... 9

2.2 – Diagrames i fitxes de cas d’ús ........................................................................... 13

3– Anàlisi .......................................................................................................................... 21

3.1- Introducció ............................................................................................................. 21

3.2- Diagrames de classe ................................................................................................ 21

3.2.1- Diagrama de classe de la Tablet (Pantalla) ......................................................... 21

3.2.2- Diagrama de classe de la Tablet (Sistema) – Primera Iteració ............................. 23

3.2.3- Diagrama de classe de la Tablet (Sistema) – Segona Iteració .............................. 26

3.2.4- Diagrama de classe de la Tablet (Sistema) – Tercera Iteració .............................. 28

3.2.5- Diagrama de classe de l’aplicació Java – Primera iteració ................................... 29

3.2.6- Diagrama de classe de l’aplicació Java – Segona iteració .................................... 31

3.3. – Fitxes de cassos d’ús per l’informàtic ..................................................................... 33

3.4. – Diagrames de seqüència ................................................................................... 38

3.4.1. – Validar Comanda...................................................................................... 38

3.4.2. – Treure productes de la comanda (no enviada) .......................................... 40

3.4.3. – Treure productes de la comanda (ja enviada) ............................................ 42

3.4.4. – Realitzar comentari sobre un producte ...................................................... 44

3.4.5. – Reduir Stock ............................................................................................. 46

3.4.6. – Canviar d’estat un producte ...................................................................... 48

3.4.7. – Generació de llistats estadístics ................................................................. 50

3.4.8. – Veure recomanacions restaurant ............................................................... 51

3.4.9. – Actualitzar Stock real i orientatiu............................................................... 52

3.4.10. – Assignar Tablet a taula .............................................................................. 53

3.4.11. – Fer pagament comanda ............................................................................. 54

4 – Disseny ........................................................................................................................ 56

4.1 - Introducció ............................................................................................................ 56

4.2 - Base de dades ....................................................................................................... 56

4

5- Prototipus ..................................................................................................................... 59

5.1- Part Android ........................................................................................................... 59

5.2- Part Java ................................................................................................................. 65

6- Manual d’usuari............................................................................................................. 67

7- Annex 1: Anàlisi de la Planificació ................................................................................... 70

8- Annex 2: Patrons de Disseny .......................................................................................... 71

9- Conclusions Finals .......................................................................................................... 74

5

1 - Pla de Projecte

1.1 – Introducció

L’objectiu d’aquest projecte és la creació d’una aplicació multi plataforma, per als diferents àmbits d’un restaurant. Aquesta aplicació, estarà enfocada a les diferents parts de les que es composa un restaurant. Per una part, el punt de vista del client, amb la conseqüent posada a punt del menú, de la petició de les comandes i de la demanda del compte, mitjançant una tablet. I per altra banda, la part corresponent als treballadors del restaurant. Aquesta part, es subdividirà en els diferents càrrecs, com els cuiners, els cambrers, el director, etc. D’aquesta manera, tots podran interactuar amb una aplicació Java per ordinador, amb diferents opcions depenent del càrrec del treballador. En aquest document s’explicarà tot el relatiu a aquest projecte. Es començarà parlant sobre el context d’aquest projecte, i una petita descripció. També s’exposarà el grup que composa aquest projecte, les eines utilitzades, la planificació i el seu corresponent diagrama de Gantt. Es seguirà amb els requeriments que vam trobar per fer aquest projecte, amb la corresponent divisió entre la part client i la part treballador, els diagrames i fitxes de cas d’us de les accions que hem trobat més rellevants. A partir d’aquí, seguirem amb l’anàlisi de tot el projecte, amb raonaments que hem fet al llarg del procés, les successives versions del diagrama de classes i la generació dels corresponents diagrames de seqüència per cada acció que hem trobat rellevant a l’apartat de cassos d’ús. Explicarem el disseny de la resta de l’aplicació, la creació de la base de dades, i el refinament dels detalls que vam trobar pertinents. Acabarem aquesta part fent una descripció de les capacitats funcionals finals de l’aplicació, i de les futures extensions que trobem que es podrien fer per millorar-la. Seguirem amb el prototipus de la nostra aplicació, tant la part de la tablet, com la de l’aplicació Java pels treballadors, així com també el diagrama de navegació Web que van veure necessari per la part de reserves de la nostra aplicació. Finalment, també s’inclouen una sèrie d’annexos pels diferents aspectes que hem cregut necessaris. Respectivament, tenim un pel manual d’usuari, un altre per l’anàlisi dels patrons de disseny, un altre per donar la nostra visió comercial de l’aplicació i el final, per descriure les tecnologies utilitzades en aquest projecte, i per què les hem fet servir. Acabarem amb unes conclusions sobre el treball fet, i les valoracions personals que ens donem per la feina feta. Sense dir res més, comencem.

1.2 – Recursos utilitzats

Al llarg de tot el projecte s’han utilitzat diferents recursos, tant humans com tècnics, per poder

acabar-lo de manera adequada. Pel que fa als recursos humans, nosaltres som un grup de quatre

persones, les quals hem fet el 100% del projecte, repartint la feina d’aquesta manera:

Nicolás Giacconi: Project manager, coordinador, disseny de classes y requeriments del sistema

Oscar Simón: Disseny de classes y requeriments del sistema, amb un enfocament a l’apartat de sistemes, xarxes, servidors, etc.

Rubén Amaro: disseny de classes, requeriments del sistema i dissenyador de la interfície gràfica. Encarregat del prototipatge.

Cristian Álvarez: disseny de classes, requeriments del sistema y coordinador de la documentació.

6

A partir d’aquests “càrrecs” s’han anat fent les successives iteracions i presentacions del projecte,

cadascú encarregant-se de la seva part. Tot i així, al final “tots hem fet de tot” i hem hagut de

tractar amb diferents aspectes generals, així com també l’avaluació de la feina de tots els

companys, per verificar la seva correctesa.

A part d’això, s’han hagut d’utilitzar els recursos tècnics propis d’una carrera com la que fem.

Recursos que ens han ajudat a organitzar-nos, tenir clar quines versions estàvem modificant o bé,

simplement a fer diagrames UML de manera correcta. En resum (a l’annex comentem aquest

aspecte amb més detall), aquestes han sigut les eines utilitzades en aquest projecte:

Nom Recurs Descripció

Per realitzar la planificació del projecte i les posteriors modificacions, s’han fet servir els diagrames de Gantt. Per fer-los, s’ha utilitzat l’eina Gantt Projecte, gratis i multi plataforma.

Eina online per realitzar diagrames de diferents tipus, des de UML, fins a base de dades. Incorpora un control de versions que ens ha anat molt bé, i tots els diagrames d’aquest projecte han estat fets mitjançant aquesta eina.

Eina online d’edició i visió de documents. Bàsicament, és una suite ofimàtica en el núvol gratis, amb un senzill editor que hem fet servir per la majoria dels documents entregats. També incorpora un historial de revisions i ha permès l’edició i col·laborativa de tot el grup, gràcies al seu sistema d’edició amb grups de treball.

Suite ofimàtica offline, utilitzada com complement de l’eina anterior. Bàsicament, ens ha permès un millor tractament de les imatges i dels diagrames.

Paint. Gràcies a aquesta senzilla eina, hem pogut modificar imatges fàcilment i sense gaire problemes. Com es coneix, gratuïta i disponibles als SO Windows.

El “notari” al nostre grup. Cada reunió feta, cada desició presa, cada tasca pendent, cada entrega propera, etc. Era registrada per l’eina de notes online Evernote. El coordinador s’encarregava d’enregistrar la informació, i d’enviar-la a la resta del grup, mitjançant una nota d’aquesta eina.

7

A més del tot descrit anteriorment, hem utilitzat el sistema de correu Gmail i Hotmail, per constants

avisos o missatges, i mantenir-nos així sincronitzats. Pel que fa a l’historial de revisions, hem anat

utilitzant el de les eines abans descrites. Finalment, per comunicar-nos quan no hi érem a la

universitat, hem utilitzat el sistema de missatgeria Gtalk i Hotmail Messenger, per escrit, i el Skype

per conversacions entre tots de manera auditiva.

1.3 – Planificació

Per començar, parlarem de les diferents entregues que hem fet al llarg del quadrimestre, en mostra

dels avanços fets amb el projecte. Respectivament, les entregues han sigut aquestes:

Data d’inici del projecte: 21 de Febrer del 2012.

Data d’entrega dels requeriments i cassos d’ús: 19 de Març del 2012.

Data d’entrega de l’anàlisi del projecte: 1 de Maig del 2012.

Data d’entrega del disseny i document final del projecte: 22 de Maig del 2012.

Data d’entrega de la presentació final del projecte: 5 de Juny del 2012.

Fase % Temps Destinat Hores Requeriments 15% 45h

Anàlisi 35% 105h Disseny 20% 60h

Prototipatge 15% 45h Documentació 15% 45h

Total 100% 300h

Òbviament, depenent del càrrec de cadascú, haurà treballat un nombre determinat d’hores en cada

apartat. En teoria, si som 4 membres al grup, cadascú haurà treballat unes 75 hores en aquest

projecte. Tot i així, i degut a les diferents fases que s’han treballat (i a les dificultats d’aquestes, més

detalls a l’annex de les valoracions personals) alguns membres han treballat en algunes fases que en

altres. Seguidament, desglossem les diferents fases amb les hores que ha dedicat cada membre del

grup:

Càrrec Requeriments Anàlisi Disseny Prototipatge Documentació Total Cristian 18h 25h 12h 4h 16h 75h Rubén 15h 25h 10h 20h 5h 75h Nicolás 15h 30h 10h 0h 20h 75h Óscar 15h 20h 15h 10h 15h 75h

Cal dir que, a més de tot això, s’han fet reunions per tractar temes com l’estat del projecte, dubtes

amb temes corresponents o simplement, per posar a punt tot el relatiu a la sincronització de la

feina pendent. Com es pot veure, tothom ha invertit una quantitat superior d’hores a la fase

d’Anàlisi. Tot això s’explicarà a l’annex de les valoracions personals.

A partir d’aquesta informació, s’ha fet un diagrama de Gantt amb tota la feina feta separada per un

espai de temps, indicant què s’ha fet. Analitzant aquest diagrama, es pot veure l’evolució del

projecte en comparació amb la planificació inicial (explicada a la primera entrega d’aquest

8

projecte). A més, s’indiquen les entregues de documents que s’han fet, i les reunions fetes amb el

professor.

1.4 – Diagrama de Gantt

9

2 – Requeriments i Cassos d'Ús

2.1- Introducció als requeriments

En aquesta secció, s'explicarà el punt de vista que s'ha agafat per realitzar els requeriments

d'aquesta aplicació, les decisions preses a partir d'aquests requeriments i el posterior refinament

d'aquests. També explicarem quina mesura vam prendre a l'hora de realitzar els diagrames i fitxes de

cassos d'ús.

A l'hora de començar a plantejar els requeriments de la nostra aplicació, calia tenir ben clar què es

podia fer, i què no es podia fer amb la nostra aplicació. Per això, vam fer una divisió dels punts de

vista, en dues parts. La part del client, i la part del treballador. D'aquesta manera, sabem

perfectament a quina part de l'aplicació estem fent referència (Tablet pel client, i aplicació Java pel

treballador, tot i que més endavant expliquem ambigüitats). Així, els requeriments que hem tret, es

divideixen en aquestes parts, tant els funcionals com els no funcionals.

Part Client

El client podrà fer una comanda amb diversos productes des de la seva taula mitjançant una tablet

proporcionada pel cambrer, on es veuran tots els plats possibles, recomanacions, opinions sobre els

productes etc. Tot això es demanarà en forma de comandes, amb molts productes per comanda,

però només una comanda per taula (tot i que pot haver-hi més d'una tablet per taula). També, el

client podrà actualitzar la seva comanda (per exemple, si a mig menjar vol una altra llauna de Coca-

Cola) o cancel·lar un plat en procés (tot i que això es permet fins que el cuiner es posa a preparar-lo).

Finalment, el client podrà controlar quan porta gastat i quins productes ha demanat. A més, es dona

l’opció de reservar taula via web, per tal de poder anar al restaurant sense tenir por de no trobar

taula.

Part Client - Requeriments Funcionals

Presentar de manera digital tota la carta del restaurant al client classificada en un menú segons l’equip directiu vulgui. El cas estàndard de l’aplicació tindrà:

Entrants

Primers Segons

Postres Begudes Menú diari.

Aquest menú és personalitzable per cada restaurant.

10

Dins de cada una de les seccions del menú principal apareixerà una llista de tota la oferta d’aquella secció ordenada alfabèticament acompanyada d’una petita imatge del producte. Per una informació més detallada, cada producte tindrà una subpantalla.

Tots els productes han de tenir una àmplia informació que estarà composada de:

Un petit text descriptiu. Una imatge amb suficient qualitat El preu del producte

Recomanacions Comentaris Puntuació general dels clients (opció per als productes que es desitji)

Tant en la llista per seccions, com en la pantalla de cada producte, el client ha de tenir l‘opció d’afegir el producte a la comanda.

L’aplicació ha de disposar d’una pantalla on es previsualitzi la comanda i pugui ser enviada cap a la cuina si tot està correcte.

Un cop la comanda s’ha enviat cap a cuina, i mentre no s’hagi tancat (pagament efectuat), el client és lliure de demanar qualsevol producte afegit, que serà notificat a la corresponent zona del restaurant per poder ser servit.

Abans de tancar la comanda, el client té l’opció de puntuar, fer un comentari o

recomanació sobre el producte que ha escollit per tal de fer una valoració que servirà pel

propi restaurant i futurs clients.

La pàgina web del restaurant tindrà un accés a la reserva prèvia de taula per al restaurant pell dia i la hora que el client desitji.

Part Client - Requeriments No Funcionals

S’hauran de tenir tablets amb sistemes operatius Android 2.2 (Froyo) i que estiguin constantment en connexió amb la base de dades central del sistema (descrita més endavant). A més, cal tenir també a prop cables de càrrega per tal de que aquestes tablets no es quedin sense bateria (es pot tenir més tablets de les que es repartiran amb el restaurant complert i aprofitar per carregar les no utilitzades). A més, per la part de les reserves, caldrà que el restaurant tingui web operativa, i que el restaurant accepti reserves.

Part Restaurant - Bussiness Requirements

La part d’administració consistirà en el control i modificació de dades de l’aplicació per part del personal del restaurant. Classificat en diferents nivells, permetrà que el personal pugui cobrar (part barra) pugui veure i planificar les comandes a preparar (part cuina), fer un control del stock de les

11

mercaderies (par magatzem), realitzar un control general de les dades de l’aplicació (part “Jefe”) i fer un manteniment de tota l’aplicació en general (part administrador).

Part Restaurant - Requeriments Funcionals

Es desenvoluparà una aplicació per gestionar la part interna d’un restaurant, des del punt de vista de la barra del bar, la cuina, el magatzem i el “Jefe”.

Barra del bar: L’aplicació permetrà gestionar les noves comandes (de begudes) que vagin fent els clients (des de una carta electrònica). Podran anar marcant les comandes com a servides o es podran anular a petició del client. També permetrà gestionar les comptes a l’hora de pagar els clients (crear, modificar, anular...).

Cuina: L’aplicació permetrà gestionar les noves comandes (de menjar) que vagin fent els clients (des de una carta electrònica). Podran anar marcant les comandes com a servides o es podran anular a petició del client (tot i que a partir d’un cert punt aquestes comandes no es podran anular).

Magatzem: Aquesta part es podria dividir en dos:

Aplicació de gestió: Aquesta eina permetrà al responsable de magatzem portar un control REAL de l’estoc de tots els productes necessaris per al local, fer comandes i donar baixes de productes.

Aplicació de orientativa: Segons les vendes que s’han fet, l’aplicació indicara al encarregat de magatzem l’estoc orientatiu que hauria d’haver-hi al magatzem. Aquesta informació servira per contrastar si hi ha moltes pèrdues (poca eficiència), “robatori”, etc.

Aquestes dues parts anirien unificades de tal manera que l’encarregat del magatzem pugui veure cada cert temps, si “li quadren” les seves quantitats de menjar indicat com consumit, i (en cas negatiu) cercar el perquè.

Central de dades: és on l’aplicació ubica el gruix de les dades, amb totes les seves característiques, i amb les quals la resta de parts podran treballar.

Jefe: amb aquesta part es podrà administrar tot el que succeeixi al sistema. Es podar consultar totes les dades de magatzem, comandes (restaurant i cuina), modificar la carta (per si no es pot oferir un cert producte) i consultar les estadístiques realitzades per el sistema.

Administrador: l’encarregat del “manteniment” de tota l’aplicació, i capaç d’accedir a totes

les parts d’aquesta.

12

Càlcul d’Estadístiques: amb les dades provinents del servidor central, es podran fer càlculs estadístics per obtenir tendències sobre què menja la gent al nostre restaurant, quan ho fa, que li sembla el nostre menjar, etc.

Part Restaurant - Requeriments No Funcionals

Part barra del bar: requerirà un PC amb característiques estàndard i connexió LAN amb el servidor central de dades (explicat més endavant).

Cuina: requerirà un PC amb característiques estàndard, i amb connexió LAN amb el servidor central de dades. A més, requerirà d’un control de comandes, per tal que un cuiner pugui “agafar-les” i que aquestes constin com “ja agafades”. D’això, en traiem que necessitarem pantalles per tal que els cuiners puguin veure fàcilment quines comandes tenen disponibles i quant temps es porten esperant els que ho han demanat.

Part Magatzem: altre PC amb característiques estàndard al qual es pugui afegir i controlar tot el relatiu al stock del menjar al magatzem. Aquest PC podrà serà consultat per l’encarregat del magatzem.

Central de dades: aquí és on es ficaran totes les dades relatives a les comandes, les quals s’utilitzaran després en les diferents parts de l’aplicació. Per això, disposarem d’un cluster format per dos servidors sobre Red Hat amb base de dades MySQL. Amb això aconseguim que, si cau el servidor principal, l’altre servidor del clúster realitza les tasques del servidor principal, i així evitem que el restaurant no gaudeixi de la nostra aplicació.

Administrador: un PC estàndard amb capacitat i permisos per accedir a totes les parts de l’aplicació i a la base de dades.

Jefe: requerirem un altre PC amb característiques estàndard on el cap podrà fer el control general de totes les dades de l’aplicació.

Càlcul d’Estadístiques: es realitzaran al servidor central de dades, tant els càlculs com les consultes dels resultats.

Davant aquests requeriments, el nostre grup va agrupar (també en dues parts, com s’ha fet abans)

les diferents accions que vèiem possibles pels futurs actors de la nostra aplicació. Accions, en un

primer cas, simples i òbvies, com que un client pugui escollir un producte o veure més informació. En

una segona instància, van sorgir les accions realment necessàries de definir, les que ens platejarien

dubtes sobre el format del diagrama de classes, la base de dades o, simplement, que ens donessin

debat sobre el nostre projecte i la direcció que havíem d’agafar. Totes aquestes accions es recullen a

la següent secció, on s’han formulat les fitxes i diagrames de cas d’ús per aquestes. Ja des d’aquest

punt separem les parts abans descrites referides als diferents càrrecs dels treballadors. Sense res

més a dir, passem a veure tot el relatiu als cassos d’ús.

13

2.2 – Diagrames i fitxes de cas d’ús

Tenint ben clara la idea inicial de l’aplicació, hem anat analitzant possibles accions per cada part (client i treballador) i així, obtenir una llista de cassos d’ús. Dit això, les accions que hem escollit per representar el que pot fer, tant el client com el treballador, han sigut aquestes:

Client:

o Afegir productes a la comanda o Treure productes de comanda (no enviada) o Treure productes de comanda (enviada) o Reservar taula via web o Validar comanda o Demanar el compte a pagar o Consultar informació producte o Realitzar comentari sobre un producte o Veure recomanacions del restaurant

Treballador Restaurant:

o Generar llistats estadístics o Reduir Stock o Canviar d’estat un producte o Donar de baixa un producte o Actualitza Stock Real / Orientatiu o Facturar comanda o Assignar Tablet a taula o Deslligar Tablet a taula

Amb aquestes accions, podem generar, tant els diagrames, com les fitxes de cas d’ús, que ens ajudaran a definir més endavant, cada acció al seu diagrama de seqüència. Seguidament, ensenyem el diagrama de cas d’ús i les fitxes corresponents:

14

15

Hem considerat correcte que, les accions que es considerin més complexes, aniran en aquests

diagrames, tot i que mirarem de representar la seva descripció amb les fitxes de cas d’ús, les quals

ensenyem seguidament:

Fitxa Usuari

Nom: Afegir productes comanda Descripció: Permet al client afegir productes a una comanda Actors: Client Precondicions: La comanda no ha estat enviada i permet l’addició i modificació de

productes Flux normal: 1. 1. Seleccionar secció comanda.

2. 2. Seleccionar botó modificar. 3. 3. Mentre no acabat

3.1. Seleccionar producte. 3.2. Seleccionar quantitat. 3.3. Confirmar.

5. 4. Confirmar selecció. Flux alternatiu: Postcondicions: Comanda modificada amb els productes que ha volgut el client

Fitxa Usuari

Nom: Treure productes comanda (sin enviar) Descripció: Permet eliminar productes d’una comanda que estem realitzant des

de la Tablet a la taula, sense que aquesta s’hagi enviat encara Actors: Client Precondicions: Comanda no enviada Flux normal: 1. 1. Polsar botó eliminar productes comanda.

2. 2. Mentre no acabat. 2.1. Seleccionar producte 2.2. Confirmar selecció més productes.

Flux alternatiu: - Postcondicions: Producte eliminat de la comanda correctament.

16

Fitxa Usuari

Nom: Treure productes comanda (enviada) Descripció: Permet treure productes a una comanda que ja s’hagi validat. Actors: Client Precondicions: La comanda ja ha estat enviada. Flux normal: 1. 1. Polsar botó treure productes comanda ja enviada

2. 2. Mentre no acabat. 2.1 Seleccionar producte. 2.2 Confirmar acció

Flux alternatiu: Postcondicions: Comanda ja enviada amb nous productes llestos per que els detecti

l’ordinador de la cuina

Fitxa Usuari

Nom: Reservar taula (via web) Descripció: Permet a l’usuari reservar taula del restaurant via web Actors: Client Precondicions: El sistema ja s’encarrega de verificar la disponibilitat Flux normal: 1. 1. Seleccionar opció reserva.

2. 2. Seleccionar dia. 3. 3. Seleccionar hora 4. 4. Seleccionar numero persones. 5. 5. Afegir dades contacte 6. 6. Confirmar selecció.

Flux alternatiu: Postcondicions: Taula reservada correctament i e-mail enviat correctament

Fitxa Usuari

Nom: Confirmar comanda Descripció: Permet confirmar la comanda des de una Tablet de la taula Actors: Client Precondicions: Comanda amb al menys un producte Flux normal: 1. 1. Polsar botó validar comanda. Flux alternatiu: - Postcondicions: Comanda enviada correctament i confirmada pel client.

17

Fitxa Usuari

Nom: Consultar informació producte Descripció: Permet a l’usuari consultar la informació d’un producte des de la

taula via Tablet Actors: Client Precondicions: - Flux normal: 1. 1. Seleccionar opció productes.

2. 2. Seleccionar productes. 3. 3. Seleccionar pestanya descripció

Flux alternatiu: Postcondicions: Informació del producte disponible per la pantalla de la Tablet.

Fitxa Usuari

Nom: Veure recomanacions restaurant Descripció: Permet veure les recomanacions del restaurant des de la Tablet Actors: Client Precondicions: - Flux normal: 2. 1. Seleccionar secció recomanacions restaurant. Flux alternatiu: - Postcondicions: El client pot visualitzar els productes recomanats pel restaurant

Fitxa Usuari

Nom: Fer comentari d’un producte Descripció: Quan els clients decideixin pagar la comanda, donar la possibilitat de

fer comentaris sobre els productes consumits Actors: Client Precondicions: Clients amb comanda ja pagada Flux normal: 1. Seleccionar opció fer comentaris

2. Escollir un producte dels consumits 3. Realitzar valoració de 1 al 10 3. 1. Si el client vol, també es farà un comentari de text 4. Repetir si el client vol realitzar més comentaris

Flux alternatiu: Postcondicions: Tablet deslligada i llesta per tornar-se a utilitzar

18

Fitxa Usuari

Nom: Reduir stock.

Descripció: Permet al cap del magatzem reduir del stock una quantitat determinada

d’un producte en concret.

Actors: Cap del magatzem

Precondicions: -

Flux principal:

1. Llistar ingredients del stock.

2. Seleccionar un ingredient.

3. Marcar opció reduir stock.

4. Entrar quantitat a reduir.

5. Marcar el motiu de la reducció.

6. Reduir stock.

Flux alternatiu: -

Postcondicions: El producte queda reduït del stock una certa quantitat.

Fitxa Usuari

Nom: Canviar d’estat un producte.

Descripció: Els productes de la nova comanda que arriba van canviant d’estat segons

l’estat anterior en que es troben.

Actors: Treballador cuina o treballador bar

Precondicions: Estat inicial del producte = ‘no iniciat’

Flux principal:

1. Seleccionar comanda.

2. Marcar opció que llistar els productes de la comanda.

3. Seleccionar producte.

4. Marcar opció canvi d’estat.

Flux alternatiu: -

Postcondicions: El nou estat del producte és el següent al que tenia.

19

Fitxa Usuari

Nom: Actualitza Stock Real i Orientatiu Descripció: Comparar les dades reals de stock amb les dades orientatives que

ens indica el sistema per tal de veure si les vendes realitzades son acords amb els productes entregats.

Actors: Cap Magatzem Precondicions: Dades suficients a la base de dades per fer la comparació Flux normal: 1. 1. Comparar valors reals i orientatius

2. Modificar valors orientatius per ajustar-los als reals Flux alternatiu: Postcondicions: Posar el stock orientatiu igual que el real un cop validades les

comparacions

Fitxa Usuari

Nom: Assignar tablet a taula Descripció: El cambrer assigna una tablet sense utilitzar a una taula Actors: Cambrer Precondicions: Tablet sense utilitzar Flux normal: 1. Seleccionar taula destí Flux alternatiu: Postcondicions: Clients a taula amb la tablet lligada i sincronitzada

20

Totes aquestes fitxes descriuen per sobre les accions que podran fer els actors de la nostra

aplicació. Això ens va ajudar a fer el diagrama de classes i els posteriors diagrames de seqüència. En

aquests diagrames de seqüències, es realitzaran les accions de les fitxes representant d'aquesta

manera el nexe entre les fitxes i els diagrames. Cal dir, però, que aquestes fitxes van ser la primera

iteració, ja que més endavant, es podran veure eles fitxes "per l'informàtic" on es descriuen més

detalladament tot el que s'haurà de fer als diagrames de seqüència. D'aquesta manera abans de fer

aquests diagrames, ja tenim clar el que s'hauria de fer, i de quina manera fer-ho. Fins aquí, la fase

d'especificació i comprensió dels requeriments, on s'estableixen les accions i requeriments bàsics

per l'aplicació. A partir d'aquí començarà l'anàlisi, on tractarem tot el relatiu al diagrama de classes,

les fitxes de cas d'ús per informàtics, els diagrames de seqüència, i totes les iteracions d'aquests,

amb les corresponents explicacions de l'evolució seguida, i la necessitat dels canvis.

21

3– Anàlisi

3.1- Introducció

Una vegada tenim clars els requeriments de l'aplicació, vam començar l'etapa de l'anàlisi amb el

diagrama de classes. Vam decidir que la base de dades, si bé és un element molt important,

necessitava definicions i conceptes relatius als diagrames de classe i de seqüència. Per això,

aquesta fase la vam dividir en

Confecció del diagrama de classes

Confecció de les fitxes de cas d'ús per l'informàtic

Confecció dels diagrames de seqüència

Per cadascuna d'aquestes parts, s'han fet més d'una iteració en concepte d'evolució de projecte.

En aquesta part s'explicarà com han evolucionat els diferents diagrames, quins canvis es van

aplicar, i amb quin motiu.

3.2- Diagrames de classe

Per fer aquests diagrames de classe, vam tenir en compte l’estructura de la nostra aplicació. Per

una part, tenim la part de la Tablet, basada en un sistema operatiu Android, amb tot el que això

comporta. I per altra, l’aplicació Java, amb la que podran interactuar els treballadors del

restaurant. Per això, vam dividir el diagrama de classes en tres parts, la part relativa a la pantalla de

navegació de la Tablet, la part interna de la Tablet i tot el relatiu a l’aplicació Java. Aquestes últimes

dues parts, son les que hem considerat més importants, i que pateixen una evolució amb diferents

canvis fets per nosaltres o suggerits pel professor. Per això, anirem passant diagrama a diagrama

per veure les seves característiques i comentar per sobre el perquè de la seva estructura.

3.2.1- Diagrama de classe de la Tablet (Pantalla)

Per fer aquesta part, vam concloure en muntar una mena de diagrama de navegació entre les

diferents classes que ens sortissin. D’aquesta manera, i mitjançant el nostre membre amb

experiència amb Android (Rubén), vam muntar aquest diagrama de clases, amb totes les possibles

pantalles que es podien representar, i les variables i mètodes necessaris per poder treballar. El

resultat és un pseudo-diagrama de navegació, amb les pantalles o casos principals amb que es pot

trobar un usuari d’aquesta Tablet, perfectes per un dissenyador gràfic d’aplicacions, i els mètodes i

variables que utilitza a nivell de codi, per l’ajuda del programador. Tot això, en conjunt forma el

nostre diagrama de classes de la part visual de la Tablet. Seguidament, ensenyem el diagrama:

22

23

Com es pot veure, cada “classe” representa cada una de les possibles pantalles que contindrà la

Tablet. Sempre es començarà a la pantalla principal de l’aplicació, que és on romandrà la Tablet

just després de que el cambrer li assigni una taula. Aquesta pantalla principal donarà un

missatge de benvinguda, i donarà a veure les diferents opcions que tindrà el client. Aquestes

opcions es mostraran mitjançant botons visuals, i portaran al client a pantalles diferents, on

pugui realitzar les accions descrites als cassos d’ús. La primera opció serà la de veure la carta

(classe Carta), on la Tablet carregarà les dades del menú a la seva memòria (més endavant

descriurem la part interna del sistema que utilitza la Tablet). Aquestes dades es mustraràn per

pantalla mitjançant una sèrie de menús d’opcions amb les respectives opcions que dona el

restaurant, estructurant el menú. Tal i com vam dir abans, aquestes opcions seran les dels

entrants, els primers plats, els segons, els postres, les begudes (de tot tipus) i el menú diari. El

client, “polsant” a sobre d’un producte, podrà passar a la seva pantalla de confirmació, on

podrà veure més informació del producte, fotos, comentaris, etc, i a més podrà confirmar si vol

el producte, i quina quantitat vol.

El client també podrà veure les recomanacions específiques del restaurant, sigui per donar més

importància o fama a un producte, o per trobar nous clients habituals amb els millors plats dels

restaurant. El client podrà arribar a aquesta pantalla per la pantalla principal, o per la pantalla

de la carta, amb el botó “Menu” de la Tablet (amb el qual surten més opcions, i aprofitem per

no sobrecarregar la pantalla amb el mateix nombre d’opcions tota l’estona). Aquesta pantalla

portarà, amb l’opció del client, a la pantalla d’informació del producte, per tal que aquest pugui

informar la selecció, i llavors, escollir la quantitat de productes d’aquest tipus que vol demanar.

A partir d’aquestes dues pantalles, el client podrà confirmar la comanda, amb una opció del

botó “Menu” de la Tablet. Amb aquesta confirmació, es posarà en marxa tot el procés de

recollida i lectura de base de dades, que explicarem més endavant. De moment, ens quedem

amb el que això representa. El fet que un client confirmi la comanda, provoca un missatge de

confirmació per part del sistema (per si de cas el client ha seleccionat aquest opció sense voler).

Si el client confirma el missatge, llavors la Tablet ho enviarà a la pantalla d’inici, on es

mostraran els productes actuals de la comanda (els que, en teoria porta fins ara).

Finalment, la pantalla de pagament, on el client accedirà mitjançant, una altra vegada, des

d’una opció de la pantalla principal, o des del botó “Menu” de la Tablet. Aquesta pantalla

mostrarà la factura que obtindrà el client, amb tots els productes demanats, les quantitats, el

preu de cadascun, el resultat total i la diferència amb i sense IVA. Amb això aconseguim que el

client pugui veure quan gastarà, que vegi el resultat total amb IVA i, a més, que el client ens

“avisi” de quan vol marxar, podent així posar la Tablet en mode Stand-By. Aquestes serien les

quatre pantalles amb les que treballaria l’aplicació Android de la Tablet, i amb les quals

treballem. A partir d’aquí, vam seguir amb la resta del sistema, la part que considerem més

important.

3.2.2- Diagrama de classe de la Tablet (Sistema) – Primera Iteració

Com hem dit, el funcionament intern de la Tablet representa tot un diagrama de classses apart.

Amb això, vam posar sobre la taula les classes i objectes que necessitaven els requeriments

plantejats anteriorment. Seguidament, podem veure la primera iteració del diagrama de classes

de la part sistema de la Tablet:

24

25

Com es pot veure, el primer apropament que vam tenir va ser molt bàsic tot i que ja

plantejàvem les bases de les futures iteracions. Hem partit de la base que, donat un “event” a

la pantalla de la tablet, tindrem una acció resultant. De vegades seran senzilles, i de vegades

complexes, però l’estructura és sempre la mateixa, el client toca una zona concreta de la

pantalla (botó, llista, opció ,etc.) i això genera una acció. Aquestes accions, interactuaran amb

els objectes comanda o producte (sigui per objecte o base de dades) per poder fer les tasques

demanades pel client. Per exemple, quan el demani les recomanacions del restaurant, es

carregaran les recomanacions disponibles al disc dur del tablet amb una llista de productes per

tal que el client les pugui veure. El mateix a a l’hora dels comentaris o de validar la comanda.

Com parlarem d’aspectes més tècnics als diagrames de seqüència, de moment deixarem clares

algunes consideracions que hem tingut en compte per fer el diagrama de classes d’aquesta

manera:

El tractament de dades del restaurant: tot el relatiu al menú del restaurant, que

després el client podrà veure i escollir entre els seus productes, estarà precarregat a

les tablets. Diàriament es sincronitzarà amb l’ordinador central del restaurant per

poder obtenir dades sobre qué mostrar als clients, noves recomanacions, etc. La

primera vegada que es sincronitzi, haurà de “baixar-se” tot el menú, amb les dades,

informació, fotografies, comentaris, etc. Però després, simplement actualitzarà les

recomanacions, els comentaris, fotografies i la seva disponibilitat (o no). Amb aquesta

tema, la disponibilitat d’un producte, hem parlat molt. Al final, hem resolt que, al

nostre projecte, s’acceptaran restaurants on s’encarreguin d’establir un límit en quant

a menjar i el stock que queda. Així, si un producte apareix a la carta, això vol dir que

tenim suficient per tot un dia de feina. En canvi, si en fer la sincronització de les

tablets, el producte surt com no disponible, això voldrà dir que no es superava el stock

mínim necessari per cobrir el dia.

La comanda local i la emmagatzemada a la base de dades: quan un client es troba

escollint els productes per la comanda, tots aquests s’emmagatzenen de manera local

en la tablet. Després, si el client vol fer alguna correcció (sense haver confirmat la

comanda), en tenir tot en local, es fa molt més ràpid. Així, quan el client confirmi la

comanda, aquesta s’enviara cap a base de dades, d’on l’ordinador de la

cuina estarà llegint contínuament per detectar comandes noves. Cal dir que, quan

una tablet envii els seus productes a la base de dades, també ho faran totes les tablets,

per així deixar clar que tota la taula està d’acord en fer la comanda. Quan el client

vulgui cancel·lar el producte enviat, o demanar més, tan sols s’actualitzarà la comanda

local amb les noves dades, enviant aquesta informació cap a base de dades. A partir

d’aqui, la resta d’ordinadors veuran els canvis fets “indirectament” pel client.

La comunicació entre les tablets: com vàrem dir, les tablets han de comunicar-se

entre si per realitzar la comanda totes a la mateixa vegada, realitzar la suma dels

productes demanats, des-lligar-se de la taula al mateix temps, etc. Per fer això,

hem creat unes classes generals, que tindrà el mateix sistema, i que

compartiran totes les tablets, que sera la classe TaulaCol, que contindrà totes les

taules del restaurant, i la seva situació (utilitzable o no). Així, el primer que farà la

tablet quan es lligui a una taula, es assignar una referència a aquesta (també objecte

general) per recorre quan faci falta totes les tablets lligades a aquesta taula.

26

Com es pot veure, classes com la estadística o l'intermediari de base de dades funcionen de

manera externa a la resta del sistema. Nosaltres ho hem fet d'aquesta manera per tal que, en

les futures iteracions d'aquest diagrama, es puguin aplicar canvis sense gaire esforç (i sabem

que s'hauran de fer), deixant la part de la base de dades per més endavant. De moment, les

crides i consultes es fan de manera genèrica, sense especificar gaire el tipus de cerca o taules

en la base de dades.

3.2.3- Diagrama de classe de la Tablet (Sistema) – Segona Iteració

Donades les reunions entre els membres del grup, i les sugerències del professor, van sorgir

canvis als diagrames de seqüència. Sobretot, pel que fa al diagrama del sistema de la Tablet.

Una bona part del plantejament anterior era erroni, així com també conceptes com classes

fronteres. Per això, vam generar una nova iteració del diagrama de classes, amb canvis relatius

a aquests aspectes.

Per una banda, canviem totalment el format de les classes frontera. Ara, entenem per classes

frontera com aquelles classes que interactuen entre el l’actor i les classes base, com Taula o

Sistema (l’antiga classe Tablet). Aquestes classes frontera faran de pont entre els gestos de

l’usuari i les funcionalitats del sistema. Per això, contem amb dues classes frontera, la classe

Pantalla (utilitzada per identificar els diferents gestos que tingui l’usuari amb la pantalla de la

Tablet, des de botons fins a llistes de productes) i la classe Control (encarregada de cridar als

diferents mètodes interns de les altres classes una vegada identificada la funcionalitat que ha

indicat l’usuari). Amb aquestes dues classe podem controlar perfectament el que vol client, i de

quina manera ho mostrarem. L’adhesió de la classe Pantalla ens ajuda a mostrar missatges i

confirmacions per comunicar-nos amb el client. En canvi, la classe Control ens aporta ordre i

organització sobre els mètodes utilitzats per les altres classes. Ara, tota l’estructura d’accions

de l’usuari passa a la classe Control. D’aquesta manera, ens estalviem tota l’antiga estructura

basada en l’herència, i cada vegada que sorgeixi un event concret de la classe Pantalla, el

Control podrà cridar als antics mètodes d’acció dels usuaris. Així, obtenim un resultat similar al

del diagrama anterior, però més controlat, i amb classes frontera, que està clar que ens feien

falta.

Seguint amb els canvis, parlem ara de l’organització de les taules. Ara cada taula estarà present

a la mateixa classe, amb una relació amb si mateixa, que és on la classe frontera Control anirà

per veure l’estat de les taules. Comentar que el canvi és mínim, més relatiu a la sintaxi i la seva

correctesa que per un error pròpiament dit. També comentar les classes Estadística i

IntermediariBaseDades, que romandran separades de la resta del diagrama, degut a la seva

condició. Una vegada explicat el diagrama final i la base de dades, explicarem de quina manera

s’utilitzen aquestes classes, i com les pot aprofitar el restaurant. Per acabar, ensenyem el

diagrama de classes en qüestió, en concordança amb tot el que hem explicat abans. Tal i com

s’ha dit, el diagrama de la part visual de la Tablet, romandrà igual, per tant, tots els canvis s’han

fet al diagrama del sistema. Totes les iteracions d’aquests, anirien amb el corresponent

diagrama de la part visual, però per una millor comprensió visual, ensenyem només la part del

sistema. Sense dir res més, ensenyem el diagrama:

27

28

3.2.4- Diagrama de classe de la Tablet (Sistema) – Tercera Iteració

29

La iteració final del nostre diagrama de classes. En aquesta iteració, hem polit diversos errors

sintàctic i organitzar de manera correcta tot el relatiu a la base de dades i al sistema

d’estadístiques. També s’han afegit la resta de mètodes generats a partir dels diagrames de

seqüències (comentats i explicats més endavant). Ara, la classe relativa a les estadístiques es

troba al diagrama de l’aplicació Java, ja que només podrà accedir el “Jefe” del restaurant, i

l’Administrador. També s’ha organitzat millor el tema de la classe frontera Control, que ara es

vincula de manera correcta amb la classe Sistema, i permetrà obtenir de manera escalonada

tots els objectes que utilitzem normalment (com la comanda, la llista de productes, etc, es veu

de millor manera als diagrames de seqüència). A partir d’ara, comencem a parlar del diagrama

de classes de l’aplicació Java.

3.2.5- Diagrama de classe de l’aplicació Java – Primera iteració

La última part de la nostra aplicació consisteix en una interfície Java amb la qual els treballadors

poden interactuar amb la base de dades. Depenent del tipus de treballador que la utilitzi, les

accions que li permetrà fer l’aplicació seran unes o altres. D’aquesta premissa va sortir la

necessitat de fer un diagrama de classes per separat, dedicat només a l’aplicació Java, tot i que

els objectes i classes amb les que interactua son molt similars a les de la part sistema de la

Tablet.

Tenim que, per identificar els usuaris, tenim classes del tipus usuari, el qual contindrà les dades

del treballador. D’aquesta classe, hereten tots els càrrecs possibles de treballador, i per tant,

cada vegada que un treballador entri al sistema, ho farà amb el seu identificador i contrasenya,

per detectar el seu càrrec. Així, ens assegurem que, si bé semblava que el tipus d’accés estaria

restringit a zones (com el bar o la cuina), en realitat està restringit a persones, per donar més

seguretat a l’aplicació. Com es podrà a veure al diagrama de classes, també fem servir classes

frontera. Ho vam pensar molt, i el concepte d’aplicació Java no es gaire diferent de la Tablet en

aquest aspecte, ja que totes dues han de detectar els possibles events o botons de la pantalla

(classe frontera Pantalla) i han de tenir una classe organitzadora que s’encarregui de dir que fer

donat aquests events (classe frontera Control). Per tant, en aquest aspecte, el funcionament es

similar a la Tablet.

També es molt similar el funcionament de les classes Producte i Comanda. Aquestes classes son

totalment necessàries, ja que, una vegada es recullen les comandes de base de dades, aquestes

s’han de guardar a memòria, a l’igual que la llista de productes que porti associada. Tot això

s’explicarà de manera més detallada a la secció de la base de dades.

Com a últim punt a comentar, el tema de com tractar la comanda. Tot i que hi ha un diagrama

de seqüència que tracta això, volíem deixar aquest tema clar. Cada vegada que un treballador

de la cuina selecciona una comanda, generarà opcions, i d’aquí, haurà de generar una llista de

productes, els associats a la comanda. Per cada producte que seleccioni aquest treballador, es

passarà a canviar l’estat de preparació d’aquest producte, passant de “NoIniciat” a “EnCurs”. A

partir d’aquest punt, el client no podrà cancel·lar aquest producte, degut a que el treballador

de la cuina ha començat a preparar-lo. Això es fa llegint i modificant directament a base de

dades, per tal de mantenir la sincronització.

Sense res més a dir, ensenyem el diagrama de classes:

30

31

3.2.6- Diagrama de classe de l’aplicació Java – Segona iteració

Donada l’anterior iteració, i amb el pas dels dies i de les reunions, vam trobar moltes errades.

Per una banda, el tema del magatzem, que no constava de la manera que ho havia de fer.

Sabem que al magatzem del restaurant hi hauran molts ingredients per preparar els productes.

Però aquests ingredients, hauran de constar per separat en el diagrama de classes, no

directament al producte. D’aquesta manera, quan haguem de fer les reduccions de Stock a base

de dades, ens serà molt més facils sabent els ingredients dels productes que s’hagin consumit.

Una vegada aclarit això, vam passar a modificar de forma correcta el diagrama de classes, tant

pel que fa al Stock, com per les Reduccions (de Stock). Aquesta classe anirà relaciona amb

Stock, i amb les tres maneres que es poden fer reduccions al nostre magatzem (Mal Estat,

Venda o ReduccioC). D’aquesta manera, controlem tot el relatiu al magatzem, i la forma en que

fem reduccions de Stock, sigui per venda o sigui “forçat”.

Per altra banda, es van implementar patrons de disseny respecte a dues classes importants. Per

una banda, tenim la classe Producte, i el patró de disseny State. Amb aquest patró, definim

l’estat actual del producte, i ens permet realitzar accions (ara i en un futur) basant-nos en

l’estat en qüestió. Com ja s’ha dit, el producte té tres estats dins de la cuina del restaurant, “No

Iniciat”, “EnCurs” i “Finalitzat”. Mitjançant la introducció del patró State, podrem definir

accions depenent d’aquest estat, podent informar al client del temps que porta el producte en

espera, quan fa que l’ha començat a preparar el cuiner, o si ja es troba a punt per posar-lo a la

taula. Totes aquestes opcions a futur, son possibles gràcies al patró State. Per altra banda,

també hem introduït el patró Strategy, amb el qual controlem les estadístiques que pot fer el

restaurant. Com hem dit, donem la possibilitat que, donada la base de dades amb suficients

dades per contingut, aquestes es puguin analitzar per treure conclusions molt similars als

estudis de mercat. Més endavant, parlem de la manera que te el restaurant d’editar i afegir

noves comandes de base de dades per extreure estadístiques personalitzades. Per ara, ens

concentrem en estadístiques bàsiques, com el producte més venut o el nombre de comandes

en un determinat espai de temps. Per acabar amb aquest aspecte, dir que també hem utilitzat

el patró Decorator per poder afegir responsabilitats (càrrecs) de forma dinàmica i més

organitzada. Tot això, resumeix el nostre treball amb els patrons de disseny.

Per altra banda, també s’ha canviat la relació de la classe frontera Control amb la resta de

classes. Ara, al igual que el diagrama de classes de la part sistema de la Tablet, aquest es

relacions de forma escalonada amb la taula, la comanda, i el producte. D’aquesta manera,

tindrem les variables i objectes corresponents de forma organitzada. També s’ha canviat la

organització de càrrecs dels treballadors. Ara, com un treballador de la cuina o de la barra

podrà encarregar-se d’una taula, creem una nova herència, per poder diferencia aquest aspecte

de la resta de treballadors.

Aquests han sigut els canvis d’aquest iteració, i l’última amb aquest diagrama. A continuació, el

diagrama de classes:

32

33

3.3. – Fitxes de cassos d’ús per l’informàtic

Per poder realitzar els futurs digrames de seqüència, vam decidir fer servir ajuda. Per això, per

cada acció que requeria un diagrama de seqüència, vam desenvolupar una fitxa de cas d'ús que

ens faci de guia. Ara sí, ens centrem en les accions més complexes de les definides a les fitxes

de cas d'ús d'usuari. Aquestes accions, han sigut escollides degut a la seva complexitat, i a la

necessitat de trobar mètodes i variables pel diagrama de classes. Cal dir, que la realització

d'aquesta fase (com s'ha pogut veure el diagrama de Gantt) va ser intercalant les diferents

iteracions dels diagrames de classe i de seqüència, donant com a resultat una evolució natural

de tot el projecte. Aquest punt és força important, ja que decidim les accions que en un futur

estaran perfectament esquematitzades pels diagrames de seqüència. Si això fos un projecte de

veritat, a l’hora de programar, aquest pas seria fonamental, per poder assolir la major part del

sistema possible amb accions complexes. Nosaltres, hem seleccionat les següents accions:

Validar comanda

Treure productes de comanda (no enviada)

Treure productes de comanda (enviada)

Realitzar comentari sobre un producte

Demanar el compte a pagar

Actualitzar Stock real / orientatiu

Assignar Tablet a taula

Reduir Stock

Canviar d’estat un producte

Generar llistats estadístics

Tenint les fitxes de cas d’ús d’usuari de cadascuna d’aquestes accions, ens es més fàcil fer una

descripció cap al client, i amb les noves versions orientades a l’informàtic, se’ns facilitarà la vida

a l’hora de realitzar els diagrames de seqüència. Aquestes fitxes, contindran el comportament

del sistema a l’hora de realitzar la corresponent acció, el que vindria a ser l’equivalent en text

dels diagrames de seqüència. A continuació, ensenyem aquestes fitxes:

Fitxa Informàtic

Nom: Validar comanda

Descripció: El client valida la comanda, i es passen els productes continguts a la

base de dades

Actors: Client

Precondicions: Comanda amb un nombre de productes superior a zero

Flux principal:

1. Polsar boto validar comanda

2. Obtenir taula

3. Obtenir comanda

4. Comprovar productes comanda

5. Actualitzar la taula a base de dades

Flux alternatiu: -

Postcondicions: La comanda ja es troba a la base de dades, a punt per que la llegeixi

l’ordinador de la cuina

34

Fitxa Informàtic

Nom: Treure productes de comanda (no enviada)

Descripció: Permet eliminar productes d’una comanda que estem realitzant des

de la Tablet a la taula, sense que aquesta s’hagi enviat encara

Actors: Client

Precondicions: Comanda encara no enviada

Flux principal:

1. Obtenir taula

2. Obtenir comanda

3. Obtenir productes

4. Ensenyar productes

5. Mentre Client seleccioni productes

a. Seleccionar productes

b. Eliminar producte

Flux alternatiu: -

Postcondicions: La comanda s’actualitza, eliminant els productes que hagi marcat el

client.

Fitxa Informàtic

Nom: Treure productes de comanda (no enviada)

Descripció:

Permet eliminar productes d’una comanda que estem realitzant des

de la Tablet a la taula, amb aquesta comanda ja enviada i present a

la base de dades

Actors: Client

Precondicions: Comanda ja enviada

Flux principal:

1. Obtenir taula

2. Obtenir comanda

3. Obtenir comanda de base de dades

4. Obtenir productes

5. Ensenyar productes

6. Mentre Client seleccioni productes

a. Seleccionar productes

b. Eliminar producte

Flux alternatiu: -

Postcondicions: La comanda s’actualitza a base de dades, eliminant els productes

que hagi marcat el client.

35

Fitxa Informàtic

Nom: Realitzar comentari

Descripció: Li dona l’opció a l’usuari de realitzar una valoració dels productes

que hagi demanat i un comentari de cadascun d’aquests.

Actors: Client

Precondicions: Client ja ha polsat el botó de pagament de la comanda

Flux principal:

1. Obtenir taula

2. Obtenir comanda

3. Obtenir productes

4. Ensenyar productes

5. Mentre Client seleccioni productes

a. Seleccionar productes

b. Donar valoració a producte

c. Si client vol realitzar comentari

i. Realitzar comentari

Flux alternatiu: -

Postcondicions: Es guarda a cada producte la valoració i els comentaris fets, i es dona

per acabada la interacció del client amb la Tablet.

Fitxa Informàtic

Nom: Reduir stock

Descripció: Permet al cap del magatzem reduir del stock una quantitat determinada

d’un producte en concret.

Actors: Cap del magatzem

Precondicions: -

Flux principal:

1. Llistar ingredients.

2. Seleccionar ingredient.

3. Reduir stock.

Flux alternatiu: -

Postcondicions: El producte queda reduït del stock una certa quantitat amb un motiu.

36

Fitxa Informàtic

Nom: Canviar d’estat un producte.

Descripció: Els productes de la nova comanda que arriba van canviant d’estat segons

l’estat anterior en que es troben.

Actors: Treballador cuina o treballador bar

Precondicions: Estat inicial del producte = ‘no iniciat’

Flux principal:

1. Seleccionar comanda.

2. Llistar productes.

3. Seleccionar producte.

4. Canviar estat.

Flux alternatiu: -

Postcondicions: El nou estat del producte és el següent al que tenia.

Fitxa Informàtic

Nom: Veure recomanacions restaurant

Descripció: Permet veure les recomanacions del restaurant des de la Tablet

Actors: Client

Precondicions: -

Flux principal:

1. Prem opció recomanats 2. Control demana la llista de productes en stock (es que es poden

servir) 3. Quan s’obté la llista, es recorre de manera que:

a. Si el producte està marcat com recomanat, es mostra. b. Altrament no es fa res amb el producte.

Flux alternatiu: -

Postcondicions: Es visualitzen per pantalla es productes recomanats.

37

Fitxa Informàtic

Nom: Actualitza Stock Real i Orientatiu

Descripció: Comparar les dades reals de Stock amb les dades orientatives que ens indica el sistema per tal de veure si les vendes realitzades son acords amb els productes entregats.

Actors: Cap Magatzem

Precondicions: Dades suficients a la base de dades per fer la comparació

Flux principal:

1. Prem boto actualitzar stock 2. Control demana les dades d’stock real i stock orientatiu. 3. Quan ha obtingut les dades, per cada parella de productes:

a. Mostra les dades stock real b. Mostra les dades stock orientatiu c. Introdueix el valor que considera que es el real i es guarda com aquest.

Flux alternatiu: -

Postcondicions: Les dades de Stock real queden ajustades, les de l’orientatiu queden igualades al real, però el sistema ja les modificarà.

Fitxa Informàtic

Nom: Assignar tablet a taula

Descripció: Donada l’entrada de nous clients, el treballador del restaurant veu l’estat de les taules, i escull una que no estigui utilitzada actualment.

Actors: Cambrer

Precondicions: Clients nous disponibles

Flux principal: 1. Llistar taules del restaurant 2. Seleccionar taula

Flux alternatiu: -

Postcondicions: La Tablet objectiu es troba lligada a la taula que li ha indicat el cambrer, i ha inicialitzat tot el sistema per tal que el client pugui seleccionar productes i demanar comandes.

38

3.4. – Diagrames de seqüència

A partir de les fitxes de cassos d’ús descrites anteriorment, generarem els diagrames de

seqüència amb els quals ja tindrem un apropament important al codi final. Si fem la vista

enrere, tot comença a la primera definició de fitxes de cas d’ús, amb descripcions per sobre de

les accions que es poden fer amb aquesta aplicació. D’aquí, sortim amb el diagrama de classes,

on definim l’estructura que tindrà l’aplicació (totes les seves parts) i definim els cassos d’ús per

l’informàtic, amb accions complexes que plantegin dubtes o noves definicions i objectes al

sistema. Finalment, a partir d’aquestes fitxes, generem els diagrames de seqüència. Aquí és on

realment es veu la interacció entre els diferents objectes, i la necessitat d’aquests al diagrama

de classes. El que farem per explicar aquests diagrames serà el següent. Mostrarem dues

iteracions dels diagrames de seqüència (de les accions on ha calgut aquesta evolució), un

primer apropament, i el resultat final. Per cadascuna d’aquestes parelles, adjuntarem una

petita explicació del que s’entén per aquella acció, a mode de resum. Sense dir res més,

comencem amb els diagrames i les explicacions:

3.4.1. – Validar Comanda

Quan un client ja ha escollit tots els productes que volia, procedeix a encarregar tota la comanda. Això voldrà dir que, a la resta de Tablets lligades amb la taula, lis sortirà un missatge per confirmar la demanda de la comanda actual. Una vegada s’han confirmat, es procedeix a enviar tota la comanda a la base de dades on, de manera automàtica, llegeix l’ordinador de la cuina i els hi surt per la seva pantalla. Com es pot veure, el client només intervé al principi de l’acció, deixant la resta del procés en mans del sistema. Respecte a això, cal dir que aquest sistema porta mecanismes de seguretat per assegurar-se de que la comanda té productes escollits, que totes les Tablets han confirmat la comanda, etc. Primera iteració:

39

Segona iteració:

40

3.4.2. – Treure productes de la comanda (no enviada)

Quan un client, pel motiu que sigui, vulgui treure un producte de la seva comanda, només haurà de prémer un botó. Amb aquest botó, es mirarà a la comanda actual per verificar aquest producte, i per treure-ho de la comanda actual. Es recarrega automàticament la llista de productes, i el client veu com s’ha tret correctament el producte desitjat. Primera iteració:

41

Segona iteració:

42

3.4.3. – Treure productes de la comanda (ja enviada)

Aquest cas no és tan senzill. Un client, després de confirmar la comanda, vol treure productes d’aquesta (o agregar). Per fer això, el sistema haurà de veure de quina comanda estem parlant, anar a buscar aquesta comanda a la base de dades i mirar el producte que es vol modificar. Si es vol treure, s’ha de mirar si encara es pot. Si l’estat de la seva preparació ha passat de “Pendent” a “En procés” aquest producte ja no es pot cancel·lar. Si encara no ha canviat, el producte s’esborra, tant la tablet com l’ordinador de la cuina actualitzen l’estat de la comanda, i per tant, els cuiners no podran començar a preparar aquest producte.

Primera iteració:

43

Segona iteració:

44

3.4.4. – Realitzar comentari sobre un producte

Quan els clients vulguin pagar el compte, els hi sortirà un missatge preguntant si estan disposats a valorar algun dels productes que han consumit. Si la resposta es afirmativa, se’ls hi desplega una llista amb els productes consumits, i, per cada producte que seleccionin hauran de donar una valoració de l’1 al 10 i (opcionalment) deixar un comentari. Després de fer això, s’emmagatzemaran aquests comentaris i valoracions en el mateix producte comentat, i a l’hora de guardar-ho tot en base de dades, es passaran aquestes informacions per tenir-les en compte la propera vegada que les Tablets s’actualitzin. Primera iteració:

45

Segona iteració:

46

3.4.5. – Reduir Stock

Com a qualsevol restaurant o allà on tractem amb menjar, ens podem trobar en la situació en que un aliment, producte o envàs adquireixi un estat nociu per a la salut d’una persona. Es pot arribar a aquesta situació, per exemple, quan un producte ha sobrepassat la seva data de caducitat, o quan la seva conservació no ha estat la més òptima. Degut a aquestes causes, ens veiem obligats a retirar la mercaderia del nostre Stock, ja sigui llençant-la a les escombraries o retornant-la al nostre subministrador. Tot i que en un principi només vam contemplar aquesta opció, a més d’aquesta causa, i a posteriori, també ens vam veure en la situació d’haver de reduir el Stock dels ingredients d’una manera més natural, simplement perquè s’han servit a taula. Quan es serveix el menjar als clients, també s’ha de reduir el Stock dels ingredients consumits. Així, vam voler agrupar aquestes dues funcionalitats que se’ns van aparèixer. Per anar més enllà, no limitar el motiu de les reduccions del Stock a aquestes dues, i fer l’aplicació més genèrica, vam afegir la classe ‘Reducció’ al diagrama de classes dels treballadors permetent així que es puguin anar afegint diferents tipus de reducció en el futur i disposar així d’una aplicació més escalable. El cap de magatzem, llistarà tots els productes del Stock que hi ha a la base de dades. De la llista que se li presenti, haurà de seleccionar l’ ingredient del qual en vulgui reduir el seu Stock. I un cop tingui el producte seleccionat, des de l’opció de reduir Stock, haurà d’inserir (amb la unitat adequada) la quantitat a reduir d’aquell producte i el motiu de la reducció. Quan es validi l’opció, la quantitat inserida quedarà reduïda del Stock original de l’ ingredient amb el tipus de reducció que s’hagi triat. A partir d’aquí, ensenyem el diagrama de seqüència:

Primera iteració:

47

Segona iteració:

48

3.4.6. – Canviar d’estat un producte

Els productes que conté una comanda que arriba a la cuina o al bar poden estar en tres estats diferents: ‘no iniciat’, ‘en curs’ o ‘finalitzat’. En arribar la comanda, els productes s’inicialitzen en el primer estat ‘no iniciat’. Quan un producte es comença a preparar, el seu estat canvia a ‘en curs’ i quan el producte està llest per servir a la taula, l’estat canvia a ‘finalitzat’. Tots aquests canvis d’estats són realitzats pels encarregats de preparar els productes. Cada un dels estats en que es troba el producte dona informació tant al client que ha demanat el producte, com al cambrer que l’ha de servir, com al propi sistema. Quan un producte es troba a l’estat ‘no iniciat’, el client coneix aquesta informació i li permet poder cancel·lar la comanda del producte des de la Tablet. L’estat ‘en curs’ prohibeix al client fer la cancel·lació, i l’estat ‘finalitzat’, indica al cambrer que el producte ja està llest i ja el pot recollir per servir-lo a la taula corresponent. Seguint amb la filosofia de tenir una aplicació escalable, per aquest cas d’ús vam optar per no limitar l’aplicació a només aquests 3 estats comentats anteriorment i dotar al sistema de poder afegir en el futur altres estats. El personal de cuina i barra són els encarregats de canviar els productes de la comanda d’estat. Per fer aquests canvis d’estat en els productes, el personal haurà de, primer de tot, seleccionar la comanda on estigui el producte al qual es vol canviar l’estat. Un cop tingui la comanda seleccionada haurà de llistar els productes que la contenen i seleccionar el producte adequat. Amb el producte ja seleccionat, només quedarà marca l’opció de canvi d’estat i el producte canviarà el seu estat al successor. Respecte a les iteracions, destacar el canvi fet de la primera i la segona respecte a l’especificació de la primera (on només parlàvem de posar un producte com “acabat”) i la generalització de la segona (on directament, parlem de canvis d’estats a nivell general). Primera iteració:

49

Segona iteració:

50

3.4.7. – Generació de llistats estadístics

La generació d’estadístiques pot ser una eina molt interessant pel cap del restaurant, pel director o per la persona que hagi de gestionar i prendre decisions importants que afectin al restaurant. La gestió de les estadístiques permet visualitzar aspectes importants del restaurant en números i gràfiques. Així, la persona encarregada pot ser capaç de veure en quina època de l’any es menja, per exemple, més carn, i ser capaç d’aquesta manera de gestionar la compra de mercaderies més eficaçment. També pot veure, per exemple, una estadística molt senzilla com és el nombre de clients diaris durant un temps determinat. Si es visualitza aquesta estadística al llarg de l’any es podrà saber quant personal es necessita exactament en cada moment de l’any per poder donar un servei de qualitat als clients. Per visualitzar les estadístiques, la persona encarregada ha de llistar totes les estadístiques possibles, n’ha de seleccionar una i un cop seleccionada se li mostra l’estadística en el format corresponent. Cal dir, que per aquest diagrama, només hem generat una iteració, degut a la necessitat d’especificar aspectes de la base de dades, i al fet que havíem de cercar un cas concret d’utilització d’aquest tipus d’estadística. Dit això, ensenyem el diagrama:

51

3.4.8. – Veure recomanacions restaurant

Quan un client està mirant els productes de la carta, si entra a la pantalla de les Recomanacions (productes proposats per el restaurant), aquesta vista el que farà és anar a la base de dades, i mostrarà únicament els productes marcats com a recomanats. D’aquesta manera, si el client està indecís per demanar o es el primer cop que va al restaurant, aquests productes recomanats haurien de ser els que el restaurant considera productes “estrella” o el productes que estan de temporada, o inclús dels quals el restaurant té un excés i vol donar tirada d’ells. Primera iteració:

Segona iteració:

52

3.4.9. – Actualitzar Stock real i orientatiu

Quan l’encarregat de magatzem vol actualitzar el Stock Real que te a magatzem, que per anar bé hauria de controlar diàriament, al final de tots els serveis, el que fa es anar a l’apartar per actualitzar Stock Real amb l’Orientatiu. Aquí el sistema l’informarà del Stock que ell creu que te realment i el sistema li indica el que ell ha calculat que hauria de tenir. Llavors, segons el criteri de l’encarregat de magatzem, ajustarà el Stock de tal manera de que ell tingui una ajuda sabent el que s’ha gastat i el que ell creu que té, per ajustar els comptes de Stock. Molt útil ja que de vegades es tenen pèrdues per que un producte surt malament, o es trenca, o es per, o mil i una coses que poden passar, i així ell pot tenir-les en consideració sense l’esforç que suposa anar comptant el que s’ha venut, el que s’ha anotat com baixa, etc. Abans d’anar amb el diagrama, dir que amb aquest diagrama vam trigar més que amb els altres, i només va tenir una iteració, amb petits canvis sense rellevància:

53

3.4.10. – Assignar Tablet a taula

Quan uns clients entren a menjar als nostre restaurant, tenim la necessitat d’assignar a la taula on menjaran una o més Tablets per tal de que puguin fer-ho tot, des de realitzar la comanda, veure les recomanacions de altres clients i del xef, o fins i tot donar la opció de pagar. Per tal de lligar una Tablet a una taula el cambrer haurà d’agafar la Tablet del racó on estan les Tablets que no s’estan utilitzant en aquest moment i mirant l’estat de les taules, seleccionar una la qual tingui el tamany igual al numero de comensals i que estigui lliure. Una vegada fet això el cambrer ja podrà acompanyar als clients a la seva taula corresponent. Cal dir que, tot i que poder hi hauran assignades més d’una Tablet a la taula (o a les taules), s’haurà de fer el mateix per totes. Per cadascuna de les Tablets, s’haurà de repetir el mateix procés, i l’únic aspecte funcional manual es queda, llavors, al cambrer, a l’hora de calcular quantes Tablets ha d’utilitzar per abastir la comanda actual. Com que aquesta acció es, d’entre totes, una de les més senzilles, només vam necessitar una iteració per determinar el seu funcionament:

54

3.4.11. – Fer pagament comanda

Quan els clients ja tenen tots els plats/begudes/cafes servits i una vegada ells estan d’acord poden s’activa el botó de pagar en la Tablet. Una vegada polsat aquest botó a la mateixa Tablet surt una pantalla en la qual s’informa als clients dels productes consumits i del preu total a pagar (una factura de tota la vida). Si els clients estan conforme i li donen a confirmar pagament. Es en aquest moment el que la pantalla d’aquesta i de totes les Tablets assignades a aquesta taula canvien la pantalla per la de valorar els productes consumits al restaurant (no es obligatori). Una vegada feta la valoració o donat a que no es vol valorar les Tablets es posen en mode Stand-By i els clients la retornen al cambrer. Primera iteració:

55

Segona iteració:

56

4 – Disseny

4.1 - Introducció

A partir de tota la feina que s’ha fet a la fase d’anàlisi, ja tenim una base molt gran pel nostre

projecte. Per una banda, tenim clara l’estructura del diagrama de classes, la qual cosa ens

ajudarà (si ho tinguéssim que fer) a definir en un principi tot el relatiu a l’estructura de

l’aplicació quan vulguem començar a codificar tot. També tenim el conjunt d’accions que

realment defineixen el nostre projecte, i que son suficientment complexes com per posar-ho a

prova. Aquestes accions, definides amb la seva fitxa de cas d’ús per l’informàtic, seran les que

posin a prova la nostra aplicació, tant des del punt de vista de concepte, com pel punt de vista

de codi. Finalment, també disposem de tots els diagrames de seqüència amb la seva iteració

final, en concordança amb el diagrama de classes, i amb els quals podrem construir el nostre

codi (per aquestes accions i cassos) d’una forma més automàtica (de fet, si s’hagués de

codificar tot, el que faríem es fer servir una eina Case per portar tots els diagrames a codi sense

més esforç). Tot això, és el que hem obtingut de la fase d’anàlisi. A partir d’aqui, comencem

amb l’últim aspecte important de l’aplicació, i que pertany directament al disseny: la base de

dades.

4.2 - Base de dades

Per la nostra base de dades, en una primera instància, vam identificar diferents elements clau

que necessitàvem per poder representar tot el relatiu a les vendes del restaurant. Això es

tradueix en una estructura molt similar a la que podem veure al diagrama de classes, amb una

taula, una comanda, una llista de productes, i les respectives relacions entre aquestes. Per tant,

en un primer moment, el diagrama d’entitat relació referent a la base de dades ens quedava

així:

Com es pot veure, disposem de les taules bàsiques per poder emmagatzemar tot el relatiu a les

vendes. Però ràpidament vam veure un problema. Si entrem en tot el relatiu al magatzem i la

seva organització, aquest diagrama se’ns queda molt petit. De fet, amb aquest simple

pensament, vam haver de fer modificacions a gran escala, per tal de poder adaptar-ho tot al

nostre concepte de magatzem. Com es pot veure, la segona i final iteració:

57

Com es pot veure, tot el relatiu a les reduccions i al magatzem queda implícit, i ho tractem de

manera correcta. A continuació, expliquem taula per taula el seu significat i la seva funció dins

de la base de dades.

Usuaris: els treballadors del restaurant, per tal de poder identificar de forma correcta

el seu càrrec i les seves funcions, hauran d’entrar al sistema (al inici del dia,

normalment). Per fer això, per cada treballador, tindrem enregistrat a base de dades

les seves dades, per tal de comprovar si realment l’usuari (el treballador) és un usuari

registrat al restaurant, i si ho és, quins privilegis té. Aquest accés, serà obligatori per

tots els treballadors del restaurant (siguin de la cuina, administradors o encarregats

58

del magatzem), i partir d’aquí, se li ensenyarà per pantalla al treballador les seves

opcions, tenint en compte els seus privilegis.

Comanda: el mateix significat que ho té al diagrama de classes, ho té aquí. La seva

funció és emmagatzemar tot el relatiu a les vendes fetes pel restaurant, des de la

factura amb la quantitat de diners que s’han gastat els clients, fins la llista de

productes que han consumit, passant pel nombre de clients, la data de la venda, etc.

Aquesta taula és una de les més importants, ja que està feta per poder treure més

endavant les estadístiques de vendes fetes.

Producte: el mateix cas que l’anterior punt. Producte contindrà les dades de cada plat

(per separat) que hagin consumit els clients. D’aquí es trauran dades com el preu del

plat, la seva imatge per ensenyar-la per pantalla, i el més important, el seu estat. A

partir d’aquí, després podem portar a terme la sincronització entre la cuina i la Tablet.

Amb el camp “estat” es podrà saber en quin punt de la seva preparació es troba el plat

en qüestió, i serà el camp a modificar quan el treballador de la cuina ho comenci a

preparar.

Comentari: com s’ha dit, el client podrà deixar comentaris al producte (en forma de

text, no confondre amb la valoració per nota). Per això, haurem de tenir una taula que

ens emmagatzemi tots aquests comentaris, amb una relació amb el producte. Per

cadascuna d’aquestes relacions, tindrà la nota qui li ha posat el client (obligada si

aquest ha demanat fer un comentari).

Stock: el punt principal que vam tractar per la segona iteració d’aquest diagrama. Per

cada producte, tindrem relacionat un Stock específic per cadascun dels seus

ingredients. Per exemple, per un pollastre a l’as amb patates, tindrem el Stock del

pollastre, de les patates, de l’oregen, de l’oli, etc. Tota aquesta relació, es fa en aquest

diagrama, i amb l’objectiu de que totes les reduccions (les quals tenen la seva pròpia

taula) es facin automàticament, tenint en compte que la relació producte ingredient ja

es troba feta.

Reduccions: l’altra taula important d’aquesta segona iteració. En aquesta taula,

enregistrarem totes les reduccions de Stock que es facin al restaurant. Els cassos

poden ser molts. El més normal, es fer una reducció de Stock (ingredients) quan

s’acabi de preparar un producte, donada una demanda d’aquest en una comanda.

Quan es fa això, s’enregistren noves entrades en la relació Stock Reducció amb les

dades dels ingredients que s’han fet servir i (tenint en compte el producte) la quantitat

d’aquest que s’ha fet servir. Finalment, a la descripció de la reducció, es posarà la

venda feta com “justificant”. També s’ha fet això, per tenir en compte els cassos més

particulars al magatzem del restaurant. Hem de tenir en compte que, de vegades, els

productes es fan malbé, sobretot els productes frescos. Per cassos com aquests, també

serveix la nostra base de dades, tan sols que, quan s’hagi de fer la reducció d’aquests

productes que s’hagin fet malbé, a la descripció s’haurà de fer constar aquest detall.

Tot això, haurà d’estar supervisat per l’encarregat del magatzem.

Tot això conforma la nostra base de dades definitiva. A partir d’aquí, vam anar per detalls de

l’aplicació més externs, i relacionats amb el seu aspecte, funcionalitats menors, etc.

59

5- Prototipus

En aquesta secció, mostrarem els prototipus de la nostra aplicació, tant per la part de Android, com per

la part de Java, indicant a quina fase del producte fa referència.

5.1- Part Android

Presentació de l’aplicació al client:

60

Elecció dels plats:

61

Selecció producte:

62

Recomanacions restaurant:

63

Estat comanda:

64

Opcions comanda:

65

5.2- Part Java

66

67

6- Manual d’usuari

El document que segueix farà una breu explicació del funcionament de l’aplicació en cas de que s’arribés

a una versió funcional.

Introducció

En la situació econòmica actual els empresaris estan preocupats per rendibilitat el seu negoci. Aquesta

aplicació pretén automatitzar tot el que sigui referent al sector de la restauració, donar un toc

tecnològic que faci diferencial els establiments que el facin servir de la resta i també, fent una inversió,

fer el negoci més eficient.

Objectiu

Quan es va a un restaurant lo típic es arribar i haver d’esperar que t’atenguin, de tant en tant demanar

alguna cosa que esta a la carta però no serveixen, quan s’ha de demanar alguna cosa més pot arribar a

ser una àrdua tasca... I això només de cara al client. De cara a l’interior, comandes que no arriben bé o

tard, haver d’estar hores després dels serveis fent recompte del que s’ha gastat... etc. La nostra aplicació

permet als clients de restaurant tramitar las seva comanda sense apenes necessitat d’un cambrer, l’únic

que necessitaran se que se’ls doni la seva carta electrònica i ells mateixos poder demanar tot el que

vulguin, consultar els productes sense haver de preguntar al cambrer e inclús veure l’opinió d’altres

clients per tenir altres referències. També de cara al personal del local els facilitarà la feina nomes haver

d’anar servint les peticions dels clients sense haver un punt entremig com és el cambrer que de vegades

es pot converit en el joc del telèfon. També el sistema proporcionarà una referència al que s’està

consumint per poder controlar el stock dels productes amb més facilitat.

Objectius principals de l’aplicació:

Carta electrònica per als clients: demanar, modificar, consultar productes i demanar el compte

sense necessitat d’esperar al cambrer.

Sistema visual de comandes per servir: cada departament del restaura tindrà un visualitzador

per veure els productes que han d’anar servint.

Control de stock de productes: proporcionarà una referència al encarregat de magatzem per

actualitzar el stock real amb el que l’aplicació suggereixi.

Afegir, treure, modificar productes a la carta.

Sistema i requeriments

El que farà falta per poder tenir tot el sistema en marxa serà:

Tablets amb Android

o Com a mínim, una tablet per taula (taula de 2 persones).

o SO Android: 2.2 o superior

Wifi al local per a la connexió de les tablets.

68

Dos servidors en clúster, per mantenir el sistema central (BDD), per tal de tenir redundància a

l’hora de falles. Requisits dels servidors:

o SO compatible amb SQL server ( preferiblement Windows Server 2008)

Un PC per secció per tal de visualitzar les dades de cada secció. Un PC de reserva per si hi ha

cap incidència amb algun dels PCS de les seccions. Requisits dels PCS:

o Windows 7.

Tablets

Tot seguit es mostraran unes captures que acompanyades d’una petita descripció ens explicaran el

funcionament bàsic de l’aplicació i els coneixements que permetran fer una comanda des d’una de les

tablets.

Plana Principal de la tablet: Aquí es mostra el logotip del restaurant i també es pot mostrar diferents

aspectes com horaris, telèfons, emails... del restaura. A la part de sota tenim les diferent opcions que es

pot escollir: Anar a la plana principal, veure el menú, veure les recomanacions del restaura i la comanda.

Amb un simple toc amb el dit podem navegar per les diferents opcions del carta electrónica.

En tocar el botó de Menú ens surten uns

desplegables amb els productes de la carta

acompanyats del seu preu. Si premem a sobre

d’ells podrem seleccionar-lo per poder afegir-lo a

la comanda, veure informació mes detallada del

producte o veure les valoracions del clients.

Quan es marca un producte, es surt un popup

demanant el numero de productes que es vol

demanar i ens indica el preu total. Podem

acaptar i afegir-lo a la comanda o cancel·lar

l’acció. Si pitgem el boto de menú de la tablet

(indicat en vermell) podrem veure altres accions

alternatives com pot ser veure informació

detallada (ingredients, historia, etc) o podem

veure les valoracions realitzades per altres clients

per no només tenir l’ informació que proporciona

el restaurant. Si premem la pestanya de

Recomanacions, veurem les recomanacions que

ens fa el restaurant, com les que et podria fer el

mateix cambrer de paraula. Molt útil tant per al

client si esta indecís com per al restaurant si vol

donar-li mes tirada a determinats productes o

promocionar-los.En la pestanya de comanda

podem veure els productes seleccionats, el seu

total sense iva i amb iva.

Si prenem el boto de menú de la tablet (indicat en vermell) ens sortiran les opcions per confirmar

comanda i que sigui tramitada pel personal de restaurant, modificar comanda per si volem retirar algun

dels productes de la comanda, o pagar, si ja han estat tot els plats servits.

69

I amb això ja podríem fer una comanda des d’una tablet.

Terminals de Cuina, Bar, Magatzem i Jefe

Aquests terminals tindran una aplicació en Java que ens demanarà un login, i segons com ens haguem

presentat, podrem visualitzar i realitzat unes determinades tasques.

Cuina i Bar

Els empleats de cuina i bar presentats a l’aplicació podran visualitzar per pantalla les comandes que

estan actualment pendents per servir, podent-les marcar com “en curs” de tal manera que aquests

productes no es podran cancel·lar o com a “servits”, que voldrà dir que ja es poden servir als clients.

També podran realitzar comandes a magatzem per tal proveir-se dels productes que els fàcil falta per

treballar. Per fer-ho hauran d’anar a l’apartat de fer comanda a magatzem i anar escollint els productes

que necessiten i la quantitat. Particularment, el personal de bar podrà facturar comandes. Quan un

client demani el compte, el personal de barra serà l’encarregat d’imprimir la factura i cobrar-la.

Magatzem

L’encarregat de magatzem podrà gestionar i controlar tot el stock i servir comandes de bar i cuina. Per

fer-ho tindrà varies opcions, com la d’actualitzar stock, que l’informarà del que el sistema creo que

hauria d’haver amb lo que s’ha consumit, i amb les entrades de stock i això, l’encarregat de magatzem

ho tindrà més fàcil per portar el stock real de magatzem. També podrà entrar baixes de productes (mal

estat, trencat... ) amb l’opció de donar baixa producte.

Jefe

L’encarregat del local tindre accés a totes les vistes mencionades anterior ment per gestionar-les.

70

7- Annex 1: Anàlisi de la Planificació

En anteriors entregues hem comentat el que nosaltres crèiem que era la millor planificació per aquest

projecte, ressaltant aspectes com les reunions setmanals, el respecte per les entregues dels diversos

documents o la importància d’una bona estructuració de tota la feina. Doncs bé, com s’ha pogut

apreciar al diagrama de Gantt al principi del document, la sèrie de terminis que ens havíem posat no van

complir-se degut a circumstàncies que explicarem en aquesta secció. També parlarem de la

reestructuració que va patir el projecte pel que fa a la distribució de les seves fases, i de quina manera

ho podíem haver millorat.

Nosaltres, havíem planificat el projecte per tal que es dividís en quatres grans etapes. L’especificació

(requeriments i cassos d’ús), l’anàlisi (diagrama de classes i de seqüència), disseny (base de dades) i

documentació (redacció del document final). Tot això, per tal que coincidís amb les dates d’entrega de

cada part, tant per la classe de teoria com per les de pràctiques. I al principi, tot va anar perfectament,

però el problema va ser quan vam arribar a l’etapa del anàlisi. El fet que no vam fer carrera de gestió, la

facilitat amb la que veiem tota la feina, i el fet que el termini d’entrega pel document d’aquesta fase era

molt llunyana, feia que ens ho agaféssim amb calma. Però, tot i que ens vam posar, el fet que la fase

d’anàlisi fos especialment dura (moltes iteracions per cada diagrama, i canvis continus que alteraven

tots aquests) va fer que ens atracéssim en l’entrega del document per aquesta fase. Per això (com es pot

veure al diagrama de Gantt al principi d’aquest document) la fase d’anàlisi ens va ocupar tant temps.

Inclòs després de fer aquesta entrega, vam haver de seguir treballant per polir errades presents als

diagrames. Tot i així, aquest excés de temps es va convertir en un avantatge, ja que aquest projecte

concentrava una bona part de la feina en aquesta fase, alliberant recursos per les altres. D’aquesta

manera, la fase de disseny, va ser molt més lleugera, ja que només teníem que dissenyar una base de

dades més o menys petita. Tot i així, els terminis d’entrega dels document d’anàlisi i disseny no es van

complir, i per tant, va ser una falta per la nostra part.

71

8- Annex 2: Patrons de Disseny

Patrons creacionals

Factoy Method i Abstract Factory

Aquests dos patrons creacionals són útils quan volem crear interfícies per crear objectes o famílies d’objectes sense especificar les classes concretes. Per a cap d’aquests dos patrons no hem trobat aplicació en el nostre sistema, ja que en cap moment ens veiem amb la necessitat de crear productes o famílies de productes de cap tipus.

Una possible aplicació del patró ‘Factory Method’ podria ser en el cas que haguéssim de crear objectes categoritzats per tipus de producte, és a dir, que féssim una distinció entre productes, com podria ser ‘primer plat’, ‘segon plat’, ‘postres’... En aquest cas podríem tenir diferents productors (primer plat, segon plat, postres, ...) i que cada un s’encarregués de crear el producte del seu tipus.

Singleton

Amb el patró de disseny Singleton ens assegurem que només tenim una única instancia d’un objecte. És útil quan es necessita un únic objecte per a coordinar accions de tot el sistema. Per al nostre sistema no hem trobat una aplicació que encaixi amb la definició d’aquest patró. Qualsevol classe pot estar instanciada més d’una vegada des de qualsevol Tablet. No tenim un objecte compartit per tot el sistema.

Patrons estructurals

Adapter

El patró Adapter és interessant de fer servir quan hem de transformar una interfície en una altra, de tal manera que la primera pugui treballar amb la segona de manera conjunta, cosa que abans no es podia degut a la incompatibilitat de les interfícies. Ara, havent-hi una interfície més general serà possible treballar amb diferents interfícies.

Un possible ús que li trobem a aquest patró en el nostre sistema per tal de que sigui escalable és en el moment d’emmagatzemar les dades. Ara mateix tenim una classe ‘IntermediariBaseDades’ que ens guarda la informació que li passem correctament a la base de dades. En aquest projecte s’ha pensat fer servir MySQL com a gestor de base de dades relacional, però amb la utilització d’aquest patró no ens tanquem, en un futur, a fer servir altres gestors de base de dades. Amb aquest patró tindríem la capacitat de fer l’emmagatzematge en diferents bases de dades fent ús d’aquesta mateixa classe realitzant pocs canvis en el diagrama de classes.

72

Composite

Aquest patró ens dona la possibilitat de construir objectes a partir d’altres objectes més simples tot mantenint una estructura en forma d’arbre i realitzant una composició recursiva.

Com en el cas dels patrons creacionals ‘Factory Method’ i ‘Abstract Factory’, si haguéssim optat per crear famílies de productes podríem haver utilitzat aquest patró per crear des d’un producte simple, un producte més complert. Per exemple, des del producte ‘Bistec’ podríem haver creat els complements d’aquest producte, afegint altres productes ‘salsa rocafort’ o ‘salsa al pebre verd’ o ‘patates fregides’, ‘arròs’ o ‘amanida’.

Decorator

El patró Decorator ens permet afegir diferents responsabilitats a un objecte. Estalvia d’aquest mode el haver de crear diferents classes que heretin d’una més general incorporant la nova funcionalitat. Permet afegir responsabilitats dinàmicament.

Hem trobat útil aquest patró per crear els diferents tipus d’usuari que poden accedir a l’aplicació. En un principi teníem una classe ‘Usuari’ que d’aquí derivaven altres usuaris com Administrador, Director, TreballadorCuina, TreballadorBar... i cada una d’aquestes classes amb els seus mètodes. Amb aquest patró queda un diagrama de classes més net i per conseqüència un codi també més clar i entenedor. Quan s’hagin d’afegir mètodes a les responsabilitats existents serà més intuïtiu de saber a on afegir-los i quan haguem de crear noves responsabilitats, crearem una nova classe per aquella responsabilitat amb els seus mètodes reduint així l’acoblament. De la manera anterior, hauríem d’afegir les responsabilitats a cada tipus d’usuari i crear tants tipus d’usuari com fossin necessaris degut a que les classes estarien fortament acoblades. Ara, amb l’ús d’aquest patró per a la creació de nous tipus d’usuaris ens limitarem a afegir-li les responsabilitats necessàries.

Patrons de comportament

State

El patró State permet a un objecte canviar el seu comportament quan el seu estat intern canvia. Aquest patró ens és molt adient al nostre sistema, ja que els Productes d’una Comanda poden estar en diversos estats. En funció del estat en que estigui cada producte el seu comportament serà diferents. Si el producte es troba en el primer estat, on encara no s’ha començat a treballar, aquest producte podrà ser eliminat de la comanda. Si ja s’ha començat a treballar en ell, no es podrà eliminar, i si ja està llest, el cambrer ja el podrà recollir per portar a la taula. En cada moment, el producte estarà en un estat diferent i aquesta informació serà mostrarà. Amb aquesta implementació, a més del tres estats inicials que proposem, es podran afegir els estats que el client desitgi.

73

Strategy

El patró Strategy determina diferents algoritmes de realitzar una mateixa operació. L’objecte client pot escollir quin utilitzar segons les seves necessitats en cada moment. Així, s’encapsulen els diferents algoritmes en una jerarquia i l’objecte client interactua amb un objecte intermediari.

En el nostre sistema, aquest patró el podem encaixar amb la classe ‘Reducció’ que pateixen els ingredients en reduir el seu stock. Els ingredients del restaurant

pateixen una reducció del seu stock per diferents motius, alguns exemples poden ser, perquè s’han venut, perquè ha complert la seva data de caducitat, o perquè han patit algun deteriorament en el seu emmagatzematge. Amb el patró ‘Strategy’ podrem aplicar una ‘Reducció’ sobre l’’Ingredient’ i a més, triar la reducció ha patit. Cada tipus de reducció és diferent i l’ingredient discrimina el tipus de reducció patida. Per mantenir l’escalabilitat, aquí podrem afegir els tipus de reducció que vulguem amb el mínim esforç possible.

Template Method

El patró ‘Template Method’ defineix una estructura algorítmica a la super-classe, delegant la implementació a les subclasses. Es defineix una estructura hereditària en la qual, la super-classe serveix de plantilla dels mètodes de les subclasses. Amb aquest patró s’evita la repetició de codi i l’aparició d’errors.

Hem fet ús d’aquest patró per cobrir el tema de les estadístiques. Quan es vol generar una estadística hi ha unes accions que són comunes per a totes les estadístiques com mostrar la estadística o recuperar les dades. Per tant, aquesta part es pot utilitzar com una plantilla. Després hi ha altres operacions com generar la estadística que cada una la fa diferent. Per tant, el ‘Template Method’ és un patró que s’ajusta a les nostres necessitats en aquest cas.

74

9- Conclusions Finals

Després de quasi 4 mesos de feina que han passat, aquest document reflexa les nostres impressions

sobre el projecte i en aquesta secció, explicarem les nostres conclusions. Amb aquest projecte, han

passat dues coses. Per una banda, se’ns ha recordat lo molt que ens queda per aprendre a gestionar i

treballar un projecte de manera correcta. I per l’altra, la de coses que hauríem canviat al nostre projecte

de final de carrera. Ens ha ajudat a veure que, tot i que hi posem bones intencions, cal posar-s’hi en

serio amb la feina, que tot i que una cosa sigui fàcil, cal dedicar-li temps. Fets com el que ens va passar a

la fase de l’anàlisi, o els continus canvis als diferents diagrames, indiquen que no s’ha seguit la millor

coordinació i sincronització pel projecte. Però, també podem treure aspectes positius. Hem aprés força

coses sobre el UML i la manera d’aplicar aquest concepte a un projecte. També se’ns ha recordat la línia

que cal seguir per la bona implantació d’un projecte, tot i que el treball es quedi en l’aspecte teòric.

Com a resum, dir que, com s’ha deduït amb aquest document, si tinguéssim que fer una altra vegada

aquest projecte des de zero, hauríem fet les coses d’una manera diferent. Tot i així, estem satisfets amb

la feina que hem fet.

Cristian Álvarez Sánchez - Rubén Amaro Parrado - Nicolás Joel Giacconi Fernández – Óscar Simón Castillo