Zadania do kursu podstawy modelowania w języku UML

powrót do kursu: Podstawy modelowania w języku UML
Na tej znajdziesz trzy różne zadania. Każde z nich ma inny poziom trudności.

SPIS ZADAŃ

Z.1 Bankomat

Opis sytuacji

Zadanie jest klasycznym zadaniem dotyczącym działania bankomatu.

mwBank (podmiot nie istnieje na rynku i został wymyślony na potrzeby ćwiczenia) w swojej sieci posiada bankomaty. Bankomat to automatyczne urządzenie służące przede wszystkim do wypłaty gotówki za pomocą magnetycznej lub inteligentnej (mikroprocesorowej, chipowej) karty płatniczej.

Korzystając z bankomatu, Klienci mogą uzyskać dostęp do swoich kont bankowych, aby dokonać wypłat gotówkowych (lub wypłacić zaliczki kartą kredytową) i sprawdzić salda tych kont.

Celem ćwiczenia jest opracowanie kilku diagramów opisujących sposób działania bankomatu. Weź pod uwagę, że poniższe opisy i powstałe na ich  podstawie modele nie będą do końca zgodne z rzeczywistością. W tym ćwiczeniu celem jest przygotowanie odpowiednich modeli zgodnych ze standardem UML.

 

Podmioty związane z pośrednio i bezpośrednio z bankomatem

Klient

Klient prowadzi transakcje za pomocą bankomatu. Może on lub ona wycofać kwoty pieniężne, sprawdzić saldo na koncie, środki depozytowe i przelać środki pieniężne między kontami. Osoba staje się Klientem w momencie, gdy otwiera konto w oddziale instytucji finansowej (mwBank).

Włamywacz

Włamywaczem jest każda osoba, która próbuje włamać się lub uszkodzić bankomat.

System bankowy

System Bankowy świadczy usługi dla bankomatu. System Bankowy ponosi odpowiedzialność za weryfikację Klientów, autoryzację transakcji i dostarczanie do systemu bankomatu (MWBB) informacji o kontach Klienta. System Bankowy pełni funkcję bramy do banku Klienta.

Administrator serwisu

Administrator serwisu jest odpowiedzialny za zapewnienie, że maszyny bankomatu spełniają wymagania w przypadku instalowania i prowadzenia kampanii reklamowych.

Administrator bezpieczeństwa

Administrator bezpieczeństwa monitoruje bankomaty pod kątem naruszenia bezpieczeństwa, polegającego na przykład na nieuczciwym wykorzystaniu karty i wszelkich próbach fizycznego włamania do bankomatu.

Pracownik techniczny

Pracownik techniczny jest odpowiedzialny za fizyczne utrzymanie bankomatu, ponowne napełnianie urządzenia gotówką i papierem, usuwanie wszelkich problemów mechanicznych i przeprowadzanie na miejscu konfiguracji urządzenia.

Operator

Operator odpowiada za działanie bankomatu, analizuje wydajność systemu (MWBB), uzgadnia konta między bankomatem a systemem bankowym oraz aktualizuje konfigurację systemu (MWBB).

 

Czynności związane z pracą bankomatu

Wypłata gotówki – klient może skorzystać z bankomatu w celu wypłaty pieniędzy z konta bankowego przypisanego do karty.

Wpłata gotówki – Klient może skorzystać z bankomatu w celu wpłaty pieniędzy na konto. Klient umieszcza pieniądze lub czeki w kopercie i wkłada kopertę do bankomatu. Koperty są bezpiecznie przechowywane wewnątrz maszyny, aż do momentu, gdy Pracownik Techniczny  zabierze je w późniejszym terminie w ramach codziennej konserwacji urządzenia.

Ponowne wypełnianie i obsługa maszyny – Pracownik Techniczny utrzymuje bieżącą sprawność bankomatu poprzez ponowne napełnianie maszyny gotówka, opróżnianie maszyny z wszelkich depozytów, ponowne napełnianie urządzenia papierem do wydruku pokwitowania i ogólnie odpowiada za serwisowanie sprzętu.

