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

Aktorzy:

• KWATERMISTRZ

• KLIENT

• MAGAZYNIER

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 rządaną 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. Analza wymagań architektoicznych

1. Wymagania architektoniczne przypadków użycia

Przeglądanie listy zamówień klienta

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie zamówienia klienta

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Potwierdzenie dostawy

Chroniona ze względu na poufność danych. Wielodostęp archiwum - jednoczesne korzystanie z usług systemu komputerowego przez wielu użytkowników, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Edycja zamówienia (KLIENT)

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Anulowanie zamównienia

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Edycja stanu podmiotu

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, pojemna ze względu na charakter rozbudowanej listy podmiotów, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Dodanie nowego produktu (KLIENT)

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, pojemna ze względu na charakter rozbudowanej listy produktów, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Dostęp do formularza zamówień

Rozproszenie funkcja musi być dostępna dla każdego klienta z poziomu aplikacji w której się zalogował, pojemna ze względu na charakter rozbudowanego formularza, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie listy zamówień

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie zamówienia

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Rejestracja zamówienia

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Wstrzymanie realizacji zamówienia

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Odmowa realizacji zamówienia

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Edycja zamówienia (KWATERMISTRZ)

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Zmiana statusu zamówienia (KWATERMISTRZ)

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie listy podmiotów

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie stanu podmiotu

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie archiwum

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, trwałość ze względu na charakter archiwum, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie zamówień - archiwum

Pojemna ze względu na charakter rozbudowanej listy zamówień, chroniona ze względu na poufność danych, trwałość ze względu na charakter archiwum, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Dostęp do harmonogramu transportu

Pojemna ze względu na charakter rozbudowany harmonogram transportu, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Edycja transportu

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Dodawanie nowego transportu

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Usuwanie transportu

Pojemna ze względu na charakter rozbudowany harmonogram transportu, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie listy zamówień zarejestrowanych

Pojemna ze względu na charakter rozbudowaną listę zamówień zarejestrowanych, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przeglądanie zamówienia zarejestrowanego

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Przyjęcie zamówienia do realizacji, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Zmiana statusu zamówienia (MAGAZYNIER)

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Sprawdzenie stanu magazynu

Pojemna ze względu na charakter rozbudowaną listę stanu zamówień, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Aktualizacja stanu magazynu

Pojemna ze względu na charakter rozbudowaną listę stanu stanu magazynu, chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

Dodanie nowego produktu (magazyn)

Chroniona ze względu na poufność danych, niezawodna nie popełnienie błędów ze względu na potrzebę bezpieczeństwa

ALBO:

Skala gwiazdek: od najmniej istotnych - +, ++, +++, ++++, +++++ do najistotniejszych

Przeglądanie listy zamówień klienta

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie zamówienia klienta

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Potwierdzenie dostawy

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Edycja zamówienia (KLIENT)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Anulowanie zamównienia

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Edycja stanu podmiotu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Dodanie nowego produktu (KLIENT)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Dostęp do formularza zamówień

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie listy zamówień

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie zamówienia

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Rejestracja zamówienia

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Wstrzymanie realizacji zamówienia

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Odmowa realizacji zamówienia

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Edycja zamówienia (KWATERMISTRZ)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Zmiana statusu zamówienia (KWATERMISTRZ)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie listy podmiotów

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie stanu podmiotu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie archiwum

Wielodostęp	++++
Wydajność	+
Trwałość	++++
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie zamówień - archiwum

Wielodostęp	++++
Wydajność	+
Trwałość	++++
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Dostęp do harmonogramu transportu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Edycja transportu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Dodawanie nowego transportu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Usuwanie transportu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie listy zamówień zarejestrowanych

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przeglądanie zamówienia zarejestrowanego

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Przyjęcie zamówienia do realizacji

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Zmiana statusu zamówienia (MAGAZYNIER)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Sprawdzenie stanu magazynu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Aktualizacja stanu magazynu

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	++++
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

Dodanie nowego produktu (magazyn)

Wielodostęp	++++
Wydajność	+
Trwałość	+
Pojemność	+
Skalowalność	+
Przenośność	++
Niezawodność	++++
Ochrona danych	++++
Ergonomia	+

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

Wszystkie przypadki użycia są równie ważne ponieważ każde łączą się z innymi. Nie ma jednego konkretnego głównego przypadku który odpowiada za pozostałe. Wszystkie podzielone są na podsystemy które w całości dają możliwość sterowania wszystkimi. Jednak mówiąc o przypadkach użycia które mogą dać jakieś korzyści napastnikowi to przypadki odpowiadające za edycje, dodawanie oraz przeglądanie list zamówień podmiotów itp.

4. Architektura systemu

1. Dobór architektury i technologii

W ramach projektu przyjmujemy rozwiązanie klasyczne - podział systemu na 2 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. 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 także ewentualny podział pracy między tworzące system zespoły. Przy wyborze technologii najważniejsza dla nas była przenośność, prostota oraz elastyczność dodatkowo zastosowaliśmy język obiektowy C++ oraz protokół komunikacyjny ???? (jaki jest w C++)

2. Podział systemu na podsystemy

Kolejnym ważnym krokiem jest analiza rozmieszczenia podsystemów na fizycznych procesora. Przyjmujemy ze 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. W ramach analizy rozmieszczenia podsystemów należy nakreślić sposób komunikacji miedzy tymi które zajmują się na różnych procesorach.

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

3. Rozmieszczenie architektury

template.doc

Michał Golon

Michał Czyżykowski

RPI_09

24

---