pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 1
w
Modelowanie systemu baz danych dużej instytucji
finansowej wsparte językiem UML 2.0
w
da
.b
w
Streszczenie. Istotą tego rozdziału jest przedstawienie możliwości języka
UML w analizie wymagań oraz modelowaniu struktury bazy danych. Podkreśleniu poddana zostaje integralność bazy danych w systemach biznesowych, jako stałego ich elementu oraz wpływ funkcjonalności tych systemów
na strukturę bazy. Po krótkim teoretycznym wprowadzeniu w elementy
języka UML, praca ukazuje praktyczne jego zastosowanie na podstawie fragmentu projektu systemu informatycznego, którego zadaniem jest integracja
z systemem Generalnego Inspektora Informacji Finansowych (SI*GIIF).
1 Wprowadzenie
pl
s.
Złożoność współczesnych systemów informatycznych oraz rosnący stopień zależności
osób, organizacji, a nawet społeczeństw od oprogramowania sprawił, że ich twórcy stanęli
przed wielkim wyzwaniem. Budowa tak skomplikowanych systemów informatycznych
wiązała się również z potrzebą współpracy licznych grup ludzi. Sprostanie realizacji dużego projektu przy zapewnieniu wysokiej jakości, niezawodności i bezpieczeństwu, były
przyczyną wielu niepowodzeń. Powodem tego była niewystarczająca komunikacja, słaba
koordynacja działań poszczególnych grup specjalistów oraz brak określonego procesu
wytwarzania oprogramowania. Z pomocą posłużył proces modelowania systemów
wspomagany językiem UML.
Zunifikowany język modelowania (ang. Unified Modeling Language), jest następcą
obiektowych metod analizy i projektowania, które pojawiły się na przełomie lat osiemdziesiątych i dziewięćdziesiątych. Koncepcja języka UML powstała w firmie Rational
Corporation, a twórcami są tzw. „trzej muszkieterowie”: Grady Booch, Jim Rumbaugh,
Ivar Jacobson. UML jest notacją graficzną stosowaną do wyrażania modeli, zapewniając
przy tym dobrą komunikację pewnych idei i pomysłów. Język naturalny jest nieprecyzyjny
i problemy przy bardziej złożonych pojęciach, natomiast UML jest niezastąpiony przy
tworzeniu dużego systemu, pomaga zobrazować główne jego składowe oraz ich współzależności [1].
Unified Modeling Language jest językiem znormalizowanym, może być stosowany do
przedstawiania, specyfikowania, tworzenia i dokumentowania elementów systemu informatycznego. Wspomaga określenie decyzji na każdym etapie zaawansowania projektu.
Sebastian Kwapisz: Uniwersytet Gdański, Katedra Informatyki Ekonomicznej,
ul. Armii Krajowej 119/121, 81-824 Sopot, Polska
email: [email protected]
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
S. Kwapisz
w
Głównymi celami języka UML są [2]:
− modelowanie elementów systemów (nie tylko oprogramowania) z użyciem pojęć
obiektowych,
− stworzenie języka do modelowania użytecznego zarówno dla ludzi jak i dla maszyn,
− pomost pomiędzy ludzkim rozumieniem struktury i działania programów, a kodem
programów,
− specyfikowanie, konstrukcja, wizualizacja i dokumentacja zagadnień związanych
z wykorzystaniem oprogramowanie.
UML skupia się na standaryzacji języka do modelowania, a nie na ujednoliceniu procesów tworzenia oprogramowania. Stworzenie wspólnej unifikacji semantyki oraz notacji,
umożliwia różnym organizacjom opisanie zagadnień, składających się z wielu procesów,
przy pomocy tego samego języka.
w
2 Znaczenie UML w projektowaniu Baz Danych
w
da
.b
Modelowanie systemu informatycznego wymaga spojrzenia na dany temat z kilku punktów
widzenia. Wiele osób związanych projektem ma inne spojrzenie na system (użytkownicy
końcowi, programiści, analitycy czy też specjaliści od integracji systemu). Każdy patrzy na
zadanie z innej perspektywy i na innym etapie jego życia.
Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu
tworzenia systemu. Pozwala zebrać i uporządkować wszystkie punkty widzenia, dlatego
jest jednym z najistotniejszych elementów systemu.
Architektura oprogramowania jest ogólną budową systemu komputerowego, która
określa składowe, powiązania miedzy nimi oraz wzajemne interakcje i przepływy informacji [3]. Oprócz struktury i dynamiki, dotyczy również jego funkcjonalności i możliwości
ponownego użycia. Uwzględnia również aspekty ekonomiczne i technologiczne, które mają
wpływ na postać systemu.
Specyfikacja UML 2.0 dostarcza wielu możliwości sprawnego opisu modelu systemu
z uwypukleniem wybranych jego elementów. Pozwala zbudować architekturę systemu,
która daje kontekst dla projektu bazy danych. Wykorzystując odpowiednie stereotypy
oraz rozszerzenia języka UML można zaprojektować tabele, związki oraz opracować logikę
procedur składowych.
Proces tworzenia bazy danych dla danego systemu informatycznego jest bardzo istotny
z punktu spełniana jego prawidłowego funkcjonowania oraz wydajności.
Najlepszym sposobem przedstawienia systemu jest zaprezentowanie jego funkcjonalności z kilku perspektyw.
Perspektywa (ang. view) – w szerszym znaczeniu określa obraz pojęciowy danych,
który jest przypisany do użytkownika lub grupy użytkowników i pomija elementy mniej
istotne dla jego działalności. Jest abstrakcyjną strukturą, przedstawioną za pomocą wielu
diagramów, która pokazuje właściwości systemu z różnych punktów widzenia [4].
Wszystkie perspektywy języka UML stanowią niezależną całość, przy czym są ze sobą
ściśle powiązane. Każdy członek zespołu projektowego może skoncentrować się na wybranym fragmencie architektury systemu, a dzięki multiperspektywiczności UML ukazane są
wzajemne jej oddziaływania.
Ponieważ projektowanie bazy danych wymaga skoncentrowania się na elastyczności
rozwiązania oraz możliwości jego ponownego wykorzystania, przejrzystość specyfikacji
języka UML sprzyja tym zabiegom. Diagramy dobrze opracowanego projektu mogą zostać
w pełni bądź częściowo zaadoptowane przez inne projekty.
pl
s.
14
Modelowanie systemu baz danych dużej instytucji finansowej wsparte językiem UML 2.0
w
Z punktu modelowania bazy danych, oczywiście w zależności od problemu i funkcjonalności bazy, największe zastosowanie mają diagramy struktury: diagram klas, diagram
struktur połączonych, diagram obiektów, diagram pakietów oraz diagramów rozlokowania: diagram komponentów i diagram rozlokowania. Jednak w celu zrozumienia
architektury systemu oraz jego funkcjonalności konieczne jest również skorzystanie
z diagramów przypadków użycia oraz modeli biznesowych. Jeśli w bazie danych mamy
do czynienia ze złożonymi procedurami składowymi można zastosować diagramy interakcji .
Dzięki programom CASE(Computer Aided Systems Engineering), wspomagającym
modelowanie, wykorzystanie możliwości UML stają się bardziej efektywne. Szczególną
uwagę należy zwrócić na bazodanowy profil UML, który dostarcza szereg mechanizmów
w postaci stereotypów bazodanowych (np.:<<Table>>, <<View>>) oraz rozszerzeń.
Istnieje już na poziomie modelu zdefiniowanie takich elementów jak kluczy, indeksów czy
nawet użytkowników. Programy CASE pozwalają na podstawie tak stworzonych diagramów wygenerować gotowy kod zarówno w wielu językach programowania (VB, C++,
Java), jak i w postaci skryptu SQL uwzględniając typ bazy danych (np. SQL Server 2000,
Oracle, InterBase itp.).
w
w
3 Potrzeby informatyzacji integracji z systemem SI*GIIF
da
.b
pl
s.
Problem „prania brudnych pieniędzy” dotyka w coraz szerszym stopniu również polski
system finansowy. W celu przeciwdziałania temu zjawisku uchwalona została ustawa narzucająca obowiązek gromadzenia i rejestracji wszelkich transakcji finansowych dokonywanych przez tzw. instytucje obowiązane.
Przedstawiony poniżej projekt systemu REJESTRATOR wspiera i usprawnia proces
przekazywania danych przez instytucje bankową do Głównego Inspektora Informacji
Finansowej zgodnie z przepisami rozporządzenia Ministra Finansów w sprawie określenia
wzoru rejestru transakcji[8].
Zadaniem systemu REJESTRATOR jest zbieranie informacji o transakcjach „ponadprogowych”, których kwota przekracza określoną przez ministerstwo wartość. Ma to na celu
wychwycenie ewentualnych oznak „prania” pieniędzy. Zarówno zakres jak i format danych
zgłaszanych do GIIF musi być zgodny z wymaganiami stawianymi przez tę instytucję.
Rozporządzenia Ministra Finansów nakładają obowiązek oraz odpowiedzialność na
instytucjach rejestracji takich transakcji na rynku między bankowym, kiedy bank działa na
podstawie dyspozycji klienta. Wymaga to od instytucji zobowiązanej przedsięwzięcie
odpowiednich kroków w celu realizacji wymagań ministerstwa. Proces wysyłania informacji wymaga od banku stworzenia odpowiedniej infrastruktury informatyczne umożliwiającej sprawne wykrywanie takich operacji oraz integrację z systemem znajdującym się
w ministerstwie. Ogólny schemat systemu Rejestrator przedstawia rys. 1.
W celu efektywnego gromadzenia danych do raportów XML system REJESTRATOR
będzie pobierał potrzebne informacje automatycznie z baz danych oddziałów. Zadaniem
Kontrolerów w jednostkach organizacyjnych banku jest weryfikacja poprawności zarejestrowanych transakcji oraz możliwość wprowadzenia ich ręcznie, jeśli występowałoby
podejrzenie o przestępstwie. Główny Kontroler jest odpowiedzialny za tworzenia „paczki”
transakcji z danego miesiąca, która jest zapisana w postaci w pliku XML oraz przesyłanie
jej do ministerstwa.
15
S. Kwapisz
SYSTEM
ZEWNĘTRZNY
SI*GIIF
Raport
XML
w
Baza Danych
Systemu
REJESTRATOR
CENTRALA
BANKU
w
w
Główny
Kontroler
ODDZIAŁY
BANKU
Server Aplikacji
Baza
Danych
Oddziału
Baza
Danych
Oddziału
da
.b
Kontrolerzy w Oddziałach
Rys. 1. Schemat systemu REJESTRATOR
System zrealizowany będzie w technologii klient – serwer, oznacz iż użytkownik
poprzez przeglądarkę internetową będzie komunikował się z serwerem aplikacyjnym.
Dzięki temu będzie możliwa praca rozproszonej grupy jednostek współpracujących
w ramach jednego banku, z jednoczesnym zapisem danych na centralnym serwerze
bazodanowym.
Rejestrator zostanie wdrożony w wewnętrznej sieci banku, będzie wykorzystywał jej
architekturę w celu komunikacji pomiędzy składowymi systemu. Komunikacja z systemami zewnętrznymi ograniczać się będzie do wysyłania i odbierania raportów.
pl
s.
3.1 Funkcjonalności systemu - Diagram Przypadków Użycia
Wykorzystując Diagram Przypadków Użycia można prawidłowo określić wymagania projektowanego systemu oraz kto i jakim zakresie będzie je wykorzystywał. Przedstawione
w ten sposób funkcjonalności pozwalają wstępnie określić, który przydatek użycia wymaga
zastosowania bazy danych oraz jakimi elementami powinna się ona charakteryzować
(tabele, związki itp.).
16
ud Przypadki Użycia
System REJESTRATOR
Administrow anie
w
Administrator
Generuj Raport
«extend»
Zarządzanie
Użytkow nikami
Weryfikuj Raport
«include»
«extend»
Przegladaj Raporty
Wyślij Raport
w
Użytkow nik
Raportow anie
«include»
«extend»
Głów ny Kontroler
Dodaj Now ą
Transakcj ę
w
Obsługa
Transakcj i
«extend»
«include»
«extend»
Weryfikuj
Transakcj ę
«extend»
da
.b
Lokalny Kontroler
Konfiguruj import
Transakcj i
Popraw
Transakcj ę
«include»
Rys. 2. Diagram Przypadków Użycia
pl
s.
Diagram przypadków użycia przedstawiony na rysunku 2 zawiera trzech aktorów:
Administrator, Główny Kontroler, Lokalny Kontroler są to uszczegółowienia abstrakcyjnego aktora Użytkownik.
Wykonanie przypadku użycia Administrowanie jest przypisane do aktora Administrator.
Umożliwia mu ustawienie aplikacji w celu poprawnego działania. Dodatkowo przypadek
ten jest rozszerzany (<<extend>>) przypadkiem Zarządzanie użytkownikami, który pozwala na pełne zarządzanie użytkownikami oraz ich rolami. Związek ten ma charakter opcyjny.
Użytkownik Główny Kontroler może korzystać z pełnych funkcjonalności systemu.
Posiada uprawnienia do wykonywania przypadków użycia Raportowanie i Obsługa
Transakcji. Natomiast zadania Lokalnego Kontrolera są mniej złożone i koncentrują się
jedynie na przypadku użycia Obsługa Transakcji.
Przypadek użycia Obsługa Transakcji pozwala na ewidencjonowanie transakcji, jest rozszerzony przez następujące przypadki: Dodaj Nowa Transakcje, Popraw Transakcję oraz
Konfiguruj import Transakcji. Użytkownik inicjując Dodaj Nowa Transakcje bądź Popraw
Transakcję jest zobligowany do zweryfikowania poprawności wprowadzanych danych.
Wykonywany zostaje wówczas zawierany(<<include>>) przypadek użycia Weryfikuj
Transakcję.
Aktor Główny Kontroler wykorzystuje funkcjonalność generowania raportów, która polega na pobraniu właściwych danych ze zbioru zarejestrowanych transakcji. Przypadek
użycia Raportowanie jest rozszerzany przez przypadki Wyślij Raport oraz Generuj Raport.
Wykorzystanie przypadku Generuj Raport pociąga za sobą konieczność zweryfikowania
17
S. Kwapisz
w
poprawności raportu. Uzyskuje się to poprzez zainicjowanie zawieranego (<<include>>)
przypadku użycia Weryfikuj Raport. Następnie po wygenerowaniu raportu i poprawnej
walidacji jest on zapisywany w bazie danych. Wówczas Główny Kontroler może wykonać
Wyślij Raport, który zawiera przypadek użycia Przeglądaj Raporty. Ma to na celu dokładne
wskazanie raportu, który ma zostać wysłany do systemu ministerstwa SI*GIIF.
Na diagramie (rys. 2) można wyróżnić trzy główne moduły systemu, które ze względu
na swoją funkcję będę wymagały zastosowania odpowiedniej struktury bazy danych.
− Moduł Administracyjny - umożliwia tworzenie użytkowników oraz przypisywanie
im uprawnień. Użytkownicy są podzieleni na administratorów systemu, Głównych
Kontrolerów Banku oraz Kontrolerów w oddziałach Banku. Lokalny Kontroler ma
możliwość wprowadzania i modyfikowania danych oraz weryfikowania poprawności
zaewidencjonowanych transakcji. Wprowadza również na bieżąco dane dotyczące
tzw. „wypłat nagłych”. Główny Kontroler Banku ma możliwość wprowadzania poprawek, edycji oraz raportowania działalności wszystkich jednostek oraz tworzenia
sprawozdań do GIIF.
− Moduł Raportujący – umożliwia operacje na danych: edycję, przeglądanie, sortowanie, generowanie raportów. Możliwości edycji, tworzenia raportów są dostępne
w zależności od nadanych użytkownikowi uprawnień.
− Moduł Obsługi Transakcji – umożliwia importowanie, wprowadzanie i modyfikowanie transakcji. System sprawdza poprawność wprowadzonych transakcji w czasie
działania. Proces automatycznego importu danych jest uruchamiany codziennie i jego efektem jest wykrycie podejrzanych finansowo transakcji w każdym z oddziałów.
da
.b
w
w
3.2 Projektowanie Procesów Systemu
pl
s.
Proces ewidencji transakcji może być realizowany na dwa sposoby. Pierwszy polega na
tym, iż uprawniony do tego użytkownik łączy się z interfejsem obsługi transakcji wprowadza dane ręcznie. Po czym następuje walidacja wprowadzonych danych, jeśli proces ten
przebiegnie pomyślnie następuje zapis w bazie danych.
Diagram sekwencji przedstawiony na rys. 3 prezentuje interakcje procesu rejestrowania
nowej transakcji. Użytkownik do uruchomienia procesu wykorzystuje Obsługę Transakcji.
Następnie kontrolę przejmuje interfejs ITransakcji, do którego użytkownik przekazuje dane
transakcji i wykonuje komunikat dodajTrans. Instancja klasyfikatora ITransakcji wywołuje
operację na tabelach Wlasciciel, Dysponent, Beneficjent w celu pobrania numeru id odpowiedniego podmiotu. Operacja ta wykonywana jest jako pętla programowa(loop) i pozwala
na przeszukanie wszystkich zarejestrowanych podmiotów. Jeśli wprowadzone dane transakcji zostaną poprawnie zweryfikowane walidujTrans interfejs ITransakcji wykonuje procedurę składową addTrans na tabeli Transakcja. Jeśli proces zostanie zakończony pozytywnie zostaje wysłany komunikat komunikat(Zapisana), w przeciwnym wypadku zostaje
przesłana informacja o błędzie komunikat(Error).
Drugi sposób rejestracji oparty jest o automatyczny import transakcji. System pobiera informacje o codziennych transakcjach Banku z istniejących bazy transakcyjnej i umieszcza
je w bazie danych systemu. Z uwagi na możliwość wystąpienia pewnych błędów podczas
importu wszystkie transakcje są zapisywane. Jeżeli walidacja importu była niepomyślna,
wówczas zostaje przypisana wartość parametrowi Walidacja = False, w przeciwnym razie
wartość wynosi True. Dzięki takiemu rozwiązaniu użytkownicy mogą łatwo wybrać transakcje wymagające korekty. Wszystkie dane w razie potrzeby mogą być uzupełniane
i poprawiane przez użytkowników.
18
sd Proces Rej estracji transakcj i
Użytkownik
«interface»
«table»
«table»
«table»
«table»
:ITransakcji
:Transakcj a
:Wlasciciel
:Dysponent
:Beneficj ent
Obsługa
Transakcji
wprowadzDane
Transakcja:= dodajTrans(Transakcja)
idWlasciciel:= selectWlasciciel()
w
loop
idDysponenta:= selectDysponent()
idBeneficjenta:= selectBeneficjent()
w
Boolean:= walidujTrans(Transakcja)
alt
[walidujTrans = True]
addTrans(Transakcja)
Komunikat(Zapisana)
w
[walidujTrans = False]
Komunikat(Error)
Zamknij
d
.b
(from Use Case Model)
Rys. 3. Proces rejestracji transakcji
l
.p
as
Diagram sekwencji przedstawiony na rys. 4 pokazuje interakcje importu transakcji.
Użytkownik do uruchomienia procesu wykorzystuje Obsługę Transakcji. Następnie kontrolę przejmuje interfejs ITransakcji, za pomocą którego użytkownik ustawia parametry
importu: wartoscTrans, BazaDanych, Tabela, login i hasło. Informacje te są konieczne, aby
poprawnie zainicjować połączenie z bazą danych, która zawiera dane do importu. W tym
celu instancja ITransakcji wywołuje operację ustawImport klasyfikatora Import. Po zainicjowaniu przez użytkownika importowania pobierane są parametry importu, a następnie
uruchamiane wyszukiwanie transakcji we wskazanej bazie danych. Operacja ta wykonywana jest jako pętla programowa(loop). Jeśli komunikat select = 0, system poinformuje użytkownika o barku transakcji. Jeśli jednak zostanie odnaleziona przynajmniej jedna transakcja, uruchamiana jest walidacja- walidujTrans, a następnie zapis danych w bazie. Na końcu
użytkownik zostaje poinformowany o efektach importu.
Wszystkie transakcje zapisane w systemie REJESTRATOR podlegają wysłaniu do GIIF.
Wykonanie eksportu okresowego raportu skutkuje wygenerowaniem dokumentu XML.
Dokument jest zapisany w pliku pod odpowiednią nazwą np. 14022006.xml. Wyeksportowane pozycje rejestru oznaczone są wspólnym identyfikatorem.
Proces generowania raportu jest inicjowany przez użytkownika o uprawnieniach Głównego Kontrolera. Najpierw następuje pobranie transakcji zapisanych w bazie danych systemu w określonym przedziale czasu. Po udanym procesie walidacji raportu, tak sporządzony
dokument XML może zostać zapisany.
19
S. Kwapisz
sd Proces importow ania transakcj i
«interface»
:Użytkownik
«table»
:Import
:ITransakcj i
:Transakcj a
Obsługa
Transakcji
Baza Danych
konfigurujImport
ustawImport
Import:= ustawImport(wartoscTrans, BazaDanych, Tabela, Login, Haslo)
uruchomImport
w
Transakcja:= ImportujTrans()
String:= pobierzParamteryImportu()
Transakcja:= select
loop
w
alt
Boolean:= walidujTrans()
[select > 0]
w
alt
[walidujTrans = True]
loop
setWalidacja(True)
Komunikat(ImportPoprawny)
da
.b
[walidujTrans = False]
loop
setWalidacja(False)
Komunikat(ImportZbledami)
[select = 0]
zamknij
komunikat(brakTrans)
pl
s.
Rys. 4. Diagram sekwencji proces importu transakcji
Diagram sekwencji przedstawiony na rys. 5 pokazuje interakcje w procesie generowania raportów. Użytkownik do zainicjowania tego procesu wykorzystuje Obsługę Raportów, która
wywołuje komunikat generujRaport na interfejsie IRaport. Następnie korzystając z komunikatu pobierzTrans interfejsu ITransakcji, pobiera za pomocą procedury składowej
selectTrans transakcje zarejestrowane w tabeli Transakcja w miesiącu, którego dotyczy
raport. Jeśli walidujRaport=True za pomocą procedury składowej addRaport wykonywany
jest zapis danych w tabeli Raport. Użytkownik wówczas otrzymuje komunikat Wygenerowano.
Proces wysyłania raportu do systemu SI*GIIF może nastąpić bezpośrednio po jego
utworzeniu lub później, wymaga jednak ingerencji Głównego Kontrolera Banku.
20
sd Generow anie Raportu
Główny Kontroler
«interface»
«interface»
«table»
«table»
:IRaportu
:ITransakcj i
:Transakcj a
:Raport
Obsługa
Raportów
generujRaport
Raport:= generujRaport()
Transakcja:= pobierzTrans()
w
loop
Transakcja:= selectTrans()
Boolean:= walidujRaport()
w
alt
addRaport(Raport)
[walidujRaport = True]
Komunikat(Wygenerowano)
[walidujRaport = False]
w
Komunikat(Error)
zamknij
da
.b
Rys. 5. Proces generowania raportów
sd Wysyłanie Raportu
Główny Kontroler
«interface»
«table»
:IRaportu
:Raport
Obsługa
raportów
SI*GIIF
wyślijRaport
wyslijRaport()
Raport:= selectRaport()
pl
s.
wyslij
alt
String:= komunikat(Zarejestrowany)
[poprawny]
Komunikat(poprawny)
[odrzucony]
String:= komunikat(niepoprawny)
Komunikat(odrzucony)
zamknij
Rys. 6. Proces wysyłania raportów do SI*GIIF
21
S. Kwapisz
w
Proces wysyłania raportu przedstawiony na rys. 6 rozpoczyna się, kiedy Główny
Kontroler wykorzystując stronę Obsługa Raportów wykona komunikat wyślijRaport na
interfejsie IRaportu. Dane raportu pobierane są z tabeli Raport, za pomocą komunikatu
selectRaport. Następnie interfejs IRaportu przekazuje komunikatem wyslij raport do
obiektu granicznego, jakim jest system ministerstwa SI*GIIF. Klasyfikator interfejsu
IRaportu oczekuje na komunikat zwrotny, po przetworzeniu raportu w ministerstwie.
W zależności o weryfikacji przeprowadzonej w systemie ministerstwa na stronie Obsługa
raportów pojawi się komunikat poprawny bądź odrzucony.
Wysłanie Raportu
w
Przetw arzanie w SI*GIIF
Odbieranie
Podpis oczekuj e na
spraw dzenie
Podpis niepopraw ny
.b
w
Weryfikuj e
Podpis popraw ny
Transakcj e
w czytano
Zarej estrow anie
True
False
Niepopraw ny
when raport = "przyjety"
s.
da
Rys. 7. Diagram Maszyny Stanowej wysyłania raportów do SI*GIIF
pl
Diagram maszyny stanowej na rys. 7 przedstawia stany w jakich znajduje się raport, po
wysłaniu do systemu ministerstwa. Przetwarzanie w SI*GIIF jest stanem złożonym, który
zawiera podmaszyny stanowe. Przedstawione na powyższym diagramie stany oznaczają:
− zarejestrowany – oznacza, iż plik został przyjęty do systemu GIIF. W przypadku
przesyłania plików pocztą elektroniczną status ten pojawi się po rozszyfrowaniu pliku, co w zależności od oczekujących plików może potrwać do kilku godzin. Dzieje
się tak dlatego, że identyfikacja przesłanego pliku i jego przypisanie do konkretnej
instytucji może nastąpić dopiero po weryfikacji podpisu elektronicznego i rozszyfrowaniu pliku;
− podpis oczekuje na sprawdzenie – oznacza, że system informatyczny GIIF oczekuje
na weryfikację autentyczności podpisu elektronicznego. Czas potrzebny na sprawdzenie autentyczności to 1h. Czas ten wynika z ustawy o podpisie elektronicznym –
w tym czasie kwalifikowane urzędy certyfikacji weryfikują autentyczność podpisu;
− podpis poprawny - oznacza, że podpis został zweryfikowany jako autentyczny i plik
oczekuje na rozszyfrowanie;
− podpis niepoprawny - oznacza, że podpis został zweryfikowany jako niepoprawny
i plik nie będzie rozszyfrowywany, a jego status zmieni się na "Do wyjaśnienia";
− transakcje wczytano – oznacza, że w rozszyfrowanym pliku system informatyczny
GIIF znalazł poprawnie zapisane dane o transakcjach i zostały one wczytane do systemu informatycznego GIIF. Proces przesłania pliku zakończony został poprawnie;
22
− niepoprawny – oznacza, że w rozszyfrowanym pliku system informatyczny GIIF
znalazł dane zapisane i przesłane przez instytucję obowiązaną z naruszeniem ustalonych przedmiotowym rozporządzeniem Ministra Finansów formatów przesyłania danych. Instytucja obowiązana powinna zweryfikować poprawność przesłanych danych
pod względem formalnej ich zgodności z formatem zawartym w rozporządzeniu i po
zidentyfikowaniu błędu należy przesłać poprawione dane po raz kolejny.
w
3.3
Model Struktury Bazy Danych
w
w
Bazodanowy profil UML zawiera wszystkie elementy potrzebne do modelowania struktury
bazy danych. Stosując odpowiednie stereotypy (<<Table>>, <<Proc>>, <<View>>)
można w łatwy sposób zaprojektować bazę danych. Wykorzystując oprogramowanie CASE
możliwa jest bardziej szczegółowa specyfikacja tworzonych diagramów oraz wygenerowanie na ich podstawie gotowych skryptów np. SQL. Istotnym elementem są również przestrzenie nazw (ang. Table space), które wykorzystywane są do agregowania oraz dekompozycji tabel. Tworzą klarowną hierarchiczną strukturę, wpływa to na lepsze zrozumienie
bazy danych przez członków zespołu projektowego. Ma to duże znaczenie w sytuacji kiedy
chcemy ponownie wykorzystać lub wprowadzić modyfikacje.
Oddział
da
.b
*PK «column» IdOddzialu: int
*
«column» Nazwa: nvarchar(100)
«column» Miasto: nvarchar(100)
+
+
+
+
«PK» PK_Oddział(int)
«proc» addOddzial()
«proc» delOddzial()
«proc» updateOddzial()
1
«FK»
+FK_Uzytkownik_Oddział 0..*
Uzytkow nik
Rola
*PK «column» IdRoli: int
«column» Nazwa: nvarchar(50)
+
+
+
+
+
«PK» PK_Rola(int)
«proc» addRola()
«proc» delRola()
«proc» updateRola()
«proc» selectRola()
1
«FK»
0..*
+
+
+
+
+
+
+
+
«column»
«column»
«column»
«column»
«column»
«column»
«column»
IdUzytkownika: int
IdRoli: int
IdOddzialu: int
Imie: nvarchar(50)
Nazwisko: nvarchar(50)
login: nvarchar(50)
haslo: nvarchar(50)
pl
s.
*PK
*FK
*FK
*
*
+FK_Uzytkownik_Rola *
*
«FK» FK_Uzytkownik_Oddział(int)
«FK» FK_Uzytkownik_Rola(int)
«PK» PK_Uzytkownik(int)
«unique» UQ_Uzytkownik_login(nvarchar)
«proc» updateUser()
«proc» addUser()
«proc» delUser()
«proc» selectUser()
Rys. 8. Diagram struktury bazy danych modułu administracji
Struktura bazy danych systemu REJESTRATOR składa się z następujących przestrzeni
nazw (<<Tablespace>>), które są tożsame z modułami systemu:
− Administracji, w którego skład wchodzą tabele : Użytkownik, Rola oraz Oddział,
− Obsługi Transakcji, którą tworzą tabele: Transakcja, Dysponent, Wlasciciel,
Beneficjent,
− Raportowania składającej się zarówno z tabeli Raport, jak i Transakcja.
23
S. Kwapisz
w
Diagram zaprezentowany na rys. 8 przedstawia schemat bazy danych modułu administracji.
Centralnym punktem tego fragmentu bazy danych jest użytkownik sytemu, którego dane
zapisane są w tabeli Użytkownik. Kluczem głównym tej tabeli, oznaczonym stereotypem
PK(PrimaryKey), jest pole idUzytkownika, które może przyjmować wartości typu int.
Tabela Uzytkownik posiada dwa klucze obce FK(ForeignKey) iRoli oraz idOddzialu, które
są odpowiednikami kluczy głównych tabel: Rola i Oddział. Wskazania liczbowe asocjacji
pomiędzy tabelami, określają budowę relacji np. użytkownik musi być przypisany do co
najmniej jednej roli, ale może nie być przypisany do ściśle określonego oddziału (np. kiedy
jest Głównym Kontrolerem Banku). Występowanie kluczy obcych w tabeli Użytkownik
jest pewnym ograniczeniem, z uwagi na rodzaj wprowadzanych danych.
Transakcj a
w
Raport
«PK» PK_Raport(int)
«proc» addRaport()
«proc» delRaport()
«proc» updateRaport()
«proc» selectRaport()
Dysponent
+
+
+
+
+
IdDysponenta: int
zTypPo: nvarchar(2)
zNz: nvarchar(140)
zAdrKr: nvarchar(2)
zObyw: nvarchar(2)
zAdrKod: nvarchar(10)
zAdrM: nvarchar(35)
1
zAdrUl: nvarchar(35)
zNrPes: nvarchar(11)
zNrReg: nvarchar(9)
zNrReS: nvarchar(10)
zNrSwt: nvarchar(15)
zNip: int
zRodzDokTo: nvarchar(2)
zNrDokTo: nvarchar(25)
«FK»
+
+
+
+
+
+
+
+
+
+
«FK» FK_Transakcja_Raport(int)
«FK» FK_Transakcja_Beneficjent(int)
«FK» FK_Transakcja_Dysponent(int)
«FK» FK_Transakcja_PodmiotWimieniu(int)
«PK» PK_Transakcja(int)
«proc» addTrans()
«proc» dellTrans()
«proc» updateTrans()
«proc» selectTrans()
«proc» setWalidacja()
l
.p
as
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
«column»
d
.b
+
+
+
+
+
IdRaportu: int
NipIO: int
IKart: int
pDat: datetime
pCzas: smalldatetime
w
*PK «column»
«column»
«column»
«column»
«column»
*PK «column» IdTransakcji: int
FK «column» IdRaportu: int
«column» nrEwT: int
«column» nrRejDat: datetime
«column» rejDat: datetime
«column» jedIO: int
«column» Status: int
+FK_Transakcja_Raport
«column» kRodzTr: nvarchar(4)
«column» kPwz: nvarchar(1)
«FK»
1..*
1
«column» kPdjrz: nvarchar(4)
«column» spDysp: int
«column» nrDokT: nvarchar(12)
«column» tDat: datetime
«column» tM: nvarchar(35)
«column» tJ: nvarchar(3)
«column» tKwZ: nvarchar(15)
«column» nrRachZ: nvarchar(56)
«column» nrRachN: nvarchar(56)
«column» Uwagi: nvarchar(1500)
+FK_Transakcja_Dysponent FK «column» IdBeneficjenta: int
FK «column» IdWlasciciel: int
1 FK «column» IdDysponenta: int
«column» Walidacja: bit
1
«PK» PK_Dysponent(int)
«proc» addDyspon()
«proc» delDyspon()
«proc» updateDyspon()
«proc» selectDysponent()
+FK_Transakcja_PodmiotWimieniu
1
+FK_Transakcja_Beneficjent
«FK»
«FK»
1
1
Beneficj ent
Wlasciciel
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
+
+
+
IdWlasciciel: int
pTypPo: nvarchar(2)
pNz: nvarchar(140)
pAdrKr: nvarchar(2)
pAdrKod: nvarchar(10)
pAdrM: nvarchar(35)
pAdrUl: nvarchar(35)
«PK» PK_PodmiotWimieniu(int)
«proc» addWlasciciel()
«proc» delWlasciciel()
«proc» updateWlasciciel()
«proc» selectWlasciciel()
*PK «column»
«column»
«column»
«column»
«column»
«column»
«column»
+
+
+
+
+
IdBeneficjenta: int
bTypPo: nvarchar(2)
bNz: nvarchar(140)
bAdrKr: nvarchar(10)
bAdrKod: nvarchar(10)
bAdrM: nvarchar(35)
bAdrUl: nvarchar(35)
«PK» PK_Beneficjent(int)
«proc» addBeneficjent()
«proc» delBeneficjent()
«proc» updateBeneficjent()
«proc» selectBeneficjent()
Rys. 9. Diagram struktury bazy danych modułu obsługi transakcji i raportowania
24
w
Dodatkowe ograniczenie zostało nałożone na kolumnę login, wymuszając wartości
unikatowe. Oznaczone to zostało stereotypem <<unique>>. Wszystkie tabele posiadają
określone stereotypem <<proc>> procedury składowe, które umożliwiają wykonywanie
operacji na tabelach
Ponieważ moduły obsługi transakcji oraz raportowania nachodzą na siebie, strukturę
tego fragmentu bazy danych można rozpatrywać na jednym diagramie. Na rysunku 8
zawarte są tabele: Raport, Transakcja, Dysponent, Wlasciciel, Beneficjent. Centralnym
punktem tego fragmentu bazy danych, z punktu widzenia funkcjonalności systemu, są dwie
tabele Transakcja oraz Raport.
Tabela Transakcja składa się z klucza głównego PK IdTransakcji oraz czterech kluczy
obcych idRaportu, idBeneficjenta, idWlasciciela, idDysponenta, które reprezentują klucze
główne swoich tabel. Pozostałe kolumny opisują dane transakcji. Ważnym elementem jest
kolumna Walidacja, która przyjmuje wartości False lub True, w zależności od przebiegu
weryfikacji poprawności przy imporcie transakcji. Liczebności asocjacji wskazują na
relacje pomiędzy tabelami. Każdej transakcji musi być przypisany jeden Wlasciciel,
Dysponent oraz Beneficjent. Natomiast Raport jest elementem agregującym transakcje
z danego miesiąca, aby mógł być stworzony musi istnieć przynajmniej jedna transakcja.
Zastosowana tutaj forma agregacji częściowej wskazuje, iż obiekty współdzielone, czyli
Transkacje mogą samodzielnie funkcjonować, niezależnie od agregatu.
w
w
dd Diagram Rozlokow ania
da
.b
- Procesor: 2 x 2 GHz Xeon
- Pamięć : 4x 1 GB
- Macierz dyskowa 2 TB
- Platforma: Microsoft Windows
Server 2003
- Baza danych: Microsoft SQL Server
firew all
Stacj a użytkow nika
1
«TCP-IP»
1..
1
«ethernet»
Siec Banku
«fast ethernet»
1
Serw er Bazy
Danych
1
Przeglądarka
internetow a
1
«fast ethernet»
1
1
- Procesor: 2x 2 GHz Xeon
- Pamięć : 2x 1 GB
- Dysk: SCSI 300 GB
10000RPM
- Platforma: Microsoft
Windows Server 2003
Serw er Aplikacj i
Raportuj ącej dla
GIIF
«deploy»
Baza Danych.mdf
«asp page»
Obsługa Raportów.aspx
«manifest»
Component
Model::Obsługa
Raportów
«deploy»
pl
s.
«deploy»
«artifact»
«deploy»
«asp page»
Logowanie.aspx
«asp page»
Obsługa Transakcji.aspx
«manifest»
Component
Model::
Administracj a
«manifest»
Component
Model::Obsługa
Transakcj i
Rys. 10. Diagram rozlokowania komponentów systemu
Powyższy diagram rozlokowania jest opracowany na poziomie fizycznym, ponieważ
zawiera szczegółowo specyfikacje atrybutów węzłów. System Rejestrator docelowo będzie
wdrożony w wewnętrznej sieci banku. Zgodnie z tym założenie diagram na rys. 10 przed25
S. Kwapisz
w
stawia rozmieszczenie tego systemu w architekturze sieciowej banku. Szczegółowe
parametry wskazano na trzech węzłach: Serwer Aplikacji dla GIIF, Serwer Bazy Danych
oraz Stacja Użytkownika. Są to jedyne elementy, które w obecnej sytuacji mogą podlegać
konfiguracji pod kątem tego systemu. Pozostałe elementy zaś, takie jak ustawienia sieci czy
firewall, są parametrami, które system musi zaakceptować.
Węzły serwer bazy dany oraz aplikacyjnego posiadają szczegółowe informacje o procesorze, pamięci RAM, kontrolerach dysków twardych oraz systemach operacyjnych.
W przypadku bazy danych określono również jej typ Microsoft SQL Server. Natomiast
stacja użytkownika powinna zawierać przeglądarkę internetową, która umożliwi mu
korzystanie z systemu.
Na serwerze aplikacyjnym zostały osadzone trzy artefakty: Obsłua_Raportów.aspx,
Logowanie.aspx, Obsługa_Transakcji.apsx oraz trzy komponenty systemu. Dzięki
umieszczeniu ich na serwerze aplikacji internetowych Microsoft IIS(Internet Information
Services), który jest składnikiem systemu operacyjnego Windows Serwer 2003, będą mogły
być wykorzystywane przez użytkownika za pomocą jego przeglądarki. Serwer bazodanowy
natomiast, będzie zawierał całą strukturę bazy danych, która jest wymagana do prawidłowej
pracy systemu.
w
w
4 Podsumowanie
da
.b
Literatura
1.
2.
3.
4.
5.
6.
7.
8.
pl
s.
Celem niniejszego rozdziału było przedstawienie przydatności języka UML w procesie
modelowania baz danych. W dużych projektach informatycznych określenie wymagań stanowi problem, gdyż błędne lub nieprecyzyjne ich określenie może mieć negatywne wpływ
na realizacje projektu. Wykorzystując możliwości UML możemy dokładnie określić funkcjonalność, usprawnić komunikację w zespołach projektowych oraz czuwać nad ujednoliceniem specyfikacji pomysłów. Dzięki rozbudowanym profilom UML oraz multiprespektywiczności, język ten jest przydatny w projektowaniu różnych dziedzin problemowych, również baz danych.
Integralną częścią systemów informatycznych jest ich baza danych, która wywiera
ogromny wpływ na działanie, wydajność oraz przyszłą modyfikację całego systemu.
Skonstruowanie optymalnej bazy danych jest trudnym zadaniem, z uwagi na wciąż rosnące
wymagania oraz odpowiedzialność stawiane twórcom oprogramowania.
Wrycza S., Marcinkowski B., Wyrzykowski K., Język UML 2.0 w modelowaniu systemów
informatycznych, HELION 2005
Ambler S.W.; The Elements of UML Style; Cambridge: University Press; 2003
Subieta K., Wprowadzenie do obiektowych metodyk projektowania i notacji UML, folia 67
Śmiałek M., Zrozumieć UML 2.0 Metody modelowania obiektowego, HELION 2005
Subieta K.: Słownik terminów z zakresu obiektowości. Akademicka Oficyna Wydawnicza PLJ,
Warszawa 1999
Robert J.Muller, Bazy danych – język UML w modelowaniu danych, MIKOM 2000
K.Subieta, Analiza i projektowanie systemów informatycznych, PJWSTK 2003
Ustawa z dnia 5 marca 2004 r.o zmianie ustawy o przeciwdziałaniu wprowadzaniu do obrotu
finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł
oraz o przeciwdziałaniu finansowaniu terroryzmu oraz o zmianie niektórych ustaw
26

pobierz plik referatu

Transkrypt

Podobne dokumenty

Osoby poszukujące pracy

Łódź coraz bliższa bankructwa (msm) Express

Polacy gotowi zmienić pracę

PODSTAWOWY TEST SPRAWNOŚCI FIZYCZNEJ

Książki dla studentów kierunku „geodezja i kartografia”

Hillwood Gdańsk - Hillwood Investment Properties

TEMAT CELE ZADANIA