Rozproszone środowisko dla biologii systemów

Wielkość: px
Rozpocząć pokaz od strony:

Download "Rozproszone środowisko dla biologii systemów"

Transkrypt

1 Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki Michał Lula Nr albumu: Rozproszone środowisko dla biologii systemów Praca magisterska na kierunku INFORMATYKA Praca wykonana pod kierunkiem dr hab. Anny Gambin Instytut Informatyki Listopad 2009

2 Oświadczenie kierującego pracą Potwierdzam, że niniejsza praca została przygotowana pod moim kierunkiem i kwalifikuje się do przedstawienia jej w postępowaniu o nadanie tytułu zawodowego. Data Podpis kierującego pracą Oświadczenie autora (autorów) pracy Świadom odpowiedzialności prawnej oświadczam, że niniejsza praca dyplomowa została napisana przeze mnie samodzielnie i nie zawiera treści uzyskanych w sposób niezgodny z obowiązującymi przepisami. Oświadczam również, że przedstawiona praca nie była wcześniej przedmiotem procedur związanych z uzyskaniem tytułu zawodowego w wyższej uczelni. Oświadczam ponadto, że niniejsza wersja pracy jest identyczna z załączoną wersją elektroniczną. Data Podpis autora (autorów) pracy

3 Streszczenie W pracy zostało opisane środowisko do przeprowadzania rozproszonych eksperymentów in silico. Środowisko pozwala na wykonywanie długotrwałych obliczeń, wspiera równoległe ich przetwarzanie i zapewnia powtarzalność. W oparciu o opisywaną aplikację zaimplementowano operacje umożliwiające wykonanie analizy wrażliwości modelów szlaków sygnałowych na zaburzenia parametrów. Aplikacja utworzona była z myślą o dalszym jej rozszerzaniu o nowe typy obliczeń. Implementacja środowiska oparta była o narzędzia związane z platformą Java Enerprise Edition (JEE) [23]. Do pracy dołączono opis przykładowych eksperymentów wykonanych za pomocą zaimplementowanego środowiska. Słowa kluczowe taverna, biologia systemów, szlaki sygnałowe, prism model checker, mathematica, java, web service, jms 11.3 Informatyka Dziedzina pracy (kody wg programu Socrates-Erasmus) D. Software D.3. PROGRAMMING LANGUAGES D.3.3. Language Constructs and Features Klasyfikacja tematyczna Distributed enviroment for system biology Tytuł pracy w języku angielskim

4

5 Spis treści Wprowadzenie Aplikacja Cele pracy Zarys funkcjonalności systemu Protokół komunikacyjny Wywołanie synchroniczne Wywołanie asynchroniczne Wykonanie obliczenia Moduły Taverna Kolejka JMS WebService Robotnik Nadzorca Zastosowanie Problem biologiczny Wieloparametrowa analiza wrażliwości Podejście deterministyczne Podejście stochastyczne Probabilistyczna weryfikacja modelowa PRISM Eksperymenty Podejście deterministyczne Operacje Przepływ czynności algorytmu MPSA Eksperyment Wyniki Podejście stochastyczne Model Specyfikacja Operacje Przepływ czynności Eksperyment Wyniki Eksperyment badający wydajność systemu

6 4. Podsumowanie A. Kompilacja, instalacja i sposób użycia A.1. Konfiguracja A.1.1. moduł webservice A.1.2. moduł register A.1.3. moduł mathematica A.1.4. moduł odesolver A.1.5. moduł prism A.2. Kolejka A.3. Budowa źródeł A.4. Testy A.5. Kontroler serwletów A.6. Uruchomienie B. Instalacja aplikacji klienta C. Dodawanie nowych operacji D. Model w PRISMie E. Opis wdrożenia F. Zawartość płyty CD Bibliografia

7 Wprowadzenie W pracy opisywany jest system do wykonywania złożonych obliczeń. System tworzony był z myślą o zastosowaniu go do obliczeń z zakresu biologii systemów. Jest to kontynuacja prac rozpoczętych w publikacji [4]. Przedstawiono tam implementację algorytmu wieloparametrowej analizy wrażliwości (ang. Multi-Parameter Sensitivity Analysis - MPSA) [7] w oparciu o symulacje wykorzystujące równania różniczkowe. Pożądane było rozszerzenie systemu o możliwość wykonania symulacji stochastycznych. W podejściu stochastycznym wykorzystywana miała być probabilistyczna weryfikacja modelowa (ang. probablistic model checking) [3]. Pozwalałoby to na wykonywanie zaawansowanej analizy jakościowej problemu (w trakcie wykonywania symulacji można badać spełnialność formuły zadanej w logice temporalnej). Zastosowanie probabilistycznej weryfikacji modelowej okazało się jednak złożone obliczeniowo. W trakcie symulacji budowana jest rozległa przestrzeń stanów. Eksploracja jej wymaga dużej mocy obliczeniowej i dużo pamięci. Wymusiło to zmianę architektury systemu dostarczonego w [4]. Konieczne było wspieranie długich obliczeń i wykonywanie równoległe niezależnych operacji. Efektem tych zmian jest dostarczony system. Praca podzielona została na 4 rozdziały i 6 dodatków. W rozdziale pierwszym opisano implementację systemu. W rozdziale drugim znajduje się omówienie problemu biologicznego motywującego napisanie systemu. Umieszczono tu również opis dwóch podejść do jego rozwiązania. W rozdziale trzecim zawarto opis eksperymentów obrazujących wykorzystanie systemu. W ostatnim rozdziale znajduje się podsumowanie całej pracy. W dodatkach umieszczono przydatne uzupełnienia. W dodatku pierwszym opisany jest proces kompilacji i instalacji. W drugim dodatku znajduje się opis instalacji z punktu widzenia klienta systemu. Trzeci dodatek stanowi kurs dodawania nowych operacji. W czwartym dodatku zawarto definicję modelu szlaku sygnałowego w PRISMie [17]. Piąty dodatek omawia wdrożenie systemu na serwerach Centrum Doskonałości BioExploratorium [5]. W ostatnim dodatku opisano zawartość płyty CD dołączonej do pracy. 5

8

9 Rozdział 1 Aplikacja 1.1. Cele pracy Głównym celem mojej pracy było stworzenie środowiska usprawniającego wykonywanie eksperymentów in silico z zakresu biologii systemów. Ze względu na charakter obliczeń aplikacja powinna: umożliwiać wykonywanie eksperymentów wymagających dużej mocy obliczeniowej, umożliwiać równoległe przeprowadzanie obliczeń, umożliwiać asynchroniczne wykonywanie długotrwałych obliczeń, być skalowalna i składać się z luźno powiązanych komponentów, umożliwiać rozszerzanie środowiska o kolejne operacje obliczeniowe, zapewnić powtarzalność wykonywania eksperymentów, być dostępna dla szerokiej grupy użytkowników Zarys funkcjonalności systemu Poniżej przedstawię zarys głównych funkcjonalności systemu. Szerszy opis poszczególnych modułów znajduje się w dalszej części rozdziału. System można podzielić na dwie główne części - część klienta i część serwerową. Część klienta stanowi aplikacja Taverna [28]. Posiada ona graficzny interfejs użytkownika umożliwiający wywoływanie operacji udostępnianych przez część serwerową systemu. Aplikacja pozwala łączyć wykonanie tych operacji w przepływy czynności (ang. workflow). W ten sposób możliwe jest formalne zdefiniowanie eksperymentu. W części serwerowej zaimplementowane zostały operacje wykonujące właściwe obliczenia. Aby możliwe było odpowiednie wykonywanie operacji, konieczne było utworzenie oprogramowania nadzorującego i zarządzającego obliczeniami. W rozdziale tym skupiam się na opisie właśnie tego oprogramowania. Opis implementacji poszczególnych operacji obliczeniowych można znaleźć w rozdziale poświęconym eksperymentom. Część serwerowa podzielona została na cztery luźno powiązane moduły funkcjonalne. Są to moduły: WebService, Kolejka, Nadzorca i Robotnik. Implementacja modułów oparta została o narzędzia wywodzące się z platformy Java Enterprise Edition (JEE) [23]. Szkic architektury przedstawiony został na rysunku

10 Rysunek 1.1: Szkic architektury 8

11 Moduł WebService udostępnia operacje obliczeniowe aplikacji klienta. Operacje udostępniane są poprzez usługi sieciowe (ang. web services). Moduł odpowiedzialny jest za komunikację z klientem, przetwarzanie wywołań klienta na komunikaty zrozumiałe dla modułów liczących i przetwarzanie wyników obliczeń na odpowiedzi usług sieciowych. Moduły części serwerowej komunikują się między sobą za pomocą komunikatów JMS (ang. Java Message Service)[24]. Implementacja komunikacji znajduje się wewnątrz modułu Kolejka. Właściwe obliczenia wykonywane są przez moduły Robotników. Pobierają one z kolejki zlecenia wykonania obliczeń. Po wykonaniu obliczeń zwracają do kolejki komunikaty z wynikami. W dostarczonym przeze mnie systemie zaimplementowane są trzy typy modułu Robotnik. Są to podprojekty Mathematica, ODESolver i Prism. Wszystkie te moduły w wykonywanych obliczeniach korzystają z aplikacji zewnętrznych (od których przejęły nazwy) i udostępniają różne funkcjonalności. Moduł Nadzorcy używany jest do zarządzania operacjami asynchronicznymi. Opis pojęcia operacja asynchroniczna znajduje się w następnym podrozdziale. W systemie może działać jednocześnie wiele instancji każdego modułu. Wszystkie moduły mogą być uruchomione na osobnych maszynach. Jedynym założeniem jest możliwość komunikacji pomiędzy komputerami za pomocą sieci TCP/IP. Właściwie skonfigurowany system umożliwia rozproszenie obliczeń i zwielokrotnienie mocy obliczeniowej. W razie potrzeby można zwiększyć lub zmniejszyć liczbę modułów liczących. Zapewnia to skalowalność i zmniejsza podatność systemu na awarie Protokół komunikacyjny Kluczowym dla poznania działania systemu jest zrozumienie funkcjonowania protokołu komunikacyjnego modułów. W systemie wspierane są dwa typy operacji: operacje synchroniczne i operacje asynchroniczne. Poprzez operacje synchroniczne rozumiem operacje, w których wyniki obliczeń zwracane są od razu. Klient oczekuje na wykonanie obliczeń i po ich ukończeniu odbiera wyniki. Operacje asynchroniczne działają w inny sposób. Wywołanie operacji jest jedynie zleceniem wykonania obliczenia. Klient nie oczekuje na wyniki. Zwracane są one za pomocą wiadomości . Każdy typ operacji ma odmienny protokół komunikacyjny. Poniżej przedstawię opis kolejnych kroków działania systemu po otrzymaniu zlecenia wykonania obliczenia. Klient wywołuje metodę web service u. Wywołanie przechwytywane jest przez moduł WebService. Parametry wywołania tłumaczone są na komunikaty JMS. Pojedyncze wywołanie może spowodować stworzenie wielu komunikatów. Na przykład, gdy celem wywołania było wykonanie symulacji modelu z różnymi parametrami, dla każdego zestawu parametrów może zostać stworzony osobny komunikat. Każdy komunikat zaopatrywany jest w sygnaturę typu operacji. Określany jest adres kolejki docelowej i jej nazwa. W tym momencie scenariusz się rozgałęzia w zależności od charakteru operacji. 9

