Software Architecture Documentation - Fastfood

last saved: Sunday, March 03, 2019 1
Software Architecture Documentation
FastFood
Gruppo
• Lonardo Gioacchino
• Pagliaro Alessandro

2 last saved: Sunday, March 03, 2019
Software Architecture Documentation............................................................................1
1 Requisiti informali del sistema software ...............................................................6
2 Analisi del sistema .........................................................................................................7
2.1 Diagrammi dei casi d’uso................................................................................................7
2.1.1 Descrizione del caso d’uso [Richiesta Posti]..........................................................................9
2.1.2 Descrizione del caso d’uso [Effettua Prenotazione]........................................................11
2.1.3 Descrizione del caso d’uso [Assegna Posti].........................................................................11
2.1.4 Descrizione del caso d’uso [Libera Posto Occupato]......................................................13
2.1.5 Descrizione del caso d’uso [Occupa Posto] .........................................................................13
2.1.6 Descrizione del caso d’uso [Visualizza Elenco Posti Occupati da 15 min]...........15
2.1.7 Descrizione del caso d’uso [Visualizza Stato Posti].........................................................15
2.2 Diagrammi di contesto ................................................................................................. 16
2.2.1 Diagramma di contesto [Software System Context Class]...........................................16
2.2.2 Diagramma di contesto [Software Context Class Diagram whit Boundary Class]
17
2.3 Modello del dominio ..................................................................................................... 18
2.4 Diagrammi dinamici...................................................................................................... 19
2.4.1 Richiesta Posti...................................................................................................................................19
2.4.2 Effettua Prenotazione....................................................................................................................20
2.4.3 Assegna Posti.....................................................................................................................................20
2.4.4 Occupa Posto......................................................................................................................................22
2.4.5 Visualizza Elenco Posti Occupati da 15 min........................................................................23
2.4.6 Visualizza Stato Posti.....................................................................................................................24
2.4.7 Stato Posto ..........................................................................................................................................25
2.4.8 Stato Postazione...............................................................................................................................26
3 Diagrammi architetturali.......................................................................................... 27
3.1 Vista architetturale [Vista Strutturale di Alto Livello] ....................................... 27
3.2 Descrizione ...................................................................................................................... 27
3.2.1 Elementi non standard..................................................................................................................27
3.3 Rationale........................................................................................................................... 27
3.4 Relazioni con altri modelli/elementi di modello................................................. 28
3.5 Vista architetturale [Decomposition View Sistema] ........................................... 28
3.6 Descrizione ...................................................................................................................... 28
3.7 Modello.............................................................................................................................. 28
3.7.1 Elementi non standard..................................................................................................................29
3.8 Rationale........................................................................................................................... 29
3.10 Vista architetturale [ERD Fastfood] ......................................................................... 30
3.11 Descrizione ...................................................................................................................... 30
3.12 Modello.............................................................................................................................. 30
3.12.1 Elementi non standard ............................................................................................................31
3.13 Rationale........................................................................................................................... 31

3.14 Relazioni con altri modelli/elementi di modello .................................................31
3.15 Vista architetturale [Vista a Layer del Client di Alto Livello] ...........................32
3.16 Descrizione....................................................................................................................... 32
3.17 Modello.............................................................................................................................. 33
3.17.1 Elementi non standard............................................................................................................33
3.18 Rationale........................................................................................................................... 34
3.20 Vista architetturale [Vista a Layer del Server di Alto Livello]..........................35
3.21 Descrizione....................................................................................................................... 35
3.22 Modello.............................................................................................................................. 35
3.23 Rationale........................................................................................................................... 36
3.25 Vista architetturale [C&C Client-Server]................................................................. 37
3.26 Descrizione....................................................................................................................... 37
3.27 Modello.............................................................................................................................. 38
3.28 Rationale........................................................................................................................... 39
3.30 Vista architetturale [C&C Shared-Memory] ........................................................... 39
3.31 Descrizione....................................................................................................................... 39
3.32 Modello.............................................................................................................................. 40
3.33 Rationale........................................................................................................................... 41
3.35 Vista architetturale [Deployment Diagram Component]...................................41
3.36 Descrizione....................................................................................................................... 41
3.37 Modello.............................................................................................................................. 42
3.38 Rationale........................................................................................................................... 44
3.40 Vista architetturale [Install Style Server]............................................................... 44
3.41 Descrizione....................................................................................................................... 44
3.42 Modello.............................................................................................................................. 45
3.43 Rationale........................................................................................................................... 45
3.45 Vista architetturale [Module View Server Dettaglio]..........................................46
3.46 Descrizione....................................................................................................................... 46
3.47 Modello.............................................................................................................................. 47
3.48 Rationale........................................................................................................................... 48

3.50 Vista architetturale [Module View Client Dettaglio] ........................................... 49
3.51 Descrizione ...................................................................................................................... 49
3.52 Modello.............................................................................................................................. 50
3.52.1 Elementi non standard ............................................................................................................50
3.53 Rationale........................................................................................................................... 51
4 Beyond ............................................................................................................................ 52
4.1 Vista architetturale [Richiesta Posti Client – Client Side].................................. 52
4.2 Descrizione ...................................................................................................................... 52
4.3 Modello.............................................................................................................................. 52
4.5 Vista architetturale [Assegna Posti– Server Side]................................................ 54
4.6 Descrizione ...................................................................................................................... 54
4.7 Modello.............................................................................................................................. 54
4.9 Vista architetturale [Thread Posto – Server Side] ............................................... 56
4.10 Descrizione ...................................................................................................................... 56
4.11 Modello.............................................................................................................................. 56
4.13 Vista architetturale [Effettua Prenotazione – Server Side]............................... 57
4.14 Descrizione ...................................................................................................................... 57
4.15 Modello.............................................................................................................................. 57
4.17 Vista architetturale [Visualizza Stato Posti – Client Side].................................. 58
4.18 Descrizione ...................................................................................................................... 58
4.19 Modello.............................................................................................................................. 58
4.21 Vista architetturale [Visualizza Posti Occupati da 15 Min – Client Side] ...... 59
4.22 Descrizione ...................................................................................................................... 59
4.23 Modello.............................................................................................................................. 59
4.25 Vista architetturale [Visualizza Stato Posti – Server Side]................................ 60
4.26 Descrizione ...................................................................................................................... 60
4.27 Modello.............................................................................................................................. 60
4.29 Vista architetturale [Occupazione Tavolo – Client Side].................................... 61
4.30 Descrizione ...................................................................................................................... 61
4.31 Modello.............................................................................................................................. 61
4.33 Vista architetturale [Occupazione Tavolo – Server Side] .................................. 63
4.34 Modello.............................................................................................................................. 63

