Podręcznik

Podczas specyfikowania wymagań oprogramowania, korzystamy ze słownika dziedziny stworzonego na etapie wymagań użytkownika. Słownik ten uzupełniamy o pojęcia pojawiające się podczas tworzenia szczegółowych wymagań oprogramowania. Definicje pojęć już istniejących w słowniku są również uszczegóławiane na tym etapie. Najistotniejszymi nowymi pojęciami w słowniku są elementy interfejsu użytkownika, które będą konieczne do realizacji planowanej funkcjonalności systemu oraz ich powiązania z przetwarzanymi przez system danymi.

2.1. Specyfikowanie szczegółowego modelu dziedziny

Przykład szczegółowego modelu dziedziny widzimy na rysunku 2.1. Jest to rozwinięcie fragmentu słownika dziedziny zaprezentowanego w rozdziale 1. Jak widzimy, podstawowe elementy obecne w słowniku utworzonym na poziomie wymagań użytkownika, zostały zachowane. Dotyczy to pojęć-klas, relacji między nimi oraz podstawowych atrybutów. Wszystkie atrybuty uzyskały określenie typu danych. Nadal nie używamy typów „informatycznych” (np. int, float, czy string). Warto jednak podkreślić, że na tym etapie możliwe jest dopuszczenie terminologii bardziej zrozumiałej (i bardziej precyzyjnej) dla zespołu budującego system.

Rysunek 2.1: Przykładowy model dziedziny

Innym istotnym elementem modelu dziedziny są operacje klas-pojęć. Operacje odwołują się najczęściej do akcji występujących w szczegółowych specyfikacjach wymagań funkcjonalnych. Operacje odróżniamy od atrybutów poprzez dodanie nawiasów () na końcu nazwy. Zazwyczaj, na poziomie specyfikacji wymagań w modelu dziedziny nie określamy dodatkowych szczegółów sygnatur operacji (parametrów, typu zwracanego rezultatu). Bardzo ważne jest, aby operacji w modelu dziedziny nie traktować jako podstawy do projektowania kodu systemu. Model dziedziny nie jest modelem kodu systemu i nie powinien być tak traktowany przez zespół projektowy. Operacje w specyfikacji wymagań należy traktować jako sposób zanotowania funkcjonalności wymaganych w ramach systemu, w kontekście określonych pojęć dziedzinowych.

Zarówno atrybuty jak i operacje klas-pojęć nierzadko wymagają dodatkowych wyjaśnień. Najczęstszą kwestią jest tutaj określenie warunków, jakie powinny spełniać wartości atrybutów. Stanowi to element specyfikacji dla walidacji danych. Odpowiedni przykład notacji dla walidacji atrybutów widzimy na rysunku 2.2. Rysunek pokazuje tylko część elementów obecnych na rysunku 2.1 – tych, które są niezbędne do wyspecyfikowania walidacji danych.

Rysunek 2.2: Przykład notacji dla opisu walidacji danych

Walidacja danych może być bardziej złożona, niż tylko sprawdzenie poprawności poszczególnych atrybutów. Aby przeprowadzić walidację danych konkretnego obiektu może być na przykład konieczne wykonanie określonych obliczeń. W takiej sytuacji powinniśmy zdefiniować określoną operację – podać algorytm wykonywania operacji walidacji, co ilustruje rysunek 2.3.

Rysunek 2.3: Przykład notacji dla opisu algorytmów operacji