12 Wywołanie synchroniczne W przypadku wywołania synchronicznego: Tworzona jest tymczasowa kolejka, niedostępna dla innych procesów. Do każdego komunikatu dołączany jest adres tej kolejki, jako adres zwrotny wyników. Komunikaty umieszczane są w docelowej kolejce. Proces web service u oczekuje na pojawienie się wyników wszystkich komunikatów w tymczasowej kolejce. Po odebraniu wszystkich komunikatów z wynikami tworzona jest na ich podstawie odpowiedź metody web service u. Wynik zwracany jest oczekującemu klientowi Wywołanie asynchroniczne W przypadku wywołania asynchronicznego: Rejestruje się wykonywane obliczenie w module Nadzorcy. Rejestracja polega na wysłaniu wiadomości do kolejki Nadzorcy, przeznaczonej do rejestrowania zgłoszeń. Wiadomość taka zawiera typ obliczenia, liczbę komunikatów wchodzących w skład obliczenia oraz adres pod jaki należy wysłać wyniki. Moduł Nadzorcy przekazuje komunikat zwrotny, którego treścią jest identyfikator zarejestrowanych obliczeń. Do każdego komunikatu dołączany jest adres kolejki Nadzorcy przeznaczonej do odbierania wyników, jako adres zwrotny rezultatów. Nadawany jest również identyfikator obliczeń. Komunikaty umieszczane są w docelowej kolejce. Proces web service u kończy tu swoje działanie. Wynikami zajmie się moduł Nadzorcy. Moduł Nadzorcy oczekuje na komunikaty w dwóch kolejkach. Pierwsza służy do rejestracji obliczeń, druga do zgłaszania wyników. Gdy w kolejce rejestracyjnej pojawi się komunikat, rejestrowany jest nadzór nad obliczeniem. Nadawany jest identyfikator obliczeń. Zapisywany jest identyfikator i typ obliczenia, adres i liczba oczekiwanych wyników. Gdy w kolejce na wyniki pojawi się komunikat, sprawdzany jest identyfikator obliczenia. Komunikat trafia do wyników o tym samym identyfikatorze. Gdy obliczenie nie było jeszcze zarejestrowane, komunikat jest zapisywany w pomocniczym buforze. Co pewien czas struktura danych gromadząca wyniki przeglądana jest w celu znalezienia skompletowanych obliczeń. Z kompletnych wyników tworzona jest wiadomość , która następnie wysyłana jest pod odpowiedni adres. 10

13 Wykonanie obliczenia Obliczenia wykonywane są w sposób niezależny od charakteru operacji (synchroniczny, asynchroniczny). Moduł obliczeniowy wspiera określone typy operacji. Dla każdego typu potrafi stworzyć proces liczący. Moduł oczekuje na pojawienie się komunikatu w kolejce. Gdy przyjdzie komunikat, sprawdzany jest jego typ. Jeśli dany typ jest wspierany, uruchamiany jest proces liczący. Jako parametr przekazuje się treść komunikatu. Gdy dany typ nie jest wspierany komunikat jest ignorowany. Po wykonaniu obliczeń budowany jest komunikat zwrotny o treści będącej wynikiem obliczenia. Komunikatowi nadawany jest taki sam identyfikator i typ, jaki miał komunikat inicjalizujący obliczenia. W przypadku wystąpienia błędu w trakcie obliczeń, treścią komunikatu zwrotnego jest wiadomość wyjątku. Komunikat wynikowy wysyłany jest pod adres zawarty w komunikacie inicjalizującym obliczenia Moduły Taverna Taverna [28] jest graficznym środowiskiem do konstruowania schematów eksperymentów in silico. Stworzona została przez, związany z uniwersytetem w Manchesterze, zespół mygrid. Głównymi celami działania Taverny są: sformalizowanie wykonywania eksperymentów, zapewnienie możliwości powtarzania eksperymentów, umożliwienie ponownego wykorzystania stworzonych przez społeczność modułów obliczeniowych. Filozofia programu oparta jest na definiowaniu przepływów czynności (ang. workflow). Przepływ czynności składa się ze zbioru procesorów. Przez procesor należy rozumieć jednostkę wykonującą ściśle określone obliczenie. Procesor przyjmuje dane wejściowe i zwraca wynik. Wyniki jednego procesora mogą być danymi wejściowymi kolejnego procesora. W ten sposób można skonstruować sieć procesorów powiązanych wejściami i wyjściami. Są to właśnie przepływy czynności. Sieć taka może realizować wykonanie złożonego eksperymentu. Taverna obsługuje różnego rodzaju procesory. Szczególnie istotne są procesory wywołujące metody web service ów. Aby zdefiniować taki procesor w Tavernie, należy za pomocą menu dodać plik WSDL (ang. Web Service Definition Language)[31] z definicją serwisu. Taverna, na podstawie tego pliku, utworzy po jednym procesorze dla każdej metody. Za pomocą innego typu procesorów można między innymi wczytywać pliki, definiować stałe, dokonywać prostych operacji na listach itd. Bardzo użyteczna jest możliwość definiowania procesorów w oparciu o BeanShell[1] prosty język skryptowy z dynamicznym typowaniem, składnią podobny do Javy. Umożliwia on np. przetwarzanie danych wejściowych lub wyników do wymaganego formatu. Taverna umożliwia zagnieżdżanie przepływów czynności. Zagnieżdżony przepływ traktowany jest jak zwykły procesor. 11

14 Przepływy czynności w Tavernie definiuje się za pomocą graficznego menu. Odnajduje się na liście właściwy procesor i przeciąga się go na okno przepływu. Aby połączyć dwa procesory należy wybrać wyjście jednego z nich i połączyć z wejściem drugiego. Możliwe jest ustawienie wartości domyślnych dla wybranych przez użytkownika wejść procesorów. Definicja przepływu czynności zapisywana jest w języku Scufl[29]. Jest to język oparty o XML. Jego składnia jest dość rozwlekała i mało czytelna, ale mimo to jest możliwe ręczne definiowanie i edycja przepływów. Taverna wyposażona jest w moduł wykonujący eksperymenty. Moduł ten wywołuje kolejne procesory zwracając ostateczny wynik przepływu lub informację o błędzie, jeśli taki wystąpił. Możliwe jest zapisanie wyników eksperymentu. Taverna umożliwia ścisłą definicję eksperymentu i zapewnia jego powtarzalność. Jest narzędziem powszechnie stosowanym w bioinformatyce, dlatego też stworzone przeze mnie środowisko zintegrowane zostało z Taverną. Do pracy dołączone są definicje przykładowych przepływów. Integralną częścią Taverny i części serwerowej jest plik WSDL definiujący sygnatury metod udostępnianych przez web service. W ten sposób udostępniane są Tavernie procesory wykonujące obliczenia zaimplementowane w części serwerowej Kolejka JMS Java Message Service (JMS) [24] jest rozwiązaniem będącym częścią standardu Enterprise Java Beans 3.0 [22]. Dostarcza protokoły komunikacyjne oparte na wymianie komunikatów poprzez sieć TCP/IP. Zaimplementowane są tu dwa typy rozgłaszania komunikatów, poprzez kolejki (ang. Queue) i tematy (ang. Topic). Komunikacja poprzez kolejkę stosowana jest w przypadku gdy komunikat może być odebrany przez dowolnego klienta kolejki, nie może być utracony i musi być przetworzony przez dokładnie jednego klienta. W modelu tym klienci czekają na pojawienie się komunikatu w kolejce. Gdy taki zostanie umieszczony w kolejce, zarządca kolejki wybiera jednego z klientów i przekazuje mu komunikat. Sposób rozdziału komunikatów pomiędzy klientów nie jest określony w standardzie i zależny jest od używanej implementacji. Gdy w chwili pojawienia się komunikatu nie ma oczekującego klienta, komunikat jest kolejkowany. Zostanie on skonsumowany, gdy pojawi się klient. Komunikacja z użyciem tematów ma charakter rozgłaszania wiadomości. Komunikat umieszczony w temacie rozsyłany jest do wszystkich zarejestrowanych klientów (zwanych subskrybentami). Gdy klient nie jest zarejestrowany w chwili przyjścia komunikatu, nie otrzyma go. Istnieje modyfikacja (ang. persistence topic) pozwalająca na utrwalanie komunikatów. Wówczas możliwe jest zawieszenie oczekiwania na komunikaty, ponowne wznowienie i odebranie komunikatów, które się w tym czasie pojawiły w temacie. Dla zaimplementowanego przeze mnie systemu właściwym modelem komunikacji jest model z kolejką. Mamy tutaj bowiem do czynienia ze zleceniami wykonania obliczeń, które mogą być obsłużone przez dowolny, oczekujący proces obliczeniowy. Obliczenie ma być wykonane dokładnie raz. Zastosowanie kolejki pozwala na rozproszenie poszczególnych modułów i ograniczenie powiązań pomiędzy nimi. Dodatkowo możliwa jest łatwa skalowalność liczby modułów. W systemie używana jest implementacja ActiveMQ[11] standardu JMS. W skład modułu Kolejka wchodzą dwa podprojekty: producer i consumer. Zaimplementowana jest w nich warstwa komunikacji wykorzystująca kolejkę. Najważniejszą klasą podprojektu consumer jest klasa Consumer. Klasa implementuje dwa interfejsy Runnable i MessageListener. Zaprojektowana została z myślą o uruchamianiu jej 12

15 w osobnym wątku. W konstruktorze przyjmuje dwa parametry: adres i nazwę kolejki. Po uruchomieniu (wywołanie metody run) tworzy sesję, łączy się z kolejką i oczekuje na komunikaty. W chwili pojawienia się komunikatu w kolejce, wywoływana jest metoda onmessage. Jest to metoda abstrakcyjna. Jej implementacja zależna jest od zastosowania klasy Consumer i powinna zostać dostarczona przez klasę dziedziczącą. Ważną metodą jest metoda reply. Pozwala ona odpowiedzieć na otrzymany komunikat. W podprojekcie producer znajduje się klasa Producer odpowiedzialna za rozsyłanie komunikatów i odbieranie odpowiedzi. W konstruktorze klasy podawane są: adres i nazwa kolejki do której ma zostać wysłana wiadomość i nazwa kolejki, do której zwrócone mają być wyniki. Gdy nie poda się ostatniego parametru, tworzona jest tymczasowa kolejka i to ona będzie gromadziła wyniki. Wysyłanie komunikatów odbywa się za pomocą wywołania metody send. Odbieranie wyników następuje poprzez wywołanie metody receive. Po zakończeniu korzystania z instancji klasy Producer należy wywołać na niej metodę close. W pozostałych modułach klasy Producer i Consumer są wyłącznym sposobem korzystania z kolejki JMS WebService Głównym zadaniem modułu jest tłumaczenie wywołań klienta na wywołania operacji obliczeniowych i wyników tych operacji na wyniki rozumiane przez klienta. Jest to implementacja końca web service u (ang. endpoint). Moduł uruchomiony jest na kontenerze serwletów. Komunikacja z klientem odbywa się za pomocą protokołu SOAP [32], a z częścią serwerową za pomocą komunikatów JMS. Moduł wspiera operacje synchroniczne i asynchroniczne. Stykiem części klienta i serwerowej jest definicja pliku WSDL[31]. Zawarte są w nim sygnatury wszystkich metod udostępnianych przez system. Moduł tworzony był zgodnie z podejściem WSDL first approach. Plik WSDL napisany był ręcznie, a na jego podstawie wygenerowane zostały klasy reprezentujące parametry i wyniki metod. Wygenerowany został także szkielet klasy implementującej koniec web service u. Do obsługi web service u wykorzystywany jest zrąb (ang. framework) CXF[9]. Jest on zgodny ze standardem JAX-WS (ang. Java API for XML Web Services)[25]. Źródła po zbudowaniu są zwykłym archiwum war. Mogą być uruchamiane na dowolnym kontenerze serwletów. Konfiguracja zrębu znajduje się w katalogu WEB-INF w plikach web.xml i cxf-servlet.xml. Dla każdego typu operacji należy zapewnić kod przekształcający parametry metody web service u na komunikaty JMS oraz komunikaty JMS na wyniki metody web service u. W systemie zakłada się, że komunikaty przesyłane między modułami są napisami. System dostarcza dwie generyczne klasy: ServiceMessage i rozszerzającą ją klasę WSMessage. Zapewniają one całą obsługę wymiany komunikatów. Implementację przetwarzania synchronicznego dostarcza metoda process, zaś asynchronicznego metoda asyncprocess. Klasa ServiceMessage operuje na komunikatach będących napisami. Klasa WSMessage ma zaimplementowane metody przekształcające za pomocą JAXB (ang. Java Architecture for XML Binding)[26] klasy na dokumenty XML. Dokumenty te traktowane są jako treść komunikatów. Oprócz zmiany formatu parametrów wywołania operacji, klasy te oferują możliwość zdefiniowania większej liczby komunikatów w celu np. zrównoleglenia wykonania operacji. Dla każdej operacji dostępnej w systemie zdefiniowana została klasa rozszerzająca klasę WSMessage. Ciało metody web service u implementującej daną operację sprowadza się do wywołania metody process lub asyncprocess tejże klasy. Rozszerzenie klasy WSMessage jest najprostszym sposobem zdefiniowania nowej operacji obliczeniowej. 13

