Vi förfinar beskrivningen av systemfunktionerna med hjälp av sekvensdiagrammet (fortsättning av "Proteiner")
I den här artikeln kommer vi att överväga hur du kan förfina (förtydliga) beskrivningen av en automatiserad funktion med hjälp av UML Sequence Diagram - ett sekvensdiagram.
I det här exemplet använder jag Enterprise Architect-miljön från ett australiensiskt företag. [1].
För den fullständiga UML-specifikationen, se [2].
Till att börja med kommer jag att förklara vad vi kommer att detaljera.
В vi modellerade processerna för ett "fantastiskt" ämnesområde - en rad om en ekorre från A.S. Pushkins Sagan om Tsar Saltan. Och vi började med aktivitetsdiagrammet. Sedan i vi utvecklade en funktionell modell med användning av Use-case-diagrammet, Figur 1 visar ett fragment.
Figur 1 Samband mellan krav och funktion
Nu vill vi förtydliga information om exekveringen av denna automatiserade funktion:
- vilka gränssnittskomponenter vår användare kommer att interagera med;
- vilka styrkomponenter vi behöver;
- vad kommer vi att lagra;
- vilka meddelanden användaren och systemkomponenterna kommer att utbyta för att utföra funktionen.
Huvudelementen i Sekvensdiagrammet är interagerande objekt med olika stereotyper och kopplingar mellan dem - interagerande objekt utbyter viss information med varandra (Figur 2).
Figur 2. Huvudelementen i sekvensdiagrammet
Objekt är ordnade i en horisontell sekvens, meddelanden skickas mellan dem. Tidsaxeln är orienterad uppifrån och ned.
Ett Actor-element kan användas för att representera en användare som initierar en ström av händelser.
Varje objekt har en prickad linje, kallad "livlina", där detta element finns och potentiellt deltar i interaktioner. Kontrollfokuset indikeras av en rektangel på objektets livlina.
Meddelanden som utbyts mellan objekt kan vara av flera typer, meddelanden kan också anpassas för att återspegla funktionerna och egenskaperna hos käll- och målelementen.
Stereotypiska element som Boundary, Control och Entity kan användas för att modellera användargränssnittet (GUI), controllers respektive databaselement.
Ett upprepat meddelandeflöde kan betecknas som ett fragment med en "loop"-typ.
Så vi planerar att förtydliga beskrivningen av funktionen "Lägg till information om en ny mutter till uttalandet".
Låt oss komma överens om följande ytterligare generaliseringar och antaganden.
- Nötter, kärnor och skal är alla materiella tillgångar av respektive typ (Figur 3).
Figur 3. Förfining av klassdiagram - Vår användare kommer att ange information om eventuella väsentliga värden i uttalandet.
- Låt oss förtydliga namnet på arket - "Redovisning för väsentliga värden."
- Låt oss säga att vår användare, som arbetar med det grafiska användargränssnittet "Redovisning av materialvärden", kan lägga till ett nytt ekonomiskt värde genom det grafiska användargränssnittet "Redovisningskort för materialvärden".
- Beroende på typen av värde ändras datastrukturen och GUI.
- När du fyller i fälten på materialvärdekontokortet kontrolleras riktigheten av de inmatade uppgifterna.
Ett diagram byggt med dessa antaganden i åtanke visas i figur 4.
Figur 4. Förtydligande av beskrivningen av funktionen "Lägg till information om en ny mutter till uttalandet"
Du kan läsa om användningen av andra typer av UML-diagram här:
Lista över källor
- Sparx Systems webbplats. [Elektronisk resurs] Åtkomstläge: Internet:
- OMG Unified Modeling Language (OMG UML) specifikation. Version 2.5.1. [Elektronisk resurs] Åtkomstläge: Internet:
Källa: will.com