Konfiguracja urządzenia – Pracownik Techniczny przygotowuje lub konfiguruje bankomat aby zapewnić jego wspólpracę z Operatorem.

Sprawdzenie, czy bankomat jest sprawny pod względem operacyjnym – Pracownik Techniczny wykorzystuje bankomat do uruchamiania zestawu procedur diagnostycznych, aby upewnić się, że bankomat działa prawidłowo.

Analiza wydajność systemu – Operator może przeglądać wewnętrzne rejestry bankomatu w celu dokonania analizy wydajności i diagnozowania problemów.

Uzgadnianie rejestrów transakcji  – Proces opisuje, w jaki sposób Operator może skorzystać z bankomatu w celu uzgodnienia wszelkich różnic między historią transakcji a Systemem Bankowym. Błędy mogą powodować, że bankomat i System Bankowy mogą mieć różne zapisy dotyczące ilości pieniędzy, które zostały wydane i pobrane.

Aktualizacja konfiguracji systemu – Operator może aktualizować, możliwe do zmiany, parametry konfiguracji systemu (MWBB) bez konieczności wycofywania bankomatu z eksploatacji. Te dające się dostroić parametry obejmują między innymi zestaw obsługiwanych banków, maksymalną kwotę wypłaty, maksymalną kwotę depozytu oraz dostępny zestaw usług.

Prowadzenie kampanii reklamowej – Administrator Serwisu może korzystać z bankomatu w celu uruchomienia kampanii reklamowej, dzięki czemu wyświetlane są reklamy, gdy bankomat znajduje się w trybie oczekiwania oraz podczas każdego z przypadków użycia. Ten przypadek użycia jest realizowany w imieniu Działu Marketingu, jednej z głównych zainteresowanych stron tego projektu.

 

Zadania

Zadanie 1.1 – diagram przypadków użycia

Zidentyfikuj aktorów wchodzących w interakcję z bankomatem

Opisz minimum 3 przypadki użycia w zakresie:

  • Nazwa
  • Krótki opis
  • Warunki początkowe i końcowe
  • Scenariusze główne i alternatywne

Zadanie 1.2 – diagram klas

Przygotuj model BCE, który:

  • Klasą Boundary będzie reprezentował ekran bankomatu
  • Klasą Control obsłuży komunikację ekranu z pamięcią urządzenia.
  • Klasami Entity opisz dane w zakresie:
    • log transakcji wypłaty (nr karty, data, kwota)
    • statusy transakcji wypłaty i wpłaty
    • status zasobnika na banknoty
    • log transakcji wpłaty
    • ilość banknotów w zasobnik transakcji

Zadanie 1.3 – diagram obiektów

Na podstawie zdefiniowanego na diagramie klas modelu przygotuj diagram obiektów, na którym pokażesz następujące sytuacje:

  • transakcja odrzucona – brak środków
  • zasobnik nie ma banknotów o nominale 50 PLN.

Jeśli potrzeba zaktualizuj diagram klas o odpowiednie klasy typu entity.

Zadanie 1.4 – diagram aktywności

Narysuj diagram aktywności obrazujące scenariusze wypłaty i wpłaty gotówki do bankomatu.

Zadanie 1.5 – diagram maszyny stanowej

Narysuj diagram maszyny stanów dla bankomatu. Uwzględnij następujące stany:

  • gotowy do wypłaty
  • brak gotówki
  • brak połączenia z bankiem
  • blokada karty (wielokrotnie podano zły pin)
  • w trakcie wypłaty

Zadanie 1.6 – diagram sekwencji

Zaprezentuj (bazując na diagramie klas) scenariusze wypłaty i wpłaty gotówki do bankomatu.

Zadanie 1.7 – diagram komponentów

Przygotuj diagram komponentów pokazujący komunikację ze światem zewnętrznym (Bank, Operator bankomatu). Zdefiniuj interfejsy pomiędzy systemami.

 

