UML Unified Modeling Language [18] (Unified Modeling Language) este un limbaj de determinare, raportare și sisteme software de proiectare de documente, sisteme organizaționale și economice, sistemele tehnice și alte sisteme de natură diferită. UML este un set standard de diagrame si notatii ale celor mai diverse specii.
· Furnizați utilizatorilor gata să folosească un limbaj expresiv de modelare vizuala, ceea ce le permite să se dezvolte modele semnificative și să le împărtășească;
· Furnizarea de mecanisme de extensibilitate și de specializare pentru a extinde conceptele de bază;
· Asigurarea independenței particularului limbaje de programare și a proceselor de dezvoltare;
· Oferă o bază formală pentru înțelegerea limbajului de modelare (limba trebuie să fie atât de precisă și ușor de înțeles, fără un formalism excesiv);
· Stimula creșterea pieței de instrumente orientate spre obiect;
· Integrarea cea mai bună experiență.
UML este în procesul de standardizare, deținută de OMG (Object Management Group) - Organizația pentru Standardizare în domeniul metodelor și tehnologiilor orientate pe obiecte, care sunt acceptate în prezent ca limbă de modelare standard si a beneficiat de sprijin larg în industria de software. UML adoptat de aproape toate marile companii - furnizori de software (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase, etc). În plus, aproape toți producătorii mondiali de CASE-înseamnă, în plus față de IBM Rational
· Structurală (structural) Model:
diagrama de clase (diagrame de clase) - pentru modelarea structurii statice a claselor de sistem și relațiile dintre ele; Diagrama de componente (diagrame componente) - pentru modelarea ierarhiei componente (subsisteme) ale sistemului;
Diagrama de plasare (diagrame de implementare) - pentru simularea unei arhitecturi de sistem fizic.
· Modele de comportament (de comportament):
Utilizați caz diagrame (diagrame caz de utilizare) - pentru modelarea proceselor de afaceri și cerințele funcționale ale sistemului creat; diagrame de interacțiune (diagrame interacțiune):
diagramă secvență (diagrame de secvență) și scheme de cooperare (diagrame de colaborare) - pentru a simula schimbul de mesaje între obiecte de proces;
diagrame de stare (diagrame statechart) - facilități pentru modelarea comportamentului sistemului în timpul tranziției de la un stat la altul;
diagrame de activitate (diagrame de activitate) - pentru a simula comportamentul sistemului în diferite cazuri de utilizare, sau fluxuri de control.
Diagramele OPȚIUNI UTILIZARE
Ideea de a descrie cerințele funcționale în formă de cazuri de utilizare (utilizare caz) a fost formulată în 1986 de către Ivar Jacobson. Această idee a fost recunoscută ca fiind constructivă și a câștigat acceptarea pe scară largă. Ulterior, cea mai importantă contribuție la rezolvarea problemei de determinare a naturii utilizării opțiunilor și modalități de a le descrie făcut Alister Kobern [19].
Utilizați caz este o secvență de acțiuni (tranzacții) efectuate de către sistem, ca răspuns la un eveniment declanșat de un obiect exterior (actor). Utilizați caz descrie o interacțiune tipică între utilizator și sistemul și reflectă înțelegerea comportamentului sistemului dintr-o perspectivă de utilizator. În cel mai simplu caz, cazul de utilizare se determină în procesul de discuție cu utilizatorul funcțiilor pe care le-ar dori să pună în aplicare, sau obiectivele pe care le exercită, în ceea ce privește sistemul în curs de dezvoltare.
Actor (actor) - acesta este rolul pe care un utilizator joacă în ceea ce privește sistemul. Actorii sunt roluri, oamenii nu specifice sau nume de lucrări.
În ciuda faptului că utilizează diagrame caz sunt afișate sub forma unor figuri umane stilizate, actorul poate fi, de asemenea, un sistem extern care are nevoie de unele informații din sistem.
Caracterele sunt împărțite în trei tipuri principale - utilizatori ai sistemului, alte sisteme care interacționează cu aceasta, și de timp. Timpul devine un actor, în cazul în care determină începerea oricărui eveniment din sistem.
Pentru o reprezentare vizuală a cazurilor de utilizare utilizate caz diagrame de utilizare. Fig. 2.47 prezintă un exemplu de o astfel de diagramă pentru sistemul bancar.
Fig. 2.47. Diagrama Exemplu caz de utilizare
Utilizarea Cauza Diagrama arată interacțiunea dintre cazurile de utilizare și actorii. Aceasta reflectă cerințele funcționale ale sistemului din perspectiva utilizatorului. Astfel, cazurile de utilizare - o funcție îndeplinită de către sistem, iar actorii - este părțile interesate (stakeholders) în ceea ce privește sistemul creat. Aceste diagrame arată care actorii inițiați caz de utilizare. Printre ei este, de asemenea, evident atunci când actorul primește informații de la caz de utilizare. Regizat de cazul de utilizare a săgeții indică faptul că actorul caz de utilizare furnizează unele informații utilizate actor. În acest caz, opțiunea de a utiliza „Efectuați o plată“ oferă informații sistemului de credite de plată prin card de credit.
Actorii pot juca roluri diferite în ceea ce privește cazul de utilizare. Ei pot beneficia de rezultatele ei înșiși participă direct în ea. Semnificația diferitelor roluri ale unui actor depinde de modul în care utilizează legăturile sale.
Scopul construirii diagramelor de caz utilizare - Documentarea cerințelor funcționale pentru sistemul în forma sa cea mai generală, astfel încât acestea trebuie să fie extrem de simplu. La construirea diagramelor de caz de utilizare trebuie să respecte următoarele reguli:
• Nu simula comunicarea între actorii. Prin definiție, caracterele sunt în afara domeniului de aplicare a sistemului. Acest lucru înseamnă că comunicarea dintre ele nu este, de asemenea, de competența sa.
· Nu conectați cele două utilizări de săgeată în sine. Diagramele de acest tip se descrie doar cazuri de utilizare, mai degrabă decât ordinea de execuție a acestora. Pentru a afișa ordinea de execuție de utilizare este utilizat pentru această activitate diagrame.
· Fiecare utilizare ar trebui să fie inițiat de un actor. Acest lucru înseamnă că trebuie să existe întotdeauna un shooter, începând de pe față și se termină cu versiunea curentă de a utiliza.
O sursă bună pentru identificarea cazurilor de utilizare a servi ca evenimente externe. Acesta ar trebui să înceapă cu o listă a tuturor evenimentelor care au loc în lumea exterioară, la care sistemul trebuie să răspundă într-un fel. Orice eveniment special, poate avea ca rezultat un sistem de reacție care nu necesită intervenția utilizatorului, sau, dimpotrivă, provoacă un răspuns de utilizator curat. Identificarea evenimentelor care trebuie să răspundă la AP, pentru a ajuta la identificarea cazurilor de utilizare.
Diagrama cazurilor de utilizare este cea mai frecventă reprezentare a cerințelor funcționale ale sistemului. Cu toate acestea, modelare de utilizare caz nu este vorba doar de desen diagrame. Pentru sistemul ulterioare de proiectare necesită mai multe detalii specifice. Aceste detalii sunt descrise într-un document numit „scenariu de utilizare caz“ sau „flux de evenimente» (flux de evenimente). Scopul fluxului de evenimente este o documentație detaliată a interacțiunii actor cu sistemul implementat în cadrul cazului de utilizare. Fluxul de evenimente ar trebui să fie descrise tot ceea ce servește pentru a satisface cererile actorilor.
Deși fluxul de evenimente și descrise în detaliu, de asemenea, nu trebuie să depindă de punerea în aplicare. Scopul - pentru a descrie sistemul chtobudet nu kakona o va face. De obicei, fluxul de descrierea evenimentelor cuprinde următoarele secțiuni:
· Fluxul principal al evenimentelor;
· Fluxuri alternative de evenimente;
Consistently uita la aceste componente.
Scurtă descriere. Fiecare caz de utilizare ar trebui să aibă o scurtă descriere a ceea ce se întâmplă în ea. De exemplu, opțiunea de a folosi „bani de transfer“ poate conține următoarea descriere.
Opțiunea de a folosi „bani de transfer“ permite clientului sau angajat al băncii de a transfera bani dintr-un cont la cerere sau cont de economii la alta.
Precondiții. O condiție prealabilă pentru utilizarea - acestea sunt condițiile care trebuie îndeplinite înainte ca un caz de utilizare va fi el însuși executat. De exemplu, această condiție poate fi executarea unei alte variante de utilizare sau utilizatorul are drepturi de acces care sunt necesare pentru a începe. Nu toate cazurile de utilizare sunt condiții prealabile. Am menționat mai devreme că utilizarea de caz diagrame nu reflectă ordinea de execuție a acestora. Astfel de informații pot fi descrise cu ajutorul precondiții. De exemplu, o condiție prealabilă pentru utilizarea un exemplu de realizare poate fi faptul că acesta trebuie să fie efectuată în celălalt timp.
Fluxurile principale și alternative de evenimente. Detalii specifice pentru această utilizare sunt descrise în general în fluxurile de evenimente alternative. Fluxul de evenimente descrie etapele pe care ar trebui să apară în timpul utilizării opțiunilor stabilite în funcționalitate. Fluxul de evenimente acordă o atenție la ceea ce va face sistemul, dar nu și modul în care se va face, și descrie toate acestea, din punctul de vedere al utilizatorului. Fluxul principal al evenimentelor descrie cursul normal al evenimentelor (fara erori), iar în cazul în care există mai multe variante posibile ale cursului de evenimente pot fi ramificate la fluxul de sclavi (subflow). fluxuri alternative descrie abaterea de la cursul normal al evenimentelor (condiții de eroare) și de prelucrare a acestora. De exemplu, fluxurile variante de evenimente folosind „retrage bani din contul“ ar putea arăta astfel:
Fluxul principal al evenimentelor
1. Cazul de utilizare începe atunci când un client introduce cartela sa într-un bancomat.
2. ATM afișează un mesaj de salut și solicită consumatorului să introduceți PIN-codul personal.
3. Clientul introduce codul PIN.
4. ATM confirmă codul introdus.
5. ATM afișează o listă de acțiuni disponibile: a face un depozit, retrage bani, transfer de bani
6. Clientul selectează „retrage bani din cont.“
7. ATM întreabă câți bani ar trebui să fie eliminate.
8. Clientul introduce suma necesară.
9. ATM determină dacă există suficienți bani în cont.
10. ATM deduce suma necesară din contul clientului.
11. ATM ofera clientului cu suma necesară de bani.
12. card de ATM revine la client.
13. ATM imprimă o chitanță pentru client.
14. Un caz de utilizare se termină.
flux alternativă a evenimentelor 1. Introducerea unui cod PIN incorect.
4A1. ATM informează clientul că codul este introdus incorect.
4a2. ATM returnează cardul la client.
4aZ. caz de utilizare se termină.
2. Un flux alternativ de evenimente nu este suficient de bani într-un cont.
9A1. ATM informează clientul că banii în contul său nu este de ajuns.
9a2. ATM returnează cardul la client.
9aZ. caz de utilizare se termină.
flux alternativă a evenimentelor 3. eroare în confirmarea sumei solicitate.
9B2. ATM intră informații despre eroare în jurnalul de erori. Fiecare intrare include data și ora defecțiunii, numele clientului, numărul de cont, precum și codul de eroare.
9b3. ATM returnează cardul la client.
9b4. caz de utilizare se termină.
• folosiți propoziții simple;
· Indică în mod clar pentru fiecare element, care efectuează acțiunea - actorul sau sistem;
· Nu afișați prea puțină acțiune;
· Nu afișați acțiunile utilizatorului detaliat în timp ce lucrează cu interfața cu utilizatorul;
· Să nu ia în considerare condițiile posibile de eroare (Acțiuni pe „Confirm“ și nu „check“).
Atunci când se identifică fluxurile de evenimente alternative trebuie să acorde o atenție mai întâi la situații care implică:
· Acțiuni de utilizator incorect (de exemplu, o parolă greșită);
· Omiterea personajului (de exemplu, parola timeout de expirare);
· Erori interne în sistem în curs de dezvoltare, care trebuie să fie detectate și prelucrate în mod obișnuit (de exemplu, blocat bancomatului);
· Deficiențe critice în performanța sistemului (de exemplu, timpul de răspuns nu se încadrează în 5 secunde).
Postconditii. Postconditii sunt acele condiții care ar trebui să fie întotdeauna efectuate după finalizarea cazului de utilizare. De exemplu, puteți să marcați caseta de selectare a oricărui comutator la sfârșitul cazului de utilizare. Acest tip de informație face parte din post-condiții. Ca condiții prealabile pentru utilizarea post-condiții puteți introduce informații despre ordinea exemplelor de realizare a sistemului. Dacă, de exemplu, după unul dintre cazurile de utilizare trebuie să fie întotdeauna diferite, acesta poate fi descris ca un postconditie. Aceste condiții nu sunt în fiecare caz de utilizare.
Extensii. Acest element este prezent, în cazul în care în mare parte de evenimente homo-ke apar tuatsii B relativ rare (cazuri speciale). O descriere a unor astfel de situații impuse în prezentul alineat.
Utilizarea de caz diagrame pot fi prezența unui TVA mai multe tipuri de conexiuni. Aceste legături de comunicare (comunicare), activați (includ), extinde (extinde) și generalizare (generalizare).
Comunicare Comunicare - este utilizată este legătura dintre varianta, Bani si actor, ea este reprezentată de-DO nonapravlennoy Association (linia săgeată). direcția săgeții vă permite să înțelegeți cine inițiază comunicarea.
comutare de comunicare este utilizat în situațiile în care există orice comportament radical al sistemului (o parte a fluxului Soby un lagăr), care se repetă mai mult de o opțiune este utilizată-vanija. Cu astfel de conexiuni sunt de obicei modelate folosite-mnogokrat dar funcționalitatea. În exemplul opțiunilor sistemului bancar utilizând „retrageți bani dintr-un cont“ și „face un depozit“ trebuie să autentifice clientul și PIN-codul său înainte de a permite punerea în aplicare a tranzacției în sine. În loc de o descriere detaliată a procesului de autentificare pentru fiecare dintre cazuri de utilizare, puteți pune această opțiune în cazul său propriu de utilizare numit „autentificat de către client.“
expansiune Comunicarea se aplică atunci când există modificări în comportamentul normal al sistemului (așa cum este descris în paragraful „Extended-TION“), care sunt de asemenea luate într-o realizare separată folosește-vanija.
Comunicare privind și să extindă prezentat ca dependența punte, așa cum se arată în Fig. 2,48.
Fig. 2,48. Comunicare privind și să extindă
Odată cu generalizarea comunicării arată că există asemănări și deosebiri între mai mulți actori. De exemplu, angajații organizației sunt proprietatea comună și diferite metode de remunerare (Fig. 2.49).
Nu este nevoie de a crea întotdeauna o conexiune de acest tip. În general, acestea sunt necesare, în cazul în care diferențele în comportamentul actorului de același tip de comportament afectează alte funcții ale sistemului. În cazul în care nu este necesară atât subtipuri, folosind aceleași cazuri de utilizare, care prezintă o generalizare a actorului.
Utilizați cazuri sunt un instrument necesar în etapele de formare a cerințelor software. Fiecare caz de utilizare - acest potențiale
Fig. 2,49. Generalizarea actor
cerință socio pentru sistem, și în timp ce acesta nu este dezvăluit, este imposibil de a planifica pentru punerea sa în aplicare.
Diferite dezvoltatorii sunt potrivite pentru descrierea cazurilor de utilizare cu diferite grade de detaliu. De exemplu, Ivar Jacobson a susținut că complexitatea proiectului cu 10 de ani-om de numărul de cazuri de utilizare poate fi de aproximativ 20 (fără a include conexiuni „la“ și „expansiune“). Ar trebui să fie preferat să mici și detaliate cazurile de utilizare, deoarece acestea facilitează pregătirea și punerea în aplicare a planului de proiect convenit.
Avantajele utilizării variante a modelului constă în faptul că:
· Determină utilizatorilor și a sistemului limita;
· Definește interfața sistemului;
· Convenabil pentru utilizatori pentru a comunica cu dezvoltatori;
· Utilizat la teste de scris;
· O bază pentru scrierea documentației de utilizare;
· Se potrivește bine în orice tehnici de proiectare (cum ar fi și structurat orientat obiect).