13.11.2011 r.
Joanna Bryzek
Mariusz Budzyn
Konrad Rzempołuch
Michał Zabielski
Grupa I8B1S1
Aplikacje internetowe
Dokument specyfikacyjny projektu
Prowadzący:
mgr inż. Rafał Kasprzyk
13.11.2011 r.
str. 2
Spis treści
1. Cel projektu i dziedzina problemu ................................................... 3
2. Wymagania funkcjonalne ................................................................ 3
3. Komponenty programu ................................................................... 6
4. Wykorzystywane wzorce architektoniczne i projektowe ................. 6
5. Architektura projektu ...................................................................... 8
6. Przestrzenie nazw ............................................................................ 8
13.11.2011 r.
str. 3
1. Cel projektu i dziedzina problemu
Zasadniczym celem projektu jest zapewnienie systemu wspomagającego działanie
firmy ubezpieczeniowej. Proponowane rozwiązanie dawałoby możliwośd sprawnego
zarządzania poszczególnymi sektorami przedsiębiorstwa przy jednoczesnej automatyzacji
najczęściej wykonywanych procedur, co przełożyd się może bezpośrednio na ich
niezawodnośd i czas realizacji. Korzystając z projektowanego systemu, zapewniane jest
również bezpieczeostwo w zakresie dostępu do informacji, podnosząc tym samym jego
prestiż i zasadnośd wykorzystania w placówkach o dużym znaczeniu w sensie ochrony
informacji niejawnych, takich jak rozpatrywana firma ubezpieczeniowa. Tworzone
rozwiązanie mogłoby stanowid źródło informacji niezbędnych do analizy działania
przedsiębiorstwa i wspomagania akcji marketingowej, co przekłada się bezpośrednio na
efektywnośd i wydajnośd funkcjonowania biznesu.
2. Wymagania funkcjonalne
Na bazie analizy biznesowej rozpatrywanego zagadnienia wyodrębnione zostały
następujące wymagania stawiane proponowanemu rozwiązaniu:
1) Jako Analityk biznesowy mam możliwośd przeglądania informacji dotyczących działania
przedsiębiorstwa i danych statystycznych istotnych z punktu widzenia akcji
marketingowej.
2) Jako Rzeczoznawca mam możliwośd wycenienia zniszczeo mienia i wystosowania
odpowiedniego odszkodowania dla klienta.
3) Jako Rzeczoznawca mam możliwośd podglądu zgłoszonych szkód.
4) Jako Rzeczoznawca mam możliwośd zmiany statusu szkody.
5) Jako Rzeczoznawca mam możliwośd aktualizacji informacji o szkodzie.
*6) Jako Rejestrator szkód mam możliwośd wprowadzenia zgłoszenia szkody do systemu.
7) Jako Pracownik działu marketingu mam możliwośd określenia odpowiedniej oferty dla
poszczególnego klienta.
8) Jako Pracownik działu komunikacji mam możliwośd rejestracji ubezpieczenia pojazdu dla
poszczególnego klienta.
*9) Jako Pracownik działu obsługi klienta mam możliwośd rejestracji klienta w systemie.
10) Jako Pracownik działu obsługi klienta mam możliwośd wyznaczenia odpowiedniej
oferty ubezpieczeniowej na podstawie informacji pozyskanych od klienta.
11) Jako Pracownik działu ubezpieczeo osobowych mam możliwośd rejestracji
ubezpieczenia dla poszczególnego klienta.
13.11.2011 r.
str. 4
12) Jako Pracownik działu ubezpieczeo nieruchomości i mienia mam możliwośd rejestracji
ubezpieczenia mienia bądź nieruchomości poszczególnego klienta.
13) Jako Pracownik działu obsługi klienta mam możliwośd przeglądu historii operacji
związanych z danym klientem w przedsiębiorstwie.
14) Jako Pracownik działu obsługi klienta mam możliwośd przeglądu stanu wykonywania
odpowiednich operacji w firmie na rzecz danego klienta.
*15) Jako Dyrektor działu mam możliwośd zarządzania uprawnieniami w obszarze swojego
działu.
*16) Jako Dyrektor działu mam możliwośd generowania zbiorczych raportów swojego
działu.
Wymagania oznaczone gwiazdką są tymi, które zostały wybrane do implementacji w
ramach zadanego projektu. Częśd z nich unaoczniają diagramy przypadków użycia,
zaprezentowane poniżej:
Analiza biznesowa przedsiębiorstwa:
Obsługa klienta:
13.11.2011 r.
str. 5
Obsługa zgłoszonych szkód:
Rejestracja ubezpieczeo:
13.11.2011 r.
str. 6
Zarządzanie działem:
3. Komponenty programu
W wyniku dokonanych ustaleo stwierdzono, że omawiany system będzie realizowany
w oparciu o następujące komponenty przedstawione w tabeli niżej:
Platforma
Microsoft .NET 3.5
Język programowania
C#, Transact-SQL, JavaScript, XML
Technologia
ASP, AJAX
Szablony
-
Biblioteki
LINQ, Telerik
System Zarządzania Bazą
Danych
Microsoft SQL Server 2008 R2
Inne komponenty
Microsoft Reporting Services 2008
4. Wykorzystywane wzorce architektoniczne i projektowe
System wspomagania działania firmy ubezpieczeniowej realizowany będzie w oparciu o
wymienione niżej wzorce:
Wzorce architektoniczne
- DAO (Data Access Object)
Wzorzec DAO zakłada istnienie odpowiedniego komponentu, udostępniającego jednolity
interfejs między aplikacją a źródłem danych. Jego zasadniczą zaletą jest możliwośd odseparowania
funkcjonalności dostępu do danych od reszty systemu, dając tym samym logiczny podział
systemu.
W realizowanym projekcie wzorzec DAO możliwy będzie do zrealizowania poprzez
zastosowanie technologii LINQ, będącej warstwą abstrakcji nad różnymi źródłami danych. W tym
przypadku rozwiązanie będzie elementem pośredniczącym w dostępie do bazy danych, separując
tym samym jej mechanizmy działania od sposobu funkcjonowania systemu.
13.11.2011 r.
str. 7
- MVC (Model View Controller)
Ten typ wzorca składa się z trzech głównych części: Modelu, Widoku i Kontrolera. Warstwa
modelu jest pewną reprezentacją problemu bądź logiki aplikacji: wykonuje różnego rodzaju
działania na danych, przygotowując je i udostępniając dla systemu. Warstwa kontrolera przyjmuje
dane wejściowe od użytkownika i zarządza odpowiednimi reakcjami systemu na wprowadzone
akcje. Z tego względu zajmuje się zmianą widoków oraz aktualizacją modeli. Warstwa widoku
zajmuje się odpowiednią prezentacją danych pozyskanych od modelu. Wszystkie z tych części są
wzajemnie połączone i przy pomocy kontrolera wpływają na swoje działanie. Wzorzec ten jest
bardzo często wykorzystywanych w aplikacjach z graficznym interfejsem użytkownika.
Realizując projekt, wzorzec ten możliwy będzie do zastosowania dzięki mechanizmom
wspierającym tworzenie aplikacji według MVC, udostępnianym na platformie Microsoft .NET.
Wzorce projektowe
- Singleton
Jest jednym z kreacyjnych wzorców projektowych. Zakłada istnienie pojedynczej instancji
klasy dostępnej w obrębie całego systemu, udostępniającej metody sterujące odpowiednim
dostępem do danych w niej zawartych. Wszelka dbałośd o istnienie tylko jednego obiektu danej
klasy spoczywa na niej samej. Dodatkowo cały proces pobierania instancji klasy jest niewidoczny
dla użytkownika, co odsuwa od niego koniecznośd pamiętania, czy dany obiekt przy
wywoływaniu metody istnieje, czy też będzie dopiero tworzony.
W wytwarzanej aplikacji wzorzec Singleton wykorzystany zostanie przy realizacji połączenia z
bazą danych oraz do przechowywania kontekstu i sesji użytkownika, zapewniając także ich
odpowiednią obsługę i zarządzanie.
Przyjmując takie wzorce, możliwa staje się odpowiednia separacja poszczególnych warstw aplikacji,
co przekładad się może na zwiększenie efektywności pracy nad projektem - poszczególną warstwą
może zajmowad się zespół odpowiednio do niej wyznaczony, specjalizujący się w realizacji rozwiązao
skojarzonych z tym obszarem systemowym. Również przestrzenie nazw dla realizowanego projektu
wytworzone zostały z myślą o realizacji wzorca DAO i MVC.
13.11.2011 r.
str. 8
5. Architektura projektu
Całośd rozpatrywanego rozwiązania wdrożona zostanie na jednym serwerze, na którym
znajdowad się będą poszczególne komponenty, wymieniane wcześniej, co zostało przedstawione na
poniższym diagramie pakietowym warstw i poziomów:
6. Przestrzenie nazw
Przestrzenie nazw zostały zdefiniowane zgodnie z obszarami funkcjonalnymi systemu z
uwzględnieniem wzorców projektowych planowanych do wykorzystania. Zobrazowane one zostały w
formie drzewa hierarchicznego na diagramie poniżej:
UBEZPIECZENIA
KOMUNIKACYJNE
NIERUCHOMOŚCI
ŻYCIE
ADMINISTRACJA
Dane
Prezentacja
Logika
Dane
Prezentacja
Logika
Dane
Prezentacja
Logika
Dane
Prezentacja
Logika
Rys.1: Diagram hierarchii przestrzeni nazw stosowanych w systemie wspomagania firmy ubezpieczeniowej.