PROJEKT INŻYNIERIA OPROGRAMOWANIA Temat: System do

Wydział Elektroniki Politechniki Wrocławskiej
Kierunek: …………………………………., Specjalność: …………….………………………..
PROJEKT
INŻYNIERIA OPROGRAMOWANIA
Temat: System do wystawiania dokumentów kasowych
- projekt wzorcowy
Opracowanie:
dr inż. Paweł Skrobanek
Wrocław 2006
2
Spis treści:
1. Opis projektowanego systemu................................................................................................ 3
1.2. Opis słowny......................................................................................................................3
1.2. Kontekst zewnętrzny projektowanego podsystemu......................................................... 4
1.3 Wzory dokumentów..........................................................................................................4
2. Diagram przypadków użycia – identyfikacja i opis usług świadczonych przez system.........6
3
1. Opis projektowanego systemu
1.2. Opis słowny
Przedmiot działalności firmy – nie jest istotny, można wyobrazić sobie rejestracje
wpłat i wypłat dla firmy prowadzącej loterie, firmy ubezpieczeniowej itp. Projekt będzie
obejmował tylko system obsługujący wpłaty i wypłaty gotówkowe z kasy firmy.
Przedmiotem projektowania jest system umożliwiający rejestrowanie operacji kasowych
w firmie ZABAWA. Nie jest to typowy system kasowy. W naszej firmie kasy są „wirtualne”,
to znaczy jest kilka osób, które pobierają opłaty od klientów lub wypłacają im pieniądze w tak
zwanym „terenie” (np. u klienta, w oddziałach naszej firmy). Od systemu oczekuje się zatem,
że poprzez terminale (np. laptopy) będące w posiadaniu takich pracowników, stworzy
możliwość rejestracji operacji gotówkowych.
Praca kasjera polega na przyjmowaniu lub wydawaniu gotówki z kasy, co jest
potwierdzane dokumentami: KP (kasa przyjmie) oraz KW (kasa wypłaci) w dwóch
egzemplarzach, jeden dla kasjera, a drugi dla klienta. Druki te są drukami „ścisłego
zarachowania”, m. in. muszą być kolejno numerowane w okresie obrachunkowym
(dopuszczalne jest kolejne numerowanie dla każdej z kas). Kasjer dodatkowo musi mieć
możliwość wykonania raportu kończącego jego zmianę. Raport kasowy zawiera wykaz
wszystkich dokumentów KP oraz KW wraz z podsumowaniem salda (ustaleniem ilości
środków finansowych w kasie). Obecnie nie przewiduje się innych form płatności niż
gotówka (w przyszłości – karta kredytowa). Ponieważ operacje muszą zawierać informację
o tym, kto ich dokonał, zatem system musi „wiedzieć”, kto pracuje przy kasie, stąd potrzebna
będzie autoryzacja kasjera przy rozpoczęciu pracy.
Do tej pory w firmie funkcjonowało jedno „okienko kasowe” w oddziale macierzystym,
a operacje były rejestrowane na jednym komputerze. Firma chciałaby, żeby system również
zapisywał informacje o operacjach na jednym serwerze i dodatkowo, drukował w centrali po
jednej kopii każdego wystawionego dokumentu (KP lub KW). Dodatkowo, w centrali będą
drukowane raporty miesięczne dla każdej kasy. Wydruk raportu nastąpi automatycznie lub na
życzenie kasjera (do ustalenia) w pierwszym dniu miesiąca następującego po miesiącu, dla
którego drukowany jest raport.
Do systemu będzie miał również dostęp tzw. administrator – zakładanie kont
użytkownikom, modyfikowanie wzorów dokumentów, itp. Do jego zadań będzie należała
również konserwacja systemu.
4
Oprócz niego, członkowie zarządu chcieliby otrzymywać w formie wydruku
zestawienia okresowe, w jakie formie – to będzie jeszcze przedmiotem ustaleń.
1.2. Kontekst zewnętrzny projektowanego podsystemu
Wstępnie opracowano diagram przestawiający kontekst zewnętrzny projektowanego
podsystemu - rysunek 1.
KASJER
ADMINISTRATOR
raporty
KP (wpłaty do kasy),
KW (wypłaty)
Zarządzanie kontami
użytkowników,
konfiguracja
parametrów
potwierdzenia operacji,
CZŁONEK
ZARZĄDU
raporty
okresowe
zestawienia (np. lista
pracowników, lista terminali)
Podsystem
obsługi kasy
raport
miesięczny
Rys.1. Kontekst zewnętrzny projektowanego podsystemu
1.3 Wzory dokumentów
Dokumenty istotne ze względu na projektowany system, to:
• KP,
KSIĘGOWY
5
•
•
KW (analogicznie, zawiera pola jak KP),
raport kasowy.
WZÓR I
Raport kasowy nr 1 za okres od 01. ................. do 10. .................
Lp.
Nr dokumentu
OPIS
1.
KP 1/00
Czek got. AA 0345133 z Banku Zachodniego
2.
KW 1/00
Za telefon tyt. Faktury F 123/RR, w tym
3.
4.
5.
….
KP 2/00
KP 3/00
KW 2/00
…..
opłata poczt. 2,80
Spłata należności od ROLATOR
Wpłata za telefon Janina Złotopolska
Zaliczka na mater. Biur. Alek Kwach
……
KWOTA
2500,00 zł
332,80 zł
KONTO
600,00 zł
25,20 zł
1000,00 zł
…
WZÓR II (źródło:
http://www.ksiegowosc.ngo.pl/x/15748;jsessionid=386DE713A60DB7AF6AC176E9C2C77729 )
pieczęć instytucji
LP
DATA
NR
DOKUMENTU DOKUMENTU
RAPORT KASOWY NR
za okres:
miesiąc, rok
OPIS
RODZAJ
KOSZTU
PRZYCHÓD
ROZCHÓD
STAN KASY
Z przeniesienia
1
2
3
0,00
0,00
0,00
6
2. Diagram przypadków użycia – identyfikacja i opis usług
świadczonych przez system
Przedmiotem projektowania jest moduł systemu umożliwiający obsługę kasy. Diagram
PU został przedstawiony w szerszym kontekście ze względu na to, by pokazać całokształt
projektu. W związku z powyższym, w rozdziale tym opisane zostały tylko przypadki użycia
oraz aktorzy związani z modelowanym „fragmentem”.
Diagram przypadków użycia przedstawia Rys.2.
Rys.2. Diagram przypadków użycia projektowanego systemu
7
AKTOR
KASJER
OPIS
Kasjer przyjmuje lub wypłaca
gotówkę z kasy. Operacje takie
są ewidencjonowane przy
pomocy dokumentów KP (kasa
przyjmie) lub KW (kasa
wypłaci).
PRZYPADKI UŻYCIA
obsługa użytkownika,
rejestracja wpłat,
rejestracja wypłat
Opis przypadków użycia:
PU
obsługa
użytkownika
rejestracja wpłaty
do kasy
OPIS
CEL: obsługa kasjera
WS (warunki wstępne): inicjalizacja przez uruchomienie
programu (np. otwarcie strony WWW, start aplikacji)
WK (warunki końcowe): --PRZEBIEG:
1. inicjalizacja PU autoryzacja
2. powrót z PU autoryzacja
3. Jeśli autoryzacja zakończona błędem, przejście do 1.
4. pokazanie menu i wprowadzenie wyboru kasjera (może
wybrać: koniec, wystaw KP, wystaw KW).
5. Jeśli „wystaw KP”, to inicjalizacja PU wystawienie
dokumentu KP i oczekiwanie na powrót.
6. Jeśli KW, to inicjalizacja PU wystawienie dokumentu KW
i oczekiwanie na powrót.
7. Jeśli nie wybrano koniec, to przejście do 1.
CEL: wystawienie dokumentu KP
WP: inicjalizacja z PU obsługa użytkownika, użytkownik posiada
ID ≠0 (autoryzacja zakończona sukcesem)
WK: wydrukowany dokument KP, alternatywnie (anulowano
operację): brak
PRZEBIEG:
1. Wprowadzenie danych przez kasjera zakończone
zatwierdzeniem lub anulowaniem.
2. Jeśli zatwierdzenie, weryfikacja poprawności
i kompletności danych.
3. Jeśli zatwierdzenie i weryfikacja OK – zapisanie
informacji w bazie danych (na serwerze) wydruk
dokumentu KP oraz kopii (jedna lokalnie, jedna
w centrali).
4. Jeśli zatwierdzenie i weryfikacja wykazała BŁĄD, to
wskazanie błędu i przejście do 1.
5. Powrót do sesji.
8
rejestracja wypłaty CEL: wystawienie dokumentu KW
z kasy
WP: inicjalizacja z PU obsługa użytkownika, użytkownik posiada
ID ≠0
WK: wydrukowany dokument KW, alternatywnie (anulowano
operację): brak
PRZEBIEG:
1. Wprowadzenie danych zakończone zatwierdzeniem przez
kasjera lub anulowaniem.
2. Jeśli zatwierdzenie, weryfikacja poprawności
i kompletności danych.
3. Jeśli zatwierdzenie i weryfikacja OK – zapisanie informacji
w bazie danych (na serwerze) wydruk dokumentu KW oraz
kopii (jedna lokalnie, jedna w centrali).
4. Jeśli zatwierdzenie i weryfikacja wykazała BŁĄD, to
wskazanie błędu i przejście do 1.
5. Powrót do sesji
autoryzacja
CEL: weryfikacja użytkownika
WP: inicjalizacja z PU obsługa użytkownika,
WK: zakończono ostatnią operację
PRZEBIEG:
1. Wprowadzenie identyfikatora i hasła przez kasjera.
2. Weryfikacja z danymi przechowywanymi w systemie
(serwer z bazą danych).
Jeśli: SUKCES
Jeśli: PORAŻKA
3a.1. Wyświetlenie
3b. Wyświetlenie komunikatu
komunikatu powitalnego. o błędzie
3a.2. Założenie sesji.
4. Zakończenie (z komunikatem zwrotnym o sukcesie
– numer ID użytkownika lub porażce ID=0). Gdzie: ID –
identyfikator.