Proiectarea si documentarea aplicatiilor software

Proiectarea si documentarea aplicatiilor software

sunt oferite modele de dezvoltare a unui produs software

metode orientate pe obiecte;

etapele prin care se dezvolta aceste elemente → proces → prezentate printr-un limbaj de proiectare.

UML - Unified Modeling Language (Limbaj de Modelare Unificat) → limbaj de model prin care se poate specifica, documenta si proiecta un sistem software orientat pe obiecte.

Etapele de baza de dezvoltare a unui produs software

analiza si specificatia cerintelor

designe (proiectare);

implementare;

testare;

mentenanta.

Prezentarea UML: contine elemente grafice si elemente textuale.

Exista noua tipuri de diagrame:

1.     diagrame de cazuri de utilizare;

2.     diagrame de clase;

3.     diagrame de interactiune de colaborare;

4.     diagrame de interactiune de secventa;

5.     diagrame de obiecte;

6.     diagrame de stare;

7.     diagrame de componente;

8.     diagrame de activitate;

9.     diagrame de flux.

1. Diagrama de cazuri de utilizare.

Utilitare

CASE - Componente Aideal Software Ingineering (Inginerie Software Asistata de Calculator)

Scopul - se alege un scenariu.

1. Specificarea cerintelor cuprinde descrierea textuala a unui scenariu.

Exemplu Firma SRL doreste sa-si dezvolte un soft pentru gestionarea vanzarilor de calculatoare

Se descrie studiul de caz

1.     softul va trebui sa tina evidenta clientilor magazinului, va memora date despre un client - cod, nume, adresa de e-mail.

2.     va trebui sa mentina intr-o baza de date, date despre un produs - cod, nume, pret.

3.     fiecare client are la dispozitie un cos de cumparaturi si clientul va putea efectua mai multe comenzi care sunt introduse in cos.

Administratorul sistemului se ocupa cu introducerea, eliminarea si actualizarea clientilor si produselor.

Exemplu:

Diagrame de cazuri de utilizare:

- isi propune sa identifice utilizatorii care folosesc produsul nostru;

in functie de ceea ce fac utilizatorii nostrii sunt de mai multe categorii

1) actori - joaca mai multe roluri in sistem.

Cum va folosi softul si ce va trebui sa faca cu el?

Printr-un actor se specifica o clasa de utilizatori ai sistemului pentru care se stabilesc o serie de cazuri de utilizare.

In UML actorul se deseneaza   si primeste un nume

Exemplu:

2) pentru cazuri de utilizare - este un task, o sarcina efectuata de un actor caruia i se atribuie un nume.

Exemplu un client poate efectua o comanda (cumpara un produs)

Nume caz de utilizare               Ex: un client efectueaza o comanda

Identificarea actorilor si specificarea cazului de utilizare:

Efectueaza comanda Adauga client

Adauga produs in cos Adauga produs

Administrator

Elimina produs din cos Elimina client

Client

Goleste cos Elimina produs

Calculeaza pretul produsului din cos

Listeaza datele despre un produs

2. Rafinarea diagramei - Relatii intre cazuri de utilizare - se trece la identificarea relatiilor intre doua sau mai multe cazuri de utilizare - relatiile sunt de tip INCLUDE si EXTENDE.

Relatiile de tip INCLUDE - un sistemul in care doua sau mai multe cazuri de utilizare au in comun o secventa de scenarii se alege ca secventa respectiva de scenarii sa devina un nou caz de utilizare ce va fi inclus de respectivele cazuri de utilizare

Relatiile de tip EXTENDE - sunt al doilea tip de relatii. Printr-o relatie EXTINDE se specifica o situatie de exceptie care poate sa apara la realizarea unui caz de utilizare. Situatia de exceptie se va reprezenta printr-un nou caz de utilizare care va extinde cazul de utilizare principal.

efect comanda <include> cauta produs in sistem

adauga produs in cos

elimina produs din cos <extende> refuza comanda

goleste cos

calculeaza pretul produsului din cos

Se implementeaza astfel if (nu exista produs in sistem)

refuza comanda