powrót do kursu: Podstawy modelowania w języku UML
powrót do menu strony: do góry


Z.2 System Rejestracji Zajęć (SRZ)

Opis sytuacji

Przedmiotem ćwiczenia jest internetowy System Rejestracji Zajęć (SRZ).

Właśnie zostałeś wyznaczony na stanowisko głównego analityka systemu. Budowany jest nowy system. Przekazano ci opis problemu (“Wstępne Pytania dotyczące Systemu” poniżej).

Celem zadania jest opracowanie specyfikacji systemu wraz z wymaganiami.

Wstępne Pytania dotyczące Systemu

Wyższa Szkoła Analizy i Projektowania (WSAP) planuje stworzenie nowego internetowego Systemu Rejestracji Zajęć (dalej zwany SRZ lub system rejestracji). Nowy internetowy system zastępuje znacznie starszy system. Nowy system umożliwia studentom rejestrację na zajęcia z dowolnej przeglądarki internetowej. Nauczyciele korzystają z systemu, aby zarejestrować się na zajęcia, które będą prowadzić.

Ze względu na zmniejszenie finansowania z funduszy ministerstwa odpowiedzialnego za szkoły wyższe, uczelnia nie może sobie pozwolić na natychmiastową zmianę całego systemu.
Wyższa Szkoła Analizy i Projektowania (WSAP) będzie przechowywać istniejącą bazę katalogową zajęć, gdzie zachowane są wszystkie informacje o zajęciach.

Wydajność dotychczasowego systemu jest słaba, dlatego nowy System (SRZ) uzyskuje dostęp do informacji o zajęciach z zasobów dotychczasowych danych, ale ich nie aktualizuje.

Biuro rejestrów nadal utrzymuje informacje o planowanych zajęciach poprzez inny system.
Studenci mogą poprosić o drukowany katalog zajęć zawierający listę oferowanych kursów w danym semestrze. Studenci mogą również w dowolnym momencie uzyskać w Internecie informacje o zajęciach. Informacje dotyczące każdego z zajęć, takie jak nazwisko prowadzącego, dział, godziny zaliczeniowe i warunki wstępne pomagające studentom w podejmowaniu świadomych decyzji.

Nowy system (SRZ) umożliwia studentom wybór czterech zajęć na nadchodzący semestr. Ponadto, każdy student wskazuje na dwa alternatywne wybory zajęć w przypadku, gdy student nie może być przypisany do głównego wyboru. W zajęciach może uczestniczyć maksymalnie dziesięciu a minimalnie trzech studentów.

Proces rejestracji kończy się pierwszego lub drugiego dnia zajęć w danym semestrze.
Każde zajęcia, na które na dzień zamknięcia rejestracji zapisało się mniej niż trzech studentów są odwoływane. Wszystkie zajęcia, które nie mają wyznaczonego prowadzącego na dzień zamknięcia rejestracji są odwoływane. Studenci, którzy są zapisani na zajęcia, które zostały odwołane zostają powiadomieni, że zajęcia zostały odwołane, i takie zajęcia są usuwane z harmonogramów. System rejestracji (SRZ) przesyła informacje o wszystkich zapisanych studentach do Systemu Rozliczeniowego, po to, aby można było każdemu studentowi wystawić fakturę za dany semestr.

Przez pierwsze dwa tygodnie semestru studenci mogą zmienić harmonogramy zajęć. W tym czasie studenci mogą uzyskać dostęp do systemu online, aby dodać lub usunąć zajęcia. Zmiany w harmonogramach są natychmiast przesyłane do Systemu Rozliczeniowego, tak, aby można było przesłać studentom zaktualizowaną fakturę za semestr. Faktury są wysyłane po zakończeniu dwutygodniowego okresu zmiany zajęć.

Pod koniec semestru student może uzyskać dostęp do systemu, aby wyświetlić elektroniczny raport. Ponieważ oceny studentów są informacjami poufnymi, system musi posiadać środki bezpieczeństwa mające na celu zapobieganie nieuprawnionemu dostępowi.