16 Robotnik Jest to właściwy moduł liczący. Jego zadaniem jest pobieranie komunikatów z odpowiedniej kolejki, przetwarzanie treści komunikatu, wywołanie obliczeń i zwrócenie wyników w żądanym formacie. Do obsługi poszczególnych typów obliczeń służą klasy implementujące interfejs Worker. Interfejs ten posiada jedną metodę execute. Jako parametr przekazywany jest tu napis będący treścią komunikatu zlecającego obliczenia. Wynikiem jest również napis, na podstawie którego buduje się treść zwrotnego komunikatu. W ciele tej metody należy umieszczać właściwe obliczenia. Typowe parametry i wyniki są dokumentami XML. Dlatego dostarczona jest klasa abstrakcyjna AbstractWorker implementująca interfejs Worker, która dokonuje konwersji dokumentów XML na klasy i klas na dokumenty XML. Klasa parametryzowana jest typem parametrów i wyników. Do tłumaczenia używana jest klasa ObjectTranslator. Rozszerzając klasę AbstractWorker, kod wykonujący właściwe obliczenia należy umieścić wewnątrz metody doexecute. Z interfejsem Worker powiązany jest interfejs WorkerFactory. Jego zadaniem jest stworzenie i odpowiednie zainicjalizowanie instancji implementacji interfejsu Worker. Realizowane jest to wewnątrz metody getworker. Interfejs WorkerFactory realizuje wzorzec projektowy fabryka abstrakcyjna[13]. Metoda getworker jest jej metodą wytwórczą. W dalszej części podrozdziału realizacje interfejsu WorkerFactory nazywane będą fabrykami. Klasa TaskConsumer odpowiedzialna jest za komunikację z kolejką. Rozszerza ona klasę Consumer opisaną w podrozdziale poświęconym modułowi Kolejka. Bardzo ważną metodą tej klasy jest metoda registerfactory. Rejestruje ona fabryki tworzące klasy liczące. Rejestracja polega na podaniu w parametrach: napisu będącego identyfikatorem typu obliczenia i instancji fabryki tworzącej klasy obliczeniowe właściwe dla danego typu. Klasa TaskConsumer implementuje metodę onmessage. W jej treści następuje wyłuskanie z komunikatu typu i treści zlecenia. Sprawdzane jest, czy dla danego typu zarejestrowano fabrykę WorkerFactory i jeśli tak, to tworzona jest instancja klasy Worker. Realizowane jest to poprzez wywołanie metody getworker fabryki. Następnie na stworzonej instancji wywoływana jest metoda execute z parametrem będącym treścią komunikatu. Wynik tej metody jest zwracany za pomocą metody reply klasy TaskConsumer. Klasa TaskConsumer implementuje interfejs Runable (implementacja tego interfejsu dziedziczona jest po klasie Consumer). Klasa ta przeznaczona jest do uruchamiania w odrębnym wątku. Istnieje możliwość jednoczesnego uruchomienia wielu wątków wykonujących obliczenia. Możliwość taką realizuje klasa TaskConsumerManager Nadzorca Moduł obsługuje wyniki operacji wykonywanych asynchroniczne. Przez operacje asynchroniczne rozumiem operacje zdefiniowane w podrozdziale opisującym protokół komunikacyjny. Do jego zadań należy rejestracja obliczeń, odbieranie wyników i wysyłanie wiadomości z wynikami. Wszystkie zadania realizowane są w osobnych wątkach. Wątki operują na strukturze danych zaimplementowanej w klasie Register. Struktura ta służy do przechowywania informacji o zarejestrowanych obliczeniach i odebranych wynikach. Zaimplementowana została zgodnie ze wzorcem projektowym singleton[13]. Oznacza to, że w systemie istnieje tylko jedna instancja klasy Register (konstruktor jest metodą prywatną). Obliczenie reprezentowane jest poprzez interfejs Computation. Kluczowymi metodami tego interfejsu są addanswer i iscomplete. Za pomocą pierwszej dodawane są otrzymane wyniki. Za pomocą drugiej sprawdza się, czy skompletowano już wszystkie wyniki. Bardzo 14

17 ważną metodą jest również getresult zwracająca dla ukończonych obliczeń treść wiadomości . Dla każdego typu obliczenia powinna istnieć klasa realizująca wzorzec projektowy fabryka konkretna[13]. Klasa taka, nazywana dalej fabryką, implementuje interfejs ComputationFactory (będący realizacją wzorca projektowego fabryka abstrakcyjna). Jej zadaniem jest zwracanie instancji odpowiedniej klasy implementującej interfejs Computation. Rejestracją nowych obliczeń zajmuje się klasa Recorder. Rozszerza ona klasę Consumer. Oczekuje ona na pojawienie się wiadomości w kolejce przeznaczonej do rejestracji. Wiadomość rejestracyjna zawiera informacje o typie obliczenia, liczbie spodziewanych wyników i adresie docelowego odbiorcy. W momencie pojawienia się wiadomości wywoływana jest metoda onmessage. W jej wnętrzu następuje nadanie identyfikatora obliczeniu (metoda getid klasy Register) i zarejestrowanie obliczenia (metoda regist klasy Register). Rejestracja polega na utworzeniu, na podstawie treści komunikatu rejestrującego, obiektu implementującego interfejs Computation. Obiekt ten reprezentować będzie rozpoczęte obliczenie. Tworzony jest poprzez wywołanie metody wytwórczej fabryki przypisanej do danego typu obliczenia. Za odbieranie wyników odpowiedzialna jest klasa Receiver. Ona również rozszerza klasę Consumer. Odbiera ona komunikaty pojawiające się w kolejce przeznaczonej na wyniki. Po nadejściu komunikatu wywoływana jest metoda onmessage. Wyłuskiwane są tu: identyfikator obliczenia, treść komunikatu będąca właściwym wynikiem. Wartości te są parametrami metody addanswer klasy Register. Wewnątrz metody, na podstawie identyfikatora odnajdywane jest zarejestrowane obliczenie i wywołana jest na klasie reprezentującej to obliczenie metoda addanswer dodająca nowy wynik. Gdy obliczenie nie było jeszcze zarejestrowane, wynik jest zapisywany w pomocniczej liście. W momencie rejestracji obliczenia o danym identyfikatorze zostanie przekazany do tego obliczenia. Co pewien czas ze struktury danych reprezentującej obliczenia usuwane są zakończone obliczenia. Wykonuje się to poprzez wywołanie metody popallcompletedcomputation klasy Register. Dla każdego skompletowanego obliczenia tworzy się wiadomość , a następnie się ją wysyła. Czynności te wykonywane są poprzez wątek Sender. Do wysyłania wiadomości używana jest biblioteka JavaMail w wersji 1.2. Konfigurację konta , z którego wysyłane są wiadomości, można znaleźć w pliku konfiguracyjnym register.properties podprojektu register. 15

18

19 Rozdział 2 Zastosowanie W rozdziale tym opiszę problem biologiczny, którego analiza była podstawą do stworzenia systemu. Opiszę dwa podejścia do wykonania analizy: deterministyczne (oparte na pracy [4]) i stochastyczne (oparte o probabilistyczną weryfikację modelową[3]) Problem biologiczny Biologia systemów jest młodą nauką interdyscyplinarną badającą systemy biologiczne w ujęciu holistycznym. Badane są tu interakcje pomiędzy składnikami systemu i ich wpływ na funkcjonowanie systemu jako całości. Takie podejście pozwala na lepsze zrozumienie działania systemu biologicznego i pozwala na poznanie mechanizmów sterujących jego funkcjonowaniem. Typowym przedmiotem badań z zakresu biologii systemów są szlaki sygnałowe. Jest to złożony zbiór reakcji biochemicznych zachodzących wewnątrz komórki. Zajście jednej reakcji może uruchamiać lub hamować zajście innej reakcji. Pojawienie się odpowiednich czynników zapoczątkowuje kaskadę reakcji. Niewielkie zaburzenie ilości stężeń poszczególnych związków chemicznych może diametralnie zmienić funkcjonowanie całej komórki. Szlaki sygnałowe sterują wieloma procesami zachodzącymi w organizmie, na przykład reakcjami immunologicznymi. Ich poznanie może mieć kluczowe znaczenie we właściwym leczeniu wielu chorób. Problem modelowania szlaków sygnałowych jest złożony. Typowy szlak sygnałowy składa się bowiem z kilkudziesięciu, a nawet kilkuset powiązanych ze sobą reakcji. Aby przedstawić problem posłużę się prostym przykładem reakcji enzymatycznej. S + E k 1 k 1 SE k 2 P + E (2.1) Przez S oznaczam substrat, przez E enzym, zaś przez P produkt reakcji. Literki k z indeksem symbolizują stałe reakcji odpowiadające szybkości jej zachodzenia. Zajście reakcji zależne jest od stężenia substratów i enzymów pełniących rolę katalizatora. Substraty mogą łączyć się z enzymami tworząc stany pośrednie. Przeważnie wszystkie reakcje składowe są odwracalne. Wszystkie też zachodzą z różną prędkością. Dla tego przykładu, model reakcji zależny jest od stężenia substratów, enzymów i stałych reakcji k 1, k 1, k 2. Każda z tych wartości ma wpływ na finalne stężenie produktu. Wpływ może być jednak zróżnicowany. Może okazać się, że zaburzenie jednego parametru nie ma wielkiego wpływu na zmianę ilości produktów w czasie, natomiast zaburzenie innego może spowodować diametralne zmiany przyrostu produktu. Wiedza o tym, które parametry mają największy wpływ na funkcjonowanie szlaku sygnałowego, jest kluczowa do poznania mechanizmów sterujących jego działaniem. 17

20 2.2. Wieloparametrowa analiza wrażliwości W celu zbadania zależności modelu od parametrów wykonuje się analizę wrażliwości modelu. Istnieją różne podejścia do tego zadania. Najprostszym z nich jest analiza lokalna, polegająca na zaburzaniu pojedynczego parametru i obserwacji zmiany wyników. Sprowadza się to do policzenia pochodnych cząstkowych. Z uwagi na złożoność reakcji wchodzących w skład szlaku sygnałowego i wzajemne powiązania między reakcjami, takie podejście może okazać się niewystarczające. Konieczne może się okazać badanie wpływu zaburzenia wartości kilku parametrów jednocześnie. Takie podejście nazywa się wieloparametrową analizą wrażliwości (ang. Multi-Parameter Sensitivity Analysis, w skrócie MPSA)[7]. W dalszej części pracy do określenia tego podejścia będę używał skrótu MPSA. W dużym uogólnieniu schemat algorytmu MPSA można przedstawić następująco: wybranie zaburzanych parametrów, dla każdego parametru wygenerowanie wartości przyjmowanych przez ten parametr, dla każdego zestawu wartości parametrów wykonanie symulacji modelu, porównanie każdego wyniku symulacji z wynikiem referencyjnym (otrzymanym na przykład poprzez symulację niezaburzonego modelu), sporządzenie rankingu parametrów na podstawie poprzedniego kroku. Poszczególne metody różnią się w sposobie wykonywania kolejnych kroków algorytmu. W mojej pracy rozważane są dwie realizacje algorytmu MPSA: deterministyczna wykorzystująca równania różniczkowe i probabilistyczna wykorzystująca procesy stochastyczne Podejście deterministyczne Implementacji algorytmu MPSA, w podejściu deterministycznym, poświęcona została praca [4]. W realizacji algorytmu MPSA, przedstawionej w tej pracy, dla każdego parametru określano zakres wartości jakie on przyjmował i wybierano w sposób losowy żądaną liczbę punktów. Dla każdego zestawu wartości parametrów symulowano model za pomocą równań różniczkowych z wykorzystaniem narzędzia ODESolver[20]. Otrzymano w ten sposób trajektorie stężeń poszczególnych substancji w punktach czasowych. Dla wyniku każdej symulacji obliczana była (jako błąd średniokwadratowy) odległość trajektorii tego wyniku od trajektorii referencyjnej. W ten sposób dla każdej symulacji otrzymywano liczbę obrazującą jak wynik symulacji odległy był od wyniku referencyjnego. Następny krok polegał na podziale zbiorów parametrów na dwie grupy: akceptowalną i nieakceptowalną. Kryterium podziału była otrzymana wcześniej odległość od wyniku referencyjnego. Jeśli dla zbioru wartości parametrów odległość ta była większa od mediany z wszystkich odległości, to zbiór zostawał uznany za nieakceptowalny. W przeciwnym przypadku zbiór uznawano za akceptowalny. Ostatnim krokiem było wyznaczenie rankingu wrażliwości parametrów. Dla poszczególnych parametrów badało się zależność pomiędzy wartością parametru a podziałem zbiorów parametrów zawierających tę wartość, na grupy akceptowalną i nieakceptowalną. Zależność ta była mierzona za pomocą korelacji Pearsona lub za pomocą statystyki Kołmogorowa-Smirnowa. Pełny opis metodologii można znaleźć w [7]. 18