5 Conclusioni .................................................................................................................... 65

1 Requisiti informali del sistema software
Si vuole realizzare un sistema software che consenta di gestire in maniera automatica la
prenotazione e l’assegnazione dei posti a sedere di un fast-food.
Il fast food ha un insieme di tavoli numerati, ognuno con un predefinito numero di posti.
Ogni posto è identificato da un codice alfanumerico di 4 caratteri e può essere “libero”
oppure “occupato”.
Il fast-food è fornito di postazioni attrezzate con un’interfaccia utente che permette ai
clienti di chiedere l’assegnazione di uno o più posti liberi appartenenti ad uno stesso ta-
volo. Il sistema verificherà la presenza di un tavolo avente il numero di posti liberi richie-
sti ed in caso affermativo assegnerà tali posti al cliente. Il terminale mostrerà inoltre a vi-
deo il numero del tavolo, gli identificativi dei posti e un codice di assegnazione numerico
di 5 cifre. In caso contrario il sistema chiederà al cliente di inserire il proprio cognome
(stringa di al più 25 caratteri alfabetici non vuota) ed un numero di cellulare (di formato
valido) che saranno inseriti in una coda di prenotazioni (gestita in modalità FIFO).
Appena uno dei tavoli avrà un numero di posti liberi sufficiente per soddisfare una delle
prenotazioni in coda allora il sistema automaticamente preleverà la prima prenotazione
assegnabile e sceglierà i posti liberi del tavolo da associare a tale prenotazione. Inoltre, il
sistema invierà un SMS con il numero del tavolo, gli identificativi dei posti liberi, un nu-
mero di assegnazione e il codice di prenotazione al numero di cellulare del cliente abbi-
nato a tale prenotazione.
Ogni posto dei tavoli è poi dotato di un dispositivo che offre al cliente un’interfaccia
utente da usare per confermare l’occupazione del posto assegnatogli. A tal fine, ogni
cliente deve inserire sia il numero di assegnazione che il codice di prenotazione ricevuto
e confermare la sua presenza al tavolo. Il sistema controllerà la corrispondenza fra i due
codici e quello del posto e nel caso di esito positivo allora il posto diventerà occupato,
sarà memorizzato l’orario di occupazione, ed il dispositivo presenterà al cliente il menu
delle pietanze disponibili. Se la conferma di occupazione del posto non avviene entro 5
minuti dal momento dell’assegnazione, il sistema libererà il posto, che tornerà disponibile
per altre prenotazioni.
Attraverso lo stesso dispositivo, il cliente dovrà comunicare al sistema il termine della
consumazione del pasto, dopo di che il posto tornerà libero.
Il sistema fornisce alla direzione anche la funzionalità di visualizzare l’elenco di posti che
sono occupati da più di 15 minuti. In particolare per ogni posto, oltre al suo identificativo
e numero di tavolo, sarà mostrato a video anche il tempo di occupazione del tavolo
espresso in minuti.

2 Analisi del sistema
2.1 Diagrammi dei casi d’uso
Nome elemento Tipo Descrizione
Richiesta Posti Caso d’uso esteso Modella l’interazione tra cliente e sistema che si
verifica quando il cliente richiede al dispositivo
per la prenotazione un certo numero di posti da
farsi assegnare. Successivamente stampa a vi-
deo un determinato risultato a seconda della di-
sponibilità di quest’ultimi.
Effettua Prenotazione Caso d’uso Viene modellata l’eventualità in cui, non sono
presenti posti liberi quando avviene la richiesta
al dispositivo di prenotazione. Il sistema intera-
gisce con il cliente, richiedendogli i dati per ef-
fettuare la prenotazione.

Assegna Posti Caso d’uso in-
cluso
Questo caso d’uso modella la funzionalità cen-
trale del sistema, cioè si preoccupa di assegnare
i primi posti liberi quando essi sono presenti al
momento della richiesta al dispositivo di preno-
tazione. Il sistema a regime, ogni volta che un
posto viene liberato cerca di assegnare la prima
prenotazione nella coda delle prenotazioni, se i
posti sono sufficienti. Segnala al cliente l’avve-
nuta assegnazione tramite un servizio di mes-
saggistica ed avvia un timer che aspetta la con-
ferma di occupazione del posto da parte del
cliente entro 5 minuti dall’assegnazione.
Libera Posto Occu-
pato
Caso d’uso Permette l’interazione attraverso il dispositivo
sul tavolo tra cliente e sistema per segnalare la
liberazione del posto occupato, quindi la termi-
nazione del pasto.
Occupa Posto Caso d’uso Modella l’occupazione dei posti assegnati
all’utente, che avviene attraverso un codice di
assegnazione ed eventualmente con uno di pre-
notazione. Successivamente il sistema verifi-
cherà la correttezza dell’assegnazione. In caso
di esito positivo il posto sarà occupato, verrà re-
gistrato l’orario di occupazione e sarà presentato
al cliente la schermata del menù. In caso contra-
rio verrà visualizzato un errore.
Visualizza Elenco
Posti Occupati da 15
min
Caso d’uso Permette ai dipendenti della direzione di otte-
nere un elenco dei posti, di ogni tavolo, che ri-
sultano essere occupati da più di 15 minuti.
Visualizza Stato Posti Caso d’uso Consente ai dipendenti della direzione di cono-
scere lo stato corrente di tutti i posti nel fast-
food, mostrando l’identificativo del posto, nu-
mero di tavolo e il tempo di occupazione
espresso in minuti.
Cliente Attore primario e
secondario
Attore primario che inizia l’interazione con il si-
stema richiedendo un certo numero di posti. Può