Wszyscy studenci, nauczyciele i administratorzy posiadają własne kody identyfikacyjne i hasła.

Nauczyciele muszą mieć dostęp do systemu online w celu wybrania zajęć, jakie chcą prowadzić. Muszą też sprawdzić, którzy studenci zapisali się na ich zajęcia. Ponadto nauczyciele mogą rejestrować oceny uczniów na każdych zajęciach.

 

Zadania

Zadanie 2.1 – diagram przypadków użycia i wymagania

  1. Zdefiniuj wymagania funkcjonalne i niefunkcjonalne na SRZ
  2. Zidentyfikuj aktorów wchodzących w interakcję system
  3. Opisz minimum 3 przypadki użycia w zakresie w zakresie:
    1. Nazwa
    2. Krótki opis
    3. Warunki początkowe i końcowe
    4. Scenariusze główne i alternatywne
  4. Podłącz wymagania do zdefiniowanych przypadków użycia.

Zadanie 2.2 – diagram klas

Korzystając z diagramu klas, przygotuj model, który opisuje dane przetwarzane w systemie SRZ

Budując ten model dodaj:

  • atrybuty
  • relacje pomiędzy klasami
  • liczebności

Model powinien swoim zakresem obejmować dane dotyczące minimum: studenta, wykładowcy,  zajęć, statusu zajęć i harmonogramu,

Zadanie 2.3 – diagram obiektów

Na podstawie zdefiniowanego na diagramie klas modelu przygotuj diagram obiektów, na którym pokażesz następujące sytuacje:

  • zajęcia na które na dzień zamknięcia rejestracji zapisało się mniej niż trzech studentów są odwoływane,
  • wszystkie zajęcia, które nie mają wyznaczonego prowadzącego na dzień zamknięcia rejestracji są odwoływane,

Jeśli potrzeba zaktualizuj diagram klas o odpowiednie klasy.

Zadanie 2.4 – diagram aktywności

Narysuj diagram aktywności obrazujące następujące scenariusz:

Student zapisuje się na zajęcia. Ma do wyboru cztery zajęcia na nadchodzący semestr. Ponadto, każdy student wskazuje na dwa alternatywne wybory zajęć w przypadku, gdy student nie może być przypisany do głównego wyboru.

Na diagramie uwzględnij obiekty. Nie zapomnij o partycjach, które powinny reprezentować system oraz studenta.  Dopuszczalne jest zdekomponowanie wybranych aktywności.

Zadanie 2.5 – diagram maszyny stanowej

Narysuj diagram maszyny stanów dla harmonogramu zajęć:

  • harmonogram pusty – przed zapisami
  • w trakcie zapisów
  • w trakcie zmian (2 tyg. po zapisaniu się)
  • zatwierdzony

Specyfikując diagram uwzględnij, o ile występują, warunki dozoru, akcje oraz wyzwalacze.

Zadanie 2.6 – diagram komponentów

Przygotuj diagram komponentów pokazujący architekturę rozwiązania. Zdefiniuj komponenty i interfejsy. Do interfejsów zdefiniuj odpowiednie operacje. Interfejsy przypisz do komponentów.

Diagram powinien zawierać:

  • System Rejestracji Zajęć – system online(przedmiot projektu), który umożliwia zapisanie się na zajęcia.
  • System Rozliczeniowy – wystawia faktury za zajecia
  • System Katalog Zajęć  – bazę katalogową zajęć, gdzie zachowane są wszystkie informacje o zajęciach
  • System powiadomień – wysyła powiadomienia

Zadanie 2.7 – diagram sekwencji

Zadanie wykonaj po przygotowaniu diagramu komponentów.