21 2.4. Podejście stochastyczne Podejście stochastyczne różni się od deterministycznego głównie sposobem wykonywania symulacji. Zamiast równań różniczkowych stosuje się tu łańcuchy Markowa. W podrozdziale tym opiszę szkic idei probabilistycznej weryfikacji modelowej. Opiszę również narzędzie PRISM[17] wykorzystujące to podejście Probabilistyczna weryfikacja modelowa Jest to technika formalnej weryfikacji systemów stochastycznych. Oparta jest na sprawdzaniu poprawności zadanego modelu w kontekście żądanej specyfikacji. Wymaga dwóch zbiorów danych. Pierwszym jest definicja modelu, drugim opis specyfikacji, jaką model ma spełniać. Model zazwyczaj opisywany jest w językach wyższego rzędu takich jak algebra procesów, czy sieci Petriego. Specyfikacja zawiera zbiór własności, które określają oczekiwane zachowanie modelu. Wygodnym jest przedstawianie tych własności za pomocą logiki temporalnej. Na podstawie definicji modelu w procesie weryfikacji modelowej budowany jest automat, w którym stany odpowiadają możliwym konfiguracjom modelu, zaś tranzycje obrazują możliwe zmiany konfiguracji. Spełnienie specyfikacji badane jest poprzez eksplorację przestrzeni stanów i sprawdzanie zachodzenia własności w poszczególnych konfiguracjach. W probabilistycznej weryfikacji modelowej, z tranzycjami wiąże się dodatkowo informację o prawdopodobieństwie ich zajścia w czasie. Matematycznym modelem jest tu łańcuch Markowa z czasem ciągłym (ang. Continuous Time Markov Chain, w skrócie CTMC)[3]. Każdej tranzycji łańcucha przyporządkowuje się nieujemną liczbę rzeczywistą będącą parametrem w rozkładzie wykładniczym prawdopodobieństwa zajścia tej tranzycji w czasie t. Łańcuch Markowa z czasem ciągłym można zdefiniować jako krotkę (S, R, L), gdzie: S jest skończonym zbiorem stanów, R: (S S) R 0 jest macierzą parametrów powiązanych z tranzycjami, L: S 2 AP jest funkcją etykietującą, przyporządkowującą każdemu stanowi podzbiór danego, skończonego zbioru etykiet AP. Macierz R przyporządkowuje każdej tranzycji parametr rozkładu wykładniczego prawdopodobieństwa jej zajścia. Gdy między dwoma stanami nie ma tranzycji, przyporządkowywana jest liczba 0. Prawdopodobieństwo, że w ciągu t jednostek czasu tranzycja pomiędzy stanami s i s zostanie wykorzystana wynosi 1 e R(s,s ). Zazwyczaj dla stanu s istnieje wiele stanów s takich, że R(s, s ) > 0. W takim przypadku może być wybrana dowolna tranzycja. Wybór tranzycji implikuje dalsze zachowanie łańcucha. Sytuację taką nazywa się wyścigiem (ang. race condition). Czas spędzony w stanie s przed przejściem do innego stanu jest zmienną losową o rozkładzie wykładniczym z parametrem E(s) = s S R(s, s ). Parametr ten nazywany jest parametrem wyjścia (ang. exit rate). Prawdopodobieństwo wyjścia ze stanu s za pomocą tranzycji s dane jest wzorem R(s, s )/E(s). Funkcja etykietująca nadaje stanom określony zbiór etykiet. Poprzez etykietę należy rozumieć pewną własność nadawaną stanowi. Łańcuchy Markowa z czasem ciągłym można rozszerzyć o tzw. funkcje nagrody (ang. reward function). Polegają one na przyznawaniu bonusów za przebywanie w określonym stanie lub przechodzenie przez określoną tranzycję. Rozszerzenie to pozwala na analizę ilościową modelowanego problemu. Funkcje nagrody promują stany bądź tranzycje spełniające określone własności. Formalnie jest to para funkcji (ρ, ι), gdzie: 19

22 ρ: S R 0 jest stanową funkcją nagrody ι: (S S) R 0 jest tranzycyjną funkcją nagrody Specyfikację, którą spełniać ma model zdefiniowany za pomocą łańcucha Markowa z czasem ciągłym, zapisuje się z użyciem logiki CSL (ang. Continuous Stochastic Logic)[3]. Aby móc korzystać w specyfikacji z funkcji nagrody należy dodatkowo rozszerzyć używaną logikę o obsługę tych funkcji. Składnię logiki CSL można zdefiniować następująco: Φ ::= true a Φ Φ Φ P p [φ] S p [Φ] φ ::= X Φ Φ U I Φ gdzie a jest etykietą, {<,, >, }, p [0; 1] zaś I R 0. Logika CSL posiada dwa typy formuł: formuły stanowe (ang. state formula) oznaczone przez Φ i formuły ścieżkowe (ang. path formula) oznaczone przez φ. Symbol P p [φ] definiuje formułę, którą intuicyjnie można opisać jako: prawdopodobieństwo spełnienia formuły ścieżkowej φ jest w relacji z wartością p. Operator S opisuje prawdopodobieństwo przebywania w określonym stanie przy czasie granicznym. Symbol S p [Φ] należy rozumieć jako: prawdopodobieństwo pozostania przy czasie granicznym w stanie spełniającym formułę stanową Φ jest w relacji z wartością p. Formuły ścieżkowe korzystają ze standardowych operatorów logiki temporalnej X i U. Symbol X Φ definiuje formułę: w następnym stanie spełniona jest formuła Φ. Symbol Φ U I Ψ wprowadza formułę o znaczeniu semantycznym: Ψ jest spełniona w pewnej chwili czasowej z przedziału I i Φ jest spełniona we wszystkich poprzedzających chwilach z tego przedziału. Rozszerzenie logiki CSL o funkcje nagrody dodaje formuły o składni: R r [C t ] R r [I =t ] R r [F Φ] R r [S] gdzie {<,, >, }, r, t R 0, a Φ jest stanową formułą CSL. Intuicyjnie powyższe formuły można interpretować następująco: R r [C t ] - stan s spełnia formułę jeśli skumulowana nagroda, do chwili upłynięcia czasu t, jest w relacji z wartością r, R r [I =t ] - stan s spełnia formułę jeśli oczekiwana wartość nagrody, w chwili t, jest w relacji z wartością r, R r [F Φ] - stan s spełnia formułę jeśli skumulowana nagroda, do chwili osiągnięcia pierwszego stanu spełniającego formułę Φ, jest w relacji z wartością r, R r [S] - stan s spełnia formułę jeśli, średnia oczekiwana wartość nagrody w czasie granicznym jest w relacji z wartością r. Formalne definicje wszystkich formuł logiki CSL można znaleźć w [18]. Skonstruowana została tu przestrzeń probabilistyczna, omówiono relację spełnialności formuł i realizację algorytmu weryfikacji modelowej w oparciu o logikę CSL i łańcuchy Markowa z czasem ciągłym. W pracy tej opisano również rozszerzenie logiki CSL o obsługę funkcji nagrody. 20

23 PRISM PRISM [17] jest narzędziem rozwijanym na uniwersytetach w Birmingham i Oxfordzie. Wspiera on wykonywanie probabilistycznej weryfikacji modelowej. Obsługuje wiele typów modeli, również łańcuchy Markowa z czasem ciągłym. PRISM posiada własny wysokopoziomowy język definicji modelu. Wspiera rozszerzenia modelu o funkcje nagrody zarówno przy definiowaniu modelu jak i specyfikacji. Wykorzystywane są tu dwa typy obliczeń oparte na algorytmach grafowych i numerycznych. Algorytmy teorii grafów wykorzystywane są do weryfikacji modelowej. Stosują się w ujęciu jakościowym problemu. Wykonywane jest tu standardowe budowanie i eksploracja przestrzeni stanów. Algorytmów numerycznych używa się w celu zapewnienia analizy ilościowej problemu (obliczenia prawdopodobieństw i funkcji nagrody). Najczęściej konieczne jest numeryczne rozwiązywanie układów równań liniowych. Narzędzie posiada graficzny interfejs użytkownika, lecz może być również uruchamiane z konsoli. Aktualną, w chwili tworzenia pracy, była wersja 3.2. Z ciekawszych funkcjonalności tej wersji należy wymienić: możliwość konwersji różnych języków definicji modelu do języka wspieranego przez PRISM (w tym konwersja z SBML), udostępnienie modułu symulacji, rysowanie wykresów funkcji dostępne za pomocą interfejsu graficznego. W następnych akapitach omówię sposób definiowania modelu i specyfikacji w PRISMie. Definicje modelu Model w PRISMie składa się z definicji modułów. Każdy moduł posiada zbiór zmiennych o skończonym zakresie wartości. Stan modułu określony jest przez wartości tych zmiennych. Stan całego modelu odpowiada wartościom wszystkich zmiennych z każdego modułu. Zbiór wszystkich zmiennych modelu oznaczmy przez V. Definicja modułu składa się z komend postaci: [akcja] warunek parametr : przypisanie; Napis akcja oznacza opcjonalną etykietę akcji. Napis warunek symbolizuje predykat określony na zbiorze zmiennych V. Napis parametr jest wyrażeniem, którego wynikiem jest nieujemna liczba rzeczywista, zaś przypisanie jest operacją uaktualniającą stan, czyli wartości zmiennych modelu. Wyrażenie ukryte pod napisem przypisanie ma postać: (x 1 = u 1) & (x 2 = u 2) &... & (x k = u k) gdzie x 1, x 2,..., x k V, zaś u 1, u 2,..., u k są funkcjami określonymi na zbiorze V. W danym stanie, komenda jest aktywna, gdy spełniony jest predykat warunek. Dla aktywnej komendy, operacja przypisanie może zostać wykonana z prawdopodobieństwem zależnym od parametru parametr. Etykieta akcja używana jest do zapewnienia synchronizacji pomiędzy modułami przetwarzanymi równolegle. Przykładowy model zdefiniowany w PRISMie mógłby wyglądać tak: 1 const i n t N; // d e f i n c j a s t a l e j 2 Listing 2.1: przykładowa definicja modelu w PRISMie 21

24 3 module TEST 4 5 k : [ 0.. N] i n i t N; // d e f i n i c j a zmiennej 6 7 [ k ] k>0 > 1 : ( k =k 1); // d e f i n i c j a komendy 8 9 endmodule Funkcje nagrody Funkcje nagrody definiuje się za pomocą składni rewards nazwa nagrody def inicje endrewards gdzie def inicje są jedną lub więcej stanową funkcją nagrody o składni definicji warunek : nagroda; oraz/lub tranzycja funkcją nagrody o składni definicji [akcja] warunek : nagroda; Napis warunek oznacza predykat określony na zmiennych modelu. Napis nagroda symbolizuje wyrażenie o wartości rzeczywistej, mogące zawierać zmienne i stałe zdefiniowane w module. Napis akcja jest etykietą akcji występującej wcześniej w definicji jednej z komend modułu. Gdy stan spełnia predykat warunek zmienna powiązana ze stanową nagrodą zwiększana jest o wartość nagroda. Dzieje się tak dla każdej definicji stanowej funkcji nagrody. Analogicznie gdy wykonywana jest komenda powiązana z akcja o etykiecie akcja i spełniony jest predykat warunek, zmienna powiązana z tranzycyjną nagrodą, zwiększana jest o wartość nagroda. Definicja funkcji nagrody dla przykładowego modelu mogłaby wyglądać tak: 1 rewards nagroda 2 Listing 2.2: przykładowa definicja funkcji nagrody w PRISMIE 3 t r u e : N k ; \\ stanowa f u n k c j a nagrody 4 [ k ] t r u e : 1 ; \\ t r a n z y c y j n a f u n k c j a nagrody 5 6 endrewards Specyfikacja PRISM do definiowania specyfikacji modeli, opartych o łańcuchy Markowa z czasem ciągłym, używa logiki CSL (ang. Continuous Stochastic Logic)[3] rozszerzonej o wsparcie dla funkcji nagrody. Oprócz możliwości sprawdzania spełnialności formuł, udostępniona jest opcja wyliczania prawdopodobieństw i wartości funkcji nagrody zadanych w formułach. Uzyskuje się to poprzez zastąpienie znaczka relacji symbolem =?, dla formuł typu P, S i R. Poniżej przedstawię kilka przykładów formuł: k = N P 0.9 [(k = N) U (k < N)] - jeśli wartość zmiennej k wynosi N, to prawdopodobieństwo zmniejszenia się tej wartości jest mniejsze od 0.9, S =? [k = 1] - jakie jest prawdopodobieństwo, że w czasie granicznym zmienna k będzie miała wartość 1, 22

