Realizacja Projektu Informatycznego

Projekt

Etap VI

RUP: Definicja architektury systemu

1. O projekcie

Tworzony system przeznaczony jest dla Komend Wojewódzkich Policji, a konkretniej dla Wydziału Gospodarki Materiałowo-Technicznej KWP. Jego głównym zadaniem będzie poprawienie jakości administracją danych poprzez:

• ujednolicenie poprzedniego systemu komputerowego z systemem papierowym;

• przystosowanie do unijnych standardów;

• skrócenie czasu dostępu do danych oraz dodawania nowych;

• zwiększenie przejrzystości;

• zwiększenie bezpieczeństwa przechowywania danych;

• zmniejszenie kosztów związanych z przechowywaniem i przetwarzaniem danych;

• zwiększenie kontroli nad podmiotami i rozdysponowywanym sprzętem.

Wyżej wymionione cele zostaną zrealizowane poprzez zaimplementowanie bazy danych oraz aplikacji klienckiej, umożliwiającej przeprowadzenie określonych operacji na owej bazie.

Głównymi ograniczeniami, które mają wpływ na kształt systemu są:

• Krótki czas przeznaczony na realizację projektu;

• System jest przeznaczony do pracy w środowisku komercyjnym (Windows);

• Łatwy w obłudze, przejrzysty i intuicyjny interfejs;

• Stacje docelowe winny być wyposażone w odpowiednie oprogramowanie, a także posiadać dostęp do Internetu.

W skład zespołu wchodzą dwie osoby, podzielone miedzy soba zadaniami i rolami: Michał Golon, Michał Czyżykowski.

2. Model przypadków użycia

Wyróżniamy trzech aktorów:

• KLIENT,

• KWATERMISTRZ,

• MAGAZYNIER.

1. 
   Diagram przypadków użycia

2. Opis przypadków użycia

Przeglądanie listy zamówień klienta

Warunki początkowe:

KLIENT zalogowany.

Przebieg:

1. KLIENT zgłasza żądanie przeglądania listy swoich zamówień.

2. System prezentuje listę zamówień klienta (nr zamówienia).

3. Będąc w trybie przeglądania listy, KLIENT może przeglądać konkretne zamówienie (patrz: Przeglądanie zamównienia klienta), anulować zamówienie (patrz: Anulowanie zamówienia ) oraz zaznaczyć zamónienie jako „dostarczone” (patrz: Potwierdzenie dostawy).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przeglądanie zamówienia klienta

Warunki początkowe:

KLIENT zalogowany.

System w trybie przeglądania listy zamówień klienta.

Przebieg:

1. KLIENT składa żądanie przeglądania swojego zamówienia.

2. System prezentuje informacje dotyczące wybranego zamównienia:

- nr zamówienia,

- typy zamówionych produktów,

- nazwy (ew. modele) zamówionych produktów,

- ilości zamówionych produktów,

- status zamównienia.

3. Będąc w trubie przeglądania, KLIENT ma możliwość edycji zamównienia (patrz: Edycja zamównienia (KLIENT)).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Potwierdzenie dostawy

Warunki początkowe:

KLIENT zalogowany.

System w trybie przeglądania listy zamówień klienta.

Zamównienie musi posiadać status „zrealizowano”.

Przebieg:

1. KLIENT zgłasza żądanie zaznaczenia zamównienia jako „dostarczone”.

2. KLIENT zaznacza wybrane zamównienie jako „dostarczone”.

3. System zapamiętuje zmiany i przenosi zamównienie do archiwum.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System przenosi zamównienie do archiwum. Zamównienie znika ze wszystkich innych list.

Edycja zamówienia (KLIENT)

Warunki początkowe:

KLIENT zalogowany.

System w trybie przeglądania zamównienia klienta.

Zamównienie musi posiadać status „brak statusu” .

Przebieg:

1. KLIENT zgłasza żądanie edycji wybranego zamówienia.

