1.2. Identyfikowanie pojęć w słowniku dziedziny

Aby móc przystąpić do tworzenia słownika dziedziny najpierw powinniśmy zrozumieć czym taki słownik powinien być. Słownik dziedziny w inżynierii wymagań oprogramowania jest uporządkowanym zbiorem wyrazów i fraz, wraz z ich znaczeniami, za pomocą których można opisać wszystkie pojęcia występujące w określonym fragmencie rzeczywistości, dla którego budujemy system oprogramowania.

Aby wyjaśnić rolę słownika w specyfikacji wymagań posłużymy się porównaniem do powieści. Na rysunku 1.1 mamy fragmenty opisujące akcję (fabułę), czyli pewne zdarzenia układające się w pewien ciąg. Oczywiście, rysunek jest pewnym uproszczeniem, gdyż akcja może mieć zdarzenia dziejące się równolegle. Akcja czasami jest przerywana i autor dokonuje „opisu przyrody”. Opisy te mają na celu przedstawianie cech występujących w akcji osób, przedmiotów czy miejsc. Opisy te mogą być uporządkowane i tworzyć mapę. Mapa określna przestrzenne zależności między poszczególnymi elementami występującymi w otoczeniu (domy, rzeki, góry, …) i wśród których toczy się akcja. Oczywiście, w specyfikacji wymagań nie rysujemy mapy terenu (czasami takie mapy spotyka się jako ilustracje w powieściach). Zamiast tego, tworzony jest graficzny model dziedziny problemu w postaci diagramu zawierającego pojęcia i relacje między nimi.

Rysunek 1.1: Konstrukcja specyfikacji wymagań z „mapą terenu”

Rezultatem analizy wymagań użytkownika pod kątem używanego słownictwa jest słownik dziedziny, który definiuje wszystkie pojęcia występujące w specyfikacji. Co jest istotne, słownik dziedziny zaczynamy tworzyć już na poziomie wizji systemu, a potem rozbudowujemy podczas tworzenia wymagań użytkownika i wymagań oprogramowania. Na poziomie wymagań oprogramowania słownik będzie uzupełniony o pojęcia związane ze szczegółami funkcjonowania systemu, o czym będziemy mówili w dalszej części podręcznika. W rezultacie, otrzymujemy spójny model dziedziny, który powinien stanowić schemat kompletnej specyfikacji wymagań z wyraźnie wyróżnionym, centralnym słownikiem dziedziny. Kluczowe jest tutaj założenie, że unikamy definiowania pojęć wewnątrz opisów poszczególnych wymagań. W ten sposób uzyskujemy konstrukcję specyfikacji wymagań podobną do mapy terenu (patrz rys. 1.1).

Przykład identyfikacji pojęć w treści wymagań widzimy na rysunku 1.2. Jak widać, pojęcia zostały wyróżnione poprzez umieszczenie ich w nawiasach kwadratowych i zapisanie kursywą. Taka notacja jest oczywiście przykładowa i wyróżnianie pojęć może być dokonane w inny sposób. Pojęcia możemy znajdować w nazwach wymagań (przypadków użycia, historii użytkownika, cech systemu, …) oraz w różnych elementach ich opisu (scenariuszach, konwersacjach, …).

Rysunek 1.2: Identyfikacja pojęć do słownika dziedziny

Bardzo istotnym problemem podczas identyfikacji pojęć słownikowych jest występowanie synonimów i homonimów. Homonimy to słowa, które są pisane (i wymawiane) identycznie, ale posiadają różne znaczenia. Z kolei, synonimy, to słowa, które są pisane różnie, ale posiadają takie same znaczenia. Odpowiednie przykłady widzimy na rysunku 1.3.  Występowanie synonimów i homonimów jest spowodowane przede wszystkim tym, że w tworzeniu specyfikacji wymagań uczestniczą różne grupy osób, które mogą używać różnego słownictwa. Przykładem są różne działy w danej organizacji, które wykształciły swoje słownictwo niezależnie od innych działów. Powstawaniu homonimów i synonimów sprzyja również utrzymywanie specyfikacji wymagań w postaci „płaskiego” dokumentu. W takim dokumencie słownik jest osobną sekcją na końcu, której aktualizacja jest zadaniem żmudnym i pracochłonnym. W takiej sytuacji, identyfikacja sprzeczności w słowniku jest bardzo trudna.

Rysunek 1.3: Przykładowe synonimy i homonimy w słowniku

Problem homonimów powinien być rozwiązany poprzez uściślenie nazewnictwa. Konieczne jest wyraźne rozróżnienie pojęć poprzez np. dodanie dodatkowych słów, np. „konto” à „konto osobiste” oraz „konto” à „konto bankowe”. W przypadku synonimów sytuacja może być bardziej skomplikowana. Najprostszym rozwiązaniem jest oczywiście zdecydowanie się na użycie jednego z synonimów w całej specyfikacji. Jest to jednocześnie rozwiązanie skutkujące najbardziej spójną specyfikacją.