svolgere il ruolo di attore secondario nel mo-
mento in cui non sono disponibili posti e gli
viene richiesto di prenotare.
Timer Attore secondario Viene attivato nel momento in cui vengono as-
segnati uno o più posti. Se entro 5 minuti
dall’assegnazione il cliente non conferma la sua
presenza al tavolo, questo verrà considerato
nuovamente libero e pronto ad essere assegnato.
Sistema SMS Attore secondario Servizio esterno al sistema software utilizzato
per inviare un messaggio al cliente che aveva
prenotato. Il messaggio contiene i codici di as-
segnazione e prenotazione e quindi lo informa
che i posti richiesti gli sono stati assegnati.
Dipendente Attore primario Generico dipendente che, attraverso il disposi-
tivo in direzione, richiede la stampa delle infor-
mazioni sullo stato corrente di tutti i posti e la
lista dei posti occupati da più di 15 minuti
Tabella 1: Elementi del diagramma dei casi d'uso
NOTA: Nel template non è riportata una sezione link di tracciabilità per i diagrammi di analisi.
Ma è opportuno precisare che esistono link di tracciabilità dal diagramma dei casi d’uso ai dia-
grammi di progettazione (in particolare, agli elementi dell’ ERD) così come dai sequence di ana-
lisi. Vedi in dettaglio la funzionalità “Reference mapping” nel file Visual Paradigm per i link di
tracciabilità.
2.1.1 Descrizione del caso d’uso [Richiesta Posti]
Questo activity viene fornito per la descrizione dello scenario base del caso d’uso di richiesta po-
sti e dello scenario alternativo, che in caso di assenza di posti disponibili, prevede di far effettuare
una prenotazione al cliente (mostrato in dettaglio nel paragrafo 2.1.2).

2.1.2 Descrizione del caso d’uso [Effettua Prenotazione]
Questo diagramma modella lo scenario alternativo di richiesta posti, ovvero l’effettuazione di una
prenotazione.
2.1.3 Descrizione del caso d’uso [Assegna Posti]
Questo diagramma modella diversi scenari presenti nel caso d’uso assegna posti. Lo scenario base
è quello in cui si assegnano i posti richiesti al dispositivo e quest’ultimi sono disponibili, se in-
vece non sono disponibili abbiamo il primo scenario alternativo. Gli altri due scenari alternativi
sono l’assegnazione della prima prenotazione in coda differenziando quando ci sono o meno i po-
sti disponibili. Scenari che si innescano a seguito della segnalazione di un posto libero.

2.1.4 Descrizione del caso d’uso [Libera Posto Occupato]
Questo diagramma di activity modella lo scenario base del cliente che libera il posto, senza consi-
derare scenari alternativi.
2.1.5 Descrizione del caso d’uso [Occupa Posto]
Questo activity diagram presenta lo scenario base e gli alternativi del caso d’uso occupa posto che
prevede, una volta assegnato il codice di assegnazione, che il cliente si segga al posto e ne con-
fermi l’occupazione. Gli scenari alternativi presenti nel diagramma mostrano che quando il
cliente sbaglia ad inserire il codice di assegnazione o il tempo per occuparlo scade, non gli viene
più permesso di occupare il posto, notificando al cliente quest’ultimo aspetto.

2.1.6 Descrizione del caso d’uso [Visualizza Elenco Posti Occupati
da 15 min]
Scenario base che descrive l’interazione tra cliente e il sistema quando chiede di visualizzare i po-
sti occupati da 15 minuti.
2.1.7 Descrizione del caso d’uso [Visualizza Stato Posti]
Scenario base che descrive l’interazione tra cliente e il sistema quando chiede di visualizzare i
dettagli dei posti.

2.2 Diagrammi di contesto
2.2.1 Diagramma di contesto [Software System Context Class]
Mostra il confine tra il sistema software e il “mondo” esterno al sistema attraverso le
classi esterne. Grazie a quest’ultime, nel prossimo diagramma, andiamo ad individuare le
boundary class.
Postazione Prenotazioni External User Rappresenta la postazione che il
cliente utilizza per richiedere i posti ed
effettuare la prenotazione.
Dispositivo Posto External User Dispositivo che il cliente utilizza da
posto per occupare o liberare il posto.
Postazione Direzione External User Dispositivo che il dipendente della di-
rezione utilizza per visualizzare i posti
occupati da più di 15 minuti e lo stato
complessivo dei posti.
Sistema SMS External System Servizio di messaggistica esterna a cui
si richiede l’invio di sms.
Timer External Timer Timer esterno che fornisce informa-
zioni temporali al sistema.
Sistema Gestione Assegna-
zione Prenotazione
Software System Indica tutto il sistema software, che
contiene internamente le classi che

provvedono a tutte le funzionalità del
sistema.
Tabella 2: Elementi del diagramma di contesto
2.2.2 Diagramma di contesto [Software Context Class Diagram whit
Boundary Class]
In questo diagramma, oltre a quello già espresso nel Software System Context Class, si
mostrano le classi boundary che modellano l’interfacciamento con le classi esterne. Per-
mette di definire nella prima fase di analisi attraverso quali elementi avviene la comuni-
cazione tra sistema ed attori e inizia a definire il perimetro del nostro sistema software.
Le classi esterne e il sistema sono descritti nella tabella precedente.
Dispositivo Prenotazioni Inte-
raction
User Interaction Rappresenta la parte di interfacciamento
del sistema con la classe esterna Posta-
zione Prenotazioni, astraendone i detta-
gli.
Postazione Direzione Interac-
tion
User Interaction Rappresenta la parte di interfacciamento
del sistema con la classe esterna Posta-
zione direzione, astraendone i dettagli.

Dispositivo Posto Interaction User Interaction Rappresenta la parte di interfacciamento
del sistema con la classe esterna Dispo-
sitivo posto, astraendone i dettagli.
SMS Interface Proxy Interfaccia interna al sistema che per-
mette di comunicare con il servizio di
messaggistica, nascondendo come av-
viene la comunicazione.
Timer Input Timer interno al sistema avviato in caso
di assegnazione ed informa che il count-
down è concluso.
Tabella 3: Elementi del diagramma di contesto
2.3 Modello del dominio
Nome elemento Descrizione
Prenotazione Mantiene informazioni circa le prenotazioni effettuate dagli
utenti. L’ordinamento FIFO della coda di prenotazioni è mo-
dellato attraverso la relazione ricorsiva.