2. System udostępnia pola formularza zamówienia do edycji (takie same jak w przypadku Dostęp do formularza).

3. KLIENT dokonuje zmian.

4. Zatwierdzenie zmian przez KLIENTA.

5. System zapamiętuje wprowadzone zmiany.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapamiętuje zmiany.

Anulowanie zamówienia

Warunki początkowe:

KLIENT zalogowany.

System w trybie przeglądania listy zamówień klienta.

Przebieg:

1. KLIENT zgłasza żądanie anulowania wybranego zamówienia.

2. KLIENT wybiera z listy zamównienia do usunięcia.

3. System usuwa wybrane zamówienia i przesyła do KWATERMISTRZA informację o anulowaniu.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System usuwa anulowane zamówienia i wysyła stosowną informację do podmiotu nadrzędnego.

Edycja stanu podmiotu

Warunki początkowe:

KLIENT zalogowany.

System w trybie przeglądania stanu podmiotu.

Przebieg:

1. KLIENT zgłasza żądanie edycji stanu podmiotu.

2. System prezentuje pola do edycji:

- typy produktów (lista rozwijana),

- nazwy (ew. modele) produktów (lista rozwijana),

- ilość produktów.

3. KLIENT dokonuje zmian.

4. System wymaga dodatkowej autoryzacji.

5. System zapamiętuje dokonane zmiany (wyjątek: „Błąd przy autoryzacji”).

6. Będąc w trybie edycji stanu podmiotu, użytkownik może dodać nowy asortyment (patrz: Dodanie nowego produktu (KLIENT)).

Przebiegi alternatywne:

Wyjątek: „Błąd przy autoryzacji”:

A1. System informuje użytkownika o nieprawidłowym haśle. Autoryzacja jest ponawiana. Trzykrotna nieudana próba powoduje automatyczne wylogowanie z systemu i zablokowanie konta.

Warunki końcowe:

System zapamiętuje wprowadzone zmiany.

Dodanie nowego produktu (KLIENT)

Warunki początkowe:

KLIENT zalogowany.

System w trybie edycji stanu podmiotu.

Przebieg:

1. KLIENT zgłasza żądanie dodania nowego przedmiotu.

2. System udostepnia:

- lista rozwijana z typami produktów,

- lista rozwijana z nazwami (ew. modelami) produktów,

- polem do wpisania ilości nowego produktu.

3. KLIENT dokonuje stosownych operacji.

4. System wymaga dodatkowej autoryzacji.

5. System zapamiętuje nowe dane (wyjątek: „Błąd przy autoryzacji”).

Przebiegi alternatywne:

Wyjątek: „Błąd przy autoryzacji”:

A1. System informuje użytkownika o nieprawidłowym haśle. Autoryzacja jest ponawiana. Trzykrotna nieudana próba powoduje automatyczne wylogowanie z systemu i zablokowanie konta.

Warunki końcowe:

System zapamiętuje nowe dane.

Dostęp do formularza zamówień

Warunki początkowe:

KLIENT zalogowany.

Przebieg:

1. KLIENT zgłasza żądanie dostępu do formularza zamówień.

2. System udostępnia formularz:

- lista rozwijana z typem asortymentu:

- materiały budowlane,

- broń,

- amunicja,

- umundurowanie,

- materiały bhp,

- artykuły biurowe.

- lista rozwijana z nazwami (ew. modelami) asortymentu, w zależności od wybranego typu,

- pola do określenia ilości wybranego asortymentu.

3. KLIENT zatwierdza wprowadzone dane.

4. System zapisuje zamównienie i umieszcza na liście zamówień klienta oraz liście zamówień przeglądanej przez KWATERMISTRZA.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapisuje zamówienie i umieszcza na odpowiednich listach.

Przeglądanie listy zamówień

Warunki początkowe:

KWATERMISTRZ zalogowany.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie przeglądania listy zamówień.

2. Istnieje możliwość wyboru kryterium wyświetlania zamówień (wg statusu):

