Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia

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

clip_image002

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).

clip_image004

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)

clip_image005

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ą.

clip_image007

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.

clip_image009

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.

 

Technorati Tagi: inżynieria oprogramowania,modelowanie systemów informatycznych,UML,Rational Software Architect,Unified Modeling Language,proces wytwórczy oprogramowania,diagramy

Podobne wpisy
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

UML – zastosowanie w biznesie

Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie. W tym przedsięwzięciu miałem swój więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top