Dopracowujemy opis funkcji systemu za pomocą Diagramu Sekwencji (kontynuacja „Białek”)
W tym artykule zastanowimy się, w jaki sposób można udoskonalić (doprecyzować) opis funkcji automatycznej za pomocą diagramu sekwencji UML - diagramu sekwencji.
W tym przykładzie używam środowiska Enterprise Architect z australijskiej firmy. [1].
Aby zapoznać się z pełną specyfikacją UML, zobacz [2].
Na początek wyjaśnię, co wyszczególnimy.
В modelowaliśmy procesy „bajkowego” obszaru tematycznego — wersu o wiewiórce z „Opowieści o Caru Sałtanie” A.S. Puszkina. Zaczęliśmy od diagramu aktywności. potem w opracowaliśmy model funkcjonalny z wykorzystaniem diagramu przypadków użycia, na rysunku 1 pokazano fragment.
Rysunek 1 Związek między wymaganiem a cechą
Teraz chcemy wyjaśnić informacje o wykonaniu tej automatycznej funkcji:
- z jakimi komponentami interfejsu będzie wchodzić w interakcje nasz użytkownik;
- jakich elementów sterujących potrzebujemy;
- co będziemy przechowywać;
- jakie komunikaty użytkownik i komponenty systemu będą wymieniać w celu wykonania funkcji.
Głównymi elementami diagramu Sekwencji są obiekty wchodzące w interakcje z różnymi stereotypami i powiązaniami między nimi – wchodzące w interakcję obiekty wymieniają między sobą pewne informacje (Rysunek 2).
Rysunek 2. Główne elementy diagramu sekwencji
Obiekty układają się w poziomą sekwencję, między nimi przekazywane są komunikaty. Oś czasu jest zorientowana od góry do dołu.
Element Actor może służyć do reprezentowania użytkownika, który inicjuje strumień zdarzeń.
Każdy obiekt ma wykropkowaną linię, zwaną „linią życia”, w której ten element istnieje i potencjalnie bierze udział w interakcjach. Fokus kontrolny jest wskazywany przez prostokąt na linii życia obiektu.
Komunikaty wymieniane między obiektami mogą być kilku typów, komunikaty można również dostosowywać, aby odzwierciedlały operacje i właściwości elementu źródłowego i docelowego.
Elementy stereotypowe, takie jak granice (Boundary), elementy sterujące (Control) i jednostki (Entity), mogą być używane do modelowania odpowiednio interfejsu użytkownika (GUI), kontrolerów i elementów bazy danych.
Powtarzalny przepływ komunikatów można określić jako fragment typu „pętla”.
Planujemy więc doprecyzować opis funkcji „Dodaj informację o nowym nakrętce do wyciągu”.
Umówmy się co do następujących dodatkowych uogólnień i założeń.
- Orzechy, jądra i łupiny to wszystkie aktywa materialne odpowiednich typów (Rysunek 3).
Rysunek 3. Uszczegółowienie diagramu klas - Nasz użytkownik wpisze do oświadczenia informacje o wszelkich istotnych wartościach.
- Wyjaśnijmy nazwę arkusza - „Zestawienie rozliczenia wartości materialnych”.
- Załóżmy, że nasz użytkownik, pracując z GUI „Zestawienie rozliczenia wartości rzeczowych”, może dodać nową wartość finansową poprzez GUI „Karta rozliczenia wartości rzeczowych”.
- W zależności od typu wartości zmienia się struktura danych i GUI.
- Podczas wypełniania pól karty rozliczeniowej wartości rzeczowej sprawdzana jest poprawność wprowadzonych danych.
Diagram zbudowany z myślą o tych założeniach pokazano na rysunku 4.
Rysunek 4. Wyjaśnienie opisu funkcji „Dodaj informację o nowej nakrętce do wyciągu”
O wykorzystaniu innych typów diagramów UML możesz przeczytać tutaj:
Lista źródeł
- Witryna firmy Sparx Systems. [Zasoby elektroniczne] Tryb dostępu: Internet:
- Specyfikacja ujednoliconego języka modelowania OMG (OMG UML). Wersja 2.5.1. [Zasoby elektroniczne] Tryb dostępu: Internet:
Źródło: www.habr.com