Precyzujemy opis funkcji systemu za pomocą diagramu sekwencji (kontynuacja „Białki”)
W tym artykule omówimy, jak można szczegółowo (precyzyjnie) opisać automatyzowaną funkcję za pomocą diagramu sekwencji UML.
W tym przykładzie korzystam z środowiska Enterprise Architect firmy Sparx Systems z Australii. [1].
Pełną specyfikację UML można znaleźć w. [2].
Na początek wyjaśnię, że będziemy szczegółowo opisywać.
W modelowaliśmy procesy z „baśniowej” dziedziny tematycznej — fragmenty na temat wiewiórki z „Baśni o carze Saltanie” A.S. Puszkina. I zaczęliśmy od diagramu aktywności. Później w opracowaliśmy model funkcjonalny za pomocą diagramu przypadków użycia, na Rysunku 1 przedstawiono fragment.
Rysunek 1. Powiązanie wymagań i funkcji
Teraz chcemy precyzować informacje na temat wykonania tej automatyzowanej funkcji:
- z jakimi komponentami interfejsu będzie współpracować nasz użytkownik;
- jakie komponenty kontrolne będą nam potrzebne;
- co będziemy przechowywać;
- jakie komunikaty będą wymieniać użytkownik i komponenty systemu w celu wykonania funkcji.
Podstawowymi elementami diagramu sekwencji są współdziałające obiekty z różnymi stereotypami oraz połączenia między nimi — obiekty te wymieniają między sobą pewne informacje (Rysunek 2).
Rysunek 2. Podstawowe elementy diagramu sekwencji
Obiekty są umieszczone w poziomej sekwencji, między nimi przekazywane są komunikaty. Oś czasu jest skierowana od góry do dołu.
Element Actor może być używany do przedstawienia użytkownika inicjującego przebieg zdarzeń.
Każdy obiekt ma przerywaną linię, nazywaną „linią życia”, gdzie ten element istnieje i potencjalnie bierze udział w interakcjach. Skupienie zarządzania jest oznaczane prostokątem na linii życia obiektu.
Komunikaty, którymi wymieniają się obiekty, mogą mieć kilka typów, a komunikaty mogą być również dostosowane do odzwierciedlenia operacji i właściwości elementów źródłowego i docelowego.
Stereotypowe elementy, takie jak granice (Boundary), elementy sterujące (Control) i jednostki (Entity), mogą być używane do modelowania interfejsu użytkownika (GUI), kontrolerów i elementów bazy danych, odpowiednio.
Powtarzający się strumień wymiany komunikatów może być oznaczony jako fragment o typie „pętla”.
Planujemy doprecyzować opis funkcji „Dodaj do ewidencji informacje o nowym orzechu”.
Ustalmy następujące dodatkowe uogólnienia i założenia.
- Orzech, rdzeń i skorupki — to wszystko aktywa materialne odpowiednich typów (Rysunek 3).
Rysunek 3. Doprecyzowanie diagramu klas - Użytkownik wprowadzi informacje o wszelkich aktywach materialnych do ewidencji.
- Doprecyzujmy nazwę ewidencji — „Ewidencja aktywów materialnych”.
- Załóżmy, że nasz użytkownik, pracując z GUI „Ewidencja aktywów materialnych”, może dodać nową aktywność materialną przez GUI „Karta ewidencji aktywu”.
- W zależności od rodzaju aktywności materialnej zmienia się struktura danych i GUI.
- Podczas wypełniania pól karty ewidencji aktywu następuje kontrola poprawności wprowadzonych danych.
Diagram zbudowany z uwzględnieniem tych założeń przedstawiony jest na Rysunku 4.
Rysunek 4. Doprecyzowanie opisu funkcji „Dodaj do ewidencji informacje o nowym orzechu”
O zastosowaniu innych rodzajów diagramów UML można przeczytać tutaj:
Lista źródeł
- Strona Sparx Systems. [Zasób elektroniczny] Dostęp: Internet:
- OMG Unified Modeling Language (OMG UML) Specyfikacja. Wersja 2.5.1. [Zasób elektroniczny] Dostęp: Internet:
Źródło: habr.com