Assegnazione Memorizza il codice di assegnazione che viene generato nel
momento in cui viene assegnato un posto libero.
Posto Informazioni identificative del posto, dello stato in cui si può
trovare e dell’orario in cui viene occupato.
Tavolo Presenta informazioni sul numero del tavolo presenti nel fast-
food.
Fast Food Possiede importati relazioni di aggregazione e composizione e
potrebbe memorizzare informazioni sul fastfood.
Menù Informazioni sulle pietanze del fastfood.
Tabella 4: elementi del modello di dominio
2.4 Diagrammi dinamici
2.4.1 Richiesta Posti
2.4.1.1 Descrizione
Questo diagramma rappresenta lo scenario base del caso d’uso di “Richiesta Posti”, dove
il cliente immette il numero di posti. La presenza di un oggetto PostazioneControl dipen-
dente dallo stato serve per modellare il comportamento della parte del sistema che risiede
nella Postazione Prenotazioni. Fino ad arrivare in una Business Logic dove viene verifi-
cata la disponibilità.
Gli scenari a cui fa riferimento il diagramma:
- Scenario base caso d’uso Richiesta Posti
2.4.1.2 Modello

2.4.2 Effettua Prenotazione
2.4.2.1 Descrizione
Il diagramma descrive la comunicazione tra gli oggetti quando non esistono posti dispo-
nibili e deve essere effettuata una prenotazione da parte del cliente.
- Scenario alternativo Richiesta Posti (Effettua Prenotazione)
2.4.2.2 Modello
2.4.3 Assegna Posti
2.4.3.1 Descrizione
Diagramma che va a modellare tutti gli scenari sia base che alternativi che si possono ve-
rificare relativamente all’assegnazione dei posti (vedi dettagli del relativo activity).
- Scenario base Richiesta Posti (nel punto di inclusione, vedi activity Richiesta Po-
sti);
- Scenari base ed alternativi di Assegnazione Posti mostrati nell’activity.

2.4.3.2 Modello
Nota: consigliamo di fare maggiore riferimento al sequence qui sotto, data la sua maggiore leggi-
bilità rispetto al communication. Quest’ultimo è stato realizzato per meglio aderire al metodo
COMET.

2.4.4 Occupa Posto
2.4.4.1 Descrizione
In questo diagramma modelliamo lo scenario di occupazione dei posti, da parte dei
clienti. Infatti, ogni cliente una volta che gli è stato assegnato un certo codice, sia a se-
guito di disponibilità immediata che di prenotazione, dovrà entro 5 minuti confermare
l’occupazione. Se ciò non viene fatto in tempo, il posto diventerà nuovamente libero per
l’assegnazione.
- Scenari base ed alternativi di Occupa Posto mostrati nell’activity.

2.4.4.2 Modello
2.4.5 Visualizza Elenco Posti Occupati da 15 min
2.4.5.1 Descrizione
Scenario base relativo alla visualizzazione dei posti occupati da più di 15 minuti da parte
di un dipendente in direzione.
- Scenario base di visualizza elenco posti occupati da 15 min mostrato nell’activity.
2.4.5.2 Modello

2.4.6 Visualizza Stato Posti
2.4.6.1 Descrizione
Diagramma che rappresenta la funzionalità che ci permette di visualizzare lo stato di tutti
i posti in un preciso istante.
- Scenario base di Visualizza Stato Posti tavolo mostrato nell’activity.
2.4.6.2 Modello

2.4.7 Stato Posto
2.4.7.1 Descrizione
Questo diagramma descrive gli stati che il posto può assumere durante l’evolvere del sistema.
2.4.7.2 Modello

2.4.8 Stato Postazione
2.4.8.1 Descrizione
Lo statechart modella gli stati della postazione che serve ad effettuare le richieste dei posti e le
prenotazioni.
2.4.8.2 Modello

3 Diagrammi architetturali
3.1 Vista architetturale [Vista Strutturale di Alto Livello]
3.2 Descrizione
Vista statica dei sottosistemi dell’applicazione che viene proposta dal COMET come
primo passo per l’inizio della fase di progettazione.
3.2.1 Elementi non standard
In questo diagramma non esistono tipologie di elementi o relazioni non standard, ma essi
sono già definiti da COMET, perciò non vengono descritti e per eventuali chiarimenti
fare riferimento agli standard COMET.
3.3 Rationale
La vista seguente serve a dare una descrizione di alto livello del nostro sistema facendo
uso di un diagramma proposto dal metodo COMET, in maniera da rendersi conto di come
gli oggetti della nostra applicazione e le associazioni tra essi sono raggruppati in sottosi-
stemi, definendo funzionalità e puntando ad essere indipendenti tra loro. Lo scopo di que-
sto metodo di progettazione è quello di capire le componenti sviluppabili indipendente-
mente ed effettuare una prima decomposizione nel lavoro di progettazione, in maniera
tale che il project manager riesca ad allocare lo sviluppo dei diversi sottosistemi a diversi
team. Anche ad un architetto per dare una panoramica generale.

3.4 Relazioni con altri modelli/elementi di modello
NOTA: il particolare link di tracciabilità da e verso un elemento del modello è specificato nella
descrizione.
Link di tracciabilità Descrizione
Decomposition View Sistema Mostra la suddivisione in package dei vari sottosistemi.
Vista a Layer del Server di
Alto Livello
Mostra l’architettura a layer del sottosistema server.
Vista a Layer del Client di
Alto Livello
Mostra l’architettura a layer dei diversi sottosistemi client.
Module view Server Dettaglio Collegamento in verticale verso una vista di dettaglio del
sottosistema server.
Module view Client Dettaglio Collegamento in verticale verso una vista di dettaglio dei
sottosistemi client.
C&C Client-Server Mostra la relativa prospettiva a run-time del software sy-
stem
Tabella 5: Relazioni con altri modelli o elementi di modello
3.5 Vista architetturale [Decomposition View Sistema]
3.6 Descrizione
Vista a moduli con stile di decomposizione dei package del sistema che descrive il server
ed i diversi client. Inoltre, vi è la presenza di un package common, che presenta il mecca-
nismo di java RMI sfruttati da client e server per comunicare.
3.7 Modello

Non sono presenti tipologie di elementi non standard, per le tipologie di elementi stan-
dard rifarsi al SEI.
3.8 Rationale
L’obiettivo di questa vista di decomposizione è quello di dare una prima strutturazione di base del
sistema per aiutare un altro architetto o chi fa manutenzione e testing a comprenderla più rapida-
mente. Utile per l’assegnazione del lavoro ai diversi componenti del team di sviluppo e per even-
tuali analisi d’impatto in caso di cambiamenti sul sistema software.
Vista a Layer del Server di Alto
Livello
Permette di individuare come i package sono distribuiti nei
diversi layer del server.
Vista a Layer del Client di Alto
Livello
Permette di individuare come i package sono distribuiti nei
diversi layer dei client.

