Projektowanie systemów informatycznych
1
Elementy systemu CRM
(Customer Relationship Management)
Projekt zrealizowany na zajęciach:
Projektowanie Systemów Informatycznych
pod kierunkiem dr hab. prof. UW. Mirosławy Lasek
Aneta Dzik 219088
Anna Kalinowska
Informatyka i Ekonometria
IV rok, 2 semestr
6 czerwca 2006, Warszawa
Projektowanie systemów informatycznych
2
Spis treści.
1. Treść zadania projektowego.
2. Cel budowy systemu, zakres, przewidywane korzyści z wdrożenia.
3. Perspektywa przypadków użycia systemu.
3.1.
Diagram przypadków użycia systemu.
3.2.
Opisy tekstowe aktorów.
3.3.
Opisy przypadków użycia i przykładowe diagramy czynności.
4. Diagramy interakcji/sekwencji.
5. Perspektywa logiczna.
5.1.
Diagram klas.
5.2.
Alfabetyczny wykaz wszystkich klas wraz z opisem,
zidentyfikowanymi atrybutami i operacjami.
5.3.
Diagramy stanów dla wybranych klas.
6. Wymagania niefunkcjonalne dla systemu.
6.1.
Oszacowanie wielkości bazy danych.
6.2.
Wymagane czasy odpowiedzi dla systemu.
6.3.
Oszacowanie ilości i typów potrzebnych stanowisk
użytkowników.
6.4.
Inna wymagania
7. Propozycja technologii informatycznych.
8. Propozycja planu projektu.
8.1.
Wyróżnione etapy i zadania, czas ich realizacji.
8.2.
Zależności między etapami i analiza zadań ścieżki krytycznej.
9. Analiza ryzyka projektu.
10.Podsumowanie.
11.Literatura.
Projektowanie systemów informatycznych
3
1. Treść zadania projektowego.
Praca jest projektem systemu niezbędnego, jak się dziś wydaje, w firmie
telekomunikacyjnej, systemu CRM (Customer Relationship Management).
CRM- zarządzanie relacjami z klientami to ogół czynności polegających na
odnotowywaniu wszelkich kontaktów z każdym klientem z osobna i
podejmowaniu odpowiednich decyzji. Aplikacje CRM powinny dawać
możliwość efektywnego zarządzania kontaktami z klientami prowadząc do
nadrzędności tego podejścia w ramach ogólnej strategii firmy.
2. Cel budowy systemu, zakres, korzyści z wdrożenia.
System jest przeznaczony dla firmy telekomunikacyjnej która planuje
wprowadzić system CRM.
Umożliwia prowadzenie polityki ciągłego doskonalenia procesu
świadczonych usług i oferowanych produktów.
Celem systemu CRM jest umożliwienie organizacji go stosującej, dbania o
zadowolenie, zaufanie i utrzymanie oraz lojalność klientów. System
pozwala na możliwie najlepsze wykorzystanie potencjału nabywczego
klientów przez odpowiednie reagowanie na ich potrzeby, formowanie
produktów i oferty.
Przewidywaną korzyścią jest wzrost ilości nowych klientów firmy.
Podstawowym zakresem, który ma spełniać system jest obsługa klientów
dzwoniących lub wysyłających wiadomości e-mail z zapytaniami. Pytania
osób można pogrupować w następujące klasy problemów:
Dana osoba nie jest jeszcze abonentem, jednakże chciałaby
uzyskać informacje na temat produktów i usług świadczonych.
Osoba dzwoniąca jest już abonentem i ma problem natury
technicznej z aparatem lub wyposażeniem dodatkowym. Z jakiś
powodów sprzęt nie chce działać lub działa w sposób nieprawidłowy.
Abonent chce zmienić zakres usług mu świadczonych przez
zwiększenie / zmniejszenie ilości tych usług.
Dana osoba składa reklamację świadczonych jej usług: kwestionuje
kwotę którą ma do zapłacenia.
Osoba chce zmodyfikować swoje dane (między innymi: nazwisko,
miejsce zamieszkania, numer identyfikacyjny telefonu, z którego
korzysta, itp.)
Abonent chce zgłosić informacje o zgubieniu / kradzieży aparatu.
Chce aby numer telefonu został zablokowany.
Zadaniem systemu jest informowanie klientów o prowadzonej działalności
firmy. Informacja ta będzie dotyczyła: nowych modeli telefonów
dostępnych w ofercie, nowych opłat abonamentowych, nowych serwisach
Projektowanie systemów informatycznych
4
udostępnionych abonentom. Kanały komunikacyjne w tym przypadku to:
rozsyłanie SMSów, dzwonienie, korespondencja listowna oraz wysyłanie
maili.
System informuje osoby z nim pracujące o abonentach, którzy nie
uregulowali rachunków telefonicznych, ponadto system rozsyła SMS’y do
osób zalegających z opłatami.
Operator obsługujący zlecenie klienta (czy to telefoniczne, czy też poprzez
e-mail) może wybrać jedną operację wykonać aktywność z ograniczonego
zbioru operacji.
Manager operatorów zarządza ich czasem pracy, monitoruje efektywność
pracy, kontroluje problemy z którymi mieli do czynienia i w jaki sposób
sobie z nimi poradzili. Wszystkie zgłaszania do systemu są rejestrowane
(czy to w przypadku rozmów telefonicznych czy też maili ). Manager może
konfigurować część z parametrów systemu, którymi tenże zarządza.
Manager może dodawać, usuwać, modyfikować zarówno pracowników jak
również operacje które oni mogą wykonywać. Operator może wybrać
rozwiązanie korzystając z „podpowiedzi”, jednakże aby skorzystać z tej
opcji musi odpowiedzieć na kilka pytań, a system sam, używając modułu
eksperckiego podsunie kilka scenariuszy rozwiązania = kilka operacji,
które może wykonać operator. W podobny sposób może postąpić operator
doradzając wybór sprzętu lub usługi. Wszyscy abonenci, o których
informacje znajdują się w systemie, są posegmentowani. Na podstawie
odpowiedzi na kilka pytań potencjalny klient jest zaszeregowany do jednej
z kategorii klientów. Operator pracujący z systemem ma możliwość
podglądu danych klienta (o ile jest on abonentem), historii jego zgłoszeń,
problemów z którymi miał do tej pory do czynienia.
Projektowanie systemów informatycznych
5
3. Perspektywy przypadków użycia.
3.1. Diagram przypadków użycia systemu.
3.2. Aktorzy
Klient
Aktor na rzecz którego wykonywane są jakieś operacje w celu
obsłużenia jego zgłoszenia.
Manager
Pracownik firmy, który nadzoruje prace operatorów. Otrzymuje
statystyki odnośnie pracy wszystkich operatorów. Może dodawać,
usuwać, modyfikować dane o operatorach, a także o zadaniach.
Operator
Pracownik firmy podlegający managerowi, obsługuje zlecenia
klienta, posiada nadane mu przez managera uprawnienia dostępu
do systemu.
klient
rozmowa z klientem
zaloguj
wyloguj
usuniecie operatora
dodanie operatora
operator
zdanie raportu
zgloszenie kradziezy
pobranie informacji
aktywacja/deaktywacja uslugi
<<extend>>
<<extend>>
<<extend>>
internet
roaming
W AP
<<ex tend>>
<<extend>>
<<extend>>
info o sprzecie
info o uslugach
<<extend>>
<<extend>>
manager
Projektowanie systemów informatycznych
6
3.3. Przypadki użycia
3.2.1. Aktywacja/deaktywacja usługi
Uczestnicy: klient, operator.
Jednym z powodów dla którego klienci dzwonią do Call-Center jest
aktywowanie lub deaktywowanie jakiejś usługi. Klient może
aktywować następujące rodzaje usług: dostęp do Internetu przez
komórkę, dostęp do Internetu za pośrednictwem WAP, wykupienie
Roamingu na dany kraj na świecie.
Zidentyfikowane sekwencje zdarzeń:
-
autentykacja
klienta
-
wybór rodzaju zadania, aktywacja/ deaktywacja
-
wybór usługi
-
sprawdzenie czy realizacja usługi jest możliwa
-
wykonanie zadania lub poinformowanie o niemożności jego
wykonania.
Częstość realizacji:
-
prawdopodobnie wiele razy dziennie dla różnych klientów, w
zależności od ich potrzeb.
Czas realizacji:
-
uzależniony od rodzaju usługi i cech klienta, typowy około
3minut, maksymalny 15minut.
Wyniki po zakończeniu przypadku użycia:
-
klient, który chciał aktywować usługę i był do tego
uprawniony aktywował ją
-
klient, który chciał deaktywować aktywną usługę
deaktywował ją.
Projektowanie systemów informatycznych
7
Aktywacja/deaktywacja usługi- diagram czynności.
3.2.2. Dodanie operatora
Uczestnicy: manager.
Manager posiadający odpowiednie uprawnienia co się przekłada na
dostęp do odpowiednich fragmentów systemu, wprowadza do
systemu dane o nowym operatorze, wprowadzając jego potrzebne
dane personalne i kwalifikacje.
Zidentyfikowane sekwencje zdarzeń:
-
otworzenie odpowiedniego okna
-
podanie danych operatora
-
sprawdzenie czy operator nie został już dodany
-
dodanie operatora.
autentykacja
klienta
wybranie
rodzaju uslugi
[ aktywacja ]
wybranie rodzaju uslugi
do deaktywowania
[ deaktywacja ]
sprawdzenie czy klient ma
juz aktywowana usluge
sprawdzenie czy klient
moze aktywowac usluge
poinformowanie o niemoznosci
aktywowania uslugi
aktywowanie
uslugi
[ tak ]
sprawdzenie czy klient ma
aktywowana usluge
deaktywowanie
[ tak ]
poinformowanie o
niemoznosci deaktywacji
[ nie ]
Projektowanie systemów informatycznych
8
Częstość realizacji:
-
w zależności od potrzeby zatrudnienia nowego pracownika i
wielkości firmy, prawdopodobnie kilka/kilkanaście razy w
roku.
Czas realizacji:
-
typowy:20 minut
Wyniki po zakończeniu przypadku użycia:
-
operator znajduje się w bazie pracowników-operatorów,
uaktualniona baza operatorów
Dodanie operatora- diagram czynności.
zadanie dodania
operatora
podaj dane nowego
operatora
czy juz taki
istnieje
wyswietl komunikat o niemoznosci
dodania operatora
zapisz w systemie
informacje o operatorze
wyswietl komunikat
o dodaniu operatora
[ tak ]
[ nie ]
Projektowanie systemów informatycznych
9
3.2.3. Informacja na temat sprzętu
Uczestnicy: klient, operator.
Dzwoniący klient może dowiedzieć się na temat telefonów i
urządzeń oferowanych obecnie w sieci. Może także dowiedzieć się
na temat ich cen, promocji itd.
Zidentyfikowane sekwencje zdarzeń:
-
uzyskanie przez klienta informacji na temat sprzętu.
Częstość realizacji:
-
w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
-
typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
-
klient uzyskuje interesujące go informacje, co może
prowadzić do zakupu nowego sprzętu.
3.2.4. Informacja na temat usług.
Uczestnicy: klient, operator.
Tak jak w przypadku informacji na temat sprzętu, klient może także
się dowiedzieć jakie są obecnie świadczone przez operatora usługi.
Zidentyfikowane sekwencje zdarzeń:
-
uzyskanie przez klienta informacji na temat usług.
Częstość realizacji:
-
w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
-
typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
-
klient uzyskuje interesujące go informacje, co może
prowadzić do aktywowania nowej usługi.
3.2.5. Internet.
Uczestnicy: klient, operator.
Jest to wybór usługi związanej z dostępem do Internetu za
pośrednictwem telefonu komórkowego.
Projektowanie systemów informatycznych
10
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi.
3.2.6. Pobranie informacji.
Uczestnicy: klient, operator.
Często do Call-Center dzwonią osoby, które jeszcze klientami firmy
nie są, a chcą się tylko dowiedzieć o dostępne telefony, bądź o
świadczone w danej chwili usługi.
Jest to ogólny przypadek użycia obejmujący dwa szczegółowe: info
na temat usług, info na temat sprzętu.
3.2.7. Roaming.
Uczestnicy: klient, operator.
Jest to kolejna usługa, którą może zamówić klient.
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi.
3.2.8. Rozmowa z klientem.
Uczestnicy: klient, operator.
Jest to podstawowy przypadek użycia, który można wyobrazić sobie
przy modelowaniu systemu CRM dla Call-Center. Operatorzy
znajdujący się w siedzibie firmy odbierają zgłoszenia telefoniczne
klientów i podejmują pewne reakcje na nie.
Zidentyfikowane sekwencje zdarzeń:
-
automatyczne odebranie rozmowy
-
wybór klienta jakich informacji potrzebuje
-
ewentualna nagrywana rozmowa z operatorem
-
zarejestrowanie zadania
-
wykonanie zadania
-
rozłączenie
Częstość realizacji:
-
w zależności od wielkości firmy, liczby klientów, w średniej
wielkości firmach telekomunikacyjnych ponad 1000 razy
dziennie.
Czas realizacji:
-
typowy około 3minut.
Wyniki po zakończeniu przypadku użycia:
-
klient uzyskuje interesujące go informacje, co może
prowadzić do zakupu nowego sprzętu bądź aktywowania/
deaktywowania usługi.
Projektowanie systemów informatycznych
11
Rozmowa z klientem- diagram czynności.
sygnalizacja nadejscia
nowego zgloszenia
automatyczne
odebranie roz mowy
wybor przez klienta
jakich info potrzebuje
zarejestrowanie
faktu polaczenia
zgloszenie sie
operatora
interakcja klienta z
automatem
operacja wymagajaca
kontaktu z czlowiek iem
[ tak ]
wlaczenie
nagrywania
zarejestrowanie
zadania klienta
wykonanie
zadania
jesli dlugi czas bezczy nnosci
lub rozlaczenie przez klienta
rozlaczenie
[ tak ]
wylaczenie
nagrania
Projektowanie systemów informatycznych
12
3.2.9. Usuniecie operatora.
Uczestnicy: manager
Pracownik posiadający odpowiednie uprawnienia, co się przekłada
na dostęp do odpowiednich fragmentów systemu, usuwa
pracownika z systemu, wydając mu świadectwo pracy. Informacje o
pracach i odpowiedzialności użytkownika pozostają w systemie.
Zidentyfikowane sekwencje zdarzeń:
-
otworzenie odpowiedniego okna
-
wybranie odpowiedniego operatora
-
usunięcie operatora= zapisanie jako byłego operatora.
Częstość realizacji:
-
w zależności od potrzeby zwolnienia/ odejścia pracownika i
wielkości firmy, prawdopodobnie kilka/kilkanaście razy w
roku.
Czas realizacji:
-
typowy:5 minut.
Wyniki po zakończeniu przypadku użycia:
-
operator znajduje się w bazie byłych pracowników-
operatorów, uaktualniona baza operatorów.
Usuniecie operatora- diagram czynności.
zadanie usuniecia
operatora
wybierz operatora ktorego
chcesz usunac
usun z systemu info
o operatorze
Projektowanie systemów informatycznych
13
3.2.10. WAP
Uczestnicy: klient, operator.
Wybór usługi związanej z dostępem do Internetu poprzez WAP.
Jest to kolejna usługa, którą może zamówić klient.
Jest to szczegółowy przypadek przypadku użycia aktywowanie/
deaktywowanie usługi
3.2.11. Wyloguj
Uczestnicy: manager, operator.
Użytkownik wylogowany z systemu kończy prace.
Zidentyfikowane sekwencje zdarzeń:
-
Wylogowanie użytkownika
Częstość realizacji:
-
Każdego dnia pracy, każdy użytkownik systemu (operator,
manager)
Czas realizacji:
-
typowy:<1minuta
3.2.12. Zaloguj
Uczestnicy: manager, operator.
Aktor, chcąc podjąć współpracę z systemem, musi być
zweryfikowany, ze może z tym systemem współpracować. Dalsze
działania aktora w systemie zakładają, ze system wie, z kim ma do
czynienia i na tej podstawie określa później uprawnienia do
podejmowania poszczególnych działań w systemie.
Zidentyfikowane sekwencje zdarzeń:
-
Podaj dane
należy podać identyfikator i hasło
-
Zweryfikuj dane
sprawdzenie poprawności wpisanych danych, jeśli są
one zgodne z tymi zapisanymi w systemie, wówczas
aktor może rozpocząć pracę i jest rozpoznawany w
Projektowanie systemów informatycznych
14
systemie. W przeciwnym przypadku należy ponowić
próbę.
Częstość realizacji:
-
Każdego dnia pracy
Czas realizacji:
-
typowy:<1minuta
Wyniki po zakończeniu przypadku użycia:
-
aktor może wykonywać swoją pracę, jest rozpoznawany
przez system.
Podaj dane
Zweryfikuj dane
[ dane poprawne ]
[ dane nieprawidlowe ]
3.2.13 Zdanie raportu.
Uczestnicy: operator.
Operatorzy co pewien czas (np. co miesiąc ) zobowiązani są do
tworzenia i przesyłania raportów z działalności za ostatni okres i
przesyłanie to do kierowników wyższych szczebli.
Zidentyfikowane sekwencje zdarzeń:
Projektowanie systemów informatycznych
15
-
Utwórz raport
-
Przekaż do zatwierdzenia (manager musi zatwierdzić raport
przygotowany przez operatora, w razie braku akceptacji
operator tworzy nową wersje raportu)
-
Prześlij i archiwizuj (gotowy raport jest przesyłany
zwierzchnikom i archiwizowany)
Wyniki po zakończeniu przypadku użycia:
-
gotowy, wysłany raport, będący podstawą wielu decyzji.
Utwórz raport
Przekaz do
zatwierdzenia
Przeslij
Archiwizuj
[ zatwierdz ony ]
[ do poprawy ]
3.2.14. Zgłoszenie kradzieży telefonu.
Uczestnicy: klient, operator.
Jest to dość szczególny przypadek użycia, gdyż wiąże się z utrata
przez klienta jakiejś wartości materialnej i w takim przypadku
Projektowanie systemów informatycznych
16
należy bardzo uważnie zająć się takim przypadkiem, odpowiednio
modelując go w systemie.
Zidentyfikowane sekwencje zdarzeń:
-
Wprowadź dane identyfikujące telefon i abonenta (klient
podaje swoje dane i numer telefonu)
-
Uwierzytelnij abonenta
-
Zablokuj kartę SIM
-
Modyfikuj rekord w bazie abonentów
Częstość realizacji:
-
Kilka, kilkanaście zgłoszeń dziennie
Czas realizacji:
− typowy:7 minut
− maksymalny:15 minut
Wprowadz dane
abonenta i telefonu
Uwierzytelnij
abonenta
Modyfikuj rekord w
bazie abonentów
Zablokuj karte
SIM
[ prawidlowe dane ]
[ nieprawidlowe ]
Projektowanie systemów informatycznych
17
4. Diagramy interakcji/sekwencji.
Diagramy interakcji to modele, które opisują w jaki sposób współpracują
ze sobą grupy obiektów. Zwykle diagram sekwencji przedstawia
zachowanie systemu dotyczące jednego przypadku użycia. Obrazuje
obiekty i komunikaty przez nie wymieniane w ramach przypadku użycia.
Poniżej przedstawiamy diagramy interakcji dla wybranych przypadków
użycia.
Aktywacja/ deaktywacja usługi
Pierwszym krokiem operatora jest wpisanie nazwy odpowiedniej usługi,
której aktywność ma być zmieniona. W wyniku tego wysyłana jest
informacja do systemu. Następnie odszukiwany jest odpowiedni abonent
w bazie abonentów. W kolejnym kroku system zmienia aktywność usługi o
czym abonent jest informowany
.
:operator
:konsola
operatora
:sys tem
:baza
abonentow
:abonent
zmien aktywnosc uslugi
zmien aktywnosc uslugi abonenta
znajdz abonenta
zmien aktywnosc uslugi
modyfikuj rekord
Projektowanie systemów informatycznych
18
Rozmowa z klientem.
Każda rozmowa z klientem jest rejestrowana, a zgłoszenie jest
odnotowywane w bazie abonentów.
Usunięcie operatora.
Na początku manager wyraża chęć usunięcia operatora. Następnie system
sprawdza czy dana osoba jest obecnie pracownikiem i usuwa operatora co
jest potem odnotowywane w bazie użytkowników.
: manager
: konsola
managera
: system
: baza
uzytkownikow
usun operatora
sprawdz czy istnieje uzytkownik
usun katalog operatora
usun rek ord uzytkownika
: operator
: konsola
operatora
: system
: baz a
abonentow
z arejetruj rozmowe
zarejes truj roz mowe
wpisz rekord zgloszenia
Projektowanie systemów informatycznych
19
Wylogowanie.
: operator
: konsola
: sy stem
: baza
uzytkownikow
wyloguj ( )
sprawdź czy zalogowany ( )
zarejest ruj wylogowanie ( )
Zalogowanie.
: operator
: baza
uzytkownikow
: konsola
: system
zaloguj ( )
sprawdz czy ist nieje uzytkownik ( )
sprawdz login i haslo ( )
zarejestruj zalogowanie ( )
Projektowanie systemów informatycznych
20
Diagram współpracy odpowiadający diagramowi sekwencji
zalogowanie.
Zgłoszenie kradzieży telefonu.
W przypadku kradzieży operator na prośbę klienta zgłasza konieczność
zablokowania karty SIM, co jest wykonywane przez system oraz
odnotowywane w bazie abonentów.
: operator
: konsola
operatora
: system
: baza
abonentow
zablokuj karte SIM ( )
zablokuj karte SIM ( )
mody fikuj rekord ( )
: o p e ra t o r
: ba z a
u z y t k o w n ik o w
: k o n s o la
: s y s t e m
1 : z a lo g u j ( )
2 : s p ra w d z c z y is t n ie je u z y t k o w n ik ( )
3 :
4 : s p ra w d z lo g in i h a s lo ( )
5 : z a re j e s t ruj z a l o go w an i e ( )
6 :
7 :
8 :
Projektowanie systemów informatycznych
21
Diagram współpracy odpowiadający diagramowi sekwencji
zgłoszenie kradzieży telefonu.
5. Perspektywa logiczna.
Diagram klas opisuje typy obiektów w systemie i różne rodzaje
statystycznych relacji między nimi. Obrazuje również atrybuty i operacje
klas oraz ograniczenia tego w jaki sposób obiekty mogą być powiązane.
: o perator
: k on s ola
o p e rat ora
: s y s te m
: baz a
ab onen to w
1: z ablok uj k arte S IM ( )
2: z ab lok uj k arte S IM ( )
3: m ody fik uj rek ord ( )
4:
5:
6 :
Projektowanie systemów informatycznych
22
konsola operatora
zarejestruj rozmowe()
zablokuj karte SIM()
zmien aktywnosc uslugi()
przeszukaj baze()
konsola managera
dodaj operatora()
usun operatora()
zatwierdz raport()
Przez klase abonent
rozumiemy wykupina
przez klienta karte SIM,
podpisana przez niego
umowe. Tak wiec czlowiek
z realnego s wiata moze
wy stepowac jako wielu
abonetow
konsola
wlasciciel konsoli
stan konsoli
zaloguj()
wys lij komunikat o bledz ie()
wyloguj()
system
sprawdz loginn haslo()
zarejestruj uzytkownik a w systemie()
wyrejestruj uzytkownika z systemu()
sprawdz cz y istnieje uzytkownik()
dodaj katalog operatora()
ustaw login i haslo operatora()
ustaw katalog operatora()
sprawdz login i haslo()
zarejestruj rozmowe()
zablokuj karte SIM()
zmien aktywnosc uslugi abonenta()
sprawdz cz y zalogowany ()
1..n
1
1..n
1
baza abonentow
znajdz abonenta()
sprawdz czy istnieje()
modyfikuj rekord()
wpisz rekord zgloszenia()
1
1
1
1
zgloszenie
data zgloszenia
nazwa zgloszenia
rezultat
sprawdz rezultat()
ustaw rezultat()
ustaw nazwe()
sprawdz nazwe()
pobierz date()
baza uslug
znajdz usluge()
wyswietl wszystkie uslugi()
sprawdz czy istnieje()
1
1
1
1
abonent
imie
nazwisko
numer karty SIM
numer telefonu
zmien aktywnosc uslugi()
zablokuj karte SIM()
podaj informacje o abonencie()
zarejestruj zgloszenie()
uslugi aktywne()
uslugi dostepne()
zarejestruj zgloszenie()
wyswietl wszystkie zgloszenia()
1..n
1
1..n
1
1..n
1
1..n
1
usluga
nazwa uslugi
dostepna w systemie
sprawdz czy dostepna()
zmien dostepnosc()
ustaw nazwe()
pobierz nazwe()
1..n
1
1..n
1
1..n
1..n
1..n
1..n
dostepnosc uslugi
aktywna
sprawdz czy aktywna()
zmien aktywnosc()
baza uzytkownika
dodaj rekord uzytkownika()
usun rekord uzytkownika()
modyfikuj rekord uzytkownika()
sprawdz stan uzytkownika()
zarejestruj zalogowanie()
zarejestruj wylogowanie()
1
1
1
1
uz ytkownik
imie
nazwisko
login
haslo
zmien haslo()
wyswietl nazwisko()
1..n
1
1..n
1
baza sprzetu
podaj nazwe sprzetu()
pokaz liste sprzetu()
pokaz promocje()
podaj cene()
sprawdz czy istnieje()
1
1
1
1
Sprzet
nazwa
cena
promocja
pokaz cene()
podaj nazwe()
sprawdz promocje()
1..n
1
1..n
1
5.2. Wykaz i opis klas
Abonent
Klasa reprezentująca właściciela karty SIM, czyli osobę, która odpisała
umowę z operatorem. Jedna osoba może być właścicielem wielu kart SIM,
a tym samym odpowiadać wielu abonentom.
atrybuty:
o
imię
o
nazwisko
o
numer karty SIM – numer karty SIM jednoznacznie
identyfikuje abonenta
o
numer telefonu
operacje:
o
zmień aktywność usługi – aktywuje/deaktywuje usługę dla
danego abonenta
o
zablokuj kartę SIM
o
podaj informacje o abonencie
o
zarejestruj zgłoszenie – powoduje zachowanie informacji w
systemie o wystąpieniu zgłoszenia wykonanego przez danego
abonenta
o
usługi aktywne- podaje aktywne usługi danego abonenta
o
usługi dostępne-podaje jakie usługi są dostępne dla danego
abonenta
o
wyświetl wszystkie zgłoszenia – wyświetla informacje o
wszystkich zgłoszeniach jakich dokonał dany abonent
Baza abonentów
Służy zarządzaniu bazą abonentów. Pozwala na wyszukiwanie, dodawanie
i usuwanie abonentów, rejestruje także informacje o zgłoszeniach.
operacje:
o
znajdź abonenta
o
sprawdź czy istnieje – sprawdza, czy dany klient figuruje w
systemie jako abonent
o
modyfikuj rekord – modyfikuje rekordy w bazie abonentów
(usuwa lub dodaje nowych)
o
wpisz rekord zgłoszenia-rejestracja podstawowych informacji
o zgłoszeniu w bazie
Baza sprzętu
Służy zarządzaniu bazą sprzętów, pozwala na przeglądaniu informacji o
sprzęcie, jego cenie oraz o istniejących promocjach.
operacje:
o
podaj nazwę sprzętu
Projektowanie systemów informatycznych
24
o
pokaż listę sprzętu
o
pokaż promocje – pokazuje listę sprzętów objętych ofertą
promocyjną wraz z warunkami promocji
o
podaj cenę
o
sprawdź czy istnieje
Baza usług
Pozwala na zarządzanie bazą usług. Umożliwia wyszukiwanie usług.
operacje:
o
znajdź usługę
o
wyświetl wszystkie usługi
o
sprawdź czy istnieje
Baza użytkowników
Służy zarządzaniu bazą użytkowników (operatorów i managerów).
Umożliwia dodawanie, usuwanie i modyfikowanie rekordów użytkowników.
Rejestruje także każdorazowe zalogowanie i wylogowanie użytkownika w
systemie.
operacje:
o
dodaj rekord użytkownika
o
usuń rekord użytkownika
o
modyfikuj rekord użytkownika
o
sprawdź stan użytkownika
o
zarejestruj zalogowanie
o
zarejestruj wylogowanie
Dostępność usługi
Klasa asocjacyjna opisująca relacje między abonentem a usługą.
atrybuty
o
aktywna - atrybut wskazujący czy dana usługa jest aktywna
dla danego abonenta
Konsola
Umożliwia użytkownikom(operatorom i managerom) wykonywanie
obowiązków, przejmuje polecenia od użytkowników i kieruje je do
systemu.
atrybuty:
o
właściciel konsoli – każdy użytkownik poprzez unikalny login i
hasło loguje się do własnej konsoli.
o
stan konsoli – konsola może być w danej chwili używana
(zalogowany użytkownik) lub niewykorzystywana
Projektowanie systemów informatycznych
25
operacje:
o
zaloguj
o
wyświetl komunikat o błędzie – wyświetla komunikat o
wprowadzeniu błędnych danych
o
wyloguj
Konsola managera
Rodzaj konsoli, której właścicielem jest manager.
operacje:
o
dodaj operatora
o
usuń operatora
o
zatwierdź raport – pozwala na przeczytanie i zatwierdzenie
(bądź odesłanie operatorowi) comiesięcznego raportu
Konsola operatora
Rodzaj konsoli, której właścicielem jest operator.
operacje:
o
zarejestruj rozmowę
o
zablokuj kartę SIM
o
zmień aktywność usługi
o
przeszukaj bazę – umożliwia operatorowi wyszukanie
informacji o sprzęcie, abonentach i usługach (odpowiednie
bazy)
Sprzęt
Klasa reprezentujący sprzęt telefoniczny jaki ma do zaoferowania swoim
klientom firma.
atrybuty
o
nazwa
o
cena
o
promocja – wskazuje, czy dany sprzęt jest aktualnie objęty
ofertą promocyjną
operacje:
o
podaj nazwę
o
pokaż cenę
o
sprawdź promocję
Projektowanie systemów informatycznych
26
System
Główna klasa w naszym systemie. Klasa ta jest warstwą pośrednicząca w
kontakcie pomiędzy poszczególnymi komponentami systemu, w
szczególności konsolą użytkownika, a różnymi bazami.
operacje:
o
sprawdź login i hasło
o
zarejestruj użytkownika w systemie
o
wyrejestruj użytkownika z systemu
o
sprawdź czy istnieje użytkownik
o
dodaj katalog operatora – gdy manager dodaje nowego
operatora tworzony jest jego katalog
o
ustaw login i hasło operatora - przy dodawaniu nowego
operatora ustala się jego login i hasło
o
zarejestruj rozmowę
o
zablokuj kartę SIM
o
zmień aktywność usługi abonenta – aktywuje/deaktywuje
usługi dla poszczególnych abonentów
o
sprawdź czy zalogowany
Usługa
Klasa reprezentuje usługi świadczone przez operatora telefonii
komórkowej abonentowi.
atrybuty:
o
nazwa usługi
o
dostępna - atrybut wskazujący czy dana usługa jest dostępna
w systemie.
operacje
o
sprawdź czy dostępna – sprawdza czy usługa jest dostępna w
systemie
o
zmień dostępność
o
ustaw nazwę
o
pobierz nazwę
Użytkownik
Klasa reprezentuje użytkowników systemu, czyli operatorów i managerów.
atrybuty:
o
imię
o
nazwisko
o
login
o
hasło
Projektowanie systemów informatycznych
27
operacje
o
zmień hasło
o
podaj nazwisko
Zgłoszenie
Klasa reprezentuje zgłoszenia napływające do systemu (wszystkie telefony
i wiadomości e-mail od klientów)
atrybuty:
o
data zgłoszenia
o
nazwa zgłoszenia
o
rezultat – wskazuje na to czy problem abonenta został
pomyślnie rozwiązany, czy uzyskał potrzebne informacje
operacje
o
sprawdź rezultat
o
ustaw rezultat
o
ustaw nazwę
o
sprawdź nazwę
o
pobierz datę
Projektowanie systemów informatycznych
28
5.3. Diagramy stanów dla wybranych klas.
Diagramy stanów są techniką opisu zachowania systemu. Opisują one
wszystkie możliwe stany, do których może przejść dany obiekt, oraz to,
jak zmienia się stan obiektu pod wpływem zdarzeń do niego
docierających. Zazwyczaj rysujemy je dla pojedynczych klas, by pokazać
cały cykl życia pojedynczego obiektu.
5.3.1 Abonent i jego możliwości w systemie
Abonent może skontaktować się z systemem na dwa sposoby – wysłać
e-mail lub zadzwonić na bezpłatną linie informacyjną.
oczekiwanie
sk ontak tuj sie
rozmowa
ex it / zapisz informacje o zgloszeniu
otrzymanie odpowiedzi
exit/ zapisz informacje o zgloszeniu
[ nie wszystko zalatwione ]
/ rozlacz
Projektowanie systemów informatycznych
29
5.3.2 Użytkownik i jego możliwości w systemie
W systemie użytkownik może być zalogowany jako operator lub manager,
co daje odmienne możliwości i uprawnienia.
Weryfikacja
do/ sprawdz prawidlowosc danych
Zalogowany
j ako operat or
Zalogowany
jako manager
odrzucone
[ operator ]
[ manager ]
[ nieprawidlowe ]
Rozmowa z klientem
entry/ weryfikacja uzyt kownika
dodawanie
operatora
usuwanie
operatora
zatwierdzanie
raportu
przygotowanie raportu
do/ napisz raport
exit/ przeslij raport
[ raport niezatwierdzony ]
zalogu j
/ wyloguj
/ wyloguj
Projektowanie systemów informatycznych
30
5.3.3 Diagram stanów odpowiadający klasie usługa.
Nowa usługa zostaje wprowadzona do systemu i pojawia się jako usługa
dostępna w systemie. Usługi zostają przypisane do poszczególnych ofert i
planów taryfowych, wobec czego stają się dostępne danym abonentom.
Abonent może aktywować/deaktywować dostępną mu usługę. Dana
usługa może przestać być dostępna dla danego użytkownika, na przykład
gdy zmienia on swój plan taryfowy.
Usługa może także nie być dostępna w całym systemie, na przykład w
przypadku awarii technicznej. W takim przypadku można ją z powrotem
udostępnić, gdy awaria zostanie usunięta, lub też całkowicie usunąć
systemu, gdy firma rezygnuje z oferowania jej klientom
usluga dostepna w
systemie
usluga dostepna
dla abonenta
niedostepna
abonentowi
aktywna
niedostepna w
systemie
dodaj usluge
udostepnij usluge
aktywuj
deaktywuj
usun usluge
Projektowanie systemów informatycznych
31
6. Wymagania niefunkcjonalne dla systemu.
6.1.Oszacowanie wielkości bazy danych
W systemie będą cztery bazy: baza użytkowników przechowująca
informacje na temat pracowników firmy – operatorów i managerów, baza
sprzętu (dane o sprzęcie telefonicznym, jaki firma oferuje klientom), baza
usług, baza abonentów.
W firmie pracuje 100 operatorów i 5 managerów, na przechowywanie
danych na ich temat wystarczy ok. 60kB
użytkownicy: 100+5 = 105 x 512 B=-=60kB
Firma oferuje swym klientom ok. 1000 rożnych urządzeń (telefonów,
zestawów słuchawkowych i innych akcesoriów) Do przechowywania tych
danych potrzeba będzie ok. 500 kB
sprzęt 1000 x 512 B = 500kB
W ofercie firmy jest ponad 40 różnych usług, do przechowywania danych o
nich wystarczy 25kB.
usługi 50 =-=25kB
Najwięcej danych przechowywanych w bazie dotyczy abonentów. Do
przechowywania informacji na ich temat potrzeba aż 12GB! Same dane
personalne abonentów mogą zająć 4 GB (firma ma obecnie 6mln
abonentów, dodatkowo policzony jest zapas 2 mln)
abonenci 6 mln + 2 mln zapasu = 8 mln x 512B =-= 4GB
Przechowywane są także informacje na temat aktywności usług. W
systemie jest dostępne ponad 40 różnych usług, jednak w ofercie żadnego
abonenta nie ma dostępnych więcej niż 25 usług.
aktywność usług 8 mln x 25 = 200 mln x 16B =-= 3 GB
Kolejną dużą kategorią danych są informacje o zgłoszeniach, dziennie jest
około 5000 zgłoszeń, są one przechowane przez 5 lat – daje to ok. 10mln
zgłoszeń.
zgłoszenia 10 mln x 512B = 5GB
W sumie dane to około 15GB (z zapasem).
Kluczem do sprawnego działania systemu jest możliwość szybkiego
wyszukiwania informacji w bazie (klient ma jak najszybciej otrzymać
potrzebną informację), dlatego dodatkowo przechowywane będą indeksy
przyśpieszające wyszukiwanie informacji w bazach. Indeksy:10GB
Projektowanie systemów informatycznych
32
6.2.Propozycja wymaganych czasów odpowiedzi dla systemu
Czas odpowiedzi systemu w przypadku odwołań do bazy danych powinien
mieścić się w 7 sekundach. Przekroczenie czasu 15 sekund może być
traktowane jako niespełnienie wymagań.
Czas odpowiedzi systemu w przypadku braku odwołań do bazy danych
powinien mieścić się w 2 sekundach. Przekroczenie czasu 5 sekund będzie
sygnalizować konieczność wprowadzenia zmian.
6.3.Oszacowanie ilości i typów potrzebnych stanowisk pracy
użytkowników systemu:
liczba operatorów: 100
o
stanowiska powinny być dodatkowo wyposażone w sprzęt
telefoniczny zintegrowany z systemem.
liczba managerów: 5
6.4. Inne wymagania:
Wydajność:
Istotny jest czas obsługi każdego zgłoszenia, zarówno czas obsługi klienta
dzwoniącego, gdzie zapisanie zgłoszenia musi się odbyć „on-line”, jak
również jak najszybsze wykonanie tego zgłoszenia.
Dostępność:
System powinien być dostępny 24h na dobę, 7 dni w tygodniu.
Bezpieczeństwo: System powinien być zabezpieczony przed dostępem
osób niepowołanych z zewnątrz firmy. Rozwiązaniem wystarczającym
wydaje się być zablokowanie dostępu z zewnątrz firmy, zastosowanie
loginów oraz haseł. Aspektem także ważnym jest odpowiednia
strukturalizacja dostępu do danych wewnątrz firmy tak, by pracownicy
mieli tylko dostęp do danych związanych z ich zakresem obowiązków, co
zaowocuje przejrzystością odpowiedzialności. Dodatkowo utrudni
inwigilację firmy przez nieuczciwych pracowników.
7. Propozycje technologii
System musi być wydajny i szybki (ważny czas obsługi klienta).
• Programowanie w C++ zapewni niezawodną i szybką
reakcję systemu.
• Wsparcie międzymodułowej komunikacji technologią
CORBA.
System musi działać w oparciu o bazę danych o wysokiej
niezawodności (i z zapewnionym bezpieczeństwem danych,
najlepiej z możliwością mirrorowania danych)
Projektowanie systemów informatycznych
33
System składać się będzie z:
serwera nadzorującego całą pracę, obsługującego
przychodzące połączenia telefoniczne oraz pobierającego i
wysyłającego pocztę elektroniczną. Jest to jedyny
komputer posiadający dostęp do internetu.
serwera baz danych, na którym znajdować się będzie baza
danych
komputerów klienckich, na których pracować będą
użytkownicy.
System operacyjny:
Linux. W przypadku obu serwerów może być to
dystrybucja Debian albo Slackware (ze względu na
bezpieczeństwo), a dla komputerów klienckich np. Fedora
Core albo Mandriva.
Baza danych
− Oracle – wydajna komercyjna baza danych, kosztowna
− PostgreSQL – darmowa baza danych, może zostać
zastosowana w celu ograniczenia kosztów projektu.
Wymagania sprzętowe:
Serwer nadzorujący
o
Serwer klasy PC z procesorem Intel Xeon, 1GB
RAM, dysk 120GB.
Serwer z bazą danych
o
Dwuprocesorowy serwer klasy PC z procesorami
Intel Xeon, 2GB RAM, macierz dyskowa SCSI, 2x2
dyski 120 GB przeznaczone na przechowywanie
danych (2 dyski, w tym jeden służący do
przechowywania kopii danych – mirroring, na
potrzeby składowania danych i taka sama
konfiguracja służąca do przechowywania indeksów
w bazie danych).
Stacje klienckie
o
Komputery klasy PC, procesor co najmniej Pentium
III 733MHz, 512MB RAM, dysk 40GB.
Wewnętrzna sieć:100Mb, okablowanie: skrętka UTP 5.
Projektowanie systemów informatycznych
34
8. Propozycja planu projektu
8.1.Wyróżnione etapy i zadania
L
p.
Etap Zadania Czas
trwania
Realizacja
1. Projektowanie
− projekt funkcjonalny
systemu,
− identyfikacja potrzeb
użytkowników
− ustalenie sposobu
testowania,
− powstanie projektu
technicznego
20 dni
roboczych
Analityk 1
Analityk 2
2. Przygotowanie do
realizacji
− zakup niezbędnego
sprzętu i
oprogramowania,
− instalacja systemu baz
danych
15 dni
roboczych
Technik 1
Technik 2
3. Oprogramowanie
(kodowanie)
− zaprogramowanie
aplikacji klienckiej
− stworzenie
oprogramowania dla
serwera
nadzorującego
25 dni
roboczych
Programista1
Programista2
4 Stworzenie bazy
danych
− stworzenie bazy
danych na potrzeby
systemu (struktura),
− wprowadzenie danych
10 dni
roboczych
Programista1
Wprowadzają
cy dane 1-5
5 Testy wewnętrzne − wewnętrzne testy
systemu
5 dni
robocze
Tester 1
6 Poprawki po
testach
− poprawki po testach
wewnętrznych
7 dni
roboczych
Programista1
Programista2
7 Wdrożenie
− Instalacja systemu,
− stworzenie
dokumentacji
systemu
5 dni
roboczych
Technik1
Programista1
8
Testy zewnętrzne
− testy systemu
realizowane przez
odbiorców systemu
5 dni
roboczych
Odbiorca
9 Poprawki po
testach
− poprawki po testach
zewnętrznych,
− oddanie systemu do
użytkowania
5 dni
roboczych
Programista1
Programista2
1
0
Utrzymanie
− Utrzymanie systemu
na warunkach
ustalonych w umowie
--- Technik
1
Projektowanie systemów informatycznych
35
8.2 Zależności pomiędzy etapami i analiza zadań ścieżki krytycznej
Etapy realizacji projektu powinny przebiegać w sposób przedstawiony na
rysunku. Przygotowanie do realizacji po stronie odbiorcy może przebiegać
równocześnie z oprogramowaniem, możliwe jest także zrównolegnienie
testów wewnętrznych i poprawek z tworzeniem bazy danych. Pozostałe
etapy muszą przebiegać po sobie.
Widać, że jest niewielka elastyczność projektu pod względem czasu
realizacji poszczególnych etapów, przesunięcia dopuszczalne są jedynie
w etapie 2 i 4. Pozostałe etapy leżą na ścieżce krytycznej (zaznaczona na
pomarańczowa), każde opóźnienie w ich realizacji doprowadzi do
wydłużenia czasu realizacji projektu.
1.
Projektowanie
(20 dni
roboczych)
2.
Przygotowani
e do realizacji
(15dni)
3.
Oprogramowanie
(25 dni roboczych
)
4.
Stworzenie
bazy danych
10 dni
5.
Testy
wewn
5dni
6.
Poprawki
po testach
7dni
7.
Wdrożenie
5 dni
8.
Testy
zewn
5dni
9.
Poprawki
po testach
5dni
Czas realizacji projektu - 72 dni
robocze
9. Analiza ryzyka projektu
Zagrożenie Szanse
wystąpienia
Stopień
szkód
Zapobieganie zagrożeniu Postępowanie w przypadku
wystąpienia zagrożenia
Niedoprecyzowanie
specyfikacji
Średnie Duży Jasne
sprecyzowanie
początkowych wymagań i stałe
konfrontowanie ich z
oczekiwaniami użytkowników.
Wszelkie niejasności w wymaganiach
funkcjonalnych należy szczegółowo
wyjaśniać. Niezwłoczne dokonywanie
potrzebnych poprawek w przypadku
znacznej różnicy między oczekiwaniami
odbiorców a stanem rzeczywistym.
Brak doświadczenia
osób wykonujących
system
Małe
Średni Odpowiedni
dobór
osób
realizujących, posiadających
odpowiednie umiejętności.
Możliwość zwrócenia się do osoby
biegłej w danej dziedzinie, która w razie
wystąpienia zagrożenia będzie w stanie
pomóc w realizacji projektu.
Awaria bazy danych Małe
Średni Znalezienie
doświadczonego
administratora baz danych.
Jak najszybsza diagnoza problemu i
usunięcie go (kopie zapasowe danych),
wykorzystanie serwera zapasowego.
Awaria serwera
zarządzającego
Małe
Średni Przygotowanie
zapasowego
serwera.
Przełączenie na zapasowy serwer i
usunięcie usterki.
Awarie sprzętowe
(z wyłączeniem
serwerów)
Małe Mały
Podpisanie z dostawcą sprzętu
umowy na serwisowanie.
Zatrudnienie technika.
Wezwanie serwisu w celu usunięcia
problemu (naprawy sprzętu).
Nieintuicyjna
obsługa systemu
Średnie Mały
Odbiór instrukcji obsługi przez
użytkowników.
Przeszkolenie użytkowników i
późniejsze konsultacje w razie dalszych
niejasności
Błędy w
dokumentacji
Małe Mały
Weryfikacja dokumentacji przez
odbiorców
Zarezerwowanie czasu na ewentualne
konsultacje, poprawienie dokumentacji
Bezpieczeństwo
informacji
Małe Duży Stosowanie
transmisji
szyfrowanej i uwierzytelniania,
aktualizacje systemu
Zmiana haseł, aktualizacja
zabezpieczeń na serwerze.
10. Podsumowanie
System zarządzania relacjami z klientami (CRM) jest w dzisiejszych
czasach niezbędny w każdej instytucji, w której znaczącą role ma kontakt
z klientem. System taki umożliwia odnotowywanie wszelkich kontaktów z
każdym klientem z osobna i podejmowanie odpowiednich decyzji.
Aplikacje CRM powinny dawać możliwość efektywnego zarządzania
kontaktami z klientami prowadząc do nadrzędności tego podejścia w
ramach ogólnej strategii firmy. W naszym przykładzie umożliwiają one
zarejestrowanie rozmowy z klientem, a w przypadku standardowych spraw
także automatyczne uzyskanie informacji.
Operator jest potrzebny tylko w przypadku zgłoszeń niestandardowych.
Dzięki systemowi CRM może on skorzystać z automatycznych
podpowiedzi, wyszukać odpowiednie informacje i sprawnie pomóc
klientowi.
Nasz projekt stanowi jedynie zarys projektu, jaki mógłby być zrealizowany w
rzeczywistości. Aby uzyskać pełny obraz wymagań funkcjonalnych dla systemu
należałoby dokładnie uzgodnić z odbiorcami (a najlepiej także z użytkownikami) ich
oczekiwań i wymagań wobec systemu. W wymaganiach powinna być uchwycona
specyfika działania konkretnego odbiorcy i jego wyobrażenie co do systemu jako
całości i wszystkich jego elementów.
UML (Unified Modeling Language) jest obecnie najważniejszym
i najpowszechniej stosowanym językiem modelowania. Stosuje się go
przede wszystkim w analizie i projektowaniu systemów informatycznych,
modelowaniu biznesowym, analizie wymagań. UML stał się standardem de
facto wykorzystywanym w prawie każdym projekcie informatycznym.
Metoda rysowania diagramów obiektowych (UML) stanowi wspólny język
porozumienia język analityków biznesowych, projektantów i
programistów, ułatwiający porozumienie się osób uczestniczących w
realizacji projektu.
Solidny i przejrzysty projekt systemu, w tym notacja UML (zrozumiała dla
przeciętnego człowieka) może pomóc uniknąć wielu błędów i niedomówień, łatwych
do usunięcia na etapie projektowania, a bardzo kosztownych i czasochłonnych w
przypadku odkrycia na dalszych etapach tworzenia systemu.
Projektowanie systemów informatycznych
38
11. Literatura
1. Fowler, M., Scott, K., UML w kropelce, Oficyna Wydawnicza LTP,
Polish language edition, Warszawa 2002
2. Lasek Mirosława, Notatki do wykładu Projektowanie systemów
informatycznych, 2005
3. Szejko, S., Metody wytwarzania oprogramowania, Wydawnictwo
MIKOM, Warszawa, 2002; r.3.2. (ISBN 83-7279-283-6).
4. Śmiałek, M. Zrozumieć UML 2.0. Metody modelowania obiektowego,
Wydawnictwo HELION, Gliwice 2005 (ISBN 83-7361-918-6).
5.
Booch, G., Rumbaugh, J., Jacobson, I., UML przewodnik
użytkownika, Wydawnictwa Naukowo-Techniczne, Warszawa 2001