Vi tydeliggjør beskrivelsen av systemfunksjonene ved hjelp av sekvensdiagrammet (fortsettelse av "Proteiner")
I denne artikkelen vil vi se på hvordan du kan detaljere (klargjøre) beskrivelsen av funksjonen som automatiseres ved hjelp av UML-sekvensdiagrammet.
I dette eksemplet bruker jeg Enterprise Architect-miljøet fra et australsk selskap. [1].
For den fullstendige UML-spesifikasjonen, se [2].
Først, la meg forklare hva vi vil detaljere.
В vi modellerte prosessene til et "eventyr"-fagområde - linjer om et ekorn fra "The Tale of Tsar Saltan" av A.S. Pushkin. Og vi startet med aktivitetsdiagrammet. Så inn vi utviklet en funksjonell modell ved hjelp av et Use-case diagram, Figur 1 viser et fragment.
Figur 1. Sammenheng mellom krav og funksjon
Nå ønsker vi å avklare informasjon om utførelsen av denne automatiserte funksjonen:
- hvilke grensesnittkomponenter vil brukeren vår samhandle med;
- hvilke kontrollkomponenter vi trenger;
- hva vi skal lagre;
- hvilke meldinger som vil bli utvekslet mellom brukeren og systemkomponentene for å utføre funksjonen.
Hovedelementene i Sekvensdiagrammet er interagerende objekter med forskjellige stereotyper og forbindelser mellom dem - interagerende objekter utveksler noe informasjon med hverandre (Figur 2).
Figur 2. Grunnleggende elementer i et sekvensdiagram
Objekter er ordnet i en horisontal sekvens og meldinger sendes mellom dem. Tidsaksen er orientert fra topp til bunn.
Aktørelementet kan brukes til å representere en bruker som starter en flyt av hendelser.
Hvert objekt har en stiplet linje, kalt "livslinjen", der det elementet eksisterer og potensielt deltar i interaksjoner. Kontrollfokuset indikeres med et rektangel på objektets livslinje.
Meldingene som utveksles mellom objekter kan være av flere typer, og meldingene kan også tilpasses for å gjenspeile operasjonene og egenskapene til kilde- og målelementene.
Stereotypiske elementer som grenser, kontroller og enheter kan brukes til å modellere henholdsvis brukergrensesnitt (GUI), kontrollere og databaseelementer.
En repeterende flyt av meldinger kan betegnes som et fragment med typen "løkke".
Så vi planlegger å avklare beskrivelsen av funksjonen "Legg til informasjon om en ny mutter på listen".
La oss bli enige om følgende ytterligere generaliseringer og antakelser.
- Nøtter, kjerne og skall er alle materielle eiendeler av tilsvarende typer (figur 3).
Figur 3. Forfining av klassediagram - Vår bruker vil legge inn informasjon om eventuelle vesentlige eiendeler i erklæringen.
- La oss avklare navnet på erklæringen - "Regnskapsuttalelse av vesentlige verdier."
- La oss anta at brukeren vår, som arbeider med GUI "Material Value Accounting Sheet", kan legge til en ny materiell verdi gjennom "Material Value Accounting Card" GUI.
- Avhengig av typen matematisk verdi, endres datastrukturen og GUI.
- Når du fyller ut feltene på materialverdi-kontokortet, kontrolleres riktigheten av de angitte dataene.
Et diagram basert på disse forutsetningene er vist i figur 4.
Figur 4. Presisering av beskrivelsen av funksjonen «Legg til informasjon om en ny mutter på listen»
Du kan lese om bruken av andre typer UML-diagrammer her:
Liste over kilder
- Sparx Systems nettsted. [Elektronisk ressurs] Tilgangsmodus: Internett:
- OMG Unified Modeling Language (OMG UML) spesifikasjon. Versjon 2.5.1. [Elektronisk ressurs] Tilgangsmodus: Internett:
Kilde: www.habr.com