Vista Strutturale di Alto Livello Permette di comprendere in quale sottosistemi (server e di-
versi client) sono collocati i package
Module view Client Dettaglio Mostra le classi contenute nei package client ed evidenzia le
relazioni d’uso tra queste.
Module view Server Dettaglio Presenta le classi contenute nel package server ed evidenzia
le relazioni d’uso tra queste.
3.10 Vista architetturale [ERD Fastfood]
3.11 Descrizione
Attraverso uno stile data-model viene definita la persistenza all’interno della nostra appli-
cazione, per mettere in luce come le informazioni delle varie entità del fastfood saranno
memorizzate nel sistema e le relazione tra di loro.
Nota: l’associazione ricorsiva presente in analisi sull’entità prenotazione è stata tolta,
maggiori dettagli nella vista di dettaglio del server (vedi link di tracciabilità)
3.12 Modello

Non sono presenti tipologie di elementi non standard, per le altre tipologie di elementi di
questa vista è possibile rifarsi allo standard del SEI.
3.13 Rationale
Vista mirata a descrivere la persistenza dell’applicazione in maniera da far comprendere a
figure come quelle del database administrator, dell’analista, dell’architetto, ma anche a
chi fa manutenzione e testing quali informazioni rilevanti dovranno essere memorizzate
nell’applicazione.
Modello del Dominio Prima fase dell’individuazione delle classi data intensive
del sistema sofware.

C&C Shared-Memory Dinamicamente il componente repository FastfoodDB ef-
fettuerà operazioni CRUD su tabelle che derivano da questa
vista.
3.15 Vista architetturale [Vista a Layer del Client di Alto
Livello]
3.16 Descrizione
Module view che mostra un decomposition e layered style. Mette in evidenza molto ad
alto livello la struttura del client ed i package contenuti in ognuno di essi con le relazioni
di allowed to use tra i layer.
Nota: Il diagramma mostra la struttura di un generico client, di conseguenza i package
della business logic sono presenti solo in PostazioneDirezione e DispositivoPosto mentre
il package control è presente solo in Postazione Prenotazione.

3.17 Modello
Per gli elementi di questa vista riferirsi alle tipologie stereotipate dal SEI.
3.17.1.1 Catalogo delle tipologie di elementi
Nota: per maggiore chiarezza documentiamo ogni elemento layer.
Nome Stereotipo
testuale
Icona dello
stereotipo
Acronimo Descrizione
Layer
Proxy
<<Layer>> LPC Contiene l’insieme dei pac-
kage e delle classi che permet-
tono di interfacciarsi con i ser-
vizi esposti dal server tramite
chiamate basate su tecnologia
java RMI.
Layer
Control
<<Layer>> LCC Contiene i package e le classi
necessarie a gestire lo stato e

la logica di business all’interno
delle postazioni del Fastfood
sfruttate dai vari attori.
Layer
Boundary
<<Layer>> LBC Contiene I package e le classi
che servono per implementare
le GUI, e quindi regolare tutta
l’interazione con l’attore.
Tabella 8 - Catalogo delle tipologie di elementi
3.18 Rationale
Il diagramma punta a proporre una vista di alto livello, indirizzandosi particolarmente
verso la figura dell’architetto corrente o di uno futuro. Infatti, è stata fornita proprio per
comprendere molto rapidamente la struttura architetturale del client. Per la progettazione
è stato scelto questo stile per evidenziare le caratteristiche di modificabilità, riuso e porta-
bilità che esso introduce.
Può essere utile per le figure che faranno manutenzione, testing di integrazione.
Vista Strutturale di Alto
Livello
Collegato ai diversi sottosistemi client. Permette di individuare
dove si trova questa struttura a layer in un diagramma a moduli
di alto livello che mostra i sottosistemi.
Decomposition View Si-
stema
Collegato ai package postazionedirezione, postazioneprenota-
zione e dispositivotavolo. Mostra dove questi layer sono pre-
senti in una vista di decomposizione di tutto il sistema.
Vista di dettaglio a layer
del client
Il link permette di andare in verticale in una vista sempre strut-
turata a layer ma più di dettaglio, esplicitando la relazione di al-
lowed to use e il contenuto dei diversi layer del client.

3.20 Vista architetturale [Vista a Layer del Server di Alto
Livello]
3.21 Descrizione
Questa vista a livelli, ripropone la stessa strutturazione scelta per il client, anche all’in-
terno del server. Infatti, il server viene progettato secondo uno stile a livelli (di tipo strict
layered), in maniera tale che ogni livello possa usufruire solamente dei servizi del livello
direttamente inferiore.
3.22 Modello
Per gli elementi di questa vista riferirsi alle tipologie stereotipate dal SEI.

Nota: per maggiore chiarezza documentiamo ogni elemento layer.
Nome Stereotipo
testuale
Icona dello
stereotipo
Layer
Proxy
<<Layer>> LPC Contiene l’insieme dei pac-
kage e delle classi che offrono
un’interfaccia e quindi i servizi
implementati dal server per i
diversi client. Le richieste di
servizio da parte del client
sono effettuate attraverso la
tecnologia java RMI.
Layer
Control
<<Layer>> LCC Contiene i package e le classi
necessarie a gestire lo stato e
la logica di business all’interno
del server per svolgere le fun-
zionalità espresse nei casi
d’uso.
Layer En-
tity
<<Layer>> LBE Contiene il package Entity in
cui sono presenti le classi data
intensive.
Layer DB
Interface
<<Layer>> LDBI Contiene i package e le classi
necessarie per interfacciarsi
con il database esterno. Realiz-
zando un ORM tramite un fra-
mework.
3.23 Rationale
La scelta che ha portato a determinare una vista di questo tipo è stata quella di una strut-
turazione del nostro sistema, al fine di dare una panoramica molto astratta dell’architet-
tura del server che può essere utile sia alla figura dell’architetto che ai membri del team
di sviluppo, ma anche per chi fa manutenzione. Tale scelta punta ad introdurre concetti di
modularità ed elevata portabilità nello sviluppo di questo componente. Ad esempio pos-
siamo variare con facilità il database relazione sottostante.