La adauga comanda in cos va aparea adauga comanda in cos

· la cautarea produsului in sistem

punct de extensie

3. Delimitarea sistemului - se desemneaza o bariera intre actori si cazuri de utilizare printr-un ..

STRUCTURA STATICA - Diagrama de Clasa

Sistemul software poate fi vazut din doua unghiuri static si dinamic.

Punct de vedere static se refera la structura de clase a sistemului. Orice program orientat pe obiecte este alcatuit dintr-o multime de clase si asocierile dintre aceste clase.

Diagrama de clase - se specifica structura de clasa a sistemului prin modul in care interactioneaza obiectele.

→ TEHNICA IDENTIFICARII SUBSTANTIVELOR (Analiza textuala) - se studiaza specificarea cerintelor si se identifica substantivele si constructiile cu rol de substantive din text.

→ Dintre substantivele specificate sunt eliminate cele care nu au legatura cu sistemul pe care vrem sa-l dezvoltam.

→ Din multimea de substantive ramase se aleg cele care se refera strict la sistemul pe care vrem sa-l dezvoltam si vor deveni clase candidate.

Desenarea unei clase in UML

Cum se declara un atribut si o operatie

Specificatorii de acces:            + public;

- private;

# protected;

sa: nume_op([lista_org]):tip returnat

+ adauga Comanda(p:Produs, c:int): void scris in UML

Clasele sistemului       - Produs, Client, Comanda, Cos, Magazie

Generare de cod - specifica scheletul clasei intr-un limbaj de programare.

Asocieri intre clase. Pentru a se realiza comunicarea intre clase este necesar sa o asociem intre legaturi. Doua clase sunt asociate (A si B) daca obiectul din clasa A trebuie sa aiba cunostinta despre obiectele din clasa B.

► = asociere

Pentru asociere se specifica un nume ► (cu acest semn se specifica cum cum se citeste asocierea). Pentru obiectul nostru avem:

Pentru asociere se mai poate stabili si are ordin de multiplicitate (numar de obiecte din fiecare clasa care participa la asociere).

Multiplicitatea se scrie la fiecare capete ale elementelor asociate sau se scrie o cifra cu interval. 1 . . 5

- multiplicitate  mai multe

0 . . x    - nici unul sau mai multe

1 . . x    - cel putin unul sau mai multe.

Navigabilitate - se pot trimite mesaje de la obiecte B , dar nu invers. Obiectele au mesaje.

Cand sunt asociate 2 clase A si B?

Atunci cand

→ un obiect din clasa B este variabila membru de tip referinta pentru clasa A. Numele asocierii va coincide cu numele referintei respective

→ atunci cand un obiect din B apare ca parametru pentru o functie membra care se afla in clasa B;

→ cand un obiect din B apare ca variabila locala intr-o functie membra din A

Avem doua tipuri de asocieri

agregare;

compunere.

Sunt cazuri particulare de asociere prin care se specifica o relatie de tip parte-intreg intre doua clase (o parte apartine la un intreg sau un intreg este format din mai multe parti).

Agregarea - modul general de specificare a unei relatii de tip parte intreg.

Intreg Parte

Citim B face parte din A.

Exemple:

1)

2)

3)

Compunerea este un tip de agregare mai puternica. Solutia intre parte si intreg este mult mai stransa. Daca este distrus intregul sau creat odata cu el se distruge si se creeaza si partea.

Partea nu este desine statatoare.

Exemplu:

La comparare multiplicitatea este 0 sau 1. (se deseneaza cu un romb catre intreg, dar este un romb umplut - negru)

Generalizarea este un tip de relatie intre clase prin care se specifica faptul ca o clasa are atribute si operatii ce sunt comune pentru mai multe clase, clase care se numesc specializari ale clasei respective. Se spune ca specializarile mostenesc atributele si operatiile clasei generale.

A - clasa generala si B, C - clase speciale

Fie clasa Persoana -     o extind prin clasa client si sistemul mai are o clasa Administrator

Desenam diagrama de clase (complet):

1

1

Atributele si operatiile pentru fiecare clasa - se complecteaza pe diagrama.