Documentatie Proiect Pizzerie

Alexandru Pele Grupa 225/2

1. Cerina problemei
O pizzerie foloseste o aplicatie pentru gestiunea tuturor comenzilor. Fiecare chelner
foloseste o fereastra prin care poate adauga o noua comanda (nr_masa, tip_pizza,
nr_bucati, ora). Atunci cand o comanda este finalizata, chelnarul o poate vedea intr-o lista
de comenzi finalizate care apare si in fereastra sa.. Aplicatia are o fereastra <Pizzerie>, in
care se afiseaza o lista cu toate comenzile (fiecare comanda este precedata de numele
chelnerului), o lista cu toate comenzile finalizate si o lista cu toate comenzile platite. Dupa
ce clientii platesc pentru o comanda chelnarul marcheaza acest lucru si acea comanda se
adauga in lista de comenzi platite si va fi stersa din celelalte liste. Bucatarul foloseste o
fereastra <Bucatarie> , in care vede toate comenzile in asteptare si atunci cand bucatarul
finalizeaza o comanda, acesta selecteaza comanda din lista de comenzi si o marcheaza ca
fiind terminata; ca urmare a acestei marchari comanda se va sterge din lista de comenzi in
asteptare si se va adauga in lista cu comenzi finalizate. Se va actualiza automat si in lista
chelnarului care a introdus-o. Numele chelnarilor se citesc dintr-un fisier text si toate
comenzile, finalizate sau nu, se salveaza astfel incat informatia sa poate fi folosita ulterior.
2. Funii de baz
Ref.

Funcie

Categorie

Adaug comand (numr mas, tip pizza,

numr bucai)

Evident

Adaug un nou chelner n sistem

Evident

terge unul dintre chelnerii din sistem

Evident

Iniializeaz un mediu nou pentru chelner

Ascuns

Obine lista cu comenzi cu un anumit status Evident

(finalizate, n ateptare, pltite)

Schimb statusul unei comenzi

Evident

Furnizeaz un mecanism de stocare

persistent

Ascuns

Furnizeaz un mecanism de comunicare

ntre ferestre

Ascuns

3. Cazuri de testare
Operaiile care nu apar n diagrama cazurilor de testare sunt cele prin care se
iniializeaza sistemul. Acestea sunt:
ncrcarea datelor (chelneri i comenzi) din fiierele n care au fost serializate n
momentul lansarii n execuie
deschiderea de ctre sistem a ferestrelor pentru Pizzerie i Buctarie
serializarea (binar) a datelor n vederea obinerii persistenei

A. Diagrama UML pentru cazuri de utilizare

1)
2)
3)
4)
5)

B. Descrierea evenimentelor tipice

Unul dintre chelneri creeaz o comand. La creere, statusul acestei comenzi n
ateptare.
n fereastra sa, buctarul vede lista tuturor comenzilor care sunt n ateptare. Pe
msura ce acestea sunt pregatite, ele vor fi marcate de buctare ca finalizate.
napoi n fereastra clientului, acesta poate vedea toate comenzile care au fost
finalizate de buctar, n vederea servirii clienilor.
Odat platit, comanda este marcat de ctre chelner cu statutul de platit
n tot acest timp, n fereastra Pizzerie, administratorul poate urmari toate comenziile
din sistem i poate terge o comanda dac e nevoie.

4. Diagrama UML a claselor

Proiectarea aplicaiei a fost realizat avnd n vedere urmtoarele abloane de
proiectare:
Observer, prin IObserver, IObservable
Repository, prin ObservableFileRepository, care e un repository n fiier generic,
serializarea datelor fcndu-se binar.
Model View Controller (MVC)

5. Particulariti ale limbajului C#

Pe parcursul implementrii proiectului, s-au folsit mai multe clase din API (.NET),
printre care se numar:
List din System.Collections.Generic, ntruct dezvoltarea unei structuri de date
noi era n afara scopului acestui proiect
FileInfo i FileStream din System.IO i clasa BinaryFormatter din
System.Runtime.Serialization n vederea realizrii persistenei aplicaiei (mai
concret, pentru serializare i deserializare binar)
Un alt lucru care merit menionat este diferena fa de felul n care sunt
implementate clasele generice n Java. n C# se folosete un mecanism de tip client server,
spre deosebire de metoda type-erasure din Java. Acest lucru duce la mici diferen e n
implementarea claselor generice.