Vista Strutturale di Alto Li-
vello
Collegato al sottosistema server. Permette di individuare
dove si trova questa struttura a layer in un diagramma a mo-
duli di alto livello che mostra i sottosistemi.
Decomposition View Sistema Collegato al package server. Mostra dove questi layer sono
presenti in una vista di decomposizione di tutto il sistema.
Vista di dettaglio a layer del
server
Il link permette di andare in verticale in una vista sempre
strutturata a layer ma più di dettaglio, esplicitando la rela-
zione di allowed to use e il contenuto dei diversi layer del
server.
3.25 Vista architetturale [C&C Client-Server]
3.26 Descrizione
Vista C&C Client-Server molto di alto livello, dove i componenti della nostra architettura
sono client (il software delle postazioni con cui interagiscono gli attori) e server. Server
che espone i propri servizi e risponde alle richieste fatte dal client attraverso comunica-
zioni basate su Java RMI. Inoltre nel modello è presente anche una vista shared-data met-
tendo in luce lo scambio di informazioni persistenti presenti sul nostro DB rispetto al
componente server.

3.27 Modello
Per le tipologie di elementi riferirsi agli stereotipi del SEI.
3.27.1.2 Catalogo delle tipologie di relazioni
Nome Stereotipo
testuale
Java Remote
Method Invocation
<<RMI>> RMI Permette ad un oggetto che viene eseguito su di
una JVM di richiamare metodi di un altro og-
getto che esegue su di un’altra JVM al fine di
effettuare una comunicazione remota tra i pro-
grammi. (Doc RMI)
Java Database
Connectivity
<<JDBC>> JDBC Si tratta di API Java che definisce come effet-
tuare l’accesso al DB. Infatti, tale tecnologia
fornisce metodi per effettuare query ed aggior-
namenti ai dati del DB.
Tabella 12 - Catalogo delle tipologie di relazioni

3.28 Rationale
Questa vista a C&C ha lo scopo di mostrare tutti gli elementi computazionali e gli archivi
di dati che sono presenti a run-time nel nostro sistema. Individuiamo i componenti più ad
alto livello per poi specializzarli in diagrammi successivi con le relative substructure, in
maniera tale da fornire una guida sullo sviluppo dell’applicazione soprattutto per la figura
dell’architetto e per il team di sviluppo, ma anche per chi fa manutenzione, specificando
la struttura ed il comportamento in esecuzione. Questa vista mostra la scalabilità dell’ar-
chitettura scelta, con la possibilità di aggiungere un certo numero di client anche a run-
time.
C&C Multi-tier Mostra, andando in verticale, il contenuto dei diversi com-
ponenti delineandone anche la loro suddivisione in tier.
C&C Shared Memory Permette di osservare in maniera più dettagliata il collega-
mento a run time tra server (attraverso i data accessor) e re-
pository.
Deployment Diagram Compo-
nent
Mostra l’allocazione dei componenti di questa vista sui di-
versi nodi fisici.
Install Style Server Presenta gli artifact che implementano il componente ser-
ver.
3.30 Vista architetturale [C&C Shared-Memory]
3.31 Descrizione
La vista mette in evidenza tutta la parte di persistenza della nostra applicazione e come le
informazioni vengono recuperate dal nostro DB. Si tratta di una vista C&C con uno sha-
red memory style. I componenti DB Wrapper del nostro sistema a run time sono le classi
che offrono servizi alle classi entity. Attraverso una connessione jdbc astraggono la ge-
stione del database ed effettuano operazioni CRUD.

3.32 Modello
Non sono presenti, e per le tipologie di elementi riferirsi al SEI.
Nome Stereotipo te-
stuale

Java Call <<Java Call>> JC Chiamata da parte di un oggetto di una
classe di un metodo esposto da un oggetto
di un’altra classe.
Java Data-
base
Connecti-
vity
<<JDBC>> JDBC Si tratta di API Java che definisce come
effettuare l’accesso al DB. Infatti, tale tec-
nologia fornisce metodi per effettuare
query ed aggiornamenti ai dati del DB.
3.33 Rationale
Lo scopo di questa vista era mostrare come avviene il recupero delle informazioni persi-
stenti a run time tra i data accessor, che si interfacciano con la repository, ed il nostro
componente database. Introduce vantaggi come il disaccoppiamento tra la figura del for-
nitore di dati da quella del consumatore ottenendo maggiore modificabilità ed inoltre per-
mette di considerare componenti multipli che possono accedere contemporaneamente ai
dati. Questa vista è in particolare indirizzata verso lo sviluppatore che implementerà que-
sto aspetto, ma anche a chi in futuro ne dovrà fare manutenzione.
C&C Client Server La vista di alto livello di cui si descrive in dettaglio la parte
shared memory.
C&C Multi tier Vista che mostra in quale tier i componenti della shared me-
mory sono presenti.
3.35 Vista architetturale [Deployment Diagram Component]
3.36 Descrizione
In questo diagramma abbiamo un allocation view che mostra un deployment style e in-
stall style. In un primo “livello” viene mostrato il collegamento con una certa tecnologia
tra i device. Successivamente con la relazione di contenimento mostro il sistema opera-

tivo utilizzato. Con dei nodi gerarchici mostro gli ambienti di esecuzione e infine il com-
ponente allocato. Una relazione di manifest mostra come gli archivi jar implementano i
componenti.
3.37 Modello
Nome Stereotipo
testuale
Icona dello
stereotipo
Postazione
Prenota-
zione
<<device
touch>>
PPD Rappresenta il dispositivo fisico do-
tato di schermo touch per l’interfac-
ciamento, con cui l’utente può effet-
tuare la richiesta dei posti. Dotato di
poche risorse computazionali (solo

quelle necessarie per la semplice lo-
gica che inseriamo all’interno).
Dispositivo
Tavolo
<<device
touch>>
DTD Questo è il dispositivo fisico usato
dall’utente per confermare l’assegna-
zione e visualizzare il menù.
Postazione
Direzione
<<device
touch>>
PDD Dispositivo fisico con schermo touch
che permette al dipendente di visua-
lizzare informazioni sui tavoli e posti
nel fastfood.
Fastfood
Server
<<device
server>>
FFSD Rappresenta il PC server su cui viene
eseguita l’applicazione lato server e
dove il database mantiene la sua per-
sistenza.
MySQL <<database
system>>
MYSQL Rappresenta il DBMS scelto per ge-
stire la persistenza del nostro pro-
getto. Un database open source suffi-
ciente per le nostre esigenze.
Archivio jar <<jar>> AJAR Rappresenta l’archivio jar in cui
sono presenti i file come i .class per
l’esecuzione e gli eventuali sorgenti
java.
Fedora 22 <<os>> F22 Il sistema operativo open source
usato su tutti i nostri nodi hardware.
Nome Stereotipo testuale Acronimo Descrizione
100Ba-
seTX
<<ethernet>> 100BT Rappresenta la tecnologia hard-
ware utilizzata per far comuni-
care i vari device hardware. Con
velocità di 100Mbps.
TCP/IP <<protocol>> TCP-IP La comunicazione di livello rete
è basata sul protocollo di
TCP/IP. Quest’ultimo più ad
alto livello è usato da java RMI.

