Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy

Po zdefiniowaniu wymagań (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia ) na system przychodzi kolej na modele, które opiszą nam z jakich elementów jest zbudowany system i jak te elementy ze sobą współpracują. Modele te buduje się w modelu analizy (ang. Analysis Model), który należy dodać do naszego projektu w sposób podobny jak to miało miejsce z modelem przypadków użycia z tym, że wybierany jest szablon Analysis Model. W tym miejscu należy wspomnieć, że model analityczny jest opcjonalnym elementem projektu. W przypadku prostych modeli można od razu budować model projektu. W naszym przypadku dla celów edukacyjnych zbudujemy ten model by następnie uszczegółowić go w modelu projektu.

W zdefiniowanym modelu analitycznym w katalogu Analysis Building Block należy utworzyć realizacje przypadków użycia. Realizacje to są elementy współpracy (ang. Collaboration), które powinny nosić nazwę przypadku użycia, którego są realizacją. Elementy współpracy jest to jeden z elementów języka UML 2.0 i dodaje się go poprzez menu kontekstowe, które jest uruchamiane prawym klawiszem myszy.

W celu zaznaczenia specjalnej roli jaką pełnią te elementy współpracy w modelu warto jest nadać im stereotyp realizacji przypadku użycia. Czynność tą jak i zmianę nazwy elementu można zrobić w oknie właściwości (properties)

clip_image002

Rysunek 6 Definiowanie dodatkowych właściwości elementu

Dodatkowo w oknie właściwości można zmienić nazwę elementu (General), dodać opis do dokumentacji (Documentation) a przy klasyfikatorach (klasy, komponenty) można definiować w nim operacje i atrybuty.

Po dodaniu realizacji przypadków użycia należy zdefiniować kandydatów na klasy projektowe. Klasy te umieszczone są także w katalogu Analysis Buildings Block.

Po wstępnym określeniu klas można przystąpić do specyfikacji atrybutów i metod jakimi te klasy będą się posługiwać (rysunek 7)

clip_image004

Rysunek 7 Definiowanie klas i dodawanie diagramów

Po dodaniu metod i atrybutów można przystąpić do budowania diagramów, które wskażą interakcję pomiędzy klasami. Doigramy te należy budować jako elementy składowe realizacji przypadków użycia. W celu dodania pierwszego diagramu (zazwyczaj jest to diagram klas) należy kliknąć prawym klawiszem na elemencie współpracy (tutaj ?Wyświetl kontakt?) i dodać diagram.

Dodany diagram klas (rysunek 8) wskazuje jakie klasy biorą udział w realizacji funkcji sytemu związanych z wyświetleniem danych kontaktowych. W omawianym przypadku klasy te to odpowiedzialna za interfejs aplikacji: InterfejsKsiazkiAdresowej, klasa sterująca KsiazkaAdresowa, oraz klasa odpowiedzialne za obsługę danych: ObslugaPliku. Klasy te połączone są za pomocą asocjacji.

clip_image006

Rysunek 8 Diagram klas dla realizacji przypadku użycia ?Wyświetl plik?

Diagram ten wskazuje jakie elementy (klasy) składają się na strukturę systemu. Kolejnym krokiem jest prezentacja zachowania tych elementów. W celu przedstawienia interakcji między klasami najczęściej stosuje się diagram sekwencji.

clip_image008

Rysunek 9 Scenariusz wyświetlania danych kontaktowych

Na diagramie sekwencji zaprezentowano scenariusz wyświetlenia danych kontaktowych (rysunek 9). W scenariuszu tym poza użytkownikiem udział biorą klasy InterfejsKsiazkiAdresowej KsiazkaAdresowa oraz ObslugaPliku. Na diagramie tym wykorzystano nowe możliwości jakie oferuje język UML 2.0. Te nowe cechy to referencja (prostokąt z napisem w lewym rogu ?ref?) ?Otwieranie pliku XML?, która jest odniesieniem do innego diagramu sekwencji, który w tym przypadku poprzedza zasadniczą część scenariusza. Zastosowanie referencji pozwala na wyeksponowanie tylko tego fragmentu scenariusza, który jest dla na s w danym momencie istotny. Drugim elementem zastosowanym na tym diagramie jest element zwany fragmentem. Fragment to wybrany obszar diagramu sekwencji, któremu nadajemy specyficzne właściwości. Wspomniane specyficzne właściwości fragmentu określone są w lewym górnym rogu tego elementu. W zaprezentowanym przypadku jest to pętla (ang. loop), która oznacza, że dany obszar diagramu sekwencji będzie wykonywany wielokrotnie.

Wybrane typy fragmentów opisano w poniższej

  • alt – dzieli fragment interakcji zgodnie z warunkami logiki boola na dwa alternatywne scenariusze; każda z alternatyw musi posiadać warunek dozoru, którego spełnienie warunkuje wykonanie danej alternatywy.
  • loop – powtórzenie fragmentu interakcji określoną warunkiem liczbę razy
  • opt – wskazuje na opcjonalny fragment interakcji, który jest wykonywany po spełnieniu warunku dozoru
  • par – prezentuje równoległe wykonywanie przepływu wiadomości
  • seq – wskazuje słabo uszczegółowiony fragment sekwencji, tzn. taki, który jest ogólny

Kolejnym diagramem jaki może pomóc w prezentacji zachowania przypadku użycia jest diagram komunikacji (ang. Communication Diagram), którego zasadniczym celem jest wskazanie jakie elementy wchodzą ze sobą w interakcję i w jakiej kolejności następuje przepływ komunikatów. W odróżnieniu od diagramów sekwencji nie wskazuje na rozmieszczenie tych komunikatów w czasie.

clip_image010

Rysunek 10 Diagram komunikacji

W tym przykładzie podczas modelowania zachowania użyto jeszcze diagramu aktywności (rysunek 11) który wskazuje na ciąg czynności służących do wczytania pliki. Na diagramie tym zastosowano element decyzyjny, który pozwala na wybranie czy plik ma być w czytany czy też nie. Negatywna selekcja powoduje zakończenie scenariusza. Natomiast Pozytywna odpowiedź prowadzi do wczytania pliku, który na tym diagramie jest zobrazowany w postaci elementu <<datastore>> (nowość UML 2.0).

W procesie uszczegóławiania przypadku użycia można zastosować także maszyny stanowej, lub zwłaszcza przy systemach czasu rzeczywistego, diagramów przebiegów czasowych. Struktura systemu może zostać pogłębiona poprzez diagramy struktury, pakietów oraz komponentów. Zawsze wybór technik modelowania zależy od złożoności systemu oraz zagadnień , które chcemy uwypuklić.

clip_image012

Rysunek 11 Diagram aktywności

W kolejnej cześci (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – implementacja) zostanie opisana technika synchronizacji modelu aplikacji z jej kodem.

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

Dodawanie komentarzy zostało zablokowane.

Scroll to Top