1.1. Formułowanie słownika dziedziny

Słownik, podobnie jak cała specyfikacja wymagań, najczęściej tworzony jest w formie dokumentu tekstowego w odpowiednim edytorze tekstu, co ilustruje rysunek 1.4. Zarządzanie słownikiem odbywa się poprzez ręczną aktualizację poszczególnych pojęć oraz ich definicji. Wymaga to sporego nakładu pracy i jest powodem wielu błędów.

Rysunek 1.4: Słownik w postaci dokumentu

Często używaną formą słownika dziedziny jest diagram (forma graficzna). Diagram pozwala zaprezentować słownik dziedziny jago graf powiązanych ze sobą pojęć, co ilustruje rysunek 1.5. Jak można zauważyć, wszystkie pojęcia z rysunku 1.5 zostały umieszczone na diagramie i połączone zgodnie z relacjami zawartymi w ich opisach. Opisy pojęć zostały na diagramie pominięte.

Rysunek 1.5: Słownik w postaci diagramu

Wizualne przedstawienie relacji między pojęciami umożliwia szybkie rozeznanie w strukturze danej dziedziny problemu. Zachowujemy jednocześnie wszystkie zalety zapisu tekstowego, gdyż do wszystkich pojęć na diagramie możemy dołączyć opisy tekstowe. Uzyskujemy w ten sposób omówiona na początku „mapę terenu”, która ułatwia zrozumienie całej specyfikacji wymagań.

Diagramy klas stanowią najbardziej uniwersalną i prawdopodobnie najbardziej rozpowszechnioną formę graficznej reprezentacji słownika dziedziny. Podstawowym elementem diagramu klas jest oczywiście klasa, reprezentująca pojęcie w danej dziedzinie problemu. Na rysunku 1.6 przedstawione zostały różne dopuszczalne reprezentacje graficzne klas w języku UML. Najprostszą reprezentacją klasy jest prostokąt zawierający wyśrodkowaną nazwę klasy. Ikona klasy może zawierać kilka przegródek, oddzielonych liniami poziomymi. Jedna z przegródek może zawierać tzw. „metki” (ang. tag), które odpowiadają atrybutom wymagań omówionym w poprzednich rozdziałach.

Rysunek 1.6: Przykładowe klasy z pokazanymi atrybutami i metkami

Po nazwie atrybutu możemy umieścić jego typ zapisany po dwukropku. Na poziomie specyfikacji wymagań użytkownika typ może być czasami istotny, chociaż w większości przypadków wystarczy samo podanie nazwy atrybutu. Zwróćmy uwagę na to, że język UML nie definiuje dopuszczalnych typów. Dlatego też możemy określić własne nazwy typów, np. „tekst”, „napis”, „liczba”. Czasami wskazane jest zdefiniowanie typów, których wartości są wyliczane jako lista. Takie typy wyliczeniowe (ang. enumeration) reprezentowane są podobnie jak klasy w postaci prostokątów z nazwą. Nad nazwą takiego typu umieszczamy dodatkowe oznaczenie «enumeration», a w drugiej przegródce podajemy listę dopuszczalnych wartości. Przykładowy typ wyliczeniowy wraz z przykładem jego zastosowania został przedstawiony na rysunku 1.7.

Rysunek 1.7: Przykłady zastosowania typów

Relacja asocjacji definiuje możliwe związki między obiektami klas (w szczególności – związki między obiektami tej samej klasy). Klasy na końcach asocjacji mogą mieć zdefiniowane określone role. Asocjacje oznaczamy linią łączącą odpowiednie klasy. Przykłady asocjacji przedstawia rysunek 1.8. Jak widzimy, między dwoma klasami możemy zdefiniować kilka asocjacji, które określają różne role dla relacji między obiektami. Zgodnie z diagramem, konkretna osoba może posiadać dowolnie dużo (od 0 do wielu) samochodów oraz może kierować (w danej chwili) maksymalnie jednym samochodem (krotność od zera do jednego). Z kolei samochód może mieć dokładnie jednego właściciela oraz maksymalnie jednego kierowcę. Na rysunku 1.8 widzimy również asocjację dotyczącą tylko klasy „Osoba” (asocjacja „zawinięta”). Zgodnie w tym fragmentem modelu, dana osoba ma dokładnie dwóch rodziców oraz może mieć dowolnie dużo dzieci.

Rysunek 1.8: Przykładowe zastosowania asocjacji