25 R { nagroda }=? [C t ] - jaka jest oczekiwana skumulowana wartość nagrody nagroda w chwili upłynięcia czasu t, R { czas }=? [F (k = 2)] - jaka jest oczekiwana skumulowana wartość nagrody czas, w chwili osiągnięcia przez zmienną k wartości 2 po raz pierwszy, (k = N) R { reaction } 0 [I t ] - jeśli zmienna k ma wartość N, to po upływie czasu t oczekiwana wartość nagrody reaction jest większa od 0, R { reactions }=? [S] - jaka jest średnia wartość nagrody reactions w czasie granicznym. 23

26

27 Rozdział 3 Eksperymenty Wraz z systemem została dostarczona implementacja operacji obliczeniowych pozwalających na wykonanie analizy wrażliwości opartej na algorytmie MPSA przedstawionym w poprzednim rozdziale. Zaimplementowane operacje umożliwiają wykonanie zarówno podejścia deterministycznego jak i stochastycznego Podejście deterministyczne W systemie zaadoptowana została implementacja eksperymentu z pracy [4]. Kod operacji utworzonych w tej pracy został przystosowany do wymogów architektury systemu. Ich sygnatury i funkcjonalność nie zmieniły się. Operacje obliczeniowe zostały podzielone na dwa moduły: Mathematica i ODESolver. W pierwszym module znajdują się operacje wykorzystujące w swym działaniu pakiet Mathematica[30]. W drugim zgromadzono kod wykonujący symulacje za pomocą programu ODESolver[20] Operacje Poniżej przedstawię listę operacji wraz z krótkim opisem ich działania i implementacji. Są to zaadoptowane operacje pochodzące z aplikacji dostarczonej razem z pracą [4]. Szerszy opis operacji znajduje się w podrozdziale 1.4 pracy [4]. sampleparams Otrzymuje listę parametrów wraz z zakresami wartości jakie dany parametr może przyjmować. Dla każdego parametru generowane są losowe wartości. Zwracane są wektory wartości parametrów utworzone poprzez połączenie wszystkich możliwych wygenerowanych wartości (każdy z każdym). Metodę web service u powiązaną z tą operacją obsługuje klasa SampleParamsMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie SampleParamsWorker. simulate Wykonuje symulacje modelu za pomocą programu ODESolver[20]. Wejściem metody jest plik w formacie SBML[15]. Zwracana jest tzw. trajektoria czyli lista wartości stężenia poszczególnych elementów modelu w różnych punktach czasowych. Metodę web service u powiązaną z tą operacją obsługuje klasa SimulateMessage. Operacja zaimplementowana jest w podprojekcie odesolver w klasie SimulateWorker. plottrajectories Zadaniem operacji jest narysowanie wykresu na podstawie dostarczonych w parametrze danych. Do rysowania wykresu używany jest pakiet Mathematica. Metodę web service u powiązaną z tą operacją obsługuje klasa PlotTrajectoriesMessage. 25

28 Operacja zaimplementowana została w klasie PlotTrajectoriesWorker podprojektu mathematica. selectobservables Zadaniem operacji jest przekształcenie wyników symulacji do postaci, która faktycznie jest obserwowana. Na przykład w eksperymencie możliwe jest jedynie mierzenie łącznego stężenia kilku substancji. W celu porównania wyników symulacji z wynikami tego eksperymentu należy przekształcić stężenia substancji na sumę ich stężeń. Operacja ta odpowiada właśnie za taką konwersję. Aktualnie operacja działa identycznościowo. Metodę web service u powiązaną z tą operacją obsługuje klasa SelectObservablesMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie SelectObservablesWorker. calctrajectoriesdistance Operacja oblicza różnicę pomiędzy dwiema trajektoriami jako błąd średniokwadratowy. Metodę web service u powiązaną z tą operacją obsługuje klasa CalcTrajectoriesDistMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie CalcTrajectoriesDistWorker. selecttreshold Operacja na podstawie dostarczonych danych (listy liczb rzeczywistych) oblicza wartość progową, jako medianę wszystkich liczb z listy. Metodę web service u powiązaną z tą operacją obsługuje klasa SelectThresholdMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie SelectThresholdWorker. classifysamples Operacja dzieli zbiory trajektorii na grupy akceptowalną i nieakceptowalną. Podział przeprowadzany jest na podstawie podanej wartości progowej. Metodę web service u powiązaną z tą operacją obsługuje klasa ClassifySamplesMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie ClassifySamplesWorker. calcsensitivity Operacja oblicza wrażliwość poszczególnych parametrów i generuje odpowiednie wykresy. W obliczeniach wykorzystywana jest korelacja Pearsona i statystyka Kołmogorowa-Smirnowa. Metodę web service u powiązaną z tą operacją obsługuje klasa SimulateMessage. Operacja zaimplementowana jest w podprojekcie mathematica w klasie SimulateWorker Przepływ czynności algorytmu MPSA Rysunek 3.1 przedstawia przepływ czynności, napisany w programie Taverna, realizujący wykonanie deterministycznego podejścia do algorytmu MPSA. Procesory oznaczone kolorem jasnoniebieskim przechowują stałe. Procesor ModelURL przechowuje ścieżkę do pliku z modelem, procesory Simulate simtp i Simulate simt agregują stałe parametryzujące symulacje, a procesory ObservablesFormula i ObservablesNames parametry procesora SelectObservables. Procesory oznaczone kolorem fioletowym wywołują metody web service ów. Kolor pomarańczowy symbolizuje procesory wykorzystujące Bean- Shell, zaś kolor niebieski procesor wykonujący wbudowaną w Tavernę operację na plikach. Wyjścia przepływu umieszczone są na dole rysunku i oznaczone są jasnoniebieskim kolorem z zielonym trójkątem. Procesor getsbmlstring wczytuje zawartość modelu ze ścieżki podanej w parametrze wejściowym i zwraca treść pliku jako napis. Napis ten jest wejściem procesorów GetParamList, setparams i SimulateOrginalModel. Procesor GetParamsList pobiera z modelu listę parametrów. Wykorzystywana jest tu biblioteka libsbml[2] (biblioteka ta wspierana jest jedynie przez Tavernę 1.7, w wersji

29 Rysunek 3.1: Przepływ czynności realizujący wykonanie deterministycznego podejścia do algorytmu MPSA nie jest ona już dostępna). W procesorach selectparams i selectparamsrange użytkownik proszony jest o wybór parametrów i określenie zasięgu przyjmowanych przez parametry wartości. Następnie wywoływany jest procesor SampleParams generujący zbiory wartości parametrów na podstawie zakresów wartości. W kolejnym kroku wykonywana jest pętla po wszystkich wartościach ze zbioru pochodzącego z poprzedniej operacji. Wewnątrz procesora setparams wartości parametrów podstawiane są do modelu. Procesor SimulateNewModel dokonuje symulacji otrzymanego w poprzednim kroku modelu. Wyniki symulacji filtrowane są za pomocą procesora SelectObsevablesNew. Przefiltrowane wyniki kierowane są do procesora PlotTrajectoriesNew, w którym na ich podstawie rysowane są wykresy. Wykresy te stanowią jedno z wyjść przepływu. 27

30 Równolegle do operacji z poprzedniego akapitu wykonywana jest symulacja niezaburzonego modelu. Model trafia do procesora SimulateOrginalModel. Wyniki symulacji filtrowane są wewnątrz procesora SelectObserveblesOrginal. Również tutaj rysowane są wykresy na podstawie wyników symulacji. Realizuje to procesor PlotTrajectoriesOrginal. Wykres, będący wynikiem działania tego procesora, jest jednym z wyjść przepływu. Przefiltrowane wyniki wszystkich symulacji trafiają do procesora CalcTrajectoriesDistance. Kończy tu się pętla rozpoczęta po wywołaniu procesora setparams. Wewnątrz tego procesora obliczane są odległości pomiędzy poszczególnymi trajektoriami. Odległości te stanowią wejście procesorów SelectTreshold i ClassifySamples. W pierwszym na podstawie odległości obliczana jest wartość progowa. W drugim na podstawie odległości i wartości progowej dokonywana jest klasyfikacja zbiorów wartości pochodzących z procesora SampleParams. Ostatnim krokiem jest wywołanie procesora CalcSensitivity obliczającego wrażliwość parametrów. Procesor zwraca wykresy częstotliwości (wyjście przepływu frequencyplots) oraz obliczoną wrażliwość (wyjście przepływu sensitivity). Przepływ odwołuje się do web service u wdrożonego na serwerze Centrum Doskonałości BioExploratorium[5] (opis wdrożenia znajduje się w dodatku E). Plik z przepływem dołączony jest na płycie CD w katalogu workflows źródeł Eksperyment Poniżej powtórzę eksperyment wykonany w pracy [4]. Eksperyment opiera się na doświadczeniu zawartym w pracy [7]. Jest to wykonanie analizy wrażliwości parametrów dla prostego modelu reakcji enzymatycznej. Model przedstawiony jest na rysunku 3.2. Definicja modelu Rysunek 3.2: Model reakcji enzymatycznej zapisana jest w formacie SBML [15]. Plik z modelem znajduje się na dołączonej płycie CD. Dokonamy analizy wrażliwości modelu na zaburzanie parametrów k1 i k3. W tym celu wykonamy przepływ opisany w poprzednim podrozdziale. Przepływ należy odpowiednio sparametryzować. Poniższe parametry podaję za [4]. 28

31 Parametr Wartość Simulate simt 10 Simulate simtp 24 selectparams subset custom selectparamsrange defaultn 2 selectparamsrange defaultlowerbound - selectparamsrange defaultupperbound - selectparamsrange usedefault - SelectThreshold method mean SampleParams distribution uniform SampleParams method MC CARTESIAN SampleParams nr 20 SampleParams scale LIN CalcSensitivity generateplots true CalcTrajectoriesDistance distancefunction meansquare SelectObservablesNew method custom ObservablesFormulas $m1,$m2,$m3,$m4 ObservablesNames substrate,enzyme,es-complex,product Wyniki Wykonanie eksperymentu, na komputerze wyposażonym w 8 GB pamięci RAM i w 4-rdzeniowy procesor (Dual-Core AMD Opteron(tm) Processor 2218 ) o mocy 2.6 GHz, zajmuje około 40 minut. Na wyjściach przepływu zwracane są: wykresy trajektorii oryginalnego i zaburzonego modelu (400 wykresów, dla każdego zaburzenia parametrów jeden wykres), obliczona wrażliwość parametrów i wykresy częstotliwości. Na listingu 3.1 przedstawiony jest wynik obliczeń wrażliwości parametrów. 1 <paramrankinglist> Listing 3.1: sensitivity.xml 2 <paramranking s e n s i t i v i t y F u n c t i o n= Kolmogorov Smirnov > 3 <paramlist> 4 <param lowerbound= name= k r e a c t i o n= k1 5 s e n s i t i v i t y= upperbound= value= /> 7 <param lowerbound= name= k r e a c t i o n= k3 8 s e n s i t i v i t y= upperbound= value= /> 10 </ paramlist> 11 </ paramranking> 12 <paramranking s e n s i t i v i t y F u n c t i o n= Pearson c o r r e l a t i o n > 13 <paramlist> 14 <param lowerbound= name= k r e a c t i o n= k1 15 s e n s i t i v i t y= upperbound= value= /> 17 <param lowerbound= name= k r e a c t i o n= k3 18 s e n s i t i v i t y= upperbound= value= /> 20 </ paramlist> 21 </ paramranking> 22 </ paramrankinglist> Wyniki należy interpretować następująco. Model jest wrażliwy na zaburzenia parametru, gdy wynik testu Kołmogorowa-Smironowa jest wysoki, a wynik korelacja Pearsona niski. Z 29

