Indiferent de metodologia de proiectare pe care îl utilizați, prima etapă de dezvoltare va fi formularea cerințelor produsului (Graddi Booch descrie Rational Unified Process [1] și Rosenberg - Iconix [2]). Un set de cerințe de produs este o sarcină tehnică. Cerințele sunt împărțite în (cerințe hardware, sisteme de operare, etc.) funcționale (de exemplu, sistemul vă permite să efectuați funcționalitatea dorită) și non-funcționale. UML a formaliza utilizarea diagramelor utilizate cerințe funcționale.
Diagrama cazurilor de utilizare, are sens să construiască în studiul tehnic al proiectului. ea constă într-o diagramă care descrie grafic actorii și cazurile de utilizare. iar caietul de sarcini este o descriere text a secvențelor specifice ale acțiunilor (Flow eveniment). utilizatorul efectuează atunci când se lucrează cu sistemul. Caietul de sarcini va deveni apoi baza pentru testare și documentare. și în următoarele etape de proiectare este completată și modelată sub formă de diagrame (in cadrul Iconix folosind o diagramă de secvență în UML, dar pentru aceasta, există, de asemenea, diagrame de activitate). În plus, diagrama caz de utilizare este destul de simplu ca s-ar putea înțelege clientul, astfel încât să puteți folosi pentru a se potrivi cu termenii de referință (deoarece diagramă descrie cerințele funcționale ale sistemului).
Utilizați diagrama sunt afișate:
În opinia mea, procedura cea mai corectă pentru construirea graficul de mai jos:
- grup select de actori (care lucrează cu sistemul în moduri diferite, de multe ori din cauza diferite drepturi de acces);
- să identifice cât mai multe opțiuni ca posibil să se utilizeze (procesele pe care utilizatorii pot efectua). Noi nu trebuie să împartă procesele prea mici, trebuie să alegeți doar cele care vor oferi utilizatorului un rezultat semnificativ. De exemplu, casierul poate „vinde bunuri“ (acest lucru va fi un precedent), dar „de introducere a codului de bare de produs pentru prețul“ nu este un precedent independent;
- completează precedente descriere verbală (script):
- pentru fiecare caz de utilizare pentru a crea partiții: „Secvența principală“ și „secvență alternativă“;
- în pregătirea script-ul trebuie să ceară insistent întrebările clienților „ce se întâmplă?“, „Ce urmeaza?“, „ce altceva se poate întâmpla?“ și să înregistreze răspunsurile acestora.
Luați în considerare dezvoltarea diagramelor folosesc exemplul de opțiuni - chiar și în cazul în care clientul ne-a dat următorii termeni de referință:
Scopul - dezvoltarea abilităților matematice la copii.
Platforma: Linux, Windows, Android.
funcționalitate:
Când porniți prima dată sistemul ar trebui să permită profesorului să introducă o parolă. Atributii sunt probleme matematice care implică adunarea, scăderea, înmulțirea și împărțirea. În unitatea sarcină poate fi orice tip de problemă (suma specificată). În plus față de tipul de operațiune de intrare efectuate în exemplul trebuie specificate intervalele admise de numere (sau numere chiar individuale, ca și în studiul tablei înmulțirii adesea predată mai întâi înmulțirea cu 2 și apoi la 5, și numai apoi restul). Mai mult decât atât, pentru operația de scădere trebuie să fie în măsură să stabilească Scăzător mai puțin Descăzut (în caz contrar rezultatul va fi negativ, iar numerele negative în școală testat mult mai târziu).
Evident, în ciuda faptului că clientul este descris în detaliu unele detalii, putem nu numai pentru a continua cu sarcina, dar chiar și o estimare aproximativă a costurilor și de sincronizare. Deoarece o astfel de sarcină nu este clar, de exemplu, că rapoartele ar trebui să conțină. Cu toate acestea, putem identifica imediat două grupuri de utilizatori, și câteva din activitățile lor.
Exemplu diagramelor
Liniile solide din diagramă reprezintă relația de asociere care să reflecte posibilitatea de a folosi precedentul actor. După cum a fost definită set de cazuri de utilizare, puteți începe elaborarea de scenarii. Scenariile trebuie descrise din punctul de vedere al utilizatorului, este important să se descrie interacțiunea utilizatorilor cu elementele de interfață. De exemplu, scenariu de înregistrare elev precedent ar putea arăta după cum urmează:
Nume precedent: înregistrarea studenților
Actor: profesor
Scop: pentru a adăuga un student la sistem, primind parola
- Profesorul selectează elementul de meniu principal „add student“;
- sistemul afișează un profesor fereastră adăugarea de câmpuri elev cuprinzând pentru introducerea unui nume de utilizator și parola I și butoanele „Next“ și „înapoi“;
- profesorul introduce numele de utilizator dorit și parola de student apasă pe butonul „Next“;
- sistemul adaugă student;
- Cadrele didactice deschide meniul principal și în 5 secunde, sunteți notificat că studentul a fost adăugat cu succes.
secvență alternativă (a reveni la meniul principal fără adăugarea studentului):
- Profesorul selectează elementul de meniu principal „add student“;
- sistemul afișează un profesor fereastră adăugarea de câmpuri elev cuprinzând pentru introducerea unui nume de utilizator și parola I și butoanele „Next“ și „înapoi“;
- profesorul apasă butonul „înapoi“;
- Cadrele didactice deschide meniul principal (datele introduse în formă de ferestre adăugarea de student nu este salvat).
secvență alternativă (adăugarea unui elev, deja disponibil în sistem):
- Profesorul selectează elementul de meniu principal „add student“;
- sistemul afișează un profesor fereastră adăugarea de câmpuri elev cuprinzând pentru introducerea unui nume de utilizator și parola I și butoanele „Next“ și „înapoi“;
- profesorul introduce numele de utilizator dorit și parola de student apasă pe butonul „Next“;
- notificare profesor este afișat timp de 5 secunde, că numele de utilizator solicitat este ocupat.
În mod similar, toate precedentele trebuie să fie precizate, ilustrată pe diagrama. Script-uri trebuie să fie suficient de greu pentru a descrie toate acțiunile posibile ale utilizatorilor din sistem. Clientul poate face acest lucru cu mare plăcere, ca un programator în detrimentul mai devreme găsește posibile cerințele clientului (ca în scenariul de mai sus, s-ar putea afla că programul ar trebui să afișeze o notificări de tip pop-up).
În ciuda simplitatea scenariului de mai sus, în secvențele sale pot fi găsite dublarea, în cazul în care are loc în script-urile dvs. - puteți alege câteva fragmente de descriere în unele precedente (care poate fi atât individual, cât și doar fac parte din alte utilizări). În același timp, între cazuri de utilizare va fie raportul de expansiune (extinde), sau activați (includ). care sunt afișate în diagrame (o relație de generalizare UML, de asemenea, există și în LMG - apel și prioritate).
Relația de incluziune în utilizarea diagrama
Raportul de expansiune în utilizarea diagrama
Cele mai frecvente erori în construcția de acest tip sunt diagrame:
- extinderea utilizării abuzive a relațiilor și de incluziune, inclusiv încercările de a folosi diagrama pentru o descompunere funcțională a sistemului. Ea provine dintr-o neînțelegere a diferențelor dintre aceste două tipuri de relații, și că diagrama caz de utilizare ar trebui să exprime numai cerințele de sistem, dar nu și detaliile punerii sale în aplicare;
- Dezvoltarea diagramei cu perspectiva unui programator, nu al utilizatorului. Scenariile ar trebui folosite nume de controale (vizibile pentru utilizator), dar indezirabil reprezintă detaliile de implementare (cum ar fi managerul de evenimente) nu este clar pentru client;
- nu este suficient de studiu al scenariilor:
- lipsa sau numărul insuficient de secvențe alternative în care trebuie să fie luate în considerare, inclusiv, introducerea incorectă a datelor în sistem;
- Descriere Acțiune utilizator fără a specifica elementele interfeței sistemului și lipsa de descriere a scenariilor de reacție a sistemului.
Este important ca procesul de Iconix este iterativ, așa că, dacă ați făcut o greșeală în etapa de dezvoltare a utilizării diagramelor - acestea pot fi găsite și corectate în următoarele etape (în special obiectele care lipsesc pot fi recuperate atunci când se lucrează la graficele de robustețea și scenarii elaborate în diagramele de construcție secvență).
Dacă urmați toate regulile de date diagrame utilizare caz, acestea pot fi folosite pentru a lucra în termenii de referință suficient de detaliat pentru a estima timpul și costul punerii sale în aplicare, descrie scenariile specifice de interacțiune cu sistemul, care va forma baza de teste și a documentației. și să coordoneze toate acestea cu clientul.
Articolul descrie principalele caracteristici ale diagramelor caz de utilizare. în opinia mea, ar trebui să fie suficient pentru dezvoltarea de marea majoritate a sistemelor, cu mai multe informații, dacă este necesar, și exemple pot fi găsite în următoarele referințe: