Wymagania na system specyfikują system z różnych perspektyw. Z moich doświadczeń wynika, że warto jest dokumentować wymagania z trzech perspektyw.
- Perspektywa danych: W tej pespektywie dokumentowana jest struktura danych wejściowych/wyjściowych do/z systemu, a także statyczna struktura danych wykorzystywanych w systemie oraz relacje pomiędzy tymi danymi.
- Perspektywa funkcjonalna: W tej perspektywie dokumentowane są informacje z otoczenia systemu, które są modyfikowane przez system oraz informacje jakie będą transmitowane z systemu do jego otoczenia.
- Perspektywa zachowania: W tej perspektywie dokumentowane jest osadzenie systemu w jego otoczeniu oraz podstawowe stany systemu z perspektywy otoczenia. Dokumentowanie z perspektywy zachowania wykonywane jest m.in. poprzez opis reakcji systemu na zdarzenia z otoczenia, warunków, które powodują zmianę stanu systemu, czy też efektów oddziaływania systemu na jego otoczenie.
Diagramy klas (UML) czyli modelowanie wymagań w perspektywie danych
Jedną z technik wykorzystywaną do modelowania wymagań w perspektywie danych są diagramy klas z języka UML. Diagram klasy przedstawiają klasy oraz powiązania pomiędzy nimi. W porównaniu do diagramów związków encji, diagramy klas pozwalają na zdefiniowanie możliwych operacji do wykonania na instancjach tych klas oraz definiują kilka rodzajów relacji pomiędzy klasami.
Notacja dla diagramów klas
Klasa jest definicją grupy obiektów, która definiuje dopuszczalny stan obiektów oraz ich zachowanie. Obiekt, który został stworzony na podstawie danej klasy nazywany jest instancją tej klasy.
Asocjacja definiuje powiązanie pomiędzy klasami. Asocjacji może zostać przypisana nazwa, krotności określające liczbę dopuszczalnych powiązań pomiędzy instancjami klas oraz role pozwalające bardziej szczegółowy określić rodzaj powiązań.
Generalizacja służy do przedstawienia dziedziczenia przez klasę atrybutów i metod z klasy bardziej ogólnej, na którą wskazuje grot strzałki modelującej relację.
Agregacja jest specyficznym wystąpieniem asocjacji, określającej, że instancje klasy z których prowadzona jest relacja są składnikiem instancji klasy głównej (na którą wskazuje diament).
Kompozycja jest „silniejszym” wystąpienie agregacji, która oznacza, że instancje klasy z której prowadzona jest relacja nie mogą istnieć bez instancji klasy głównej (na którą wskazuje diament).
Przykład
Diagramy czynności (UML) czyli perspektywa funkcjonalna
Diagramy czynności pozwalają na modelowanie sekwencji akcji wykonywanych przez modelowany fragment systemu. Diagram sekwencji pozwala także na prezentowanie kontroli przepływu pomiędzy czynnościami, modelowanie przebiegów współbieżnych oraz zmiany stanów obiektów podczas przechodzenia pomiędzy czynnościami. Elementy, z których składa się diagram sekwencji to:
Aktywność/czynność modeluje określone zachowanie systemu. Czynność jest wykonywalnym węzłem aktywności, natomiast aktywność jest sparametryzowanym fragmentem systemu, które może być zdekomponowane za pomocą innych elementów.
Węzły końcowe i początkowe oraz koniec przepływu określają odpowiednio miejsca rozpoczęcia i zakończenia modelowanego zachowania systemu.
Punkt decyzyjny oraz węzeł połączenia reprezentuje odpowiednio miejsce rozpoczęcia i zakończenia przebiegu alternatywnego, przy czym punkt decyzyjny musi zawierać warunek określający kierunek przebiegu przepływu.
Przepływ sterujący wskazuje kierunek przejścia pomiędzy węzłami diagramu.
Węzły rozwidlenia i scalenia prezentują odpowiednio miejsca rozpoczęcia i zakończenia przebiegu równoległego.
Obiekt służy do zaprezentowania danych przesyłanych pomiędzy poszczególnymi węzłami na diagramie. Obiektowi może zostać przypisany jego stan, dzięki czemu istnieje możliwość modelowania zmiany stanów obiektu w trakcie przejścia pomiędzy poszczególnymi węzłami diagramu.
Ograniczenie określa jaki warunek musi być spełniony aby czynność mogła być wykonana lub warunek jaki musi być spełniony po wykonaniu czynności.
Przykład diagramu czynności
Perspektywa zachowania to w moim odczuciu przede wszystkim diagramy przypadków użycia, które opisałem tydzień temu.
Wspomniane perspektywy nie zamykają katalogu wymagań na system. Przykładowo ekrany użytkownika też są perspektywą interakcji użytkownika z systemem.
A jakich Ty używasz perspektyw?
Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011