Narysuj diagram sekwencji. Wykorzystaj komponenty z zadania 2.6. Na komunikatach wykorzystaj operacje zdefiniowane w interfejsach.  W razie potrzeby zaktualizuj operacje.

  • Studenci, którzy są zapisani na zajęcia, które zostały odwołane zostają powiadomieni, że zajęcia zostały odwołane, i takie zajęcia są usuwane z harmonogramów.
  • System rejestracji (SRZ) przesyła informacje o wszystkich zapisanych studentach do Systemu Rozliczeniowego, po to, aby można było każdemu studentowi wystawić fakturę za dany semestr. Zmiany w harmonogramach są natychmiast przesyłane do Systemu Rozliczeniowego, tak, aby można było przesłać studentom zaktualizowaną fakturę za semestr.

 

powrót do kursu: Podstawy modelowania w języku UML
powrót do menu strony: do góry


Z.3 Hotel

 

Opis sytuacji

Hotel „Pod Wiązem” jest statystycznie średniej wielkości placówką (ok. 100 pokoi). Hotel posiada również dwa punkty gastronomiczne, fitness klub oraz kilka sal konferencyjnych.

Proces telefonicznej rezerwacji pokoju hotelowego przez klienta wygląda następująco:

  1. Klient dzwoni do recepcji hotelu i prosi o rezerwację pokoju, podaje datę przybycia, liczbę dni i ilość osób.
  2. Recepcjonista sprawdza w systemie czy są wolne pokoje w określonym terminie i przekazuje tę informację klientowi.
  3. Po zapadnięciu decyzji odnośnie rezerwacji pokoju hotelowego, klient podaje swoje dane kontaktowe i dane karty kredytowej.
  4. Recepcjonista weryfikuje kartę kredytową, rezerwuje pokój i przekazuje tę informację klientowi.

Właściciel Hotelu pragnie zwiększyć procent obłożenia pokoi. Wdrożenie rezerwacji przez Internet połączone z odpowiednią kampanią marketingową wydaje się być dobrym rozwiązaniem.

Obłożenie pokoi wymaga zwiększenia efektywności zespołu odpowiedzialnego za obsługę techniczną pokoi. W związku z tym należy wesprzeć proces lub procesy związane z  przydzielaniem i realizacją prac związanych z utrzymaniem czystości pokoi hotelowych.

Aktualny proces realizacji prac związanych z utrzymaniem czystości pokoi wygląda następująco:

  1. Szef/Szefowa służby pięter na podstawie informacji z recepcji o zwolnieniu pokoju, zleca sprzątaczce posprzątanie danego pomieszczenia
  2. Sprzątaczka realizuje zlecone zadanie
  3. Sprzątaczka informuje Szefa/Szefową służby pięter o wykonaniu zadania

Właściciel Hotelu  chce wspomóc ten proces poprzez:

  • wprowadzenie systemu umożliwiającego ręczne i automatyczne przydzielanie prac pracownikom służby pięter
    • ręczne – posprzątanie schodów, pokoju lub innego pomieszczenia na skutek nieprzewidzianego zanieczyszczenia przez Gościa hotelowego zlecone przez Recepcjonistę
    • automatyczne – zdarzenia w systemie: wymeldowanie Gościa hotelowego generuje zadanie posprzątania pokoju; zbliżający się termin rezerwacji generuje zadanie przygotowania pościeli
  • wprowadzanie automatycznego doliczenia do rachunku kosztów nieplanowanych prac sprzątaczek, a także kosztów związanych z uzupełnieniem pokojowych minibarów.

Dodatkowe wymagania stawiane dla rozwiązania:

  • Sprzątaczki powinny być wyposażone w urządzenia przenośne (telefon, tablet) z aplikacją mHOTEL
  • komunikacja aplikacji z urządzeń przenośnych z systemem zarządzania hotelem HOTEL tylko w ramach wewnętrznej sieci bezprzewodowej
  • rezerwowanie pokoi hotelowych za pośrednictwem sieci Internet przy użyciu dowolnej przeglądarki internetowej
  • zapewnienie bezpiecznej komunikacji
  • zapewnienie szerokich kryteriów wyszukiwania
  • Rezerwację pokoi hotelowych zapewnia system HOTEL. System Hotel  posiada moduły: Rezerwacje, Fakturowanie, Sprzątanie.