3.38 Rationale
Sono stati inseriti stereotipi non standard per meglio rappresentare gli elementi di questa
vista, andando a specificare l’hardware e gli ambienti di esecuzione utilizzati e i vari li-
velli della comunicazione tra i nodi come ethernet e protocol.
Questa vista è pensata per dare indicazioni al system eng. per gestire l’hardware necessa-
rio all’intera applicazione e al network administrator per configurare e manutenere oppor-
tunamente la rete. Può in una prima fase permettere la stima dei costi, dell’hardware e le
licenze dei software (che essendo open source sono gratuite), che il customer deve soste-
nere per usare il nostro software. In fine la possiamo proporre al project manager per
avere un indicazione su come allocare i team per sviluppare i diversi componenti.
C&C Client Server Prospettiva a C&C in cui viene mostrato il tipo di connet-
tore tra i componenti.
3.40 Vista architetturale [Install Style Server]
3.41 Descrizione
Mostriamo sinteticamente gli elementi artifact contenuti nel server.jar. Nota: non mo-
striamo tutte le classi contenute nel jar per motivi di leggibilità.

3.42 Modello
Nome Stereotipo
testuale
Icona dello
stereotipo
Archivio jar <<jar>> AJAR Rappresenta l’archivio jar
in cui sono presenti i file
come i .class per l’esecu-
zione e gli eventuali sor-
genti java.
hiber-
nate.cfg.xml
<<xml hi-
bernate>>
HCX Rappresenta i file xml uti-
lizzato dal framework hi-
bernate, per configurare la
gestione di tutti gli aspetti
del DB.
3.43 Rationale
Mostro questa vista per comunicare al team di sviluppatori come dovranno creare il file
.jar. In particolare specificando il file xml necessario alla configurazione di hibernate e le
librerie che dovranno essere presenti per implementare il componente server.

Deployment Diagram Compo-
nent
Considerando il componente Server, il riferimento è utile
per mostrare dove viene manifestato il server.jar in una vi-
sta di allocazione.
3.45 Vista architetturale [Module View Server Dettaglio]
3.46 Descrizione
La vista seguente presenta una module view, caratterizzata da uno stile a decomposi-
zione, d’uso e di generalizzazione/specializzazione. Descrive la struttura interna risul-
tante dalla progettazione di dettaglio del server.

3.47 Modello

NB Per una migliore visione rifarsi al progetto Visual Paradigm.
Sono presenti elementi non standard, per gli altri tipi di elementi rifarsi agli standard del
SEI.
Nome Stereotipo
testuale
Icona dello
stereotipo
Pattern Single-
ton
<<Pattern
Singleton>>
PS Una classe così stereotipata
indica che deve essere im-
plementata rispettando il
pattern singleton
Pattern State <<Pattern
State>>
pattern state
Database Wrap-
per
<<Database
Wrapper>>
DW Una classe in cui devono es-
sere inserite le informazioni
per effettuare l’ORM e le
operazioni CRUD.
3.48 Rationale
Questa vista viene mostrata per fornire una visione architetturale del sistema ad un basso
livello di dettaglio, in maniera tale da essere utilizzata dal team di sviluppo per pianifi-
care uno sviluppo incrementale dei componenti e farne una successiva integrazione in
base alle dipendenze d’uso. Inoltre, questa vista è anche pensata per la figura di chi fa
manutenzione o testing per pianificare come impattano gli effetti di una modifica sul re-
sto del sistema.

Vista a layer server di alto li-
vello
Permette di comprendere ad una maggiore astrazione il pat-
tern architetturale utilizzato per lo sviluppo.
ERD Offre un collegamento tra il package che contiene le classi
entità ed il modello di persistenza dei dati.
Decomposition view Permette di comprendere questa vista su quale parte del si-
stema si concentra. Collegamento che va verso il package
server.
C&C Client-Server Questa module view si rivela a run time con il componente
server.
C&C Multi Tier Mostra il raggruppamento topologico in tier delle classi del
server a run time.
Vista shared-memory Partendo dal package DBWrapper di questa vista, fornisce
una visione a run time delle interazioni tra i componenti
DBWrapper ed il componente database.
3.50 Vista architetturale [Module View Client Dettaglio]
3.51 Descrizione
La vista seguente presenta una module view, caratterizzata da uno stile a decomposi-
zione, d’uso e di generalizzazione/specializzazione. Descrive la struttura interna con cui
sono stati progettati i diversi client.

3.52 Modello
NB Per una migliore visione rifarsi al progetto Visual Paradigm
Sono presenti elementi non standard, per gli altri tipi di elementi rifarsi agli standard del
SEI.
Nome Stereotipo
testuale
Icona dello
stereotipo

Pattern State <<Pattern
State>>
patter state
3.53 Rationale
Questa vista fornisce una vista architetturale dei client ad un basso livello di dettaglio in-
dirizzata agli sviluppatori. Utile anche a chi fa manutenzione o testing, infatti, mette in
luce le varie dipendenze d’uso tra i vari componenti, di cui bisogna tenere conto per
eventuali modifiche o debugging sul sistema.
Vista a layer client di alto li-
vello
Permette di comprendere ad una maggiore astrazione il pat-
tern architetturale utilizzato per lo sviluppo.
Decomposition view Permette di comprendere questa vista su quale parte del si-
stema si concentra. Collegamento che va verso il package
client.
C&C Client-Server Questa module view si rivela a run time con i componenti
client dispositivo tavolo, postazione prenotazione, posta-
zione direzione.
C&C Multi Tier Mostra il raggruppamento topologico in tier delle classi dei
tre client a run time.

