Förtydliga systemfunktionernas beskrivning med hjÀlp av en sekvensdiagram (fortsÀttning "Ekorren")
I denna artikel kommer vi att diskutera hur man kan specificera (förtydliga) beskrivningen av den automatiserade funktionen med hjÀlp av UML-sekvensdiagrammet.
I detta exempel anvÀnder jag miljön Enterprise Architect frÄn det australiensiska företaget [1].
Den fullstÀndiga specifikationen av UML finns i. [2].
Först ska jag förklara vad vi kommer att specificera.
I Vi modellerade processerna i det "sagolika" ÀmnesomrÄdet - raderna om ekorren frÄn "Sagan om tsar Saltan" av A.S. Pusjkin. Och vi började med aktivitetsdiagrammet. Sedan i utvecklade vi en funktionell modell med hjÀlp av use-case-diagrammet, fragment av detta visas i Figur 1.
Figur 1. Relation mellan krav och funktion
Nu vill vi förtydliga informationen om genomförandet av den automatiserade funktionen:
- vilka grÀnssnittsdelar vÄr anvÀndare kommer att interagera med;
- vilka styrkomponenter vi behöver;
- vad vi kommer att lagra;
- vilka meddelanden som kommer att utbytas mellan anvÀndaren och systemkomponenterna för att genomföra funktionen.
De huvudsakliga elementen i sekvensdiagrammet Àr interagerande objekt med olika stereotypier och relationer mellan dem - interagerande objekt utbyter viss information med varandra (Figur 2).
Figur 2. Huvudelementen i sekvensdiagrammet
Objekten Àr placerade i horisontell sekvens, meddelanden överförs mellan dem. Tidsaxeln Àr orienterad uppifrÄn och ner.
Elementet Actor kan anvÀndas för att representera en anvÀndare som initierar hÀndelseflödet.
Varje objekt har en prickad linje, kallad "livslinje", dÀr detta element existerar och potentiellt deltar i interaktioner. Kontrollpunkten markeras med en rektangel pÄ objektets livslinje.
Meddelanden som utbyts mellan objekten kan vara av flera typer, och meddelandena kan ocksÄ anpassas för att Äterspegla operationer och egenskaper hos de ursprungliga och mÄlobjekten.
Stereotypiska element, sÄsom grÀnser (Boundary), styrobjekt (Control) och entiteter (Entity), kan anvÀndas för att modellera anvÀndargrÀnssnittet (GUI), kontroller och databasobjekt, respektive.
En Äterkommande meddelandeflöde kan anges som ett fragment med typen "loop".
SÄ, vi planerar att specificera beskrivningen av funktionen "LÀgg till information om den nya nötter i registret".
Vi kommer överens om följande ytterligare sammanfattningar och antaganden.
- Nötter, kÀrnor och skal Àr alla materiella tillgÄngar av motsvarande typer (Figur 3).
Figur 3. Förtydligande av klassdiagrammet - I protokollet kommer vÄr anvÀndare att registrera information om alla materiella tillgÄngar.
- LĂ„t oss specifisera namnet pĂ„ protokollet â "Protokoll för materiella tillgĂ„ngar".
- Anta att vÄr anvÀndare, nÀr denne arbetar med GUI "Protokoll för materiella tillgÄngar", kan lÀgga till en ny materiell tillgÄng via GUI "Konto för materiell tillgÄng".
- Beroende pÄ typen av materiell tillgÄng Àndras databasstrukturen och GUI.
- Vid ifyllnad av fÀlten i kontot för materiell tillgÄng görs en kontroll av korrektheten hos de inmatade uppgifterna.
Diagrammet, som Àr uppbyggt med hÀnsyn till dessa antaganden, visas i Figur 4.
Figur 4. Förtydligande av funktionen "LÀgg till information om en ny nöt i protokollet"
Om anvÀndningen av andra typer av UML-diagram kan du lÀsa hÀr:
KÀllförteckning
- Webbplats för Sparx Systems. [Elektronisk resurs] à tkomstlÀge: Internet:
- OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Elektronisk resurs] à tkomstlÀge: Internet:
KĂ€lla: habr.com