- wszystkie,

- zarejestrowane,

- wstrzymane,

- opóźnione,

- niezarejestrowane (bez statusu),

- w trakcie realizacji.

3. System prezentuje listę zamówień (uwzględniając nazwę klienta i nr zamówienia).

4. Będąc w trybie przeglądania, KWATERMISTRZ może:

- wyświetlić zawartość wybranego zamównienia (patrz: Przeglądanie zamówienia).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przeglądanie zamównienia

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania listy zamównień.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie przeglądania zamówienia.

2. System wyświetla informacje dotyczące wybranego zamówienia:

- nazwę klienta i nr zamówienia;

- typy produktów,

- nazwy (ew. modele) produktów,

- ilość zamówionych produktów,

- status zamówienia.

3. Będąc w trybie przeglądania, KWATERMISTRZ może:

- zarejestrować zamówienie (patrz: Rejestracja zamówienia),

- wstrzymać realizację zamówienia (patrz: Wstrzymanie realizacji zamówienia),

- odmówić realizacji zamówienia (patrz: Odmowa realizacji zamówienia),

- edytować wybrane zamówienie (patrz: Edycja zamówienia (KWATERMISTRZ)),

- przechodząc do trybu edycji, zmienić status zamówienia (patrz: Zmiana statusu zamówienia (KWATERMISTRZ)).

Przebiegi alternatywne:

W przypadku wybrania jednej z powyższych opcji i zatwierdzeniu jej, po powrocie do trybu przeglądania zamównienia opcje te nie są dłużej dostępne (za wyjątkiem edycji zamówienia).

Warunki końcowe:

Brak.

Rejestracja zamówienia

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania zamówienia.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie rejestracji wybranego zamówienia.

2. KWATERMISTRZ potwierdza rejestrację wybranego zamówienia.

3. System zaznacza zamówienie jako „zarejestrowane” i umieszcza je na liście zamówień zarejestrowanych.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System umieszcza zamówienie na liście zamówień zarejestrowanych oraz zmienia jego status.

Wstrzymanie realizacji zamówienia

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania zamówienia.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie wstrzymania realizacji zamówienia.

2. KWATERMISTRZ uzasadnia decyzję.

3. KWATERMISTRZ potwierdza wstrzymanie realizacji wybranego zamówienia.

4. System zapamiętuje decyzję i zaznacza zamówienie jako „wstrzymane”.

5. System wysyła informację do określonego podmiotu z informacją, że zamówienie zostało wstrzymane. Do informacji załączone jest również uzasadnienie.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zmienia status zamówienia na „wstrzymane”.

System wysyła informację do podmiotu o dokonanych czynnościach wraz z uzasadnieniem.

Odmowa realizacji zamówienia

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania zamówienia.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie odmowy realizacji zamówienia.

2. KWATERMISTRZ uzasadnia decyzję.

3. KWATERMISTRZ potwierdza odmowę realizacji wybranego zamówienia.

4. System zaznacza zamówienie jako „zablokowane”.

5. System wysyła informację do określonego podmiotu z informacją, że zamówienie zostało zablokowane. Do informacji załączone jest rówież uzasadnienie.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zmienia status zamówienia na „zablokowane”.

System wysyła informację do podmiotu o dokonanych czynnościach wraz z uzasadnieniem.

Jeśli w przeciągu 24 godzin nie nastąpi zmiana statusu, zamównienie zostaje usunięte z listy zamówień.

Edycja zamówienia (KWATERMISTRZ)

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania zamównienia.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie edycji wybranego zamówienia.

2. System udostępnia pola formularza zamówienia do edycji.

3. KWATERMISTRZ dokonuje zmian.

4. Zatwierdzenie zmian przez KWATERMISTRZA.

5. System zapamiętuje wprowadzone zmiany.

6. Będąc w trybie edycji zamówienia, KWATERMISTRZ może zmienić status zamówienia (patrz: Zmiana statusu zamówienia (KWATERMISTRZ)).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapamiętuje zmiany.