Oprócz opisu operacji czasami może być konieczne opisanie ogólnej dynamiki zmiany stanów obiektów. W tym wypadku, często powstaje potrzeba wprowadzenia dodatkowych atrybutów definiujących stan (status). Przykłady widzimy na rysunku 2.1. Pojęcia-klasy Samochód i Cennik posiadają stany odpowiednich rodzajów (Status sprzedaży, Status cennika). Zauważmy, że zmiany statusu sprzedaży samochodu zostały zdefiniowane na rysunku 2.4. Rysunek ten stanowi prostą maszynę stanów. Maszyna ta zaczyna swe działanie po wykonaniu operacji utworzenia zamówienia, co ustala stan samochodu na „Zamówiony”. Jest to oznaczone poprzez przejście wychodzące z tzw. pseudostanu początkowego (ikona czarnego kółka). Pod wpływem różnych zdarzeń samochód zmienia swój stan, aż dochodzi do stanu „Sprzedany”, który kończy cykl życia samochodu w kontekście jego sprzedaży. Zauważmy, że przejścia między stanami na diagramie z rysunku 2.4 odpowiadają operacjom klasy Samochód pokazanym na rysunku 2.3. Dla niektórych zdarzeń określone są warunki umieszczone w nawiasach kwadratowych. Na przykład, zdarzenie „rejestruj na stan” podlega dwóm warunkom („do magazynu” i „do salonu”). W zależności od spełnienia określonego warunku, po zajściu zdarzenia przechodzimy do różnych stanów.

Rysunek 2.4: Przykładowa maszyna stanów opisująca zmiany stanów obiektów danej klasy

2.2. Specyfikowanie modelu interfejsu użytkownika

W wielu wypadkach korzystne jest wykonanie modelu interfejsu użytkownika, który odnosi się do modelu dziedziny. Pozwala to w jednoznaczny sposób określić te składniki obiektów dziedziny problemu, które będą uwidaczniane i modyfikowane w poszczególnych elementach interfejsu użytkownika. Przykłady fragmentów modelu dziedziny rozbudowanego o elementy interfejsu użytkownika zostały pokazane na rysunkach 2.5 i 2.7. Pierwszy z nich używa notacji zależności, a drugi – notacji agregacji. Na diagramach klas, elementy interfejsu użytkownika zostały oznaczone stereotypami. Elementy główne (okienka) zostały oznaczone stereotypem «UI element», a elementy aktywne (opcje, przyciski) – stereotypem «UI trigger» (wyzwalacz). Należy jednak podkreślić, że nazwy stereotypów nie są ustandaryzowane i powinny być dobrane zgodnie z wytycznymi obowiązującymi w danym projekcie czy organizacji (np. w języku polskim). Z okienkami zostały powiązane relacjami odpowiednie klasy modelu dziedziny. Pozwala to określić zakres danych, które będą wizualizowane przez dany element ekranowy. Przykładowo, z diagramu na rysunku 2.5 wynika, że „Okno dodawania modelu samochodu” będzie umożliwiało nadanie wartości (początkowych) modelom samochodów oraz wyświetlanie danych poszczególnych pozycji ich cenników. Można się domyślać, że jakieś inne okno (niewidoczne na diagramie) będzie umożliwiało zmianę wartości tych pozycji cennika.

Rysunek 2.5: Przykład notacji dla opisu elementów interfejsu użytkownika

Zauważmy, że diagram na rysunku 2.5 przedstawia elementy występujące w ramach jednego przypadku użycia. Typowy scenariusz tego przypadku użycia rozpoczyna się w oknie listy modeli samochodów. Następnie, wyświetlane jest okno dodawania modelu samochodu, a na koniec – komunikat o sukcesie operacji. Okna te zawierają wybrane elementy z modelu dziedziny. Odpowiednia informacja o tych elementach zawarta jest w notatkach doczepionych do relacji łączących elementy interfejsu użytkownika i pojęcia-klasy z modelu dziedziny.

Diagram z rysunku 2.5 możemy przełożyć na szkic modelowanych elementów interfejsu przedstawiony na rysunku 2.6. Szkic ten pokazuje wstępne rozmieszczenie na poszczególnych ekranach wszystkich elementów danych. Jak możemy zauważyć, szkic ekranów dokładnie realizuje specyfikację z modelu słownika. Rolą projektanta interfejsu użytkownika jest dopracowanie wyglądu okien i przedstawienie scenopisu.

Rysunek 2.6: Przykładowy szkic interfejsu użytkownika wykonany na podstawie modelu

 

Rysunek 2.7: Przykład słownika na poziomie wymagań oprogramowania z elementami interfejsu użytkownika związanymi z wieloma przypadkami użycia