Pierwszym krokiem po włączeniu Rational Software Architect’a jest wybór miejsca, w którym znajdować się będzie nasz projekt (ang. workspace). W tym przypadku zamiast domyślnego katalogu umieścimy nasze rozwiązanie w katalogu Projekt
Rysunek 1 Katalog z projektem
W związku z tym, że naszą aplikację chcemy zaprojektować to w pierwszej kolejności utworzony projekt aplikacji, który będzie zawierał model systemu wyrażony w języku UML. W tym celu należy kliknąć w menu na File -> New Project i wybrać projekt UML. Następnie należy nadać mu nazwę (tutaj: KAX_UML) i określić pierwszy model projektowy.
Model przypadków użycia
W związku z tym, że budowę rozwiązań informatycznych zaczyna się od zbierania wymagań, pierwszym modelem będzie model przypadków użycia, który jest wizualnym repozytorium wymagań funkcjonalnych. W RSA model przypadków użycia jest zdefiniowany szablonem, którego należy użyć.(rysunek 2).
Rysunek 2 Wybór nowego projektu
Dodany model zawiera szereg pakietów, które grupują elementy składowe modelu przypadków użycia ze względu na zastosowanie.
Kolejnym krokiem będzie dodanie aktorów, czyli elementów, które wchodzą w interakcje z systemem. Aktorów jak i inne elementy modelu można dodać albo przez użycie menu kontekstowego (uruchamianego prawym klawiszem myszy) lub przez paletę elementów (rysunek 3)
Rysunek 3 Dodawanie elementów do modelu
W podany sposób do modelu dodane będą przypadki użycia i aktorzy. W omawianym przykładzie zdefiniowano pięć przypadków użycia i jednego aktora. Aktor został umieszczony w pakiecie Versatile Actors a przypadki użycia w dodanym pakiecie ?Przypadki użycia?.
Przy budowaniu diagramów przypadków użycia tak jak przy innych diagramach należy pamiętać by były one czytelne. Oznacza to, że na diagramie nie powinno być więcej niż 7-9 elementów. Przy konstruowaniu diagramów przypadków użycia istotne jest także by każdy aktor był przypisany minimum jednemu przypadkowi użycia.
W związku z tym, że budowana aplikacja jest prostym rozwiązaniem utworzono jednego aktora i pięć przypadków użycia, które wskazują na funkcjonalne cechy systemu (rysunek 4). Aktor z przypadkami użycia jest połączony asocjacją.
Rysunek 4 Diagram przypadków użycia
Diagram ten został wzmocniony o dwie zależności: rozszerzania i zawierania. Związek rozszerzania (ang. extend) oznacza, że dany przypadek użycia opcjonalnie zostanie użyty. W naszym przypadku oznacza to, ze edycja danych kontaktowych (przypadek użycia ?Edytuj kontakt?) jest uruchamiana na dopiero po wyświetleniu danych (przypadek użycia ?Wyświetl kontakt? ) i spełnieniu warunku jakim jest istnienie potrzeby zmiany danych, co zostało zapisane w notce. Związek zawierania oznacza natomiast obligatoryjne wykonanie przypadku użycia, który jest zawierany. W tym przypadku oznacza to, że po dodaniu danych kontaktowych (przypadek użycia ?Dodaj kontakt? )następuje obligatoryjnie zapamiętanie danych (przypadek użycia ?Zapamiętaj dane? ).
Należy wspomnieć, że w sytuacji gdy system jest bardziej rozbudowany należy utworzyć kilka diagramów przypadków użycia, z których każdy wskazywać będzie na inny aspekt funkcjonalności systemu.
Jak wspomnieliśmy pierwszym etapem podczas budowania rozwiązań informatycznych jest zbieranie wymagań. Do tej pory zrobiliśmy to gromadząc wymagania w postaci wizualnej ? diagramu przypadków użycia. RSA oferuje możliwość współpracy z IBM Rational RequisitePro ? narzędziem, które jest przeznaczone do zarządzania wymaganiami przez cały czas budowania aplikacji. Wspomniana współpraca pozwala na zintegrowania wymagań wyrażonych przypadkami użycia z pozostałymi wymaganiami na system.
W celu rozpoczęcia pracy z RequisitePro (oczywiście po jego zainstalowaniu) należy w RSA otworzyć perspektywę wymagań. Perspektywę tą otwieramy przez klikniecie w Menu na Window -> Open Perspective -> Requirements. W perspektywie tej w oknie Requirements Explorer używając prawego klawisza myszy można otworzyć wcześniej zdefiniowany projekt z zapisanymi wymaganiami.
Synchronizacja wymagań z modelem przypadków użycia odbywa się za pomocą techniki przeciągnij i upuść. Zsynchronizowanie wymagania z danym elementem systemu obarczone jest małą strzałeczką na piktogramie danego elementu.
Rysunek 5 Wymagania na system
W kolejnych częściach (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy) opisane zostaną dalsze kroki jakie zostały podjęte celem zbudowania projektu aplikacji.
