plik

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. 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.