Zmiana statusu zamówienia (KWATERMISTRZ)

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie edycji zamówienia, wybranego wcześniej z listy zamówień.

Przebieg:

1. KWATERMISTRZ zgłasza żadanie zmiany statusu aktualnie przeglądanego zamówienia.

2. System prezentuje listę możliwości:

- bez zmian,

- opóźnione,

- wstrzymane,

- zablokowane (odmowa realizacji),

- w trakcie realizacji.

3. KWATERMISTRZ ustawia nowy status zamówienia.

4. System żąda dodatkowej autoryzacji (wyjątek: „Błąd przy autoryzacji”).

5. Po poprawnej autoryzacji, system zapamiętuje nowy status.

Przebiegi alternatywne:

Wyjątek: „Błąd przy autoryzacji”:

A1. System informuje użytkownika o nieprawidłowym haśle. Autoryzacja jest ponawiana. Trzykrotna nieudana próba powoduje automatyczne wylogowanie z systemu i zablokowanie konta.

Warunki końcowe:

System zapamiętuje nowy status.

Przeglądanie listy podmiotów

Warunki początkowe:

KWATERMISTRZ zalogowany.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie przeglądania listy podmiotów.

2. System prezentuje żądaną listę (nazwy podmiotów).

3. Będąc w trybie przeglądanie listy podmiotów, KWATERMISTRZ ma możliwość wglądu w stan wybranego podmiotu (patrz: Przeglądanie stanu podmiotu).

Przebiegi alternatywne:

Brak.

Waunki końcowe:

Brak.

Przeglądanie stanu podmiotu

Warunki początkowe:

KLIENT lub KWATERMISTRZ zalogowany.

System w trybie przeglądania listy podmiotów (dotyczy KWATERMISTRZA).

Przebieg:

1. KLIENT lub KWATERMISTRZ zgłasza żądanie przeglądania stanu podmiotu.

2. System przezentuje informacje o podmiocie:

- nazwa podmiotu,

- aktualny stan magazynu podmiotu:

- typy produktów,

- nazwy produktów (ew. modele),

- ilości produktów;

- listę aktualnie złożonych zamówień podmiotu.

3. Będąc w trybie przeglądania stanu podmiotu, KLIENT ma możliwość edycji stanu podmiotu (patrz: Edycja stanu podmiotu).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przeglądanie archiwum

Warunki początkowe:

KWATERMISTRZ zalogowany.

Przebieg:

1. KWATERMISTRZ składa żądanie dostępu do archiwum.

2. Istnieje możliwość wyboru kryterium wyświetlania zamówień:

- wg daty złożenia zamówienia,

- wg daty przyjęcia zamówienia,

- wg daty dostarczenia zamówionych produktów,

- wg nazw zamawiających,

- wg numerów zamówień.

3. System prezentuje listę zrealizowanych zamówień.

4. Będąc w trybie przeglądania archiwum, KWATERMISTRZ ma możliwość przeglądania wybranych zamówień (patrz: Przeglądanie zamówień - archiwum).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przeglądanie zamówień - archiwum

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie przeglądania archiwum.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie przeglądania wybranego zamówienia.

2. System prezentuje informacje dotyczące wybranego zamównienia:

- nr zamównienia

- data złożenia zamównienia,

- data przyjęcia zamównienia do realizacji,

- data potwierdzenia dostarczenia zamówionych produktów,

- dane zamawiającego

- typy zamówionychproduktów,

- nazwy (ew. modele) zamówionych produktów,

- ilości zamówionych produktów.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Dostęp do harmonogramu transportu

Warunki początkowe:

KWATERMISTRZ zalogowany.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie dostępu do harmonogramu.

2. System prezentuje użytkownikowi kalendarz z zaznaczonymi transportami.

