WOJSKOWA AKADEMIA TECHNICZNA

im. Jarosława Dąbrowskiego

WYDZIAŁ CYBERNETYKI

Analiza i modelowanie systemów teleinformatycznych

Ćwiczenie laboratoryjne nr 2

Autorzy:	Prowadzący:
Adrian MYŚLIWIEC Mateusz SUCHOCKI Tomasz TROJANOWSKI	mgr inż. Łukasz LASZKO

Treść zadania:

Na podstawie opisu firmy zajmującej się produkcją oprogramowania z dziedziny bezpieczeństwa teleinformatycznego, który był przedstawiony w ramach laboratorium nr 1 oraz opracowanego modelu biznesowego organizacji, przedstaw model wymagań na system elektronicznego obiegu informacji (EDI) dla tej firmy, który najlepiej spełni jej nadzieje związane z wprowadzeniem środków IT do wsparcia swojej działalności.

Zadania szczegółowe:

0.  Przeprowadź mapowanie obiektów opracowanego modelu biznesowego na aktorów i przypadki użycia,

1. W repozytorium modeli werbalnych (RRp) przedstaw, co najmniej, wymagania typu:

• ACT,

• STRQ,

• TERM,

• FEAT,

• UC+SR,

gdzie ACT będzie nowym typem wymagań na aktora projektowanego systemu,

2. Przedstaw jak wymagania typu STRQ będą odwzorowane na cechy systemu, na podstawie macierzy śledzenia (RRp),

3. Przedstaw jak wymagania typu FEAT są zaspokajane przez UC, na podstawie macierzy śledzenia (RRp),

3. Wygeneruj i uzupełnij dokument specyfikacji przypadków użycia (UCS) i dokument wizji (VD),

4. Dokonaj asocjowania repozytorium werbalnego (RRp) z wizualnym (RSA) oraz przedstaw UC w sposób graficzny,

5. Przedstaw realizacje kluczowych przypadków użycia:

• scenariusz przedstaw w postaci diagramu sekwencji (SD),

• wymaganą strukturę systemu przedstaw w postaci diagramu clas (CD).

 

1. Realizacja zadania

Pierwszy etap zadania polegał na zdefiniowaniu wymagań w modelu werbalny na system EDI. Wymagania zostały określone w oprogramowaniu Rational RequisietPro. Wyniki uzyskane po wykonaniu tego zadania zostały przedstawione na poniższych rysunkach.

Rysunek 1.1 Wymagania typu STRQ

Rysunek 1.2 Wymagania typu TERM

Rysunek 1.3 Wymagania typu ACT

Rysunek 1.4 Wymagania typu FEAT

Rysunek 1.5 Wymagania typu UC

Rysunek 1.6 Wymagania typu SR

W kolejnym etapie zadania należało przedstawić w postaci macierzy śledzenia, jak odwzorowywane będą wymagania typu STRQ na cechy systemu. Na poniższym rysunku przedstawiony został wynika realizacji tego zadania.

Rysunek 1.7 Macierz śledzenia dla wymagań typu STRQ

Następnie analogicznie do wcześniejszego zdania należało przedstawić macierz śledzenia. W tym przypadku uwidocznione zostało jak wymagania typu FEAT są zaspakajane przez UC. Poniższy rysunek przedstawia wynik realizacji tego zdania.

Rysunek 1.8 Macierz śledzenia dla wymagań typu FEAT

W tym etapie zadania należało dokonać asocjacji repozytoriów: werbalnego (Rational RequisitePro) i wizualnego (Rational Software Architect). Po wykonaniu asocjacji należało dokonać wizualizacji przypadków użycia (UC).

Rysunek 1.9 Widok okna RSA po asocjacja repozytorium RRp z RSA

Rysunek 1.10 Przypadki użycia

Ostatnie zadanie polegało na przedstawieniu realizacji kluczowych przypadków użycia. Zadanie to zostało zrealizowane w dwóch etapach. W pierwszym etapie zrealizowane zostały scenariusze przy wykorzystaniu diagramu sekwencji. W drugim etapie zadania została przedstawiona struktura systemu w postaci diagramu klas.

Rysunek 1.11 Diagram sekwencji dla przypadku użycia „Wyślij wiadomość”

Rysunek 1.12 Diagram sekwencji dla przypadku użycia „Wystaw fakturę”

Rysunek 1.13 Przypadek użycia „Dodaj konto użytkownika”

Rysunek 1.14 Diagram klas struktury systemu

1. Wnioski

Do realizacji zdania laboratoryjnego posłużyło oprogramowanie dostarczane przez IBM. Pierwszy etap zadania, w którym należało zdefiniować wymagania na system został zrealizowany przy użyciu programu Rational RequisitePro. Dostarcza on wiele funkcji ułatwiających tworzenie modeli werbalnych. Jednym z atutów tego oprogramowanie jest integracja z edytorem tekstowym Microsoft Word 2003, mianowicie dostępna jest funkcja generowania dokumentów tekstowych dotyczących modelowanego systemu, co znacznie usprawnia i ułatwia pracę. W dalszej części zadania posłużono się programem Rational Software Architekt. Udostępnia on narzędzia do wizualnego modelowania tworzonego systemu. Możliwa jest integracja obu wymienionych programów firmy IBM, dzięki czemu po wykonaniu etapu specyfikacji wymagań w RRp możliwe jest przeniesienie danych do programu RSA, w którym przy użyciu tych danych tworzone są diagramy.