4 Beyond
4.1 Vista architetturale [Richiesta Posti Client – Client Side]
4.2 Descrizione
Questo sequence diagram descrive l’interazione dinamica del lato client ad un basso li-
vello di dettaglio nel caso della richiesta di un certo numero di posti.
4.3 Modello

Module view Client di Detta-
glio
In particolare al subsystem PostazionePrenotazione che
contiene classi e quindi metodi e attributi per realizzare il
caso d’suo.
Communication di analisi Ri-
chiesta Posti
Per avere un riferimento al diagramma di analisi che detta-
glia.

4.5 Vista architetturale [Assegna Posti– Server Side]
4.6 Descrizione
Questo sequence diagram descrive come avviene dinamicamente sul server l’assegna-
zione di un posto richiesto al dispositivo di prenotazione (notifica = 0) o una prenotazione
in attesa (notifica = 1).
Nota: Thread Posto è la classe che consente di lanciare un thread che dopo 5 minuti va a
liberare un posto non occupato.
4.7 Modello

Module view Server di Detta-
glio
In particolare al subsystem Server che contiene package,
classi e quindi metodi per realizzare il caso d’suo.
Sequence di analisi Assegna-
Posti
glia.
Thread Posto Server Side Mostra in dettaglio cosa avviene dopo l’istanziazione della
classe ThreadPosto

4.9 Vista architetturale [Thread Posto – Server Side]
4.10 Descrizione
Sequence diagram che descrive il timeout di 5 minuti, tempo a disposizione per occupare
il posto assegnato.
4.11 Modello
glio
In particolare al subsystem server che contiene package,
Sequence di analisi Assegna
Posti
glia.

4.13 Vista architetturale [Effettua Prenotazione – Server
Side]
4.14 Descrizione
Questo sequence descrive cosa avviene sul server nel caso in cui è necessario registrare una pre-
notazione. In caso di successo viene ritornato una variabile booleana settata a true, se ci sono
eventuali errori a false.
4.15 Modello

glio
Communication di analisi Ef-
fettua Prenotazione
glia.
4.17 Vista architetturale [Visualizza Stato Posti – Client
Side]
4.18 Descrizione
Sequence diagram che modella la richiesta di visualizzazione delle informazioni sui posti
(id posto, numero tavolo, tempo di occupazione) da parte di un dipendente della dire-
zione.
4.19 Modello

glio
In particolare al subsystem PostazioneDirezione che con-
tiene classi e quindi metodi e attributi per realizzare il caso
d’suo.
Sequence di analisi Visualizza
Stato Posti
glia.
4.21 Vista architetturale [Visualizza Posti Occupati da 15
Min – Client Side]
4.22 Descrizione
Sequence di dettaglio che descrive la richiesta di visualizzazione dei posti occupati da più
di 15 minuti.
4.23 Modello

glio
In particolare al subsystem PostazioneDirezione che con-
tiene classi e quindi metodi e attributi per realizzare il caso
d’suo.
Posti Occupati da 15 Min
glia.
4.25 Vista architetturale [Visualizza Stato Posti – Server
Side]
4.26 Descrizione
In questo sequence viene illustrato come sono recuperate le informazioni sui tavoli e i po-
sti. Per implementare il lato server sia della funzionalità visualizza stato posti che visua-
lizza posti occupati da 15 minuti.
4.27 Modello

glio
Stato Posti
glia.
4.29 Vista architetturale [Occupazione Tavolo – Client Side]
4.30 Descrizione
Sequence diagram che descrive l’occupazione del posto sul lato client. Il cliente inserisce
i codici di assegnazione e prenotazione, e se sono corretti gli viene mostrato il menù altri-
menti viene stampato un messaggio di errore.
4.31 Modello

glio
In particolare al subsystem DispositivoTavolo che contiene
package, classi e quindi metodi per realizzare il caso d’suo.
Communication di analisi Oc-
cupazione Tavolo
glia.

4.33 Vista architetturale [Occupazione Tavolo – Server Side]
Sequence diagram che descrive l’occupazione del posto sul lato server. Si riporta che
viene verificato il codice di assegnazione ed eventualmente quello di prenotazione se
l’assegnazione è associata ad una prenotazione. In base all’esito di questa verifica viene
fatto transitare lo stato del ControlState. L’id del posto viene passato dal client poiché
contenuto nel dispositivo posto.
4.34 Modello
glio

Communication di analisi Oc-
cupazione Tavolo
glia.

5 Conclusioni
Nel progettare questo sistema in fase di analisi ci siamo basati sul metodo COMET, svi-
luppando i diagrammi di analisi richiesti. Successivamente non è stato necessario co-
struire l’Integrated Comunication Diagram richiesto da COMET. Il criterio per suddivi-
dere in subsystem il sistema si è basato sulla loro localizzazione geografica.
Nella fase di progettazione seguendo l’approccio Views and Beyond proposto dal SEI, si
è deciso di mostrare le viste che mettevano maggiormente in risalto gli aspetti fondamen-
tali del nostro sistema. Aspetti come la struttura interna a layer del Client e del Server, la
relativa comunicazione Java RMI tra essi mostrata in una vista a C&C, fino ad arrivare
alle viste di allocazione che documentano l’hardware e gli ambienti di esecuzioni neces-
sari per implementare il nostro sistema.
Tutta l’implementazione del sistema è stata realizzata utilizzando tecnologie Java, come
le librerie Swing per le GUI. Il mapping ORM è stato realizzato attraverso il framework
Hibernate, mentre il DBMS scelto è stato MySQL. Queste tecnologie sono state scelte
nell’ottica di fornire un software che non richiedesse licenze a pagamento, così da ren-
derlo economicamente più appetibile al committente. Data la portata del progetto si è
scelto di non fare riuso di componenti già esistenti, ma tutto è stato implementato autono-
mamente.
Il Ciclo di sviluppo del sistema ha richiesto diverse settimane, perché per aderire meglio
ai requisiti del committente si è dovuto ritornare indietro in analisi. La modifica dei dia-
grammi di analisi ha reso necessario modificare tutti i diagrammi collegati.

Software Architecture Documentation - Fastfood

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Architecture Documentation - Fastfood

Similar to Software Architecture Documentation - Fastfood (20)

Software Architecture Documentation - Fastfood