3. Będąc w trybie dostępu do harmonogramu, KWATERMISTRZ ma możliwość dodania nowego transportu do harmonogramu (patrz: Dodanie nowego transportu) oraz edycji transportu(patrz: Edycja transportu).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Edycja transportu

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie dostępu do harmonogramu.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie edycji trasnportu.

2. System udostępnia transport do edycji:

- data transportu,

- miejsce przeznaczenia.

3. KWATERMISTRZ dokonuje zmian.

4. Zatwierdzenie zmian przez KWATERMISTRZA.

5. System zapamiętuje wprowadzone zmiany.

6. Będąc w trybie edycji transportu, KWATERMISTRZ ma możliwość usunięcia transpotru z harmonogramu (patrz: Usunięcie transportu).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapamiętuje zmiany.

Dodawanie nowego transportu

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie dostępu do harmonogramu.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie dodania nowego trasnportu do harmonogramu.

2. System prezentuje formularz dodawania nowego transportu:

- data transportu,

- miejsce przeznaczenia.

3. KWATERMISTRZ wypełnia formularz.

4. KWATERMISTRZ zatwierdza wprowadzone dane.

5. System dodaje transport do harmonogramu.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System dodaje nowy transport.

Usuwanie transportu

Warunki początkowe:

KWATERMISTRZ zalogowany.

System w trybie edycji transportu.

Przebieg:

1. KWATERMISTRZ zgłasza żądanie usunięcia transport z harmonogramu.

2. KWATERMISTRZ potwierdza chęć usunięcia przeglądanego transportu z harmonogramu.

3. System usuwa transport z harmonogramu.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System usuwa transport z harmonogramu.

Przeglądanie listy zamówień zarejestrowanych

Warunki początkowe:

MAGAZYNIER zalogowany.

Przebieg:

1. MAGAZYNIER składa żądanie przeglądania listy zamówień zarejestrowanych.

2. System przezentuje MAGAZYNIEROWI żadaną listę (nr zamówienia, zamawiający).

3. MAGAZYNIER wybiera określoną pozycję.

4. Będąc w trybie przegladania listy, MAGAZYNIER może przeglądać wybrane zamównienie (patrz: Przeglądanie zamównienia zarejestrowanego).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przeglądanie zamównienia zarejestrowanego

Warunki początkowe:

MAGAZYNIER zalogowany.

System w trybie przeglądania listy zamówień zarejestrowanych.

Przebieg:

1. MAGAZYNIER zgłasza żądanie przeglądania wybranego zamówienia.

2. System przezentuje MAGAZYNIEROWI informacje dotyczące zamównienia:

- nazwę zamawiającego i nr zamównienia,

- typy produktów,

- nazwy produktów (ew. modele),

- zamawianą ilość,

- status zamówienia.

3. Będąc w trybie przegladania, MAGAZYNIER może zmienić status zamówienia (patrz: Zmiana statusu zamównienia (MAGAZYNIER)) oraz przyjąć zamównienie do realizacji (patrz: Przyjęcie zamównienia do realizacji).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Przyjęcie zamównienia do realizacji

Warunki początkowe:

MAGAZYNIER zalogowany.

System w trybie przeglądania zamównienia zarejestrowanego.

Przebieg:

1. MAGAZYNIER zgłasza żądanie przyjęcia zamównienia do rejestracji.

2. MAGAZYNIER potwierdza przyjęcie zamównienia do rejestracji.

3. System zapamiętuje decyzję i zmienia status zamównienia na „w trakcie realizacji”.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zmienia status zamównienia na „w trakcie realizacji”.

Zmiana statusu zamównienia (MAGAZYNIER)

Warunki początkowe:

MAGAZYNIER zalgowany.

System w trybie przeglądania zamównienia zarejestrowanego.

Przebieg:

1. MAGAZYNIER zgłasza żądanie zmiany statusu zamównienia.

2. MAGAZYNIER wybiera jedną z dostępnych opcji:

- bez zmian,

- opóźnione,

- w trakcie realizacji,