Aplikacje:

  • Hotel – aplikacja wspierajaca rezerwację oraz zarządzanie czystością w hotelu (zwna również system Hotel)
  • mHotel – aplikacja mobilna – wspołpracuje z aplikacją Hotel

Zadania

Zadanie 3.1 – diagram przypadków użycia i wymagania

  1. Zdefiniuj wymagania funkcjonalne i niefunkcjonalne dla apliacji mHotel i Hotel
  2. Zidentyfikuj aktorów wchodzących w interakcję systemami
  3. Opisz minimum 3 przypadki użycia w zakresie w zakresie:
    1. Nazwa
    2. Krótki opis
    3. Warunki początkowe i końcowe
    4. Scenariusze główne i alternatywne
  4. Podłącz wymagania do zdefiniowanych przypadków użycia.

Zadanie 3.2 – diagram klas

Korzystając z diagramu klas, przygotuj model, który opisuje dane przetwarzane w systemach Hotel i mHotel

Budując ten model dodaj:

  • atrybuty
  • relacje pomiędzy klasami
  • liczebności

Model powinien swoim zakresem obejmować dane dotyczące minimum: rezerwacji i zleceń sprzątania.

 

Zadanie 3.3 – diagram aktywności

Narysuj diagram aktywności dla scenariusza działania aplikacji, w którym:

  • wymeldowanie Gościa hotelowego generuje zadanie posprzątania pokoju;
  • zbliżający się termin rezerwacji generuje zadanie przygotowania pościeli

Zadanie 3.4 – diagram maszyny stanowej

Narysuj diagram maszyny stanów dla stanu pokoju np.: posprzątany w trakcie sprzątania, zajęty, oczekujęcy na sprzątanie, dodatkowe sprzątanie.

Specyfikując diagram uwzględnij, o ile występują, warunki dozoru, akcje oraz wyzwalacze.

Zadanie 3.5 – diagram komponentów

Przygotuj diagram komponentów pokazujący architekturę rozwiązania. Zdefiniuj komponenty i interfejsy. Do interfejsów zdefiniuj odpowiednie operacje. Interfejsy przypisz do komponentów. Nie zapomnij o architekturze wewnętrznej aplikcji Hotel.

Zadanie 3.6 – diagram sekwencji

Zadanie wykonaj po przygotowaniu diagramu komponentów.

Narysuj diagramy sekwencji. Wykorzystaj komponenty z zadania 3.5. Na komunikatach wykorzystaj operacje zdefiniowane w interfejsach.  W razie potrzeby zaktualizuj operacje.

  • zgłoszenie  pokoju do sprzątania w aplikacji Hotel wraz z powiadomieniem w aplikacji mHotel
  • zgłoszenie w aplikacji mHotel realizacji dodatkowego posprzątania pokoju co skutkować będzie doliczeniem dodatkowej opłaty do rachunku gościa

Zadanie 3.7 – diagram wdrożenia

Przygotuj diagram wdrożenia, na którym zaprezentujesz architekturę fizyczną aplikacji Hotel. Architektura fizyczna powinna obejmować swoim zakresem bazę danych (np.: PostgreSql), serwer www (Apache) oraz środowisko zapasowe. Weź pod uwagę, ze baza danych oraz serwer www są na innych maszynach. Nine zapomnij tez o aplikacji mobilnej 🙂

Zadanie 3.8 – diagram widoku interkacji

Przygotuj diagram widoku interakcji, na którym zaprezentujesz sekwencję działania aplikacji:

  • zgłoszenie  pokoju do sprzątania w aplikacji Hotel wraz z powiadomieniem w aplikacji mHotel
  • zgłoszenie w aplikacji mHotel realizacji dodatkowego posprzątania pokoju co skutkować będzie doliczeniem dodatkowej opłaty do rachunku gościa

Do zrealizowania diagramu wykorzystaj  diagramy przygotowane w zadaniu 3.6

 

powrót do kursu: Podstawy modelowania w języku UML
powrót do menu strony: do góry


Przewiń do góry