Specjalną własnością asocjacji jest tzw. nawigowalność (skierowanie asocjacji). Nawigowalność oznacza możliwość efektywnego osiągnięcia obiektów jednej klasy przez obiekty drugiej klasy. W specyfikacji wymagań może to odpowiadać użyciu nazwy pojęcia w definicji innego pojęcia. Nawigowalność asocjacji oznaczamy poprzez dodanie grotu strzałki na końcu asocjacji, co ilustruje przykład na rysunku 1.9. Z rysunku wynika, że obiekty klasy „Dowód rejestracyjny” mają dostęp do danych odpowiadających im samochodów, natomiast obiekty klasy „Samochód” nie mają zdefiniowanego dostępu do danych przypisanych do nich dowodów rejestracyjnych.

Rysunek 1.9: Przykład asocjacji nawigowalnej

Specjalnym rodzajem asocjacji są relacje agregacji. Stosujemy je, kiedy potrzebne jest odzwierciedlenie związku między grupą, a jej elementem lub elementami. Relacja agregacji jest zatem relacją grupowania, na przykład grupowania składników (części) pewnej całości. Relacja agregacji stosuje wszystkie elementy notacji asocjacji i dodatkowo jest wyróżniana poprzez umieszczenie małej ikony rombu po jednej stronie relacji. Romb umieszczany jest przy tej klasie, która stanowi całość. Przykład relacji agregacji widzimy na rysunku 1.10. Klasa „Samochód” stanowi element grupujący (całość), a klasa „Bagaż” definiuje elementy grupowane (składniki).

Rysunek 1.10: Przykład zastosowania agregacji i kompozycji

Rysunek 1.10 zawiera również relację między klasami „Samochód” i „Silnik”. Jest ona oznaczona podobnie jak relacja agregacji, lecz ikona rombu jest wypełniona. Jest to relacja kompozycji, która stanowi „silniejszą” wersję relacji agregacji. Reprezentuje ona związek pomiędzy całością a jej integralnymi częściami. Istotną cechą relacji kompozycji jest zasada, że obiekty odpowiadające składnikom nie mogą być zawarte w więcej nić jednym obiekcie odpowiadającym całości. Inaczej mówiąc – w relacji kompozycji składniki nie mogą być dzielone między różne całości. Dlatego też, krotność po stronie całości nie może być większa niż 1. Dodatkowym wyróżnikiem relacji kompozycji jest to, że składniki zazwyczaj powstają i kończą swoje istnienie razem z całością, do której należą – czas życia składników jest ograniczony czasem życia.

Istotnym aspektem specyfikowania słownika dziedziny jest tworzenie taksonomii pojęć. W języku UML taksonomie tworzymy za pomocą relacji generalizacji-specjalizacji (w skrócie – generalizacji). Relacja generalizacji określa zależność pomiędzy klasami-pojęciami bardziej ogólnych i klasami-pojęciami bardziej specjalizowanych. Klasy specjalizowane „dziedziczą” po klasie ogólnej wszystkie jej atrybuty oraz relacje (asocjacje, agregacje, kompozycje, generalizacje). Oznacza to, że obiekty klasy specjalizowanej posiadają wszystkie elementy zdefiniowane w danej klasie, oraz dodatkowo – wszystkie elementy pochodzące z klasy ogólnej. Relacje generalizacji oznaczamy strzałką z dużym grotem w kształcie trójkąta. Strzałka zwrócona jest od klasy specjalizowanej do klasy ogólnej (wskazuje na klasę ogólną). Przykłady zastosowania relacji generalizacji widzimy na rysunku 1.11.

Rysunek 1.11 Przykład zastosowania generalizacji i klas abstrakcyjnych

Stosując powyższe zasady budowy diagramów klas tworzymy słownik dziedziny w formie graficznej. Na rysunku 1.12 widzimy kontynuację i rozszerzenie przykładu z rysunku 1.4. Widzimy tutaj wszystkie rodzaje relacji między klasami-pojęciami. Jak widzimy, modele samochodów są składnikami cennika, który zawiera również pozycje cennika. Z kolei pozycje cennika zostały podzielone na pozycje dodatkowe oraz podstawowe. Wprowadziliśmy również ogólną klasę-pojęcie Osoba, od której specjalizuje Klient. To dodatkowe pojęcie przyda nam się w przyszłości, kiedy będziemy definiować inne pojęcia, które są specjalizacjami osoby (np. Pracownik, Kierowca, …).

Rysunek 1.12: Słownik w postaci diagramu klas

Diagram klas zawiera większość informacji, które moglibyśmy przedstawić w formie tekstowej. Ewentualne dodatkowe informacje definiujące pojęcia w słowniku graficznym możemy podać jako opisy klas-pojęć. Opisy takie nie są typowo widoczne na diagramie. Większość narzędzi CASE pozwala jednak na wygenerowanie odpowiedniego dokumentu, w którym obok diagramu będą widoczne wszystkie dodatkowe opisy.

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