- zrealizowano (wyłącznie, jeżeli poprzedni status był „w trakcie realizacji”).

3. MAGAZYNIER ustawia nowy status zamównienia.

4. W przypadku wybrania statusu „zrealizowano”, potrzebna jest dodatkowa autoryzacja (wyjątek: „Błąd przy autoryzacji”).

5. MAGAZYNIER zatwierdza zmiany.

6. System zapamiętuje nowy status.

Przebiegi alternatywne:

Wyjątek: „Błąd przy autoryzacji”:

A1. System informuje użytkownika o nieprawidłowym haśle. Autoryzacja jest ponawiana. Trzykrotna nieudana próba powoduje automatyczne wylogowanie z systemu i zablokowanie konta.

Warunki końcowe:

System zapamiętuje zmiany.

Sprawdzenie stanu magazynu

Warunki początkowe:

MAGAZYNIER lub KWATERMISTRZ zalogowany.

Przebieg:

1. MAGAZYNIER lub KWATERMISTRZ zgłasza żądanie sprawdzenia stanu magazynu.

2. System wyświetla informacje dotyczące stanu magazynu:

- typy produktów,

- nazwy produktów (ew. modele),

- ilość produktów w magazynie.

3. Będąc w trybie sprawdzania stanu magazynu, użytkownik może zaktualizować stan magazynu (patrz: Aktualizacja stanu magazynu) oraz dodać nowy produkt (patrz: Dodanie nowego produktu (magazyn)).

Przebiegi alternatywne:

Brak.

Warunki końcowe:

Brak.

Aktualizacja stanu magazynu

Warunki początkowe:

MAGAZYNIER lub KWATERMISTRZ zalogowany.

System w trybie sprawdzania stanu magazynu.

Przebieg:

1. MAGAZYNIER lub KWATERMISTRZ zgłasza żądanie aktualizacji stanu magazynu.

2. System prezentuje:

- listę rozwijaną z typami produktów;,

- listę rozwijaną z nazwami (ew. modelami) produktów, w zależności od wybranego wcześniej typu produktu,

- pole do wpisania nowej ilości wybranego produktu.

3. Użytkownik dokonuje żądanych zmian.

4. Użytkownik zatwierdza wprowadzone zmiany.

5. System zapamiętuje nową ilość danego produktu.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapamiętuje nowe dane.

Dodanie nowego produktu (magazyn)

Warunki początkowe:

MAGAZYNIER lub KWATERMISTRZ zalogowany.

System w trybie sprawdzania stanu magazynu.

Przebieg:

1. MAGAZYNIER lub KWATERMISTRZ zgłasza żądanie dodania nowego produktu do asortymentu magazynu.

2. System prezentuje listę rozwijaną typów:

- dodaj nowy typ,

- lista dostępnych do wyboru typów.

3. Użytkownik dokonuje zmian.

4. W przypadku wybrania dodania nowego typu, system prezentuje okno do wpisania nazwy typu.

5. W przypadku wybrania typu dostępnego z listy, system prezentuje okno do wpisania nazwy produktu.

6. Użytkownik zatwierdza zmiany.

7. System zapamiętuje wprowadzone dane.

Przebiegi alternatywne:

Brak.

Warunki końcowe:

System zapamiętuje nowe dane.

3. Analiza wymagań architektonicznych

1. Wymaganie architektoniczne przypadków użycia

	rozproszenie/wielodostęp	wydajność	trwałość	pojemność	skalowalność	przenośność	niezawodność	ochrona danych	ergonomia
