WOJSKOWA AKADEMIA TECHNICZNA

im. Jarosława Dąbrowskiego

WYDZIAŁ CYBERNETYKI

ANALIZA I PROJEKTOWANIE SYSTEMÓW TELEINFORMATYCZNYCH

Sprawozdanie z laboratorium nr 2

Temat: System pobierania opłat za paczki pocztowe.

Zespół: Marcin Przerwa Marek Oleksiak Krzysztof Piotrowski Kamil Piersa Maciej Prokopczyk Paweł Mieczkowski Kamil Michniewicz Tomasz Majewski	Prowadzący: mgr inż. Kamil Komański Wykonano: 10.01.2012

W a r s z a w a 2012

Wstęp

Zespół projektowy

Skład zespołu projektowego (Grupa I0H1S4, Podgrupa 2):

• MarcinPrzerwa (kierownikzespołu)

• KamilPiersa

• MarekOleksiak

• Krzysztof Piotrowski

• MaciejProkopczyk

• KamilMichniewicz

• Tomasz Majewski

• PawełMieczkowski

Treść zadania

a. Zaawansowane modelowanie statyki ST

• Zadaniem grupy studentów jest rozpoznanie narzędzi i zamodelowanie diagramów klas dla wybranego przez prowadzącego na pierwszych zajęciach systemu z użyciem OCL i wzorców projektowych (strukturalnych).

b. Modele architektoniczne

• Zadaniem grupy studentów jest rozpoznanie narzędzi i zamodelowanie diagramów komponentów, dla wybranego przez prowadzącego na pierwszych zajęciach systemu oraz przeprowadzenie 10 minutowej prezentacji dotyczącej podejścia wybranego przez wykładowcę pojęcia (MDA, MDD, TDD).

Zaawansowane modelowanie statyki ST

Diagram klas

Najważniejszą cechą diagramu klas jest to, że zawiera informacje między elementami (klasami) projektowanego systemu. Opracowany diagram klas dla systemu pobierania opłat za paczki pocztowe przedstawia Rysunek 1.

Rysunek 1. Diagram klas

Najistotniejszym elementem na diagramie jest klasa ZarzadcaSystemu ze stereotypem Singleton. Oznacza to, że w systemie występuje tylko jeden zarządca systemu oraz ma zapewniony globalny punkt dostępu przez pozostałe obiekty. Poza tym, przechwytuje żądania powstania licznych instancji oraz zapewnia łatwy dostęp do już istniejącej. Użytkownik ma możliwość zarządzania systemem poprzez interfejs GUI. ZarządcaSystemu wykorzystując interfejs IDatabaseProvider realizuje operacje Bazy danych (również Singleton – bezpieczne rozwiązanie, gdyż obiekt powstanie i zostanie zniszczony tylko raz). Według diagramu jedno lub wiele zleceń może zostać zrealizowanych przez ZarzadceSystemu, a dzięki Magazynowi Przesyłek zarządca posiada informacje o przesyłce (adresie i wadze i rozmiarze). Zarządca używa Systemu Płatniczego do realizacji operacji Systemu Bankowego.

Pogrupowanie systemu w pakiety

Podczas modelowania wszystkie elementy systemu zostały pogrupowane w sposób pokazany na Rysunku 2.

Rysunek 2. Elementy systemu podzielone na pakiety

Wszystkie elementy systemu zostały podzielone na następujące pakiety:

• System Główny (odpowiedzialny za realizację głównych zadań przez system ), który zawiera klasy: Adres, Przesylka, WagaiRozmiar, Zlecenie, MagazynPrzesylek i ZarzadcaSystemu.

• System Bazodanowy (odpowiedzialny za przechowywanie danych w systemie), który uwzględnia klasy BazaDanych, IDatabaseProvider –.

• System Płatniczy (odpowiedzialny realizujący operacji związanych z płatnościami) zawierający klasy SystemPlatniczy i SystemBankowy.

• System Komunikacyjny - odpowiedzialny za komunikację z użytkownikiem systemu.

Tak jak i na diagramie klas zostały uwzględnione krotności pomiędzy poszczególnymi klasami.

Rysunek 3 przedstawia zależności pomiędzy poszczególnymi pakietami systemu.

Rysunek 3. Zależności pomiędzy pakietami

Zależności od Systemu Głównego wynikają z wykorzystywania interfejsów zawartych we wskazywanych pakietach. System Płatniczy powiązany jest z Systemem Bazodanowym w celu archiwizowania wpłat a z Systemem Komunikacyjnym w celu wykonywania operacji płatniczych.

