Opracowanie - Instytut Łączności

Zakład Zaawansowanych Technik Informacyjnych (Z-6)
Wybrane aspekty budowy łańcucha
przetwarzania danych w zorientowanych
usługowo rozproszonych systemach
dostarczania informacji decyzyjnych
Praca nr 06300039
Warszawa, grudzień 2009
2
Wybrane aspekty budowy łańcucha przetwarzania danych w zorientowanych usługowo
rozproszonych systemach dostarczania informacji decyzyjnych
Praca nr 06300039
Słowa kluczowe (maksimum 5 słów): SOA, Jakość danych, Metoda Punktów Funkcyjnych,
Zarządzanie Reputacją, Sprawiedliwy Podziału Zasobów
Kierownik pracy:
mgr inż. Mariusz Pajer
Wykonawcy pracy:
mgr inż. Michał Majdan
mgr inż. Paweł Olender
inż. Agnieszka Gosk
mgr inż. Piotr Celej
Kierownik Zakładu: dr inż. Janusz Granat
© Copyright by Instytut Łączności, Warszawa 2009
3
4
Spis Treści
1
Wstęp ...............................................................................................................................7
2
Metody zapewnienia jakości w usługowych łańcuchach przetwarzania...........................7
2.1
Motywacja do budowy usługowo zorientowanych łańcuchów przetwarzania...........7
2.2
Massive Parallel Processing i Shared Nothing Architecture jako klucz do
wydajności i efektywności ....................................................................................................9
3
2.3
Service Oriented Architecture jako klucz do efektywności i elastyczności .............10
2.4
Podsumowanie .......................................................................................................14
Metoda Punktów Funkcyjnych jako narzędzie konstrukcji łańcucha przetwarzania.......14
3.1
Wstęp .....................................................................................................................14
3.2
Metoda Punktów Funkcyjnych – krótka charakterystyka ........................................14
3.2.1
Podstawowe elementy metody .......................................................................14
3.2.2
Klasyfikacje.....................................................................................................16
3.3
Charakterystyka systemów informacyjnych w kontekście pomiaru wielkości.........19
3.4
Dostosowanie Metody Punktów Funkcyjnych – propozycja ...................................20
3.5
Podsumowanie i Wnioski........................................................................................21
4
Zarządzanie Reputacją w Systemach Informacji Zarządczej o Niepewnej Jakości Źródeł
Informacji................................................................................................................................22
5
6
4.1
Wstęp .....................................................................................................................22
4.2
Operator agregacji WOWA .....................................................................................22
4.3
Model systemu zarządzania reputacją ...................................................................23
4.4
Podsumowanie .......................................................................................................26
Sprawiedliwy podział zasobów a systemy oparte o SOA ...............................................26
5.1
Wprowadzenie ........................................................................................................26
5.2
SOA w systemach wspomagania decyzji ...............................................................27
5.3
Sprawiedliwość jako warunek efektywności SOA...................................................28
5.4
Podsumowanie .......................................................................................................29
Podsumowanie ...............................................................................................................29
Bibliografia..............................................................................................................................29
Załącznik 1 .............................................................................................................................31
Załącznik 2 .............................................................................................................................41
5
6
1
Wstęp
Łańcuchy przetwarzania (ŁP) są jednym z podstawowych elementów nowoczesnych
systemów informacyjnych. W Hurtowniach Danych (HD), które są szczególnym skłądniukiem
a jednocześnie i rodzajem systemów informacyjnych, łańcuch przetwarzania jest tożsamy
z kompletnym zbiorem procesów Ekstrakcji, Transformacji i Ładowania (ang. ExtractionTransorformation-Load – ETL). W przypadku tradycyjnie zbudowanych systemów
informacyjnych, łańcuchy składają się z procedur, funkcji lub skryptów implementowanych
najczęściej w tej samej technologii lub technologiach powiązanych ze sobą poprzez
narzędzia dostawcy tzw. silnika hurtowni danych. Monolityczna budowa łańcucha
przetwarzania bywa często powodem wielu komplikacji już w trakcie projektowania
i implementacji hurtowni danych, które wiążą się najczęściej ze zbyt płytką analizą źródeł,
ograniczonym lub nie pełnym projektem koncepcyjno-funkcjonalny, heterogenicznością i nie
kompatybilnością źródeł danych, ograniczeniami w zakresie dostępnych interfejsów
wyjściowych. W dalszych etapach życia systemu informacyjnego, budowa monolityczna
powoduje często ograniczenia w zakresie wydajności lub rozwoju systemu informatycznego,
które często łączą się z podatnością na utratę jakości danych. Biorąc pod uwagę powyższe
ułomności tradycyjnych monolitycznych łańcuchów przetwarzania, autorzy niniejszej pracy
proponują konstruowanie elastycznych i rozproszonych łańcuchów przetwarzania danych
w zorientowanych usługowo rozproszonych systemach dostarczania informacji decyzyjnych,
które umożliwią przezwyciężyć ograniczenia monolitycznych łańcuchów przetwarzania.
W niniejszej pracy przedstawiono kilka nowych propozycji i metod w zakresie wybranych
aspektów budowy łańcucha przetwarzania danych w zorientowanych usługowo
rozproszonych systemach dostarczania informacji decyzyjnych, wśród których znalazły się:
problemy zapewnienia jakości, szacowanie złożoności przy użyciu metody punktów
funkcyjnych, problemy zarządzania reputacją oraz problemy sprawiedliwego podziału
zasobów.
2
2.1
Metody zapewnienia jakości w usługowych łańcuchach przetwarzania
Motywacja do budowy usługowo zorientowanych łańcuchów przetwarzania
Schemat przepływu danych w tradycyjnym systemie dostarczającym informacje decyzyjne
przedstawia Rysunek 1. Jak widać, system taki jest najczęściej oparty o monolityczną
hurtownię danych, w której stosuje się dwie podstawowe formy organizacji przetwarzania
i składowania danych:
1. łańcucha przetwarzania danych do informacji wyjściowej zapisywanej w Globalnym
Zasobie Hurtowni Danych (GZHD) – w tym przypadku procesy ETL formułują zwarty
łańcuch przetwarzania, który jako monolityczny blok przetwarza dane źródłowe
w informacje składowane w hurtowni danych i udostępniane użytkownikom, w tym
przypadku, każda z aplikacji użytkownika może najczęściej korzystać z tego samego
zestawu agregatów i wielowymiarowych kostek danych;
2. łańcucha przetwarzania do informacji operacyjnych zapisywanych w Operacyjnych
Zasobach Hurtowni Danych (OZHD) i informacji wyjściowych zapisywanych
w specjalizowanych Data Martach (DM) – w tym przypadku łańcuch procesów ETL jest
dzielony na dwa bloki, pierwszy służy do przetworzenia danych pochodzących ze źródeł
danych w operacyjne dane HD składowane w Operacyjnych Zasobach Hurtowni
Danych, drugi służy do przetworzenia informacji Operacyjnego Zasobu Hurtowni Danych
w docelowe informacje HD, zgodne z oczekiwaniami aplikacji użytkowników, w tym
przypadku, każda z aplikacji użytkownika korzystać z własnego, dedykowanego zestawu
agregatów i wielowymiarowych kostek danych.
7
Jak widać na wymienionym rysunku, w obydwu przypadkach, procesy ETL formułują zwarty
blok łańcucha przetwarzania, a jedynymi znaczącymi różnicami są: wykorzystanie OZHD,
jako dodatkowego operacyjnego repozytorium danych i specjalizacja wyjściowych struktur
danych dla potrzeb aplikacji użytkowników w drugiej ze stosowanych form.
Źródła danych
Hurtownia
Procesy ETL
Danych
Baza
danych
Baza
danych
Pliki
S
Moduły
ładowania
danych
Globalny zasób
HD
Moduły
transformacji
danych
Operacyjne
zasoby HD
Moduły
ekstrakcji
danych
Moduły
TL
OLTP
Interfejsy
użytkownika
HD
Aplikacja
OLAP 1
Aplikacja
OLAP n
Data
Mart(y)
S
Monolityczna Hurtownia Danych
Rysunek 1: Schemat przepływu danych w systemie informacyjnym
opartym o tradycyjną hurtownię danych
Tradycyjny monolityczny łańcuch przetwarzania jest nie adekwatny wobec potrzeb
odbiorców informacji decyzyjnych, którzy zgłaszają potrzeby w zakresie:
1. dodawania nowych typów źródeł danych (ŹD, ang. Data Source – DS), którymi mogą
być na przykład strumienie danych czy sieci czujników;
2. integracji danych pochodzących z wielu heterogenicznych źródeł danych, np. baz
danych, plików tekstowych i binarne, dokumentów HTML i XML, różnorodnych systemów
transakcyjnych (ang. On-line Transaction Processing – OLTP);
3. adaptacji używanych łańcuchów przetwarzania do lawinowo narastającej liczby
i różnorodności ładowanych danych, które pochodzą ze zmiennych w czasie źródeł
danych;
4. dostarczania zawsze aktualnych danych w wyjściowych strukturach GZHD lub Data
Mart, przy czym oznacza to, że użytkownicy coraz częściej chcą móc obserwować
w czasie rzeczywistym propagację zmian zachodzących w ŹD do informacji będących na
wyjściu HD;
5. możliwości otrzymywania informacji decyzyjnej w postaci konfigurowalnych analiz
i analiz wykonywanych na bieżąco na zamówienie decydenta (ang. ad-hock).
Należy tu ponadto zauważyć, że w znaczący sposób jest zauważalne wzrastanie presji na
natychmiastowe zaspokajanie wszystkich powyższych potrzeb na żądanie odbiorców
informacji oraz na udostępnienie decydentom narzędzi mogących służyć do samodzielnego
definiowania i modyfikowania analiz (zawartości aplikacji) udostępniających informacje
decyzyjne, a także uruchamiania łańcucha przetwarzania w celu odświeżenia wytworzonej
informacji lub wytworzenia nowej informacji decyzyjnej.
8
Częściowe spełnienie potrzeb 3 i 5 można uzyskuje się poprzez zwiększenie wydajności
i efektywności przetwarzania danych, przy czym samo zastosowanie bardziej wydajnego
sprzętu i oprogramowania tzw. silników przetwarzania danych jest tu nie wystarczające
i konieczne staje się wprowadzanie zmian w konstrukcji używanych łańcuchów
przetwarzania danych.
Wszelkie wprowadzanie zmian w monolitycznych łańcuchach jest pracochłonne i obarczone
ryzykiem wprowadzenia błędu, który nie zaburzając działania aktualnie modyfikowanego
ogniwa łańcucha, będzie rzutował na działanie innych ogniw, a przez to będzie trudny do
identyfikacji i usunięcia. Dodatkowe komplikacje pojawiają się w przypadku wprowadzania
nowych funkcjonalności, które poszerzają zakres obsługiwanych źródeł, zwiększają
złożoność przetwarzania I zmieniają zakres i formę informacji wyjściowych, tak jak tego
wymagają wszystkie powyższe potrzeby. Z powyższych względów konieczne staje
podzielenie łańcucha przetwarzania na mniejsze części, które staną się nie zależnymi
ogniwami, które będzie można elastycznie modyfikować, dodawać i usuwać bez wpływu na
inne ogniwa.
Podsumowując, aby móc spełnić potrzeby 1-5, konieczne jest spełnienie trzech
fundamentalnych postulatów jakościowych, które stawia się wobec nowoczesnych
łańcuchów przetwarzania w systemach dostarczania informacji decyzyjnych:
1. większa wydajność;
2. większe efektywność;
3. większa elastyczność.
2.2
Massive Parallel Processing i Shared Nothing Architecture jako klucz do wydajności
i efektywności
Jak już wcześniej wspomniano, jedną z metod zwiększania efektywności i wydajności
łańcuchów przetwarzania danych w systemach decyzyjnych jest zastosowanie bardziej
wydajnego sprzętu i oprogramowania tzw. silników przetwarzania danych. Jedną
z najbardziej obiecujących technologii stosowanych obecnie do osiągnięcia tych celów jest
Massive Parallel Processing (MPP), co tłumaczy się na język polski jako „Komputery
Masowo Równoległe”.
MPP jest terminem oznaczającym bardzo wydajną architekturę komputerową i technologię
wielostrumieniowego przetwarzania danych, zgodnie z którą pojedynczy i złożony system
komputerowy budowany jest z użyciem wielu niezależnych od siebie jednostek
obliczeniowych, które mogą być jednostkami arytmetycznymi, logicznymi lub pełnymi
procesorami, z których każdy dysponuje własną prywatną pamięcią operacyjną i przestrzenią
składowania danych, choć np. pamięć operacyjna może być również współdzielona.
Wszystkie jednostki obliczeniowe, które wchodzącą w skład pojedynczego systemu MPP,
działają równolegle i nie zależnie od siebie. Dzięki temu możliwe jest rozłożenie złożonych
i zasobochłonnych obliczeń na kilka strumieni przetwarzanych równolegle na wielu
jednostkach obliczeniowych.
W przypadku łańcuchów przetwarzania danych, zastosowanie MPP umożliwia
wprowadzenie wielu równoległych strumieni wprowadzania ustrukturalizowanych
i nieustrukturalizowanych danych, ich transformacji i ładowania w ramach jednego
wspólnego łańcucha przetwarzania, a także umożliwia stosowanie równoległych strumieni
podłańcucha przetwarzania pomiędzy OZHD i DM, które mogą mieć formę strumieni zapytań
pracujących na ustrukturalizowanych i nieustrukturalizowanych danych.
Nowoczesne silniki hurtowni danych zbudowane w oparciu o architekturę MPP są obecnie
coraz częściej implementowane w postaci wirtualnych hurtowni danych, które korzystają
9
z wirtualnych serwerów obliczeniowych osadzonych na sprzętowych rozwiązaniach typu
serwery kasetowe (ang. Blade). Serwery kasetowe są rozwiązaniem polegającym na
umieszczeniu od kilku do kilkunastu serwerów w jednej specjalizowanej obudowie, która
zapewnia im korzystanie z wysokowydajnych i zwielokrotnionych szyn wymiany danych,
komunikacji sieciowej i zasilania. Zastosowanie serwerów kasetowych, które korzystają
z procesorów kompatybilnych z x86, pozwala nie tylko na minimalizację kosztów zakupu
sprzętu, ale i na minimalizację kosztów utrzymania platformy sprzętowej, dzięki mniejszemu
zużyciu energii, mniejszym wymaganiom wobec potrzebnej powierzchni użytkowej
i mniejszej generacji ciepła. Jednak w przypadku wykorzystania MPP dla obsługi łańcuchów
przetwarzania danych, podstawowe znaczenie ma możliwość skonstruowania przy użyciu
platformy wirtualizacyjnej systemu MPP, w którym rolę jednostek obliczeniowych mogą
pełnić poszczególne serwery kasetowe albo serwery wirtualne współdzielące fizyczne
zasoby fizycznych serwerów kasetowych. Przykładem rozwiązania implementującego
wirtualną hurtownię danych w architekturze MPP w oparciu o serwery kasetowe
i wirtualizację jest rozwiązanie Kognitio WX2.
Upowszechnianie się technik wirtualizacyjnych, doprowadziło również do powstania nowych
rozwiązań hybrydowych, które połączyły cechy klasycznie rozumianej architektury MPP
z rozwiązaniami typowymi bardziej dla konkurencyjnej technologii wielostrumieniowego
przetwarzania wielkich zbiorów danych w postaci obliczeń rozproszonych (ang. distributed
computing). Przykładem takiego rozwiązania hybrydowego jest Shared Nothing Architecture
(SN), w której każdy z węzłów obliczeniowych (jednostek obliczeniowych) jest nie zależny
i samowystarczalny, przy czym węzły są zbudowane w oparciu o pojedyncze fizyczne
serwery, które z założenia mogą być rozproszone lokalizacyjnie i fizycznie połączone siecią
komputerową. Charakterystyczną cechą SN jest brak pojedynczych punktów dostępu do
łańcuchów przetwarzania oraz informacji przetwarzanych i składowanych. Jest to cecha
różniąca SN od tradycyjnych systemów obliczeń rozproszonych, w których poszczególne
węzły mają ściśle określony zakres obsługiwanych funkcjonalności i porcji informacji, w SN
każdemu z węzłów można zlecić wykonanie ten samego łańcucha obliczeniowego i uzyskać
dostęp do tej samej porcji informacji, co oznacza, że systemem wewnętrznie i niejako poza
kontrolą użytkownika dokona dystrybucji zleceń przetwarzania i odczyta rozproszone porcje
informacji. Przykładem rozwiązania będącego implementacją wirtualnego systemu MPP
w oparciu o SN jest Teradata, o której traktuje artykuł Agnieszki Gosk „Query optimization in
Teradata warehouse”, kóry stanowi Załącznik 1 do niniejszego opracowania. Innym
przykładem system zbudowanego z użyciem MPP SN jest GreenPlenum (produkt
komercyjny).
Wśród wysoko wydajnych systemów niekomercyjnych na uwagę zasługuje Apache Hadoop,
który jest systemem zmierzającym w kierunku MPP SN pod względem sposobu
przechowywania danych i organizacji przetwarzania i wyszukiwania informacji, jednak brak
w nim jeszcze mechanizmów pełnej niezależności i samo wystarczalności wszystkich
węzłow.
2.3
Service Oriented Architecture jako klucz do efektywności i elastyczności
Zastosowanie MPP i SN umożliwia konstruowanie łańcuchów przetwarzania danych, które
w swojej wydajności zbliżają się do przetwarzania w czasie rzeczywistym, o ile strumień
przetwarzanych danych ma ograniczoną pojemność, do której dopasowano skalowanie
wdrożonego silnika przetwarzania danych. Praktyka utrzymywania hurtowni danych dowodzi,
że nie w dłuższym horyzoncie czasu nie jest możliwe utrzymanie zakładanej efektywności,
a co za tym idzie wydajności przetwarzania, bez zastosowania dodatkowych rozwiązań,
które umożliwią obsługę nie przewidywalnych zmiany w pojemności wejściowych strumieni
danych, jakości danych wprowadzanych i przetwarzanych w łańcuchu przetwarzania, nawet
przy zapewnieniu nie zmienności źródeł danych, konstrukcji łańcuchów przetwarzania
i struktur informacji wyjściowych. Co więcej dynamika zmian zachodzących w źródłach
10
danych oraz wymagań wobec zawartości informacji decyzyjnych, które mają być
produkowane przez łańcuchy przetwarzania powoduje, że konieczne jest wprowadzenie
dodatkowych rozwiązań, które poprzez modularyzację łańcuchów przetwarzania zapewnią
ich elastyczność, a poprzez to wymaganą efektywności i wydajność.
Dla przykładu częstym problemem występującym w łańcuchach przetwarzania jest chwilowa
utrata jakości danych pochodzących z jednego ze źródeł, która prowadzi do uzyskania
pozbawionej jakości informacji wyjściowej. W takim przypadku konieczne jest powtórzenie
przetwarzania dla poprawionego zbioru danych źródłowych. W przypadku monolitycznych
łańcuchów przetwarzania, oznacza to powtórne wykonanie całego łańcucha, co
w znaczącym stopniu skonsumuje część mocy obliczeniowej zasobów przewidywanych do
wykonywania tego samego łańcucha dla aktualnych porcji danych źródłowych, a to może
oznaczać nawet 50-o procentowy spadek efektywności i wydajności przetwarzania danych.
Metodą pozwalającą na uniknięcie takiego spadku efektywności i wydajności przetwarzania
jest taki podział łańcucha na moduły, aby konieczne było wykonanie tylko części z modułów
łańcucha przetwarzani, które skonsumują dalece mniej zasobów niż cały łańcuch.
Przytoczony powyżej przykład wskazuje również na konieczność zapewnienia konstruowania
elastycznych modułowych łańcuchów przetwarzania, w celu uzyskania odpowiedniego
poziomu zapewnienia jakości danych, co jest możliwe jedynie w przypadku wprowadzenia
kontroli jakości na poziomie produktów poszczególnych modułów (ogniw) łańcucha
przetwarzania.
Innym częstym przykładem związanych z kwestią zapewnienia jakości przetwarzanych jest
wprowadzenie do łańcucha przetwarzania zmian związanych z dodaniem, usunięciem czy
modyfikacją źródła danych lub, co bardziej znaczące, zmian w logice przetwarzania danych
w samym łańcuchu. W takim przypadku (jak to już wcześniej wspomniano) monolityczny
łańcuch przetwarzania jest bardziej podatny na propagację utraty jakości danych będącej
konsekwencją błędów w implementacji lub niezgodności z innymi niż modyfikowany partiami
kodu.
W celu zapewnienia odpowiedniego poziomu efektywności i elastyczności, konieczne jest
zastosowanie architektury, która pozwoli na:
ϖ rozdrobnienie i modularność łańcucha przetwarzania – dzięki czemu łańcuch przestanie
być monolityczną aplikacji, a stanie się zbiorem niezależnych modułów, które pozwolą na
osiągnięcie najbardziej optymalnego rozdrobnienia procesów przetwarzania;
ϖ możliwość wielokrotnego wykorzystania każdego z modułów łańcucha przetwarzania;
ϖ możliwość nie zależnego budowania i modyfikacji poszczególnych modułów, jako
komponentów wytwarzanych przez różnych dostawców;
ϖ możliwość komponowania z dostępnych modułów dowolnej liczby różnych procesów
przetwarzania danych;
ϖ możliwość interakcji modułów pomiędzy sobą oraz pomiędzy nimi a źródłami danych
i aplikacjami interfejsu użytkownika;
ϖ zgodność modułów ze wspólnymi standardami tworzenia i interakcji niezależnych
komponentów oprogramowania;
ϖ zgodność modułów ze standardami wymiany i przepływu struktur danych i informacji
specyficznymi dla rodzaju działalności biznesowej, w której konieczne będzie
zastosowanie modułów przetwarzania;
ϖ automatyzację identyfikacji, kategoryzacji, wyszukiwania, dostarczenia, zabezpieczenia
i monitorowania udostępnionych modułów.
Wszystkie wymienione powyżej postulaty spełnia Architektura Zorientowana Usługowo (ang.
Service Oriented Architecture – SOA), która umożliwia budowę łańcucha przetwarzania
11
danych w zorientowanych usługowo rozproszonych systemach dostarczania informacji
decyzyjnych. Jest to możliwe między innymi dlatego, ze każda z usług zgodnych z SOA
może działać jako dostawca i odbiorca usług, co oznacza, że usługi-moduły łańcucha
przetwarzania zaimplementowanego w SOA są w pełni wzajemnie interaktywne. Spośród
wielu możliwych sposobów implementacji rozwiązań opartych o SOA, najbardziej efektywne,
elastyczne i coraz popularniejsze są implementacje korzystające z taskanych usług
sieciowych (ang. Web Service – WS).
W przypadku zastosowania WS do implementacji modułów łańcucha przetwarzania każdy
moduł łańcucha jest implementowany jako usługa sieciowa. Jeżeli, w formę usług sieciowych
zostaną również opakowane źródła danych i aplikacji interfejsu, to wtedy możliwa jest
budowa kompletnego Zorientowanego Usługowo Rozproszonego Systemu Dostarczania
Informacji Decyzyjnych (ZURSDID), a dzięki temu możliwe jest spełnienie wszystkich
postulatów 1-5 wymienionych w punkcie 2.1 niniejszego opracowania.
Filozofia SOA promuje wprowadzenie nowych narzędzi zapewniania jakości w zakresie
efektywnego rozdrobnienia funkcjonalności łańcucha przetwarzania danych pomiędzy
poszczególnymi modułami-usługami. Rozdrobnienie funkcjonalności musi zapewniać
bowiem jednoznaczną identyfikację zakresu i celu działania usługi oraz przeciwdziałać
nadmiernym narzutom na obsługę interfejsów usług-modułów, co może mieć miejsce przy
zbyt dużym rozdrobnieniu. Nowym użytecznym narzędziem zapewnienia jakości staje się
w tym przypadku Business Process Modeling Notation (BPMN), który pozwala na
zdefiniowanie logiki łańcucha przetwarzania zgodnie z logiką działań biznesowych, przez
odbiorców informacji decyzyjnych, ekspertów w zakresie przedmiotu analiz zawierających
informacje decyzyjne, ekspertów w zakresie zawartości źródeł danych i ekspertów
w zakresie metod stosowanych w łańcuchach przetwarzania. Dzięki BPMN można
wyodrębnić zbiory funkcjonalności, które zostaną zaimplementowane później jako usługimoduły oraz zdefiniować łańcuchy przetwarzania z nich korzystające. Dzięki możliwości
przełożenia diagramów BPMN na język Web Services Business Process Execution
Language (WS-BPEL), który specyfikuje interakcję pomiędzy usługami sieciowymi, można
bezpośrednio zamieniać zdefiniowaną logikę dziedzinową na logikę działania łańcucha
przetwarzania przy użyciu modułów-usług. W ten sposób decydenci mogą samodzielnie
definiować nowe łańcuchy przetwarzania i tworzyć nowe aplikacje informacyjne bez utraty
zapewnienia jakości wynikłej z ich braku wiedzy w zakresie działania samych modułowusług. Co więcej rozwiązania wypracowane przez ekspertów dziedzinowych w celu
zapewnienia jakości na poziomie BPMN, mogą być łatwo przenoszone na poziom interakcji
modułów-usług.
Dzięki WS SOA, moduły łańcucha przetwarzania stają się luźno powiązanymi usługami,
pomiędzy którymi nie ma żadnych bezpośrednich zależności. Konieczne jest przy tym
natomiast dostarczenie informacji niezbędnych do zapewnia interakcji pomiędzy modułami,
które muszą być “świadome” istnienia, interfejsów i możliwości usług kooperujących. Dlatego
tworzone są kontrakty usług, które opisują warunki korzystania z pracy poszczególnych
modułów i komunikacji z nimi. Kontrakt opisujący moduł-sługę może być ponadto istotnym
nowym narzędziem zapewnienia jakości w łańcuchu przetwarzania, ponieważ w ramach
zawartej w nim umowy Zapewnienia Poziomu Usługi (ang. Service Level Ageerment – SLA),
można zapisać wymagania co do jakości jego działania, wymagania warunkujące jakość
jego działania w trakcie interakcji z innymi usługami.
Kontrakty opisujące usługi są również konieczne z tego powodu, że każdy z modułów
przetwarzania jest abstrakcyjną usługą, która enkapsuluje (opakowuje, ukrywa przedświtem
zewnętrznym) swoje wewnętrzne mechanizmy działania przy użyciu zewnętrznych
interfejsów. Dzięki temu, każdy moduł-usługa uzyskuje pełną autonomię w zakresie
kontrolowania swojej wewnętrznej logiki działania. Abstrakcyjność, enakpsulacja i autonomia
usług są kolejnymi nowymi narzędziami zapewnienia jakości, ponieważ uodparniają moduł –
usługę od błędów poczynionych w pracy nad innymi modułami i chronią inne moduły od
błędów poczynionych w pracach nad aktualnym modułem. Pozwalają ponadto na
12
podniesienie jakości wdrażania ZURSDID, a szczególnie transformacji tradycyjnego systemu
dostarczania informacji decyzyjnych w ZURSDID, gdzie w pierwszym etapie wdrażania
ZURSDID, można dokonać tylko opakowywania wyodrębnionych modułów przetwarzania
w interfejsy usługowe, co pozwoli wprowadzanie zmian w logice działania poszczególnych
modułów w dowolnych kolejnych etapach i w dowolnej kolejności.
Kontrakty są ponadto niezbędne dla poprawnego działania narzędzi do odkrywania usług
dostępnych do użycia w budowanych aplikacjach. Mechanizm ten pozwala na odnalezienie
i dostęp do dobrze zdefiniowanych usług. Z tego powodu w ZURSDID konieczne jest
zapewnienie nowych narzędzi, które pozwolą na weryfikację jakości oferowanych kontraktów
i działania mechanizmu wyszukiwania.
Dzięki powyższych mechanizmom, moduły-usługi mogą być dowolnie komponowane
w usługi złożone, które składają się z grup połączonych, skoordynowanych i pozostających
w interakcji usług. Zdolność do kompozycji i ponownego wykorzystania raz utworzonych
modułów-usług jest następnym nowym narzędziem, które pozwala zapewnić wymagany
poziom jakości w trakcie tworzenia łańcucha przetwarzania lub jego złożonego elementu
o nowej funkcjonalności. Wymaga to jednak zastosowania dodatkowych nowych narzędzi
w postaci standardów specyfikujących zasady i organizację współpracy pomiędzy modułamiusługami, do czego w WS służą języki Web Services Choreography Description Language
(WS-CDL) i WS-BPEL.
Zgodnie z założeniami SOA, systemy informacyjne oparte o tę architekturę mogą korzystać
z usług-modułów, które choć mogą być dostarczane przez różnych dostawców, to powinny
być traktowane równorzędnie. Jednocześnie SOA przewiduje i promuje wprowadzanie zasad
umożliwiających wybór usług działających i pasujących w sposób najbardziej optymalny do
logiki działania aplikacji składającej się z tych usług. W przypadku ZURSDID stwarza to
możliwość wprowadzenia nowego narzędzia do oceny jakości działania modułów-usług
w łańcuchów przetwarzania danych, które pozwoli na preferowanie usług-modułów
o najwyższej jakości.
Źródła danych
Baza
danych
ZURSDID
Usługi ŹD i HD ETL
Moduł
Moduł
Moduł
Aplikacje
Interfejsu
Moduł
Moduł
Baza
danych
Usługi
UI
Globalny zasób
HD
Moduł
OLAP
Moduł
Moduł
Metadane
HD
Moduł
Moduł
Moduł
OLAP
Moduł
Pliki
A diti
Moduł
OLTP
Struktury Hurtowni
Danych
Zasób
Operacyjny
Moduł
Data
Mart(y)
Moduł
Moduł
OLTP
Moduł
Rysunek 2: Schemat przepływu danych w Zorientowanego Usługowo Rozproszonego
Systemu Dostarczania Informacji Decyzyjnych (widoczne moduły-usługi łańcucha
przetwarzania)
13
2.4
Podsumowanie
Dzięki zastosowaniu Service Oriented Architecture zaimplementowanemu przy użyciu Web
Services w połączeniu z Massive Parallel Processing lub Shared Nothing Architecture
możliwe stało się zbudowanie Zorientowanych Usługowo Rozproszonych Systemów
Dostarczania Informacji Decyzyjnych, które spełniają wymagania jakościowe względem
wydajności, efektywności i elastyczności przetwarzania. Kluczem do realizacji tych
wszystkich tych postulatów stało się przekształcenie monolitycznego łańcucha przetwarzania
w elastyczny modułowo-usługowy łańcuch przetwarzania. Rozdrobnienie i racjonalność
enkapsulowania funkcjonalności w modułach, ich autonomia, wzajemna niezależność
i zdolność do kompozycji w bardziej złożone grupy usług stały się nowymi strategicznymi
narzędziami do zapewnienia jakości w łańcuchu przetwarzania ZURSDID. Operacyjnymi
nowymi narzędziami zapewnienia jakości są Business Process Modeling Notation, Web
Services Business Process Execution Language, Web Services Choreography Description
Language I kontrakty definiujące warunki działania usług.
3
Metoda Punktów Funkcyjnych jako narzędzie konstrukcji łańcucha przetwarzania
3.1
Wstęp
Nieodłącznym elementem budowy systemów informatycznych, w tym także systemów
informacyjnych i przetwarzania danych jest szacowanie wielkości systemu. Szacowania takie
wykonuje się w różnych celach, do których należy między innymi ocena pracy wymaganej do
budowy systemu, ocena złożoności jak i ocena wydajności. W przypadku systemów
transakcyjnych, zbudowanych w celu przetwarzania operacyjnego danych oraz wykonywania
czynności związanych z obsługiwanymi obszarami, szacowanie takie jest uproszczone, gdyż
związane jest ono bezpośrednio z liczbą funkcjonalności, jakie implementuje dana aplikacja.
Znacznie większy problem jest w przypadku systemów informacyjnych, w przypadku których,
na najwyższym poziomie abstrakcji można powiedzieć, że implementowana jest jedna
funkcjonalność – dostarczanie informacji (danych, raportów itp.). Z oczywistych względów
takie przedstawienie systemu informacyjnego jest zbyt dużym uproszczeniem i nie ma
żadnego praktycznego zastosowania. W tej części pracy zaprezentowano metodę
szacowania wielkości systemów zwaną metodą Punktów Funkcyjnych (Function Points
Analysis) oraz zaproponowano modyfikacje związane z jej zastosowaniem w systemach
dostarczających informacje.
3.2
Metoda Punktów Funkcyjnych – krótka charakterystyka
Metoda Punktów Funkcyjnych została po raz pierwszy zaproponowana przez Allana
J. Albrechta z IBM w roku 1979. Pierwotnie miała na celu poprawienie możliwości
szacowania wielkości aplikacji komputerowych jaką wcześniej wykonywano poprzez
zliczanie linii kodu aplikacji. Metoda ta proponowała podejście od strony funkcjonalności
dostarczanych użytkownikom, a nie od strony programisty, co pozwalało na szacowanie
wielkości systemów niezależnie od zastosowanej technologii. W bardzo krótkim czasie
metoda okazała się przydatna do szacowania większych aplikacji i pozwalała na
wytłumaczenie zakładanej lub wyprodukowanej złożoności systemu stronie zamawiającej
czyli w większości przypadków osobom bez doświadczenia informatycznego.
3.2.1
Podstawowe elementy metody
14
3.2.1.1 Określenie granic systemu
Najważniejszym elementem szacowania wielkości systemu metodą Punktów Funkcyjnych
jest określenie granic systemu. Związane jest to z dalszymi krokami tej metody. Każdy
nowocześnie budowany system jest w jakiś sposób powiązany z innymi działającymi
w organizacji i już samo to zadanie może okazać się skomplikowane. Każdy z działających
systemów wyposażony jest także w szereg strumieni danych, poprzez które wymienia
informacje z otoczeniem (w tym wypadku interfejs użytkownika też może być traktowany jako
specyficzny strumień wymiany danych).
System Zewnętrzny 1
S
W tru
ej mi
śc eń
io
wy
System Zewnętrzny 2
System Zewnętrzny 4
eń
mi y
ru ciow
t
S jś
y
W
Strumień
Wejściowy
Opisywany System
mie
ń
We
-W
y
System Zewnętrzny 3
St
ru
m
ie
ń
W
eW
y
Str
u
Rysunek 3: Schemat systemu i otoczenia
Wyznaczenie granic opisywanego systemu jest istotne dla określenia w którym momencie
wymieniane z otoczeniem pliki (w ramach strumieni) lub zapytania przekraczają jego granice,
a gdzie są one jedynie przetwarzane wewnątrz systemu. Takie określenie przetwarzanych
danych jest konieczne, gdyż idea metody Punktów Funkcyjnych opiera się na identyfikacji
tych właśnie plików i operacji.
3.2.1.2 Elementy Szacowania
Wyróżnienie poszczególnych elementów szacowania pozwala na określenie wielkości
systemu. Jednocześnie ułatwia to badanie informacji o systemie, gdyż wyznaczony jest
konkretny cel – poszukiwanie opisu elementów. Informacje o tych elementach można
znaleźć w projekcie systemu, dokumentacji technicznej, dokumentacji przepływów danych i
innych dokumentach opisujących techniczne rozwiązania w systemie i otoczeniu.
W metodzie Punktów Funkcyjnych wyróżnione są następujące elementy szacowania
(podano wraz z krótką definicją):
1. Zewnętrzne Wejścia (External Inputs) – Jako Zewnętrzne Wejście (EI) określany jest
atomowy proces, w którym przetwarzane dane przekraczają granice systemu wchodząc
15
do jego wnętrza. Źródło tych danych nie jest w tym momencie istotne. Przy identyfikacji
wejścia jako EI należy pamiętać, że powinno mieć ono wpływ na modyfikację plików
wewnętrznych (ILF).
2. Zewnętrzne Wyjścia (Externat Outputs) – Zewnętrzne Wyjście (EO) to atomowy proces
odwrotny do EI. W EO dane wygenerowane wewnątrz systemu w ramach przetwarzania
plików ILF przekraczają jego granice w strumieniu wyjściowym.
3. Zewnętrzne Zapytania (External Inquires) – Zewnętrzne Zapytania (EQ) są procesami
systemu, które nie angażują w trakcie działania Logicznych Plików Wewnętrznych (ILF).
4. Logiczne Pliki Wewnętrzne (Internal Logical Files) – Logiczne Pliki Wewnętrzne (ILF) to
zbiory danych, powiązanych ze sobą logicznymi zależnościami i pogrupowanych pod
względem logicznym, które znajdują się (i są przetwarzane) w całości wewnątrz granic
systemu.
5. Pliki Zewnętrzne (External Interface Files) – Pliki Zewnętrzne (EIF) to zidentyfikowane
pliki logiczne wyłącznie używane przez system, a w żaden sposób nie modyfikowane.
EIF zawsze umieszczone są poza granicami systemu i modyfikowane przez inne
aplikacje.
3.2.2
Klasyfikacje
Po zidentyfikowaniu wszystkich elementów systemu konieczne jest dokonanie ich klasyfikacji
w celu oceny złożoności (czyli liczby Punktów Funkcyjnych charakteryzujących system).
Pierwszym krokiem jest ocena wielkości poszczególnych zidentyfikowanych elementów.
Oceny tej dokonuje się oddzielnie dla procesów EI, EO i EQ oraz dla plików ILF i EIF. Dla
procesów oceniana jest liczba plików modyfikowanych i takich, do których w trakcie
wykonania procesu następują odwołania – liczba ta nazywana jest FTR. Istnieją sztywne
reguły określające sposób liczenia FTR narzucone przez standard IFPUG 0.
Drugim elementem oceny wielkości procesów jest określenie liczby rekordów logicznych,
jakie w nich uczestniczą. Rekordy te nazywane są w metodzie DET. Tak jak w przypadku
FTR istnieją ścisłe reguły określające jak należy liczyć liczbę DET, dzięki którym możliwe jest
ścisłe określenie dla każdego procesu liczb DET i FTR.
Podobna klasyfikacja wykonywana jest dla plików ILF i EIF. W tym wypadku określana jest
w pierwszej kolejności liczba RET mówiąca jaka jest unikalna liczba rekordów logicznych
w ramach danego pliku. Należy zwrócić uwagę, że w tym wypadku mowa jest o logicznych
rekordach, bez odnoszenia się do fizycznej reprezentacji plików.
W drugiej kolejności, tak jak w wypadku procesów, określana jest liczba DET, która ma
podobne jak wcześniej znaczenie.
Mając określone liczby DET i FTR dla procesów oraz liczby DET i RET dla plików możliwe
jest przypisanie każdego z atomowych elementów do jednej z trzech kategorii (LOW,
AVERAGE, HIGH) określających ich wielkość (złożoność). Jednocześnie dla każdej z tych
kategorii wyspecyfikowana została liczba bazowych punktów, które jej odpowiadają dla
każdego z elementów. Liczby punktów przypisane do kategorii zebrane zostały w tabelach
złożoności (pokazanych niżej). Tabele zostały opracowane przez IFPUG na bazie statystyk
zbieranych z realizowanych projektów mierzonych metodą Punktów Funkcyjnych. W
tabelach litera oznacza przypisanie do kategorii, zaś w nawiasach podano bazową liczbę
punktów dla kategorii.
16
Tabela złożoności procesów EI
FTR\DET
1-4
5-15
16+
0-1
L(3)
L(3)
A(4)
2
L(3)
A(4)
H(6)
3+
A(4)
H(6)
H(6)
Tabela złożoności procesów EQ/EO
FTR\DET
1-5
6-16
20+
0-1
L(3/4)
L(3/4)
A(4/5)
2-3
L(3/4)
A(4/5)
H(6/7)
4+
A(4/5)
H(6/7)
H(6/7)
Tabela złożoności dla plików EIF/ILF
RET/DET
1-19
20-50
51+
1
L(5/7)
L(5/7)
A(7/10)
2-5
L(5/7)
A(7/10)
H(10/15)
6+
A(7/10)
H(10/15)
H(10/15)
Wartości z tabel zostają następnie przemnożone przez współczynniki dla każdego elementu,
w celu uzyskania liczby bazowych punktów funkcyjnych dla systemu (Total Number of
Unadjusted Function Points). Tabela ze współczynnikami wygląda następująco:
Typ elementu
Wielkość
LOW
AVERAGE
HIGH
EI
X3
X4
X6
EO
X4
X5
X7
EQ
X3
X4
X6
ILF
X7
X 10
X 15
EIF
X5
X7
X 10
SUMA PF
Razem Bazowych Punktów Funkcyjnych
Następnie ta bazowa wielkość musi zostać skorygowana o odpowiedni multiplikator
(współczynnik korekty) wynikający ze specyfiki systemu (jego przeznaczenia, planowanego
użycia, funkcji specyficznych itp.). IFPUG określa 14 kryteriów niezależnych od technologii,
które wyznaczają odpowiedni multiplikator. Dla każdego z podanych kryteriów określa się
wpływ na system w skali od 0 do 5 gdzie 0 oznacza brak wpływu na złożoność systemu,
a 5 oznacza bardzo duży wpływ:
17
L.p.
Kryterium
Opis
1.
Komunikacja
Jak wiele modułów jest potrzebnych w procesie
komunikacji i wymiany informacji w systemie?
2.
Przetwarzanie rozproszone
Jak są zrealizowane i jak
przetwarzania rozproszonego?
3.
Wydajność
Czy czas odpowiedzi systemu jest istotny dla
użytkownika końcowego?
4.
Użycie infrastruktury
Jak bardzo obciążona jest infrastruktura fizyczna
(hardware) na której działa system?
5.
Częstotliwość transakcji
Jak często wykonywane są transakcje?
6.
Wprowadzanie danych
Jak duża część informacji wprowadzana jest On-Line?
7.
Efektywność
Jak ważna
interfejsu?
8.
Zmiany danych On-Line
Jak wiele plików ILF jest zmienianych On-Line?
9.
Złożone operacje
Czy system przetwarza dane w złożonych
algorytmach logicznych/matematycznych?
10.
Wielokrotne Użycie
Czy system został zaprojektowany do użycia przez
jednego czy wielu użytkowników? Jak wielu?
11.
Łatwość instalacji
Jak skomplikowana jest instalacja i konwersja na inne
platformy?
12.
Łatwość obsługi
Jak skomplikowane i zautomatyzowane są procedury
zatrzymania/uruchomienia, backupu, odzyskania itp.
dla systemu?
13.
Liczba instalacji
Czy system był projektowany dla wielu organizacji lub
środowisk?
14.
Otwartość na zmiany
Czy system był projektowany pod kątem łatwiejszego
(automatycznego) wprowadzania zmian?
dla
użytkownika
wiele
jest
jest
funkcji
efektywność
Współczynnik korekty wyznaczany jest na podstawie wzoru (IFPUG):
14
V = 0.65 + 0.01 × ∑ c i
(1)
i =1
Gdzie ci jest wartością określoną dla kryterium i z wcześniejszej tabeli. Ostateczny wynik
określający liczbę Punktów Funkcyjnych (czyli złożoność systemu) otrzymujemy przez
przemnożenie bazowej liczby punktów funkcyjnych i współczynnika korekty.
Wykonana w ten sposób modyfikacja bazowej liczby Punktów Funkcyjnych może sięgać +/35%.
Dopiero zmodyfikowana liczba Punktów Funkcyjnych określa złożoność systemu. Na
podstawie tej liczby wyznaczyć można inne charakterystyki.
Dla przykładu pomnożenie liczby punktów funkcyjnych dla systemu przez produktywność
w danej technologii wyrażoną stosunkiem liczby FP na osobodzień pracy, pozwala na
określenie pracochłonności wykonania systemu.
18
3.3
Charakterystyka systemów informacyjnych w kontekście pomiaru wielkości
Systemy informacyjne, a w szczególności systemy rozproszone są bardzo trudne do
oszacowania jeśli chodzi o ich wielkość. Problemem w tym momencie staje się już na
wstępie określenie granic systemu. Jest to związane z ich budową i tym, że zazwyczaj
osadzone są one bardzo mocno i bardzo głęboko w środowisku informatycznym organizacji.
Typowa struktura systemu przetwarzania informacji została pokazana na rysunku
Rysunek 4: Schemat systemu dostarczania informacji
System dostarczania informacji może być rozpatrywany na kilku poziomach. Na każdym
z nich można mówić o innych funkcjonalnościach. Tym bardziej, że często są to elementy
realizowane oddzielnie i obwarowane innymi wymaganiami. Przy dużej wielkości systemach,
a takie często występują w przypadku systemów informacyjnych, dodatkowym elementem
jest fakt iż poszczególne części mogą być wykonywane przez odseparowane zespoły,
a zatem powinny być oceniane oddzielnie.
Z punktu widzenia użytkowników systemów (taki punkt widzenia narzuca metoda Punktów
Funkcyjnych) przedstawiony na schemacie system informacyjny ma funkcjonalności
związane z dostarczanymi na końcu procesu raportami. Jednakże zasady budowy systemów
informacyjnych pokazują, że większa część systemu znajduje się w jego wnętrzu, czyli
elementach związanych z ładowaniem danych z systemów źródłowych do Hurtowni Danych
oraz przetwarzaniem danych zgromadzonych w HD do tematycznych składnic danych
analitycznych. Te elementy systemu mogą stanowić nawet 80% jego złożoności.
W procesie ładowania danych wykonywane są dwa rodzaje operacji:
ϖ Ładowanie (Extracting) – ekstrakcja danych z systemów źródłowych i ładowanie ich albo
bezpośrednio (bez żadnych modyfikacji) do docelowej Hurtowni Danych albo do
pośrednich baz tymczasowych
ϖ Czyszczenie i wstępna obróbka (Data Preparation) – czyszczenie danych pochodzących
z różnych systemów źródłowych, wstępna klasyfikacja i zastosowanie prostych reguł,
uspójnienie danych pochodzących z różnych źródeł (np. uspójnienie definicji).
Te operacje stanowią pewien element złożoności systemu informacyjnego, który z definicji
nie jest widoczny dla użytkownika końcowego. Dodatkową trudność stanowi sytuacja,
w której system informacyjny gromadzi dane z całej organizacji, co powoduje multiplikowanie
źródeł danych i znaczne powiększenie warstwy związanej z ładowaniem i czyszczeniem
danych.
19
Hurtownia Danych, jako baza specyficzna i dedykowana do konkretnych zastosowań, jest
dość ustandaryzowana. Jednakże w każdym osobnym przypadku wymaga pracy
analitycznej związanej z jej zaprojektowaniem.
Element najważniejszy z punktu widzenia poprawnego działania systemu informacyjnego
(czyli systemu z założenia udostępniającego wiarygodną informację o organizacji) to
warstwa przetwarzania danych. Procesy występujące w tej warstwie mają za zadanie przy
pomocy wysoce wyspecjalizowanych algorytmów przetworzyć wstępnie zagregowane dane
znajdujące się w hurtowni danych na pogrupowane tematycznie bazy analityczne. Procesy
przetwarzania danych implementują algorytmy data mining takie jak segmentacje, algorytmy
predykcyjne, symulacje i inne złożone logicznie i matematycznie zadania. Rozpatrywanie
złożoności systemu stosującego takie algorytmy z punktu widzenia dostarczanych
funkcjonalności może prowadzić do błędu jakim byłoby znaczne zaniżenie takiej oceny
Ostatnią warstwą każdego systemu informacyjnego jest wygenerowanie i dostarczenie
użytkownikowi końcowemu raportów czy to w formie statycznej (jak strony WWW,
wiadomości mail czy raporty papierowe) czy w dynamicznej (jak zintegrowane karty
wyników, raporty OLAP 1 , dynamiczne portale informacyjne). Na tym etapie złożoność
systemu związana jest z wygenerowaniem odpowiedniej formy raportu.
3.4
Dostosowanie Metody Punktów Funkcyjnych – propozycja
Warstwa 1: Hurtownia Danych
Warstwa 2: Przetwarzanie Analityczne
Warstwa 3:
Raportowanie
Raporty
Przetwarzanie
System źródłowy
Składnica Danych
Analitycznych
Ładowanie danych
Przetwarzanie
Raporty
System źródłowy
Hurtownia Danych
Składnica Danych
Analitycznych
System źródłowy
Przetwarzanie
Raporty
Składnica Danych
Analitycznych
Rysunek 5: Schemat systemu dostarczania informacji w podziale na najważniejsze warstwy
Aby poprawnie szacować złożoność systemów informacyjnych metodą Punktów
Funkcyjnych konieczna jest jej modyfikacja. Nie jest możliwe rozpatrywanie systemu jako
całości. Tak jak opisano wcześniej, po pierwsze system informacyjny, mimo niekiedy dużego
zaawansowania technologicznego, dostarcza użytkownikowi końcowemu bardzo prostą
funkcjonalność (raport). Po drugie system informacyjny zazwyczaj składa się z kilku warstw,
z których każda jest złożonym elementem i każda wspiera końcową funkcjonalność jaką jest
dostarczenie informacji.
1
OLAP – OnLine Analitycal Processing – nazwa raportów wielowymiarowych umożliwiających
użytkownikowi końcowemu analizę danych w wielu przecięciach.
20
Proponuje się zatem, aby dokonać modyfikacji metody tak, aby odzwierciedlała ona
rzeczywistą złożoność systemów tej klasy. Naturalne wydaje się skorzystanie ze specyfiki
budowy systemu informacyjnego, jaką jest jego wielowarstwowość. System w podziale na
warstwy przestawiono na rysunku Rysunek 5.
W większości przypadków taki naturalny podział można dość łatwo wykonać. Widać także
wyraźnie, że w momencie dokonania tego podziału w systemie wyróżnione zostały trzy
podsystemy. Każdy z nich można w tym momencie traktować oddzielnie i opisywać
oddzielnie. Dla każdego można także oddzielnie wyznaczyć wszystkie elementy określane
w metodzie Punktów Funkcyjnych. Proponuje się zastosowanie następujących reguł:
ϖ Podsystem 1 – Hurtownia danych
¬ Wyznaczamy EIF dla każdego logicznego pliku źródłowego na wejściu podsystemu.
Ważne jest aby rozpoznać pliki logiczne w oderwaniu od ich fizycznej implementacji.
¬ Wyznaczamy EI dla każdej aplikacji ładowania danych do hurtowni danych.
¬ Wyznaczamy ILF dla każdego pliku logicznego przechowywanego w hurtowni
danych.
¬ Nie wyznaczamy żadnych elementów metody dla plików wstępnie czyszczonych
i przetwarzanych w bazach pośrednich.
¬ Nie wyznaczamy żadnych elementów dla plików i/lub strumieni wyjściowych
z podsystemu.
ϖ Podsystem 2 – Przetwarzanie analityczne
¬ Wyznaczamy EI dla każdego procesu przetwarzania danych analitycznych
¬ Wyznaczamy ILF lub EIF dla każdego logicznego pliku w Składnicy Danych
Analitycznych. ILF wyznaczany jest dla plików, które nie są używane w dalszym
przetwarzaniu (np. słowniki danych). EIF wyznaczany jest dla tabel faktów na
podstawie których generowane są raporty.
¬ Wyznaczamy EO dla każdego procesu eksportującego dane do raportowania.
ϖ Podsystem 3 – Raportowanie
¬ Wyznaczamy EIF dla każdego raportu, kostki wielowymiarowej i strony WWW.
Dla każdej z podanych tutaj zasad stosowane są standardowe techniki określania wielkości
zaproponowane w metodzie Punktów Funkcyjnych. Pozwala to na określenie złożoności
każdego z elementów systemu informacyjnego i nie zgubienie wewnętrznych procesów jakie
w tym systemie zachodzą.
Taki podział systemu informacyjnego i rozpatrywanie każdego z podsystemów oddzielnie ma
też dodatkową zaletę polegającą na tym, że możliwe jest wydzielenie i szacowanie
oddzielnie jego elementów. Sprzyja to np. podziałowi pracy pomiędzy różne jednostki
w organizacji.
3.5
Podsumowanie i Wnioski
W przypadku systemów dostarczania informacji konieczne wydaje się zastosowanie jakiejś
metody szacowania złożoności. Jest to związane z koniecznością późniejszego szacowania
pracochłonności, wydajności i innych parametrów zależnych od wielkości systemu. Istotne
jest także, aby szacowanie wykonane zostało w oderwaniu od użytej technologii czy
fizycznej implementacji systemu. Metoda Punktów Funkcyjnych pozwala na wykonanie
takiego szacowania jednak w swojej oryginalnej wersji nie może zostać zastosowana.
21
Wynika to z faktu, że w założeniu skupia się ona na funkcjonalnościach dostarczanych
użytkownikom końcowym. W przypadku systemów informacyjnych szacowanie na tej
podstawie wiedzie do zdecydowanie zaniżonych wartości gdyż większość złożoności
systemu jest ukryta przed wzrokiem użytkownika końcowego. Zaproponowano zatem pewną
modyfikację sposobu stosowania tej metody, która pozwala na uwzględnienie złożoności
wewnętrznych modułów systemu informacyjnego. Dzięki temu daje się oszacować jego
rzeczywistą wielkość a co za tym idzie określić np. pracochłonność wykonania, koszt
wykonania i inne parametry zależne.
4
4.1
Zarządzanie Reputacją w Systemach Informacji Zarządczej o Niepewnej Jakości
Źródeł Informacji
Wstęp
W systemach otwartych w których nadzór nad poprawną pracą wszystkich elementów
systemu nie jest sprawowany przez centralną jednostkę występuje naturalna tendencja do
zróżnicowania jakości świadczonych usług. Zgodnie z teorią przedstawioną przez G Akerloff
(1976) w jego znanym artykule pt. ”The Market for ‘Lemons’” [17], w takim przypadku
komponenty świadczące usługi o dobrej jakości mogą być wyparte przez komponenty
świadczące usługi złej jakości w sytuacji gdzie ocena usługi nie może być wykonana a-priori
przez jej odbiorcę. Sposobem na wymuszenie dobrej jakości usług świadczonych przez
poszczególne niezależne komponenty systemu informacyjnego jest wprowadzenie
zarządzania reputacją w takim środowisku.
Reputacja jest to całokształt ocen komunikowanych w danym środowisku na temat danego
komponentu tego środowiska - uczestnika systemu. Jako element reputacji można traktować
rekomendację źródła ze strony odbiorcy danego towaru dla potencjalnych innych odbiorców
tego samego towaru. Reputacja jest to w takiej sytuacji zbiór rekomendacji komunikowany
przez członków wybranego środowiska. Jeżeli uczestników systemu reputacyjnego
potraktujemy jako zbiór to reputacja wybranego źródła może różnić się w poszczególnych
podzbiorach. Tym samym odbiorca-agent który zmienia swoje lokalne środowisko – podzbiór
uczestników z którymi się komunikuje może obserwować inna reputacje dotyczącą tego
samego źródła.
Na podstawie reputacji i własnych doświadczeń związanych z danym źródłem informacji
odbiorca określa miarę nazywaną zaufaniem wobec tego źródła.
Zaufanie jest to
subiektywne prawdopodobieństwo że dany Partner w tym przypadku – źródło informacji
zachowa się tak jak to deklaruje sytuacji gdy jego prawdomówność nie może być
stwierdzona a priori. W powyższe sposób zaufanie definiuje D. Gambetta [18]. Zaufanie jest
wyznaczane jako agregacja reputacji.
W niniejszym rozdziale przedstawiony jest model zarządzania zaufaniem i reputacją
z wykorzystaniem operatora WOWA jako metody agregacji informacji.
4.2
Operator agregacji WOWA
Operator agregacji ważonej porządkowej średniej ważonej (ang. Weighted Ordered
Weighted Average) w skrócie WOWA został po raz pierwszy zaproponowany w roku 1997
przez V. Torra [19], jako uogólnienie operatora porządkowej średniej ważonej (ang Ordered
Weighted Average) OWA zaproponowanego przez Yagera [20].
Konstrukcja operatora zasadza się na definicji dwóch wektorów precyzujących preferencje
decydenta.
22
ϖ Wektor wag preferencyjnych
agregowanych wartości.
(wi)
–
precyzuje
preferencje
odnośnie
wielkości
ϖ Wektor wag istotnościowych(pi) – precyzuje preferencje co do poszczególnych kryteriów
których wartości są agregowane.
(2)
oznacza operator porządkowania wartości
od największej do
Gdzie operator
najmniejszej. Wektor wag
jest konstruowany według następującej zasady:
(3)
interpoluje punkty (
wraz z punktem (0,0). Przy czym
Gdzie funkcja
o ile to możliwe funkcja interpolująca powinna przyjmować postać funkcji odcinkami liniowej.
Operator WOWA jest uogólnieniem zarówno operatora średniej ważonej jak i operatora
porządkowej średniej ważonej. Przypadku gdy wagi preferencyjne są równe operator działa
jak średnia ważona w przypadku gdy równe są wagi wektora wag istotnościowych operator
zachowuje się tak jak OWA. Wartość wyniku agregacji WOWA jest zawsze położona
pomiędzy wyżej wymienionymi przypadkami brzegowymi.
Zastosowanie operatora WOWA zaproponowane w pracy E.Damiani i innych [21]
przedstawia możliwe zastosowanie operatora WOWA w zarządzaniu reputacją. Kolejny
punkt niniejszego opracowania przedstawia przykładowe zastosowanie WOWA bazujące na
tej koncepcji i odnoszące się do przypadku jednokryterialnego.
4.3
Model systemu zarządzania reputacją
Problem zarządzania reputacją w przypadku systemu informatycznego zbierającego
i przetwarzającego dane może zostać przedstawiona w następujący sposób. System ma za
zadanie zbierać dane ze swojego otoczenia biznesowego, przetwarzać je, agregować
doprowadzać do spójnej postaci. Następnie dane te są udostępniane odbiorcom.
Usługa – źródło danych spełniające na rzecz systemu funkcje na podstawie jego żądań.
Funkcje te mogą dotyczyć dostarczania danych opisujących konkretne aspekty
rzeczywistości biznesowej którą obsługuje element systemu operacyjnego przedsiębiorstwa.
Na przykład dane na temat aktualnej na daną chwilę bazy klientów kluczowych.
System – system informacyjny gromadzący, przetwarzający i udostępniający informację na
temat przedsiębiorstwa w postaci zagregowanej i ujednoliconej zgodnie z wymaganiami
informacyjnymi na poziomie zarządczym.
Klient – aplikacja pobierająca i wyświetlająca informacje udostępniane przez system.
Usługi udostępniają informację na rzecz szeregu systemów. Jakość tej informacji jest
oceniana przez system na podstawie liczby reklamacji jakości danych otrzymywanych od
odbiorców systemu za pośrednictwem aplikacji klienckich. System publikuje swoją ocenę
reputacji usługi w sieci łączącej systemy. Systemy określają poziomy zaufania do
poszczególnych usług dostarczających właściwe im typy informacji na podstawie
23
rekomendacji opublikowanych przez inne systemy oraz własnego doświadczenia
z kontaktów z daną usługą. Na podstawie dokonanej oceny wybierany jest najbardziej
zaufany dostawca informacji. Wzrost jakości danych końcowych udostępnianych odbiorcom
biznesowym powodowany jest przez eliminację z systemu źródeł najmniej zaufanych.
Rysunek 6: Model sytemu informacyjnego z reputacją
W proponowanym modelu sytuacja decyzyjna jest zdefiniowana w następujący sposób.
W sieci reputacyjnej łączącej systemy opublikowane są rekomendacje odnoście każdej
z usług z których zasilają się uczestnicy sieci. Rekomendacje wyrażone są w postaci
znormalizowanych liczb z zakresu <0,1>.
Przyjmujemy, że na podstawie oddzielnego modułu oceny wiarygodności każdy system jest
w stanie pozyskać informację o wiarygodności każdego z systemów partnerskich w ramach
sieci reputacyjnej. Na tej podstawie każdej z rekomendacji przydzielana jest waga (pi)
określająca poziom wiarygodności danej rekomendacji. Wektor tych wag tworzy wektor wag
istotnościowych (pi) przypisanych do każdego systemu.
Każdy z systemów może zostać wyposażony w model preferencji określający stopień
akceptacji niepewności. System krytyczny którego zasilenie musi spełniać wysokie standardy
jeżeli chodzi o wiarygodności danych będzie wymagał by usługa która ma być dopuszczona
jako źródło danych była powszechnie uznawana za godną zaufania. Wadą takiego podejścia
do problemu jest możliwość utraty źródła informacji gdy przestanie ono spełniać wysokie
wymagania co do reputacji. Tym samym system nie będzie w stanie dostarczać raportów
użytkownikom.
System o większej tolerancji niepewności co do jakości danych może zostać wyposażony
w model preferencji dopuszczający usługę gdy w jej reputacji pojawi się choć jedna wysoka
ocena przy pewnej dopuszczalnej wysokości pozostałych ocen. System taki zapewni sobie
większą dostępność, niestety dopuszczając spadek jakości danych w pewnych
okolicznościach.
24
Wyżej opisane dwa modele preferencji odpowiadają różnym kształtom funkcji interpolującej
definiowanej przez wektor wag preferencyjnych w modelu agregacji WOWA. Funkcja
wklęsła odpowiada podejściu o większej tolerancji niepewności.
Rysunek 7: Funkcja W*
odpowiadająca zwiększonej podatności na niepewność źródeł danych
W przypadku takiego kształtu funkcji interpolującej wagi wektora wag preferencyjnych
przypisane są w ten sposób, że rekomendacjom o wysokiej wartości przypisywane są
najwyższe wagi podczas gdy niskie wartości miary reputacji maja przypisane wagi relatywnie
mniejsze.
Rysunek 8: Funkcja W*
odpowiadająca zmniejszonej podatności na niepewność źródeł danych
25
Funkcja wypukła odpowiada mniejszej podatności na niepewność źródeł danych co można
związać z wysokimi wymaganiami dotyczącymi stabilnej jakości danych w stosunku do
systemów krytycznych. W takiej sytuacji wysokie wagi przypisywane są małym wartościom
ocen w wektorze agregowanym przy stosunkowo mniejszych waga właściwych dla miar
reputacji o wysokich wartościach.
Przy takich modelach preferencji wbudowanych w system widać że aby osiągnąć tę samą
wartość zagregowanej miary zaufania system o ostrożnym stosunku do źródeł danych
potrzebuje wyższych rekomendacji od swoich partnerów niż system o większej tolerancji dla
niepewnych danych.
4.4
Podsumowanie
Problematyka zarządzania zaufaniem i reputacją wywodzi się z obszaru otartych systemów
niezależnych „samolubnych” agentów takich jak sieci „peer to peer”, czy też sieci handlu
internetowego. Na współczesne systemy informacji zarządczej można spojrzeć jako na
systemy wymiany informacji pomiędzy niepewnymi źródłami danych a pewnymi platformami
raportowymi. Podstawową bolączką w długookresowym utrzymaniu systemu informacji
zarządczej jest jego wrażliwość na błędy w danych źródłowych. Ocena jakości danych jest
zwykle wykonywana dokładnie na etapie konstrukcji takiego systemu. Późniejsze utrzymanie
systemu zwykle prędzej czy później napotyka na problem spadku jakości danych w systemie
na skutek zmian w jednym lub więcej źródeł danych. Błędy wynikają zwykle z faktu że
organizacja nie przywiązuje właściwej wagi do przystosowania systemu informacji
zarządczej do zmieniającego się formatu i znaczenia produktów oferowanych przez usługę
źródłową. W przypadku dużej liczby źródeł danych i ich intensywnego rozwoju zapanowanie
w zorganizowany sposób nad zmieniającym się otoczeniem systemu informacyjnego
nastręcza szeregu problemów i zwykle w istotny sposób zmniejsza elastyczność
i dostępność systemu dla jego odbiorców oraz powoduje wzrost kosztów jego posiadania.
Proponowane tutaj alternatywne podejście do wykrywania „błędów” w źródłach danych
pozwala na wykrywanie i eliminacje źródeł danych, które na skutek różnych czynników
zmieniają znaczenie oferowanych przez siebie danych w nieuporządkowany sposób.
Zastosowanie tego podejścia jest właściwe dla organizacji dysponujących poważną liczbą
systemów źródłowych – operacyjnych przedsiębiorstwa oraz zdolnych do wytworzenia
warstwy pośredniej systemów informacji zarządczej (systemów analitycznych i raportowych)
rozwijanych na bazie źródeł i połączonych wspólną siecią reputacyjną.
5
5.1
Sprawiedliwy podział zasobów a systemy oparte o SOA
Wprowadzenie
Architektura zorientowana na usługi (ang. SOA – service-oriented architecture) jest obecnie
bardzo popularnym tematem w świecie IT. Zainteresowanie to wynika z korzyści, które
można uzyskać stosując tę architekturę do budowy systemów informatycznych w różnych
obszarach gospodarki. Główne zalety to zwiększenie efektywności, zmniejszenie kosztów
oraz większa elastyczności w utrzymaniu i rozwoju tego typu systemów. Dotyczy to
w szczególności systemów do wspomagania decyzji. Jak wiadomo są one wykorzystywane
w różnorodnych przedsiębiorstwach i organizacjach, które często przeznaczają na ich
budowę i obsługę duże środki finansowe, przez co są zainteresowane wykorzystaniem ich
w możliwie najefektywniejszy sposób. W ramach obecnej pracy statutowej, kontynuując
tematykę badań i wykorzystując doświadczenia zdobyte podczas realizacji pracy
zeszłorocznej, powstał artykuł prezentujący projekt systemu do wspomagania decyzji,
wykorzystujący podejście zorientowane na usługi. Artykuł został zgłoszony do redakcji JTIT.
26
Jak to zazwyczaj bywa nowe idee oprócz zalet stwarzają różnego rodzaju trudności.
Również SOA stawia pewne wyzwania, które wymagają uwagi projektantów i użytkowników
tych systemów. Poszczególne aplikacje składające się na całość rozwiązania SOA są
zazwyczaj rozproszone i komunikują się pomiędzy sobą poprzez sieć. Wymiana informacji
między nimi może być intensywna. Z tego względu sieć i jej zasoby stają się kluczową
kwestią decydującą o możliwości, szybkości i efektywności działania systemów
zorientowanych na usługi [23]. Ponieważ zasoby są wykorzystywane przez wiele różnych
usług potrzebny jest odpowiedni mechanizm ich współdzielenia, zapewniający
sprawiedliwość obsługi. W ramach pracy przyjrzano się aspektowi sprawiedliwego podziału
zasobów.
5.2
SOA w systemach wspomagania decyzji
W artykule z Załącznika 2 przedstawiony został projekt systemu do wspomagania analizy
rozwoju szerokopasmowych sieci dostępowych. Wykorzystuje on model technoekonomiczny i programowanie stochastyczne do zaplanowania budowy sieci FTTH w danym
regionie. Można w nim wyróżnić 3 podstawowe moduły (usługi), którym przypisane są różne
zadania:
ϖ obliczenie najkorzystniejszego stopnia agregacji w węzłach sieci;
ϖ wybór podobszarów do podłączenia, maksymalizujących wartość bieżącą netto (ang.
NPV – net present value);
ϖ wyznaczenie dodatkowych wskaźników ekonomicznych przedsięwzięcia.
Każda z tych usług rozwiązuje zadany podproblem i na podstawie danych wejściowych
oblicza wyjście, które może być dalej wykorzystywane jako wejście dla innej usługi. Dzięki
temu, w przypadku chęci modyfikacji lub rozbudowy systemu, można się ograniczyć tylko do
wybranego podzbioru usług. Zachowanie takiego samego sposobu komunikacji
z otoczeniem i pozostałymi częściami systemu gwarantuje działanie całości po
wprowadzeniu zmian w interesującym obszarze. Zmiany w prezentowanym modelu można,
więc wprowadzać stopniowo. Przykładowe modyfikacje to:
ϖ zmiana modelu wymiarowania sieci, topologii etc.;
ϖ zmiana metody budowy drzewa scenariuszy;
ϖ opracowanie koncepcji dekompozycji problemu w części optymalizacyjnej;
ϖ dodanie nowych wskaźników ekonomicznych przedsięwzięcia.
Można również rozpatrzyć wydzielenie nowej usługi dedykowanej tylko do konstrukcji drzewa
scenariuszy. Jest to oczywiście przykład małego systemu z małą liczbą modułów. Z tego
powodu może wydawać się, że zyski z takiego podejścia są niewielkie. Należy jednak wziąć
pod uwagę, że systemy komercyjne wykorzystywane na rynku są zazwyczaj znacznie
większe z dowolnie dużą liczbą usług. Ogólna koncepcja jest jednak taka sama. W takim
przypadku ograniczenie skali zmian przekłada się na realne obniżenie kosztów, jak również
skrócenie czasu ich realizacji i wdrożenia. Jest to szczególnie ważne przy dzisiejszych
dynamicznych zmianach na rynku i silnej konkurencji, kiedy zdolność i szybkość
przystosowania się do aktualnej sytuacji stanowi być albo nie być dla danego
przedsiębiorstwa. Czasami, ze względu na wielkość i złożoność systemów, jest to jedyny
sposób na ich przebudowanie niedezorganizujący funkcjonowania bazujących na nich
instytucji. Tutaj ważny jest również aspekt osób utrzymujących tego typu systemy
i możliwości ich zastąpienia.
27
5.3
Sprawiedliwość jako warunek efektywności SOA
Poszczególne usługi i aplikacje mają różne zapotrzebowanie na współdzielone zasoby sieci.
Z tego względu musi istnieć mechanizm, który zapewni odpowiedni podział tych zasobów.
Ma on na celu utrzymanie pewnego poziomu usług, który może np. wynikać z podpisanej
umowy (ang. SLA – service level agreement). Zarządca zasobów powinien rozdysponować
dostępne zasoby efektywnie i sprawiedliwie. Pojęcie sprawiedliwości wywołuje burzliwe
dyskusje od wielu wieków, których treści wykraczają daleko poza rozważania naukowe.
Panuje jednak dosyć powszechna zgoda na zaproponowaną przez Ch. Perelmana opinię,
gdzie sprawiedliwość określa się „jako zasadę działania, w myśl której osoby należące do tej
samej kategorii istotnej powinny być traktowane jednakowo” [24]. Oczywiście główny
problem dotyczy określenia kategorii istotnej, jednak nawet to nie jest wystarczające do
oceny i porównywania poszczególnych podziałów. Ponieważ jednak tego typu rozważania
nabierają już charakteru filozoficznego w praktycznych zastosowaniach przyjmuje się, że
kryteria sprawiedliwości zostały przyjęte i nie podlegają dyskusji. W przypadku
współdzielenia zasobów sieci można powiedzieć w uproszczeniu, że sprawiedliwy podział to
taki, w którym każda aplikacja ma szansę dostać pewną część dobra. Ponieważ
podstawowym zasobem sieci jest jej przepustowość, jej podział jest często rozważany
w różnych opracowaniach. Zasób ten ma również pewne własności pożądane ze względu na
problematykę podziału:
ϖ jednorodność – brak różnic jakościowych pomiędzy częściami dobra; występują jedynie
różnice ilościowe pomiędzy podziałami;
ϖ doskonała podzielność – brak ograniczeń realizowalności w partycjonowaniu dobra.
Formułując problem zakłada się istnienie łącza o określonej przepustowości,
współdzielonego przez wiele aplikacji, które zgłaszają potrzeby na przepływy o różnej
wielkości. Zarządca zasobów na podstawie określonej rangi usług przydziela pasmo za
pomocą zdefiniowanych algorytmów. Algorytmy te są zazwyczaj zaimplementowane w
routerach i przełącznikach, które przekierowują ruch na odpowiednie łącza.
Formalnie problem może być przedstawiony jak poniżej [25]. Zakłada się, że dostępna ilość
pasma wynosi Z . O dostęp do tego pasma konkuruje ze sobą n aplikacji, których
zapotrzebowanie wynosi D = [d1 , d 2 , K , d n ] . Zakładając, że każda aplikacja ma takie samo
prawo do zasobu, należy wyznaczyć pewien przydział zasobu A = [a1 , a 2 , K , a n ] . Przydział
dopuszczalny powinien spełniać dwa warunki:
ϖ każdy uczestnik podziału otrzymuje przydział większy lub równy zero;
∀a
i
≥0
i
ϖ sumaryczny przydział jest mniejszy lub równy wielkości dostępnego dobra;
∑a
i
i
;
≤Z
.
Jednym z mechanizmów sprawiedliwego podziału jest kryterium maksyminowe.
Dopuszczalny przydział jest określano jako sprawiedliwy według tego kryterium, jeśli
zwiększenie części przyznanego dobra dla jednego uczestnika i , może być możliwe tylko
przy zmniejszeniu części przyznanego dobra dla innego uczestnika j , dla którego
a j ≤ ai [26].
Zgodnie z tym kryterium zabronione jest zmniejszanie małych (mniejszych)
udziałów na korzyść większych. Można to również rozumieć jako pewnego rodzaju
priorytetyzację mniejszych udziałów.
Innym przykładem metody podziału jest mechanizm sprawiedliwości proporcjonalnej. W tym
przypadku funkcją celu jest maksymalizacja funkcji użyteczności przydziału [27].
Przykładową funkcją użyteczności jest funkcja logarytmiczna. Jej interpretacją jest
28
satysfakcja uczestnika względem wielkości otrzymanego dobra. Wadą tego podejścia jest
m.in. konieczność przekazania informacji o funkcji użyteczności do zarządcy zasobów.
Oprócz wspomnianych wyżej przykładów istnieją również inne metody podziałów, jak
chociażby podejścia wykorzystujące gry o zasoby. Poszczególne mechanizmy zapewniające
sprawiedliwy podział mają określone wady i zalety przez co działają inaczej dla różnych
warunków podziałów. Jednak już proste podejścia mogą znacząco wpłynąć na efektywność
łańcucha przetwarzania w architekturze SOA i zapewnić określony poziom i jakość usług.
5.4
Podsumowanie
W ramach pracy badano możliwości oraz ewentualne korzyści i trudności wykorzystania
architektury SOA w systemach do wspomagania decyzji. Przedstawiono przykład projektu
systemu z wykorzystaniem podejścia zorientowanego na usługi, zwracając uwagę na
korzyści z tego płynące. W dalszej części rozpatrzono wymogi stawiane przez architekturę
SOA względem zasobów sieci i rozważono możliwość wykorzystania mechanizmu
sprawiedliwego podziału zasobów w celu zapewnienia efektywności współdziałania
poszczególnych usług, a w konsekwencji pracy całego systemu. Potrzebne są dalsze analizy
różnych zasad sprawiedliwego podziału zasobów oraz ich teoretyczne i empiryczne
porównanie, mające na celu określenie głównych klas algorytmów w odniesieniu do
zróżnicowanych warunków współdzielenia zasobów, a w dalszej części podjęcie próby
opracowania nowych metod podziałów dla tej klasy zastosowań.
6
Podsumowanie
Propozycje i metody przedstawione w niniejszym sprawozdaniu i jego załącznikach
w zakresie aspektów zapewnienia jakości, szacowania złożoności przy użyciu metody
punktów funkcyjnych, zarządzania reputacją oraz sprawiedliwego podziału zasobów
umożliwiły realizację wszystkich trzech celów szczegółowych pracy: A (Metodyka
zapewnienia jakości Produktów Informacyjnych w projektowaniu łańcucha przetwarzania
danych zgodnie z Architekturą Zorientowaną Usługowo (SOA)), B (Metodyka przetwarzania
łańcucha przetwarzania danych w czasie rzeczywistym z użyciem źródeł o zawartości
zmiennej w czasie) i C (Metody oceny zaufania usług). Wyniki niniejszych prac zostaną
wykorzystane w przygotowaniu rozpraw doktorskich między innymi Michała Majdana i Pawła
Olendra. Wyniki niniejszej pracy są i będą w przyszłości wykorzystywane do przygotowania
i wykonania w projektów realizowanych przez zespół Zakładu Zaawansowanych Technik
Informacyjnych na rzecz operatorów telekomunikacyjnych, agencji rządowych oraz innych
projektów wykonywanych w ramach programów między narodowych (np. EUREKA – projekt
EDFAS) i krajowych (np. Program Operacyjny Innowacyjna Gospodarka – np. projekty
„Inżynieria Internetu Przyszłości”, „System Informacyjny o Infrastrukturze Szerokopasmowej
i portal Polska Szerokopasmowa”, „Informatycznego Systemu Osłony Kraju”).
Bibliografia
[1]
Liya Wu, Barash G., Bartolini C.: A Service-oriented Architecture for Business
Intelligence. Proceedings of the IEEE International Conference on Service-Oriented
Computing and Applications (SOCA’07), IEEE Computer Society, p. 279-285
[2]
Arsanjani A.: Service-Oriented Modeling & Architecture. IBM, 2004,
http://www.ibm.com/developerworks/library/ws-soa-design1/
[3]
OASIS: Definition of SOA,
http://opengroup.org/projects/soa/doc.tpl?gdid=10632
29
[4]
OASIS: SOA Reference Model definition,
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
[5]
Kognitio WX2: http://www.kognitio.com/services/products/wx2.php:
[6]
Teradata: http://www.teradata.com
[7]
Greenplum: http://www.greenplum.com/
[8]
Apache Hadoop: http://hadoop.apache.org/
[9]
BPMN: http://www.bpmn.org/
[10] WS-BPEL 2.0: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
[11] Web Services Choreography Description Language Version 1.0:
http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/
[12] Function Point Counting Practices Manual, version 4.0, www.ifpug.org
[13] Introduction To Function Point Analysis, http://www.softwaremetrics.com/fpafund.htm
[14] Longstreet D.: Fundametals of Function Point Analysis, www.softwaremetrics.com
[15] Longstreet D.: Improved Function Point Definictions, www.softwaremetrics.com
[16] Toffano Calazans A., Marcal de Oliveira K., Ribeiro dos Santos R.: Adapting Function
Point Analysis to Estimate Data Mart Size
[17] Akerlof G. A.: The market for “lemons”: Quality uncertainty and the market mechanism.
The Quarterly Journal of Economics, 84(3):488–500, 1970.
[18] Gambetta D.: Can we trust trust. In Trust: Making and Breaking Cooperative Relations,
pages 213–237. Basil Blackwell, 1988
[19] Torra V.: The weighted
Systems,12:153–166, 1997.
owa
operator.
International
Journal
of
Inteligent
[20] Yager R. R.: On ordered weighted averaging aggregation operators in multicriteria
decisionmaking. IEEE Trans. Syst. Man Cybern., 18(1):183–190, 1988
[21] Damiani E., De Capitani di Vimercati S., Samarati P., Viviani M.: A wowa-based
aggregation technique on trust values connected to metadata. In Metadata,
International Workshop on Security and Trust Management, 2005
[22] Liya Wu, Barash G., Bartolini C.: A Service-oriented Architecture for Business
Intelligence. Proceedings of the IEEE International Conference on Service-Oriented
Computing and Applications (SOCA’07), IEEE Computer Society, p. 279-285
[23] Cisco Service-Oriented Network Architecture: Support and Optimize SOA and Web 2.0
Applications, http://www.cisco.com
[24] Lissowski G.: Zasady sprawiedliwego podziału dóbr. Warszawa, Wydawnictwo
Naukowe Scholar, 2008
[25] Hosaagrahara M., Sethu H.: Max-min fair scheduling in input-queued switches. IEEE
Transactions on Parallel and Distributed Systems, 2008, nr 19(4), s. 462-475
[26] Boudec J. L.: Rate adaptation, congestion control and fairness: A tutorial. Technical
Report 3132, Ecole Polytechnique Federale de Lausanne (EPFL), 2005
[27] Salgueiro E., Cunha P., Salgueiro R., Monteiro J.: Fair Bandwidth Sharing Using
Shapley Value. Euro American Conference On Telematics And Information Systems
2008, Aracaju, 2008
30
Załącznik 1
Artykuł złożony do druku
w Journal of Telecommunications and Information Technology
Agnieszka Gosk:
Query optimization in Teradata warehouse
31
32
Załącznik 2
Artykuł złożony do druku
w Journal of Telecommunications and Information Technology
Paweł Olender:
Stochastic models in techno-economic analysis of broadband access networks
41