Przeglądanie listy zamówień klienta	++++	++++	+++	++++	++++	+++	++++	+++++	++
Przeglądanie zamówienia klienta	++++	++++	+++	+++	+++	+++	++++	+++++	++
Potwierdzenie dostawy	++++	++++	+	+	+	+++	++++	+++++	+
Edycja zamówienia (KLIENT)	++++	++++	+++	+++	+++	+++	++++	+++++	++
Anulowanie zamównienia	++++	++++	+	+	+	+++	++++	+++++	+
Edycja stanu podmiotu	++++	++++	+++	+++	+++	+++	++++	+++++	++
Dodanie nowego produktu (KLIENT)	++++	++++	+++	+++	+++	+++	++++	+++++	++
Dostęp do formularza zamówień	+++++	+++++	++++	++++	++++	++++	+++++	+++++	+++
Przeglądanie listy zamówień	+	++++	++++	++++	++++	++++	+++++	+++++	+++
Przeglądanie zamówienia	+	++++	++++	++++	++++	++++	+++++	+++++	+++
Rejestracja zamówienia	+	++++	+	+	+	+++	++++	+++++	+
Wstrzymanie realizacji zamówienia	+	++++	+	+	+	+++	++++	+++++	+
Odmowa realizacji zamówienia	+	++++	+	+	+	+++	++++	+++++	+
Edycja zamówienia (KWATERMISTRZ)	++	++++	+++	+++	+++	+++	++++	+++++	++
Zmiana statusu zamówienia (KWATERMISTRZ)	++	++++	+	+	+	+++	++++	+++++	+
Przeglądanie listy podmiotów	+	++++	+++	+++	+++	+++	++++	+++++	++
Przeglądanie stanu podmiotu	+++	++++	+++	+++	+++	+++	++++	+++++	++
Przeglądanie archiwum	+	++++	++++	++++	++++	++++	++++	+++++	++++
Przeglądanie zamówień - archiwum	+	++++	++++	+++	++	+++	++++	+++++	+++
Dostęp do harmonogramu transportu	+	++++	++++	++++	++++	++++	++++	+++++	+++
Edycja transportu	+	++++	+++	+++	+++	+++	++++	+++++	++
Dodawanie nowego transportu	+	++++	+++	+++	+++	+++	++++	+++++	++
Usuwanie transportu	+	++++	+	+	+	+++	++++	+++++	+
Przeglądanie listy zamówień zarejestrowanych	++	++++	++++	++++	++++	++++	++++	+++++	++
Przeglądanie zamówienia zarejestrowanego	++	++++	+++	+++	+++	+++	++++	+++++	++
Przyjęcie zamówienia do realizacji	++	++++	++	+	+	+++	++++	+++++	+
Zmiana statusu zamówienia (MAGAZYNIER)	++	++++	+	+	+	+++	++++	+++++	+
Sprawdzenie stanu magazynu	++	++++	+++	+++	++	+++	++++	+++++	+
Aktualizacja stanu magazynu	++	++++	+++	++++	++++	+++	++++	+++++	++
Dodanie nowego produktu (magazyn)	++	++++	+++	++++	++++	+++	++++	+++++	++

2. Wybór przypadków użycia sterujących architekturą systemu

Wszystkie przypadki użycia są równie ważne ze wzgledu na relacje z innymi. Nie ma jednego konkretnego głównego przypadku, który odpowiada za pozostałe. Jednak można wyróżnić kilka głównych przypadków użycia, bez których jakakolwiek funkjonalność systemu by nie istniała. Te przypadki uzycia to:

• Dostęp do formularza zamówień,

• Przeglądanie listy zamówień,

• Przeglądanie zamówienia,

• Rejestracja zamówienia,

• Przeglądanie listy zamówień zarejestrowanych,

• Przeglądanie zamówienia zarejestrowanego,

• Przyjęcie zamówienia do realizacji,

• Dostęp do harmonogramu transportu,

• Dodanie nowych transportów.

4. Architektura systemu

1. Dobór architektury i technologii

W ramach projektu przyjmujemy rozwiązanie klasyczne - podział systemu na dwie warstwy, z których jedna zajmuje się interakcją z użytkownikiem i sterowaniem, a druga zawiera tzw. logikę biznesową i zarządzanie danymi. Podział ten umożliwia niezależne zmiany klas granicznych, odpowiedzialnych za interfejs użytkownika oraz klas odpowiedzialnych za zarządzanie informacją i wykonanie funkcji biznesowych.