32 wyników z listingu 3.1 wynika, że model jest bardziej wrażliwy na zaburzenia parametru k3, niż na zaburzenia parametru k1. W pracy [7] dla parametrów k1 i k3 otrzymano wrażliwości, mierzone za pomocą korelacji Perasona, równe odpowiednio i Zatem nasz eksperyment nie potwierdził wyników z tej pracy. Na rysunku 3.3 załączone zostały wykresy częstotliwości będące wynikiem przeprowadzonego eksperymentu. Dla porównania, na rysunku 3.4 załączone zostały wykresy pochodzące z pracy [7]. Rysunek 3.3: Wykresy częstotliwości będące wynikiem eksperymentu. Rysunek 3.4: Wykresy częstotliwości pochodzące z pracy [7]. 30

33 3.2. Podejście stochastyczne Do zobrazowania działania systemu w podejściu stochastycznym przedstawię eksperyment polegający na weryfikacji modelu opartego o szlak sygnałowy MAPK. Dane do eksperymentu pochodzą z [21]. Do wykonania eksperymentu konieczne było dodanie nowych operacji obliczeniowych. Zaimplementowane są one w dwóch modułach: Mathematica i Prism. W pierwszym module znajdują się operacje rysujące wykresy. W drugim zgromadzono kod wykonujący symulacje za pomocą programu PRISM Model Za model eksperymentu przyjmujemy model zdefiniowany na stronie [21]. Opisuje on szlak sygnałowy kinazy MAP (ang. Mitogean-Activated Protien). Szlak ten odpowiedzialny jest między innymi za wzrost wielu typów komórek. Składa się on z molekuł: kinazy kinazy MAPK (MAPKKK), kinazy MAPK (MAPKK) i MAPK. Szlak inicjalizowany jest poprzez fosforylację MAPKKK. W wyniku tego aktywowany jest MAPKK poprzez fosforylację dwóch reszt serynowych. Następnie aktywowany jest MAPK poprzez fosforylację reszt treoniny i tyrozyny. Szlak może zostać wywołany poprzez między innymi czynniki wzrostu, neurotransmitery i cytokiny. Schemat szlaku przedstawiony jest na rysunku 3.5. Rysunek 3.5: Model szlaku sygnałowego MAPK Przy definiowaniu modelu zastosowano podejście populacyjne. Zapobiega to problemowi eksplozji przestrzeni stanów. Każdy podstawowy element szlaku sygnałowego modelowany jest poprzez osobny moduł. Reakcje pomiędzy elementami szlaku modelowane są za pomocą zsynchronizowanych komend modułów. W modelu zawarte zostało pięć funkcji nagrody: activated - przypisuje każdemu stanowi ilość aktywowanego MAPK, activated squared - przypisuje każdemu stanowi kwadrat ilości aktywowanego MAPK (potrzebne do obliczenia wariancji i odchylenia standardowego), percentage - przypisuje każdemu stanowi procent aktywowanego MAPK, reactions - przypisuje nagrodę równą 1 wszystkim tranzycjom odpowiadającym reakcjom pomiędzy MAPK i MAPKK, time - przypisuje każdemu stanowi nagrodę równą 1. 31

34 Definicja modelu w PRISMie dołączona jest w załączniku D Specyfikacja W eksperymencie będą badane następujące właściwości: ilość i odchylenie standardowe aktywowanego MAPK w czasie t, oczekiwany procent aktywowanego MAPK w czasie t, oczekiwana liczba reakcji pomiędzy MAPK i MAPKK w czasie t, oczekiwany czas do aktywowania wszystkich cząsteczek MAPK. Własności te można zapisać za pomocą logiki CSL następująco: 1 const double t ; // time bound 2 Listing 3.2: specification.csl 3 // the expected amount o f a c t i v a t e d MAPK at time t 4 R{ a c t i v a t e d }=?[ I=t ] 5 // the expected amount squared o f a c t i v a t e d MAPK at time t ( used to c a l c u l a t e 6 // standard d e v i a t i o n ) 7 R{ a c t i v a t e d s q u a r e d }=?[ I=t ] 8 // the expected percentage o f a c t i v a t e d MAPK at time t 9 R{ percentage }=?[ I=t ] 10 // the expected number o f r e a c t i o n s between MAPK and MAKK by time t 11 R{ r e a c t i o n s }=?[ C<=t ] 12 // the expected time u n t i l a l l MAPK are a c t i v a t e d at the same time i n s t a n t 13 R{ time }=?[F kpp=n ] Operacje Do wykonania symulacji z użyciem PRISMa konieczne było zaimplementowanie poniższych operacji. simulateprism operacja wykonująca symulacje za pomocą programu PRISM. Operacja ma charakter synchroniczny(patrz rozdział 1.3). Jako parametr przyjmowana jest: definicja modelu w języku PRISMa, definicja specyfikacji z wykorzystaniem logiki CSL, lista par: stała i niepusty zbiór przyjmowanych przez stałą wartości. Spośród wartości stałych tworzy się wszystkie możliwe kombinacje par stała-wartość. Model i specyfikacja wymagają nadania wartości dla wszystkich zdefiniowanych w nich stałych. Z kombinacji par stała-wartość konstruuje się unikalne listy nadające wartości stałym modelu i specyfikacji. Dla każdej takiej listy wykonywana jest symulacja. Symulacje mogą być wykonywane niezależnie. Dla każdej symulacji tworzony jest więc osobny komunikat zawierający definicję modelu, treść specyfikacji i listę par stała-wartość. Operacja zwraca listę wyników poszczególnych symulacji. Na wynik symulacji składa się lista wartości stałych wykorzystanych w symulacji i lista wyników każdej formuły ze specyfikacji. Implementacja operacji znajduje się w klasie SimulatePrismMessage znajdującej się w module webservice oraz wewnątrz klasy SimulatePrismWorker w module prism. 32

35 asyncsimulateprism jest to asynchroniczna wersja operacji simulateprism (patrz rozdział 1.3). Symulacje z wykorzystaniem programu PRISM są czasochłonne. Operacje synchroniczne nie powinny trwać dłużej niż 5 minut. Po czasie oczekiwania na wyniki dłuższym niż 5 minut zwracany jest wyjątek przekroczenia czasu oczekiwania. Operacja stosowana jest więc do długotrwałych symulacji. Operacja przyjmuje dodatkowy parametr będący adresem , pod który należy wysłać skompletowane wyniki. Wyniki zwracane em są w identycznym formacie jak wyniki operacji synchronicznej. Operacja zaimplementowana jest z wykorzystaniem klas implementujących operację simulateprism. Dodatkowo do kompletowania wyników wykorzystywana jest klasa SimulatePrismComputation modułu register. plotchart zadaniem operacji jest rysowanie wykresów. Wspierane są wykresy dwuwymiarowe i trójwymiarowe. Jako parametry przyjmowane są: jedna lub dwie etykiety osi co najmniej jedna etykieta wykresów zbiór punktów wykresów Każdy punkt składa się z listy etykietowanych wartości. Na podstawie etykiet osi oraz wykresów wybiera się odpowiednie wartości z punktów i buduje się na ich podstawie wykresy. Wynik operacji to binarny plik zawierający obrazek z wykresem w formacie PNG. Operacja zaimplementowana jest wewnątrz klasy PlotChartMessage znajdującej się w module webservice oraz w klasie PlotCharWorker w module mathematica Przepływ czynności Eksperyment realizowany jest z użyciem dwóch przepływów. Pierwszy służy do wywołania w sposób asynchroniczny symulacji modelu. Drugi służy do rysowania wykresów na podstawie zwróconych poprzez wyników obliczeń. Podział eksperymentu na dwa przepływy był konieczny ze względu na czasochłonność wykonywania symulacji. Zastosowanie operacji synchronicznej możliwe byłoby jedynie dla mało skomplikowanych symulacji (po 5 minutach trwania operacji zwracany jest bowiem wyjątek przekroczenia czasu oczekiwania). Na dołączonej płycie znajduje się również synchroniczna wersja przepływu. Omówmy najpierw przepływ wykonujący asynchronicznie symulacje. Procesory formulapath, modelpath, , constants gromadzą stałe. Są to odpowiednio: ścieżka do pliku z definicją specyfikacji, ścieżka do pliku z definicją modelu, adres , lista stałych modelu i formuły. Procesory getformula i getmodel na podstawie ścieżek wczytują odpowiednie pliki. Procesor setconstantvalue prosi użytkownika o określenie wartości stałych modelu i formuły. Zadaniem procesora simulateprismparamsxml jest skumulowanie wszystkich parametrów wywołania procesora asyncsimulateprism. Ostatni procesor wywołuje operację web service u. Kończy to działanie przepływu. Przepływ rysujący wykresy ma jedno wejście. Należy w nim podać plik z wynikami odesłany przez . Procesor calcstandarddeviation oblicza odchylenie standardowe wyników z etykietą activated. Procesor selectresult pozwala na wybranie spośród wyników danych do wykresu. Procesory plotchartparamsxml, plotchartresultxml i Decode base64 to byte mają charakter pomocniczy i służą do odpowiedniej konwersji parametrów i wyników. Procesor plotchart wywołuje poprzez web service operację plotchart. Jej wynikiem jest wykres przekazanych w parametrze danych. 33

36 Rysunek 3.6: Przepływy symulacji z wykorzystaniem PRISMa, po lewej wywołujący asynchroniczną symulację modelu, po prawej rysujący wykresy na podstawie wyników Eksperyment Powtórzę tutaj eksperyment pochodzący z [21]. Polegać on będzie na wykonaniu przepływu czynności z poprzedniego rozdziału. Modelem eksperymentu będzie model opisany w podrozdziale Model wyrażony za pomocą języka PRISM znajduje się w załączniku D. Weryfikacji modelowej będziemy dokonywać względem specyfikacji opisanej w podrozdziale Model i specyfikacja posiadają dwa parametry N i t. W eksperymencie parametr N przyjmuje wartości 1, 2, 3, 4, zaś parametr t przyjmuje wartości 1, 2,..., Wyniki Eksperyment zwraca dwa rodzaje wyników. Pierwszym są wartości formuł wyliczone w trakcie symulacji modelu z różnymi parametrami. Drugim są wykresy tych wartości. Dalej załączam kilka wykresów, będących wynikami eksperymentu. Na rysunku 3.7 przedstawiono wyniki formuły R{"activated"}=?[ I=t ] dla parametru N równego 4. Formuła ta wylicza oczekiwaną liczbę aktywowanych molekuł MAPK w czasie t. Dodatkowo umieszczono wykresy wartości różniących się o odchylenie standardowe od badanej własności. Dla porównania zamieszczono wyniki pochodzące z [21]. Rysunek 3.8 przedstawia wykres tej samej formuły dla nieustalonego parametru N. Na rysunku 3.9 umieszczo- 34

37 Rysunek 3.7: Oczekiwana liczba aktywowanych molekuł MAPK w czasie t dla parametru N równego 4. U góry wynik eksperymentu, na dole wykres pochodzący z [21]. 35

38 Rysunek 3.8: Oczekiwana liczba aktywowanych molekuł MAPK w czasie t dla nieustalonego parametru N. 36

39 Rysunek 3.9: Odchylenie standardowe liczby aktywowanych molekuł MAPK. U góry wynik eksperymentu, na dole wykres pochodzący z [21]. 37

40 Rysunek 3.10: Wykres oczekiwanego procentowego udziału aktywowanych molekuł MAPK w czasie t. U góry wynik eksperymentu, na dole wykres pochodzący z [21]. 38