Wzorce projektowe

• Wzorzec kreacyjny

Jak wspomniano przy opisywanym diagramie klas wybranym przez nas wzorcem kreacyjnym jest Singleton. Wzorzec ten używany jest do ograniczenia wystąpień liczby instancji klasy do jednego obiektu. Wzorzec zapewnia także globalny dostęp do utworzonego obiektu. Wzorzec Singleton wykorzystamy do stworzenia obiektu odpowiedzialnego za wykonywanie operacji na bazie danych przetrzymujących dane o płatnościach. Zapewni nam to gwarancję tego, że na bazie danych będzie wykonywana jedna tranzakcja w danym momencie. Singleton tworzony jest w momencie, gdy jest potrzebny.

Rysunek 4. Wzorzec kreacyjny Singleton

Ograniczenia OCL

Następną fazą jaka została przyjęta podczas modelowania statyki było nałożenie ograniczeń OCL na klasy Przesylka, Adres, Zlecenie co widać na Rysunku 4.

Rysunek 5. Ograniczenia OCL

Ograniczenie dla kasy Przesylka:

Podane ograniczenie wymaga, aby przesyłka miała podany adres odbiorcy i nadawcy, gdyż tylko wtedy będzie mogła być obsłużona przez system.

Ograniczenie dla kasy Adres:

Ograniczenie wymaga aby w adresie nie były puste pola Imie, Nazwisko, NrDomu, KodPocztowy, Miejscowosc.

Ograniczenie dla kasy Zlecenie:

W celu zrealizowania zlecenia data przyjęcia paczki nie może być wcześniejsza od daty jej realizacji. Dodatkowo, numer zlecenia musi być unikatowy.

Modele architektoniczne

Kolejnym krokiem było zamodelowanie diagramu komponentów (Rysunek 5), który pokazuje podział systemu programowego na mniejsze podsystemy. W niniejszym przypadku poszczególny komponent reprezentowany jest przez odpowiedni pakiet. Komponenty realizowane są przez struktury, które wykorzystują porty i interfejsy dostarczane bądź wymagane.

Rysunek 6. Diagram komponentów

System, który wcześniej został podzielony na pakiety (Rysunek 2) można przedstawić w postaci diagramu struktury wewnętrznej, co widać na Rysunku 6.

Rysunek 7. Diagram struktury wewnętrznej

Diagram pokazuje zależności między komponentami za pomocą interfejsów i portów. Interfejsy od komponentu MainSystem są wymagane, natomiast interfejsy od komponentów DatabaseProvider, GUI, PaymentSystem są dostarczane.

Poniższe rysunki (od do ) uszczegóławiają powyższy diagram – ilustrując klasy jakie występują w poszczególnych komponentach.

Rysunek 8. Struktura wewnętrzna Systemu Głównego

Rysunek 9. Struktura wewnętrzna Systemu Komunikacyjnego

Rysunek 10. Struktura wewnętrzna Systemu Bazodanowego

Rysunek 11. Struktura wewnętrzna Systemu Płatniczego

Rysunek 12 pokazuje zależności pomiędzy przedstawionymi wcześniej komponentami. Z uwagi na to, że opierają się one na pakietach (dzielące elementy systemu) zależności te są takie same.

Rysunek 12. Zależności pomiędzy komponentami

Wnioski

Modelowanie statyki systemów teleinformatycznych pozwala na uzyskanie modelu reprezentującego kluczowe elementy modelowanego systemu. Podczas realizacji zadania laboratoryjnego nauczyliśmy się modelować statykę oraz architekturę systemu IT. Wykorzystaliśmy także język OCL, który świetnie się nadaje do wprowadzania ograniczeń. Ważnym elementem modelowania statyki ST jest grupowanie klas w pakiety co pozwala na lepsze zrozumienie podsystemów modelowanego systemu. W naszym modelu każdy pakiet składał się z grupy klas oraz interfejsów, które tworzyły także pojedynczy komponent. Przy modelowaniu komponentów użyliśmy struktur wykorzystujących porty oraz interfejsy dostarczane lub wymagane. Środowisko Rational Software Architect pozwala na stworzenie wielu bardzo dokładnych oraz złożonych diagramów a co najważniejsze całych struktur modeli. Oprogramowanie to pozwala także w łatwy sposób modelować ograniczenia OCL a także przeprowadzać test ich poprawności. Tworzenie modeli architektonicznych ułatwia zrozumienie współdziałania oraz komunikowania się ze sobą różnych podsystemów występujących w modelowanym systemie. Pozwala to na jeszcze lepsze zrozumienie problemu.