Przy wyborze technologii, najważniejsza dla nas była przenośność, prostota oraz elastyczność, dlatego zastosowaliśmy język obiektowy C++ oraz protokół komunikacyjny SSH, służący do bezpiecznego przesyłania danych w sieci za pomocą protokołu transportowego TCP/IP.

2. Podział systemu na podsystemy

Dalszego podziału na pakiety dokonano ze względu na rodzaj użytkownika i zarządzanej informacji. Dodatkowo wzięliśmy pod uwagę możliwe rozmieszczenia komponentów odpowiedzialnych za poszczególne funkcje systemu. Taka dekompozycja umożliwia ewentualny podział pracy, między tworzące system zespoły.

Pakiet	Opis
KLIENT	Zawiera klasy odpowiedzialne za komunikację z Klientem i sterowanie procesami przez niego inicjowanymi.
MAGAZYNIER	Zawiera klasy odpowiedzialne za komunikację z Magazynierem i sterowanie procesami przez niego inicjowanymi.
KWATERMISTRZ	Zawiera klasy odpowiedzialne za komunikację z Kwatermistrzem i sterowanie procesami przez niego inicjowanymi.
MAGAZYN	Zawiera klasy odpowiedzialne za zarządzanie informacją o magazynie i jego stanie.
HARMONOGRAM	Zawiera klasy odpowiedzialne za zarządzanie informacją o harmonogramie.
PODMIOTY	Zawiera klasy odpowiedzialne za zarządzanie informacją o podmiotach i ich stanach.
ARCHIWUM	Zawiera klasy odpowiedzialne za zarządzanie informacją o archiwum.
ZAMÓWIENIA	Zawiera klasy odpowiedzialne za zarządzanie informacją o zamówieniach.
LOGIKA APLIKACJI	Warstwa logiki aplikacji. Zawiera klasy służące do modelowania działań i zarządzanie danymi.
INTERFEJS UŻYTKOWNIKA	Warstwa interfejsu użytkownika. Służy do interakcji z zewnętrznymi użytkownikami systemu - Klientami, Kwatermistrzem i Magazynierem.




3. Rozmieszenie architektury

Kolejnym ważnym krokiem jest analiza rozmieszczenia podsystemów na fizycznych procesorach (komputery, serwery). Przyjmujemy, że Komenda Wojewódzka ma jeden centralny serwer, dodatkowo dysponuje własnymi stanowiskami komputerowymi dla pracowników. Klienci powiatowych jednostek używają komputerów we własnych placówkach.

Z zagadnieniem rozmieszczenia podsystemów związany jest też problem współbieżności. Każdy system będzie dysponował osobnym wątkiem sterowania. W ramach poszczególnych podsystemów możemy przyjąć, że współbieżności z punktu widzenia naszego podsystemu nie ma, każdy podsystem dysponuje pojedyńczym wątkiem sterowania, gdyż kolejkowaniem zapytań do poszczególnych serwerów zajmie się wewnętrzny mechanizm oferowany przez środowisko C++.




Procesor	Opis	Podsystemy
Stanowisko MAGAZYNIERA	Stanowisko - komputer, za pomocą którego Magazynier łączy się z serwerem; najcześciej umieszczony w magazynie	MAGAZYNIER
Stanowisko KWATERMISTRZA	Stanowisko - komputer w placówce KWP, za pomocą którego Kwatermistrz łączy się z serwerem	KWATERMISTRZ
Stanowisko KLIENTA	Stanowisko - komputer w siedzibie KPP, z pomocą którego Klient łączy się z serwerem	KLIENT
SERWER KOMENDY	Serwer przechowujący i udostępniający wszystkie informacje.	MAGAZYN, HARMONOGRAM, ZAMÓWIENIA, ARCHIWUM, PODMIOTY

STA06.v1.doc

Michał Golon

Michał Czyżykowski

RPI_09

16

---