41 Rysunek 3.11: Oczekiwana liczba reakcji pomiędzy MAPK i MAPKK w czasie t. U góry wynik eksperymentu, na dole wykres pochodzący z [21]. 39

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: 209216. Aukcjomat

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: 209216. Aukcjomat Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki Paweł Parys Nr albumu: 209216 Aukcjomat Praca licencjacka na kierunku INFORMATYKA w zakresie INFORMATYKA Praca wykonana pod kierunkiem

Bardziej szczegółowo

Webowy generator wykresów wykorzystujący program gnuplot

Webowy generator wykresów wykorzystujący program gnuplot Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Marcin Nowak nr albumu: 254118 Praca inżynierska na kierunku informatyka stosowana Webowy generator wykresów wykorzystujący

Bardziej szczegółowo

Zaawansowane narzędzia programowania rozproszonego

Zaawansowane narzędzia programowania rozproszonego Zaawansowane narzędzia programowania rozproszonego Karol Gołąb karol.golab@tls-technologies.com 28 listopada 2001 1 Streszczenie Omówienie i porównanie popularnych standardów mechanizmów komunikacyjnych:

Bardziej szczegółowo

Architektury Usług Internetowych. Laboratorium 2. Usługi sieciowe

Architektury Usług Internetowych. Laboratorium 2. Usługi sieciowe Architektury Usług Internetowych Laboratorium 2. Usługi sieciowe Wstęp Celem laboratorium jest zapoznanie się z modelem usług sieciowych na przykładzie prostego serwera Apache Axis2. Apache Axis2 Apache

Bardziej szczegółowo

Uniwersytet Mikołaja Kopernika w Toruniu. Profilowanie ruchu sieciowego w systemie GNU/Linux

Uniwersytet Mikołaja Kopernika w Toruniu. Profilowanie ruchu sieciowego w systemie GNU/Linux Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ferliński Nr albumu: 187386 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Tworzenie i obsługa wirtualnego laboratorium komputerowego

Tworzenie i obsługa wirtualnego laboratorium komputerowego Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Michał Ochociński nr albumu: 236401 Praca magisterska na kierunku informatyka stosowana Tworzenie i obsługa wirtualnego

Bardziej szczegółowo

Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki

Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki Tomasz Pawłowski Nr albumu: 146956 Praca magisterska na kierunku

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie

Bardziej szczegółowo

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Narzędzia i aplikacje Java EE Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Niniejsze opracowanie wprowadza w technologię usług sieciowych i implementację usługi na platformie Java EE (JAX-WS) z

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

Galileo - encyklopedia internetowa Plan testów

Galileo - encyklopedia internetowa Plan testów Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................

Bardziej szczegółowo

SCENARIUSZ LEKCJI. TEMAT LEKCJI: Zastosowanie średnich w statystyce i matematyce. Podstawowe pojęcia statystyczne. Streszczenie.

SCENARIUSZ LEKCJI. TEMAT LEKCJI: Zastosowanie średnich w statystyce i matematyce. Podstawowe pojęcia statystyczne. Streszczenie. SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH Autorzy scenariusza:

Bardziej szczegółowo

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa 1 Java Wprowadzenie 2 Czym jest Java? Język programowania prosty zorientowany obiektowo rozproszony interpretowany wydajny Platforma bezpieczny wielowątkowy przenaszalny dynamiczny Rozumiana jako środowisko

Bardziej szczegółowo

Definicje. Algorytm to:

Definicje. Algorytm to: Algorytmy Definicje Algorytm to: skończony ciąg operacji na obiektach, ze ściśle ustalonym porządkiem wykonania, dający możliwość realizacji zadania określonej klasy pewien ciąg czynności, który prowadzi

Bardziej szczegółowo

Szpieg 2.0 Instrukcja użytkownika

Szpieg 2.0 Instrukcja użytkownika Szpieg 2.0 Instrukcja użytkownika Spis treści: Wstęp: 1. Informacje o programie 2. Wymagania techniczne Ustawienia: 3. Połączenie z bazą danych 4. Konfiguracja email 5. Administracja Funkcje programu:

Bardziej szczegółowo

EJB 3.0 (Enterprise JavaBeans 3.0)

EJB 3.0 (Enterprise JavaBeans 3.0) EJB 3.0 (Enterprise JavaBeans 3.0) Adrian Dudek Wirtualne Przedsiębiorstwo 2 Wrocław, 1 czerwca 2010 Plan prezentacji 1 Wprowadzenie Cel prezentacji Czym jest EJB 3.0? Historia 2 3 Cel prezentacji Wprowadzenie

Bardziej szczegółowo

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail 1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce

Bardziej szczegółowo

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r.

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Stworzenie platformy internetowej na potrzeby projektu. 1 Wykonanie portalu internetowego na potrzeby e-usługi, obejmującego

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Studia podyplomowe dla nauczycieli INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Przedmiot JĘZYKI PROGRAMOWANIA DEFINICJE I PODSTAWOWE POJĘCIA Autor mgr Sławomir Ciernicki 1/7 Aby

Bardziej szczegółowo

Program dla praktyki lekarskiej

Program dla praktyki lekarskiej Program dla praktyki lekarskiej ErLab Instrukcja konfiguracji i obsługi Spis Treści 1. Wstęp... 2 2. Konfiguracja... 3 2.1. Serwer... 3 2.2. Laboratorium... 3 2.3. Punkt pobrań... 4 3. Wysyłanie skierowania...

Bardziej szczegółowo

TECHNOLOGIA OBSŁUGI KONTRAKTÓW INFORMACJA O AKTUALIZACJI SYSTEMU ISO 9001:2008 Dokument: Raport Numer: 10/2016 Wydanie: 2008-04-22 Waga: 90

TECHNOLOGIA OBSŁUGI KONTRAKTÓW INFORMACJA O AKTUALIZACJI SYSTEMU ISO 9001:2008 Dokument: Raport Numer: 10/2016 Wydanie: 2008-04-22 Waga: 90 SYSTEM INFORMATYCZNY KS-SOMED'2016 WERSJA Nr 2016.01.0.02 z dnia 2016-03-31 Raport Nr 10/2016 MODUŁ OPIS ZMIAN, MODYFIKACJI i AKTUALIZACJI M12 ZLECENIA 1. Ustawiono datę dla opcji Pozwól na rejestrowanie

Bardziej szczegółowo

Instrukcja instalacji i obsługi programu Szpieg 3

Instrukcja instalacji i obsługi programu Szpieg 3 COMPUTER SERVICE CENTER 43-300 Bielsko-Biała ul. Cieszyńska 52 tel. +48 (33) 819 35 86, 819 35 87, 601 550 625 Instrukcja instalacji i obsługi programu Szpieg 3 wersja 0.0.2 123 SERWIS Sp. z o. o. ul.

Bardziej szczegółowo

KURIER BY CTI. Instrukcja do programu DATA 16.09.2014. Informatycznej Zygmunt Wilder w Gliwicach WERSJA 2014.1 mgr Katarzyna Wilder DLA DPD

KURIER BY CTI. Instrukcja do programu DATA 16.09.2014. Informatycznej Zygmunt Wilder w Gliwicach WERSJA 2014.1 mgr Katarzyna Wilder DLA DPD KURIER BY CTI DLA DPD Instrukcja do programu DATA 16.09.2014 PRODUCENT Centrum Technologii Informatycznej Zygmunt Wilder w Gliwicach WERSJA 2014.1 AUTOR mgr Katarzyna Wilder 1. Opis Program Kurier DPD

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel"

Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny doręczyciel Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel" dn.24.09.2009 r. Dokument opisuje przykładowy program doręczający dokumenty na

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

UML cz. III. UML cz. III 1/36

UML cz. III. UML cz. III 1/36 UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

3.1. Na dobry początek

3.1. Na dobry początek Klasa I 3.1. Na dobry początek Regulamin pracowni i przepisy BHP podczas pracy przy komputerze Wykorzystanie komputera we współczesnym świecie Zna regulamin pracowni i przestrzega go. Potrafi poprawnie

Bardziej szczegółowo

Jednolite zarządzanie użytkownikami systemów Windows i Linux

Jednolite zarządzanie użytkownikami systemów Windows i Linux Uniwersytet Mikołaja Kopernika Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Paweł Gliwiński Nr albumu: 168470 Praca magisterska na kierunku Informatyka Jednolite

Bardziej szczegółowo

Bezpieczeństwo systemów i lokalnej sieci komputerowej

Bezpieczeństwo systemów i lokalnej sieci komputerowej Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Jan Werner Bezpieczeństwo systemów i lokalnej sieci komputerowej Praca magisterska

Bardziej szczegółowo

Diagram wdrożenia. Rys. 5.1 Diagram wdrożenia.

Diagram wdrożenia. Rys. 5.1 Diagram wdrożenia. Diagram wdrożenia Zaprojektowana przez nas aplikacja bazuje na architekturze client-server. W tej architekturze w komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia

Bardziej szczegółowo

KS-ZSA. Mechanizm centralnego zarządzania rolami

KS-ZSA. Mechanizm centralnego zarządzania rolami KS-ZSA Mechanizm centralnego zarządzania rolami 1. Opis funkcjonalności W KS-ZSA zostaje udostępniona funkcji centralnego zarządzania rolami. W samym programie jest możliwość tworzenia centralnej roli

Bardziej szczegółowo

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej.

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Dział Zagadnienia Wymagania podstawowe Wymagania ponadpodstawowe Arkusz kalkulacyjny (Microsoft Excel i OpenOffice) Uruchomienie

Bardziej szczegółowo

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia ZP/ITS/11/2012 Załącznik nr 1a do SIWZ ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia Przedmiotem zamówienia jest: Przygotowanie zajęć dydaktycznych w postaci kursów e-learningowych przeznaczonych

Bardziej szczegółowo

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC.

Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC. 1 Moduł OPC Moduł OPC pozwala na komunikację z serwerami OPC pracującymi w oparciu o model DA (Data Access). Dzięki niemu można odczytać stan obiektów OPC (zmiennych zdefiniowanych w programie PLC), a

Bardziej szczegółowo

Międzyplatformowy interfejs systemu FOLANessus wykonany przy użyciu biblioteki Qt4

Międzyplatformowy interfejs systemu FOLANessus wykonany przy użyciu biblioteki Qt4 Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Agnieszka Holka Nr albumu: 187396 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

D:\DYDAKTYKA\ZAI_BIS\_Ćwiczenia_wzorce\04\04_poprawiony.doc 2009-lis-23, 17:44

D:\DYDAKTYKA\ZAI_BIS\_Ćwiczenia_wzorce\04\04_poprawiony.doc 2009-lis-23, 17:44 Zaawansowane aplikacje internetowe EJB 1 Rozróżniamy dwa rodzaje beanów sesyjnych: Stateless Statefull Celem tego laboratorium jest zbadanie różnic funkcjonalnych tych dwóch rodzajów beanów. Poszczególne

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych zbudowanym w oparciu

Bardziej szczegółowo

1 Moduł Modbus ASCII/RTU 3

1 Moduł Modbus ASCII/RTU 3 Spis treści 1 Moduł Modbus ASCII/RTU 3 1.1 Konfigurowanie Modułu Modbus ASCII/RTU............. 3 1.1.1 Lista elementów Modułu Modbus ASCII/RTU......... 3 1.1.2 Konfiguracja Modułu Modbus ASCII/RTU...........

Bardziej szczegółowo

Algorytm. a programowanie -

Algorytm. a programowanie - Algorytm a programowanie - Program komputerowy: Program komputerowy można rozumieć jako: kod źródłowy - program komputerowy zapisany w pewnym języku programowania, zestaw poszczególnych instrukcji, plik

Bardziej szczegółowo

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

Bardziej szczegółowo

Budowa i oprogramowanie komputerowych systemów sterowania. Laboratorium 4. Metody wymiany danych w systemach automatyki DDE

Budowa i oprogramowanie komputerowych systemów sterowania. Laboratorium 4. Metody wymiany danych w systemach automatyki DDE Budowa i oprogramowanie komputerowych systemów sterowania Laboratorium 4 Metody wymiany danych w systemach automatyki DDE 1 Wprowadzenie do DDE DDE (ang. Dynamic Data Exchange) - protokół wprowadzony w

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to przeznaczone jest dla właścicieli sklepów internetowych opartych

Bardziej szczegółowo

Wprowadzenie do projektu QualitySpy

Wprowadzenie do projektu QualitySpy Wprowadzenie do projektu QualitySpy Na podstawie instrukcji implementacji prostej funkcjonalności. 1. Wstęp Celem tego poradnika jest wprowadzić programistę do projektu QualitySpy. Będziemy implementować

Bardziej szczegółowo

Dokumentacja programu. Instrukcja użytkownika modułu Gabinet Zabiegowy. Zielona Góra 2015-06-18

Dokumentacja programu. Instrukcja użytkownika modułu Gabinet Zabiegowy. Zielona Góra 2015-06-18 Dokumentacja programu Instrukcja użytkownika modułu Gabinet Zabiegowy Zielona Góra 2015-06-18 Głównym celem funkcjonalnym modułu Gabinet zabiegowy jest komunikacja z laboratoriami diagnostycznym w celu

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla WF-Mag

Instrukcja użytkownika. Aplikacja dla WF-Mag Instrukcja użytkownika Aplikacja dla WF-Mag Instrukcja użytkownika Aplikacja dla WF-Mag Wersja 1.0 Warszawa, Kwiecień 2015 Strona 2 z 13 Instrukcja użytkownika Aplikacja dla WF-Mag Spis treści 1. Wstęp...4

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa

Bardziej szczegółowo

enova Systemowe Narzędzia Projektowe

enova Systemowe Narzędzia Projektowe enova Systemowe Narzędzia Projektowe Sebastian Wabnik Spis treści Opis rozwiązania...3 Dostęp do narzędzia...3 Wywoływanie narzędzia...4 Zakładka Logi czasu...4 SQL Stat...5 Zakładka Liczniki...7 Zakładka

Bardziej szczegółowo

Jak ustawić cele kampanii?

Jak ustawić cele kampanii? Jak ustawić cele kampanii? Czym są cele? Jest to funkcjonalność pozwalająca w łatwy sposób śledzić konwersje wygenerowane na Twojej stronie www poprzez wiadomości email wysłane z systemu GetResponse. Mierzenie

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Architektura systemu Architektura systemu System udostępnia dwa kanały dostępu,

Bardziej szczegółowo

Forum Client - Spring in Swing

Forum Client - Spring in Swing Forum Client - Spring in Swing Paweł Charkowski. 0. Cel projektu Celem projektu jest próba integracji Spring Framework z różnymi technologiami realizacji interfejsu użytkownika, oraz jej ocena. Niniejszy

Bardziej szczegółowo

znajdowały się różne instrukcje) to tak naprawdę definicja funkcji main.

znajdowały się różne instrukcje) to tak naprawdę definicja funkcji main. Część XVI C++ Funkcje Jeśli nasz program rozrósł się już do kilkudziesięciu linijek, warto pomyśleć o jego podziale na mniejsze części. Poznajmy więc funkcje. Szybko się przekonamy, że funkcja to bardzo

Bardziej szczegółowo

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED Podręcznik użytkownika Katowice 2010 Producent programu: KAMSOFT S.A. ul. 1 Maja 133 40-235 Katowice Telefon: (0-32) 209-07-05 Fax:

Bardziej szczegółowo

Instrukcja użytkownika. Aplikacja dla Comarch ERP XL

Instrukcja użytkownika. Aplikacja dla Comarch ERP XL Instrukcja użytkownika Aplikacja dla Comarch ERP XL Instrukcja użytkownika Aplikacja dla Comarch ERP XL Wersja 1.0 Warszawa, Listopad 2015 Strona 2 z 12 Instrukcja użytkownika Aplikacja dla Comarch ERP

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Cechy systemu X Window: otwartość niezależność od producentów i od sprzętu, dostępny kod źródłowy; architektura klient-serwer;

Cechy systemu X Window: otwartość niezależność od producentów i od sprzętu, dostępny kod źródłowy; architektura klient-serwer; 14.3. Podstawy obsługi X Window 14.3. Podstawy obsługi X Window W przeciwieństwie do systemów Windows system Linux nie jest systemem graficznym. W systemach Windows z rodziny NT powłokę systemową stanowi

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Koszty dodatkowe w projekcie, administracja i rozliczanie.

Koszty dodatkowe w projekcie, administracja i rozliczanie. Koszty dodatkowe w projekcie, administracja i rozliczanie. Prowadzenie dużych projektów produkcyjno-montażowych w firmie nie zawsze związane jest tylko z kosztami realizacji produkcji tj. kosztami materiałów,

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

1. Opis. 2. Wymagania sprzętowe:

1. Opis. 2. Wymagania sprzętowe: 1. Opis Aplikacja ARSOFT-WZ2 umożliwia konfigurację, wizualizację i rejestrację danych pomiarowych urządzeń produkcji APAR wyposażonych w interfejs komunikacyjny RS232/485 oraz protokół MODBUS-RTU. Aktualny

Bardziej szczegółowo

Współpraca z platformą Emp@tia. dokumentacja techniczna

Współpraca z platformą Emp@tia. dokumentacja techniczna Współpraca z platformą Emp@tia dokumentacja techniczna INFO-R Spółka Jawna - 2013 43-430 Pogórze, ul. Baziowa 29, tel. (33) 479 93 29, (33) 479 93 89 fax (33) 853 04 06 e-mail: admin@ops.strefa.pl Strona1

Bardziej szczegółowo

Modyfikacja algorytmów retransmisji protokołu TCP.

Modyfikacja algorytmów retransmisji protokołu TCP. Modyfikacja algorytmów retransmisji protokołu TCP. Student Adam Markowski Promotor dr hab. Michał Grabowski Cel pracy Celem pracy było przetestowanie i sprawdzenie przydatności modyfikacji klasycznego

Bardziej szczegółowo

Monitorowanie i zarządzanie urządzeniami sieciowymi przy pomocy narzędzi Net-SNMP

Monitorowanie i zarządzanie urządzeniami sieciowymi przy pomocy narzędzi Net-SNMP Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Szymon Klimuk Nr albumu: 187408 Praca magisterska na kierunku Informatyka Monitorowanie

Bardziej szczegółowo

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest internetowemu menadżerowi sprzedaży BaseLinker.

Bardziej szczegółowo

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Akademia MetaPack Uniwersytet Zielonogórski Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Krzysztof Blacha Microsoft Certified Professional Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Agenda:

Bardziej szczegółowo

1 Moduł Modbus ASCII/RTU

1 Moduł Modbus ASCII/RTU 1 Moduł Modbus ASCII/RTU Moduł Modbus ASCII/RTU daje użytkownikowi Systemu Vision możliwość komunikacji z urządzeniami za pomocą protokołu Modbus. Moduł jest konfigurowalny w taki sposób, aby umożliwiał

Bardziej szczegółowo

1 Moduł Inteligentnego Głośnika 3

1 Moduł Inteligentnego Głośnika 3 Spis treści 1 Moduł Inteligentnego Głośnika 3 1.1 Konfigurowanie Modułu Inteligentnego Głośnika........... 3 1.1.1 Lista elementów Modułu Inteligentnego Głośnika....... 3 1.1.2 Konfigurowanie elementu

Bardziej szczegółowo

LEKCJA TEMAT: Zasada działania komputera.

LEKCJA TEMAT: Zasada działania komputera. LEKCJA TEMAT: Zasada działania komputera. 1. Ogólna budowa komputera Rys. Ogólna budowa komputera. 2. Komputer składa się z czterech głównych składników: procesor (jednostka centralna, CPU) steruje działaniem

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,

Bardziej szczegółowo

Część II Wyświetlanie obrazów

Część II Wyświetlanie obrazów Tło fragmentu ABA-X Display jest wyposażony w mechanizm automatycznego tworzenia tła fragmentu. Najprościej można to wykonać za pomocą skryptu tlo.sh: Składnia: tlo.sh numer oznacza numer

Bardziej szczegółowo

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu. AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów

Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów Eksploracja danych Piotr Lipiński Informacje ogólne Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów UWAGA: prezentacja to nie

Bardziej szczegółowo

wersja dokumentu 1.0 data wydania 2008.11.14

wersja dokumentu 1.0 data wydania 2008.11.14 HERMESEDI System elektronicznej wymiany dokumentów w systemie EDI/ECOD wersja dokumentu 1.0 data wydania 2008.11.14 Syriusz sp. z o.o. Rzeszów 2008 SPIS TREŚCI: 1. Przeznaczenie... 3 2. Schemat pracy...

Bardziej szczegółowo

Skanowanie podsieci oraz wykrywanie terminali ABA-X3

Skanowanie podsieci oraz wykrywanie terminali ABA-X3 Skanowanie podsieci oraz wykrywanie terminali ABA-X3 Terminale ABA-X3 od dostarczane od połowy listopada 2010 r. są wyposażane w oprogramowanie umożliwiające skanowanie podsieci w poszukiwaniu aktywnych

Bardziej szczegółowo

Dokumentacja końcowa projektu z ZPR

Dokumentacja końcowa projektu z ZPR Dokumentacja końcowa projektu z ZPR Temat projektu: Prowadzący projekt: Zespół projektowy: Losowe przeszukiwanie stanów dr inż. Robert Nowak Piotr Krysik Kamil Zabielski 1. Opis projektu Projekt ma za

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24 Dokumentacja Użytkownika Systemu Integracja z Okazje.info, Skąpiec, Sklepy24 Wersja 2016 Spis treści 1 INTEGRACJA... 3 2 REJESTRACJA... 4 2.1 OKAZJE.INFO... 4 2.2 SKĄPIEC... 4 2.3 SKLEPY24.PL... 4 3 KONFIGURACJA...

Bardziej szczegółowo

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE Warszawa, 13.09.2013 Nabywca: Rabateo Sp. z o.o. Ul. Tamka38 00-355 Warszawa Tel./fax 22 556 23 45 e-mail: dariusz.urbanski@rabateo.coml Dane oferenta: ZAPYTANIE OFERTOWE W zawiązku z realizacją projektu

Bardziej szczegółowo

Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK.

Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK. FK - EDeklaracje Dokument opisuje sposób postępowania prowadzący do wysłania deklaracji VAT, PIT lub CIT drogą elektroniczną za pomocą funkcji systemu ADA modułu FK. W założeniu przyjęto, iż użytkownik

Bardziej szczegółowo

Hermes EFK Dokumentacja użytkownika. v. 1.0.1.5

Hermes EFK Dokumentacja użytkownika. v. 1.0.1.5 Hermes EFK Dokumentacja użytkownika v. 1.0.1.5 Syriusz sp. z o.o. Rzeszów 2013 Hermes EFK [1.0.1.5] Dokumentacja użytkownika str. 1 Spis treści 1.Główne okno aplikacji...2 2.Zarządzanie klientami...4 3.Konfiguracja

Bardziej szczegółowo

KS-ZSA. Mechanizm aktualizacji kartotek lokalnych w aptece na podstawie zmian w kartotece CKT. Data aktualizacji: 2013-08-29

KS-ZSA. Mechanizm aktualizacji kartotek lokalnych w aptece na podstawie zmian w kartotece CKT. Data aktualizacji: 2013-08-29 KS-ZSA Mechanizm aktualizacji kartotek lokalnych w aptece na podstawie zmian w kartotece CKT Data aktualizacji: 2013-08-29 1. Opis funkcjonalności Funkcjonalność umożliwia obsługiwanie zmian urzędowych

Bardziej szczegółowo

Programowanie współbieżne i rozproszone

Programowanie współbieżne i rozproszone Programowanie współbieżne i rozproszone WYKŁAD 1 dr inż. Literatura ogólna Ben-Ari, M.: Podstawy programowania współbieżnego i rozproszonego. Wydawnictwa Naukowo-Techniczne, Warszawa, 2009. Czech, Z.J:

Bardziej szczegółowo

Stan/zdarzenie Nexo. Zmienne wirtualne. Zdarzenia wirtualne

Stan/zdarzenie Nexo. Zmienne wirtualne. Zdarzenia wirtualne WARUNKI WARUNKI I I ZDARZENIA ZDARZENIA Określają czy pewna zależność logiczna związana ze stanem systemu jest w danej chwili spełniona lub czy zaszło w systemie określone zdarzenie. STAN SYSTEMU: stan

Bardziej szczegółowo