XII International PhD Workshop OWD 2010, October 2010 METODA OCENY EFEKTYWNOŚCI OPROGRAMOWANIA NA ETAPIE JEGO PROJEKTOWANIA

Transkrypt

1 XII International PhD Workshop OWD 2010, October 2010 METODA OCENY EFEKTYWNOŚCI OPROGRAMOWANIA NA ETAPIE JEGO PROJEKTOWANIA PERFORMANCE EVALUATION OF SOFTWARE DURING DESIGN STAGE Arkadiusz Wrzosk, Wojskowa Akademia Techniczna Abstract Software performance estimation should be applied on early stages. Correction of errors in software architecture detected too late can be very expensive. This paper describes an approach based on simulation to performance prediction of software system. Performance is estimated during design stage when software architecture is specified by UML. UML is an industry standard used as a common OO modeling language. Process-oriented simulation model is derived from annotated diagrams: Use Case, Sequence, Activity and Deployment. UML diagrams are annotated using standard UML extensions mechanisms aggregated in performance profile. This profile allows designer to include quantitative information, which are used to build a simulation program. Performance evaluation process can be automated. This paper describes created IBM Software Architect extensions used to automate transformations and run simulation. UML profile, diagrams transformation, and standard plugin extension mechanism were used. Results are reported using Business Intelligence and Reporting Tools (BIRT). This paper describes steps required to evaluate performance using proposed approach. This steps are defined in the context of Rational Unified Process. Performance analysis is a role responsible for performance evaluation. Streszczenie W pracy zaprezentowano metodę badania efektywności oprogramowania na wczesnym etapie jego wytwarzania, jakim jest projektowanie. Zaproponowano podejście umożliwiające przeprowadzenie badań z wykorzystaniem symulacji komputerowej. W ramach pracy opisane zostało narzędzie, pozwalające na przeprowadzenie badań i stanowiące część platformy IBM Rational Software Architect. 1. Wprowadzenie Wczesna ocena poprawności wymagań funkcjonalnych i niefunkcjonalnych jest ważnym aspektem procesu wytwarzania oprogramowania. Szczególne znaczenie mają wymagania niefunkcjonalne takie, jak efektywność czy niezawodność. Poprawienie późno wykrytych błędów w projekcie architektury może być kosztowne. Dlatego ocena parametrów systemu powinna być wykonywana możliwie najwcześniej. W niniejszej pracy opisano metodę oceny architektury na etapie projektowania. Językiem wybranym do zapisu architektury jest Unified Modeling Language (skrót UML). Jest on językiem znormalizowanym, służącym do dokumentowania projektu architektury. Może być stosowany do obrazowania, specyfikowania, tworzenia i dokumentowania artefaktów powstałych podczas procesu budowy systemu informatycznego. Jest on powszechnie akceptowanym i stosowany w środowisku inżynierów. UML dostarcza wygodnych mechanizmów, umożliwiających rozszerzenie jego semantyki. Zbiór rozszerzeń może być agregowany w tzw. profilu. W oparciu o [1] i [4] zaproponowano profil, który jest zbiorem stereotypów i notek umożliwiających uzupełnienie projektu architektury o informacje wymagane do przeprowadzenia badań. Jako technikę oceny projektu architektury zapisanego w języku UML wybrano symulację dyskretno - zdarzeniową. Nie wymaga ona budowy prototypu i pozwala na przeprowadzenie badań na etapie projektowania.. Symulacja umożliwia wyznaczenie ilościowych charakterystyk pracy oraz badanie wpływu zmiany parametrów na charakterystyki systemu, co w przypadku badań architektury pozwala na ocenę i porównanie różnych decyzji podjętych na etapie projektowania. W oparciu o [1] opracowano kroki transformacji modelu architektury oprogramowania 61

2 udokumentowanej z wykorzystaniem języka UML do modelu symulacyjnego. Zaproponowano następujące diagramy UML opisujące architekturę wymagane do jej oceny: przypadków użycia, sekwencji, aktywności, komponentów i wdrożenia. W ramach pracy powstała lista rozszerzeń środowiska Rational Software Architekt wspierająca proces oceny architektury oprogramowania. Opisana w pracy metoda ma zastosowanie w przypadku badań własności oprogramowania modelowanego z wykorzystaniem metod obiektowych. Została ona opisana w kontekście metodyki RUP i powinna stanowić kroki dyscypliny analizy i projektowania. 2. Transformacja projektu architektury do modelu symulacyjnego Niestety w obecnej chwili nie istnieje język umożliwiający modelowanie dowolnej dziedziny systemu. Dlatego twórcy języka UML zapewnili możliwość kontrolowanego rozszerzania jego notacji. W celu modelowania dziedziny badania efektywności systemów zdefiniowany został profil UML. Umożliwia on dodanie do diagramów informacji niezbędnych do przeprowadzenia badań z wykorzystaniem symulacji. Na poniższym rysunku przedstawiono, na jakie elementy modelu symulacyjnego będą transformowane poszczególne diagramy. Diagramy UML Przypadków użycia Wdrożenia Komponentów Aktywności Stereotypy Model symulacyjny Obciążenie Zasoby Komponenty Akcje Parametry Rys. 1. Mapowanie elementów UML na model symulacyjny Fig. 1. UML diagrams to simulation model mapping 2.1 Adnotacje UML Obciążenie systemu modelowane jest z wykorzystaniem diagramów przypadków użycia. Aktorzy reprezentują strumień napływających do systemu zgłoszeń. W pracy zdefiniowano dwa typy strumieni. Skończony strumień zgłoszeń i nieskończony strumień zgłoszeń. W skończonym strumieniu zgłoszeń, każde zgłoszenie po zakończeniu scenariusza, zanim ponownie uruchomi kolejny, spędza określony czas poza systemem. Skończony strumień zgłoszeń definiujemy nadając aktorowi stereotyp <<ClosedWorkload>>. Wielkość populacji definiowana jest atrybutem population, natomiast rozkład czasu spędzonego poza systemem przez atrybut extdelay. W nieskończonym strumieniu zgłoszenia pojawiają się co losowy czas. Aby zdefiniować strumień zamknięty aktorowi należy nadać stereotyp <<OpenWorkload>>. Rozkład czasu pomiędzy kolejnymi zgłoszeniami definiujemy z wykorzystaniem atrybutu occurence. Przypadki użycia (skrót PU) reprezentują zbiór scenariuszy, które są symulowane po nadejściu zgłoszenia. Dodatkowo do asocjacji aktora z PU dodano informację o liczbie wykonań PU (atrybut executions stereotypu <<Transition>>), co umożliwia szacowanie prawdopodobieństwa jego uruchomienia. * * Rys. 2. Diagram przypadków użycia z adnotacjami Fig.2. Annotated Use Case diagram Diagramami, które zawierają informacje o scenariuszach, są diagramy interakcji. W proponowanym podejściu wykorzystane zostały diagramy sekwencji. W prawdzie służą one do pozyskiwania informacji o klasach, ich metodach i powiązaniach między nimi, ale zawierają również informacje o kolejnych krokach scenariusza PU. Do problemu uzupełnienia diagramów o informacje wymagane do przeprowadzenia badań, możemy podejść w dwojaki sposób. Możemy wkomponować informacje w diagramy sekwencji, bądź utworzyć na podstawie diagramów sekwencji, diagramy aktywności i dopiero na nie nanieść potrzebne adnotacje. Ze względu na to, że stereotypy wnoszą na diagram informacje dodatkowe, wybrano podejście drugie, tj. generacja diagramów aktywności na podstawie diagramów sekwencji. Dzięki temu, użytkownik dokumentacji nie będzie miał problemów z jej czytelnością. Aktywności na utworzonych diagramach reprezentują żądanie dostępu do zasobu. Podstawowym typem aktywności jest akcja prosta, reprezentująca krok obliczeniowy i związana z żądaniem wykorzystania zasobu aktywnego. W celu zdefiniowania takiej akcji do aktywności należy dodać stereotyp <<SimpleAction>>. Podstawowym atrybutem tej akcji jest atrybut demand, który definiuje czas żądania dostępu do zasobu aktywnego. Dodatkowo może ona przeprowadzić dowolne obliczenia zanim zażąda dostępu do zasobów (atrybut delay) oraz może być wykonana wielokrotnie, w określonych odstępach czasu (atrybuty: repetitions, interval). Kolejnym typem akcji jest akcja informująca o zakończeniu wywołania akcji prostej, która jest z nią powiązana (stereotyp <<CommStep>>). Ostatnimi typami akcji są akcje związane z alokacją i zwalnianiem zasobów pasywnych. Definiujemy je * 62

3 z wykorzystaniem stereotypów: <<AcquireAction>> oraz <<ReleaseAction>>. Podstawowym atrybutem tych akcji jest atrybut quantity, który w zależności od typu akcji, reprezentuje liczbę tokenów zasobu do zaalokowania lub zwolnienia. Specjalnymi stereotypami są: <<ForkAction>>, <<JoinAction>>. Służą one do modelowania współbieżnego wykonania akacji i są nanoszone na diagramach sekwencji. Ma to ułatwić automatyczne tworzenie współbieżnych ciągów akcji na diagramach aktywności. Podczas transformacji komunikatów z diagramu sekwencji zachowywana jest informacja o klasie implementującej metodę. Będzie ona wykorzystywana na etapie automatycznego wiązania zasobów z akcjami. o1:klasa1 Komunikat 1 Komunikat 2 o2:klasa2 <<SimpleAction>> Komunikat 1 <<CommStep>> Komunikat 1 <<SimpleAction>> Komunikat 2 <<CommStep>> Komunikat 2 Rys. 3. Diagramy sekwencji i aktywności z adnotacjami Fig. 3. Annotated sequence and activity diagram Zasoby modelowane są z wykorzystaniem diagramów wdrożenia. Rozróżniamy dwa rodzaje zasobów: aktywne i pasywne. Zasoby aktywne definiujemy z wykorzystaniem stereotypu <<ActiveResource>>. Reprezentują one wieloprocesorowe maszyny obsługujące zgłoszenia. Założono, że wszystkie procesory są jednakowe i charakteryzują się taką samą mocą obliczeniową. Liczbę procesorów definiujemy z wykorzystaniem atrybutu procnum, natomiast częstotliwość pracy zegara, z wykorzystaniem atrybutu rate. Zasoby pasywne definiujemy z wykorzystaniem stereotypu <<PassiveResource>>. Reprezentują one zasoby, które są alokowane. Dostępna jest skończona ilość danego zasobu (określona przez liczbę tokenów). Liczbę dostępnych tokenów definiujemy z wykorzystaniem atrybutu capacity, natomiast czas potrzebny na zajęcie zasobu, definiowany jest atrybutem accesstime. Zwalnianie zasobu nie powoduje upływu czasu. Każdy zasób obsługuje akcje zgodnie z określonym algorytmem. W przypadku zasobu pasywnego zaimplementowano algorytmy: LIFO i FIFO. W przypadku zasobów aktywnych zaimplementowano dodatkowo algorytm Time Sparing (atrybut schedpolicy). Rys. 4. Diagram wdrożenia z adnotacjami Fig. 4. Annotated deployment diagram Na diagramach wdrożenia należy dodatkowo nanieść informacje o komponentach, które są na nich uruchomione. Dodatkowym diagramem, który jest wykorzystywany w proponowanym podejściu jest diagram komponentów. Powinien on zawierać informacje o klasach implementujących dany komponent oprogramowania. Asocjacja komponentu z pakietami lub klasami wspomaga jednoznaczną identyfikację powiązania akcji z komponentem (na podstawie sygnatury metody przypisanej do akcji). Mając na diagramie aktywności informacje o klasie implementującej metodę, której reprezentacją jest dana akcja, komponencie, który jest implementowany z wykorzystaniem tej klasy i węźle, na którym uruchomiony jest wybrany komponent możemy automatycznie uzyskać informację o zasobie, na którym uruchomiona jest akcja. Jest to istotne, ponieważ przy dużych systemach nanoszenie na diagramy aktywności informacji o zasobie, na którym jest uruchomiona definiowana akcja, może być bardzo czasochłonne. 2.2 Transformacja modeli Ogólny algorytm transformacji modelu systemu zapisanego w języku UML na model symulacyjny jest następujący: - każdy aktor tłumaczony jest na obciążenie systemu, - każda akcja na diagramie aktywności tłumaczona jest na krok symulacji, - węzły na diagramach aktywności mapowane są na zasoby, - komponenty transformowane są na obiekty komponentów w modelu symulacyjnym. Diagramy przypadków użycia służą do uzyskania informacji o obciążeniu. W zależności od stereotypu przypisanego do aktora tworzona jest instancja klasy reprezentującej strumień skończony lub nieskończony. Z każdym aktorem powiązana jest pewna liczba przypadków użycia. Każdy z nich agreguje zbiór scenariuszy, które zobrazowane są na diagramie aktywności. Dla każdego przypadku użycia tworzona jest akcja złożona. Dla każdej akcji z diagramu aktywności, bazując na jej stereotypie, tworzona jest instancja klasy, odpowiadająca krokowi symulacji. Akcje wiązane są następnie w relacji poprzednik następnik. Na podstawie zawartości diagramów wdrożenia tworzone są instancje zasobów aktywnych i pasywnych, na których działają akcje. 63

4 Na podstawie diagramów komponentów tworzone są instancje komponentów oprogramowania. 3. Metoda badania własności oprogramowania Opracowana metoda ma zastosowanie tylko w przypadku badań wydajności architektury na etapie projektowania, modelowanej z wykorzystaniem metod obiektowych. Powinna zostać umiejscowiona w dyscyplinie analizy i projektowania procesu, jakim jest Rational Unified Process (RUP). Konkretna konfiguracja zależy od specyfiki organizacji i projektu. 3.1 Charakterystyka podstawowych elementów metody Opracowana metoda stanowi fragment metodyki RUP. Omówiona jest w kontekście ról, artefaktów i czynności. Kolejne punkty zawierają szczegółowy opis tych elementów. W celu przeprowadzenia badań oprogramowania należy wyznaczyć rolę, odpowiedzialną za ich wykonanie. Utworzona rola to: analityk wydajności. Jest ona odpowiedzialna za koordynacje i przeprowadzenie badań wydajnościowych. Każda rola związana jest ze zbiorem artefaktów oraz kroków, za których wykonanie jest odpowiedzialna. Na poniższym rysunku przedstawiono powiązania roli analityka wydajności. Rys. 5. Powiązania roli analityka wydajności Fig. 5. Performance analyst associations Osoba w roli analityka odpowiedzialna jest za poprawne przeprowadzenie następujących czynności: - wzbogacenie diagramów UML o informacje wymagane do przeprowadzenie badań, - przeprowadzenie badań, - przeprowadzenie analizy uzyskanych wyników, - poinformowanie o stanie architektury wszystkich ról za nią odpowiedzialnych. Osoba pełniąca rolę analityka powinna posiadać wiedzę na temat języka UML oraz zagadnień związanych z badaniem wydajności. Do artefaktów powstałych w trakcie prowadzenia oceny wydajności należy raport o wydajności systemu, zawierający wyniki badań. Celem utworzenia tego artefaktu jest prezentacja wyników badania systemu w postaci posiadającej wartość analityczną. Artefakty stanowią dane wejściowe i wyjściowe czynności. Poza tym określona jest również rola za nie odpowiedzialna. W poniższej tabeli przedstawiono powiązania opisywanego artefaktu. Powiązania raportu o wydajności systemu Tab. 1. Software architecture performance report associations Role Odpowiedzialna: analityk wydajności Zadania Wejście dla: udoskonalenie architektury Modyfikuje: analityk wydajności Wyjście z: ocena wydajności architektury 3.2. Kroki metody badania oprogramowania Czynność oceny wydajności wiąże się z realizacją pewnych kroków, w konsekwencji których powstaje raport o wydajności. Omówiono je kolejno w punktach poniżej. 1. Określenie celów badania. Cel: Określenie elementów architektury, które będą badane ze szczególną uwagą. Na tym etapie należy określić główne cele badania oraz ewentualnie zmodyfikować projekt systemu, w celu poprawnego przeprowadzenia badań w ich kontekście. 2. Uzupełnienie modelu przypadków użycia. Cel: Definiowanie parametrów obciążenia. Jednym z podstawowych elementów związanych z badaniami wydajności jest obciążenie systemu. Dla każdego aktora należy zdefiniować typ strumienia generowanych zgłoszeń. Typ strumienia identyfikujemy w następujący sposób: - jeśli liczba użytkowników systemu jest ograniczona, to modelujemy to za pomocą strumienia zamkniętego, - w przeciwnym wypadku będzie to strumień otwarty. Każdy aktor związany jest z uruchamianymi przypadkami użycia. Przypadki użycia opisują dostarczane usługi i agregują scenariusze interakcji użytkownika z systemem. Należy określić to, ile razy podczas współpracy użytkownika z systemem wykonywany jest określony przypadek użycia. 3. Utworzenie perspektywy wydajnościowej. Cel: Utworzenie modelu wydajnościowego zawierającego scenariusze działania systemu. Jedną z danych wejściowych wymaganych do przeprowadzenia badań oprogramowania są scenariusze interakcji użytkownika z systemem. Modelują one zachowanie systemu podczas działania. Należy utworzyć model opisujący scenariusze działania systemu, na którym zostaną naniesione informacje, wymagane do przeprowadzenia badań. Należy pamiętać o poprawnym modelowaniu współbieżności i punktów decyzyjnych. 64

5 4. Uzupełnienie diagramów aktywności Cel: Określenie obciążenia generowanego przez poszczególne akcje. Każda akcja wykonywanego scenariusza wiąże się z wykorzystaniem do jej realizacji pewnych zasobów. Należy określić obciążenie, jakie akcja generuje. 5. Uzupełnienie modelu wdrożenia. Cel: Definiowanie typu zasobów. W ramach badań wydajnościowych wyróżniane są różne typy zasobów. W tym kroku należy zdefiniować i sparametryzować zasoby aktywne i pasywne. Identyfikacji typu zasobu można dokonać w następujący sposób: - zasób aktywny - maszyna wieloprocesorowa udostępniająca usługi obliczeniowe, - zasób pasywny - część systemu, którego ilość jest ograniczona np. pula połączeń do bazy danych. Po identyfikacji typu zasobu należy zdefiniować parametry opisujące dany typ. 6. Dobór metryk. Cel: Wybór metryk umożliwiających porównanie różnych rozwiązań architektonicznych. Należy dobrać metryki tak, aby możliwe było porównanie różnych rozwiązań architektonicznych z różnych badań. 7. Przeprowadzenie badań. Cel: Przygotowanie danych do oceny architektury. Podstawą do oceny wydajności architektury są wyniki przeprowadzonych badań. Danymi wejściowymi do analizy są następujące elementy: - model przypadków użycia, przedstawiający obciążenie systemu i usługi dostarczone przez system, - model wdrożenia, przedstawiający zasoby udostępnione przez system, - scenariusze działania systemu z perspektywy wydajnościowej, - model przedstawiający komponenty, pozwalający na powiązanie zasobów z akcjami na nich wykonywanymi. Na podstawie powyższych danych powinny zostać przeprowadzone badania wydajnościowe. Wyniki tych badań powinny zostać zarchiwizowane i przygotowane do dalszej analizy. Na podstawie uzyskanych wyników powinien zostać stworzony raport, przedstawiający obraz wydajności architektury. 8. Analiza wyników symulacji. Cel: Ocena wydajności architektury. Wyniki uzyskane podczas przeprowadzonych badań powinny zostać przeanalizowane. Na ich podstawie powinna zostać przygotowana lista ewentualnych uwag dotyczących wydajności architektury. O wszelkich problemach związanych z wydajnością powinny zostać poinformowane wszystkie osoby odpowiedzialne za architekturę systemu Listy kontrolne W ramach metodyki RUP udostępniono mechanizm list kontrolnych, umożliwiających weryfikację poprawności wykonanej czynności. Poniżej przedstawiono listę kontrolną dla czynności oceny wydajności architektury. Zawiera ona następujące punkty: - dla każdego aktora został określony typ strumienia, - dla każdego przypadku użycia określono liczbę jego wykonań, - dla każdego przypadku użycia zdefiniowano jego realizacje, - na diagramach obrazujących realizacje przypadku użycia zaznaczono punkty rozwidleń i scaleń, - komponenty powiązane są z artefaktem opisującym zasób, na którym jest on uruchomiony, - komponenty powiązane są z pakietami i klasami, które je implementują, - określono typ każdego zasobu, - każda akcja modelu wydajnościowego zawiera informacje o generowanym obciążeniu zasobów. 4. Rozszerzenie środowiska Rational Software Architect (RSA) Opisana w punkcie 3 metoda jest wspierane przez zbiór rozszerzeń środowiska RSA. W celu umożliwienia przeprowadzenia badań na podstawie diagramów opisujących architekturę, rozszerzenie środowiska powinno umożliwić stworzenie i uruchomienie modelu symulacyjnego badanego oprogramowania. Na rysunku został przedstawiony proces, jaki musi zostać zrealizowany, aby osiągnąć wyżej postawiony cel. Zaznaczono również na nim wykorzystane metody rozszerzenia platformy RSA. Rys. 6. Rozszerzenie platformy IBM Rational Software Architekt Fig. 6. IBM Rational Software Architect extensions W celu implementacji oprogramowania umożliwiającego przeprowadzenie badań skorzystano z następujących mechanizmów rozszerzeń środowiska RSA: profilu UML, transformacji, wtyczek. Profil UML został stworzony w celu modelowania dziedziny problemowej badań systemów z wykorzystaniem symulacji. W punkcie 65

6 2.1 zostały omówione podstawowe elementy tego profilu. Mechanizm transformacji wykorzystany został w dwóch przypadkach. Pierwszy z nich rozwiązuje problem scenariuszy działania oprogramowania. W opisywanym podejściu należy dokonać transformacji diagramów sekwencji na diagramy aktywności. Zastosowanie ma tutaj mechanizm transformacji jednego modelu do drugiego. Drugim punktem, w którym zostały wykorzystane transformacje, jest konwersja modelu stworzonego w UML na model symulacyjny. Generowany jest plik interpretowany później przez oprogramowanie implementujące program symulacyjny. Ostatnim mechanizmem rozszerzenia, jaki został wykorzystany, jest standardowa wtyczka, umożliwiający uruchomienie symulacji i archiwizację wyników. Podstawową jej częścią jest zaimplementowana biblioteka, umożliwiająca uruchomienie symulacji. Nazwano ją UMLSimKit. Do jej implementacji wykorzystana została biblioteka do symulacji zorientowanej procesowo o nazwie DESKit. Wyniki prezentowane są z wykorzystaniem systemu raportowego o nazwie Business Intelligence and Reporting Tools (BIRT) dostarczony wraz z platformą IBM. Rozszerzenie środowiska dostarczone jest jako zbiór wtyczek, realizujących wyżej opisaną funkcjonalność. 5. Wnioski W pracy przedstawiono metodę oceny architektury oprogramowania oraz narzędzie wspierające ten proces. Jako język modelowania wykorzystano UML oraz dostarczone wraz z nim mechanizmy rozszerzenia jego semantyki. Wybór symulacji jako techniki oceny, pozwolił odzwierciedlić działanie systemu na wybranym poziomie. Proces oceny architektury wspierany jest przez zaimplementowany zestaw wtyczek do środowiska Rational Software Architect. Wyniki badań są archiwizowane i mogą być prezentowane w zrozumiałej formie zainteresowanym użytkownikom. Elementem do dalszej analizy jest włączenie do badań kolejnych diagramów. Szczególną uwagę należałoby zwrócić na diagramy stanów, które modelują zachowanie obiektu i jego reakcje na zdarzenia. Dodatkowym zagadnieniem, które należałoby włączyć do analizy, jest niezawodność zasobów aktywnych i pasywnych. Może mieć to szczególne znaczenie w systemach, w których wymaga się dużej dostępności. Należałoby również zaimplementować mechanizm, wspierający podejmowanie decyzji o zmianach w architekturze. Conclusion This paper describes approach for performance evaluation of a system on early developing process stages. UML as an OO modeling language was used. Performance evaluation process is supported by Rational Software Architect extensions. Future research should focus on other diagrams and their possible use for performance evaluation. State diagrams are especially interesting. Other problem which should be considered is reliability of passive and active resources. This is an important issue in high availability systems. Provided RSA extensions should be furtherly developed. They should support a designer in making decision about changes on an architectural level. Literatura 1. M. Marzolla, Simulation-Based Performance Modeling of UML Software Architectures, Universita Ca'Foscari, Wenecja P. Kruchten, Rational Unified Process od strony teoretycznej, WNT, Warszawa G. Booch, J. Rumbaugh, I.Jacobson, UML przewodnik użytkownika, WNT, Warszawa Object Management Group (OMB), UML profile for schedulability, performance and time specification, OMG Adopted Specification ptc/ , OMG 2007 Adres służbowy autora: mgr inż. Arkadiusz Wrzosk Wojskowa Akademia Techniczna ul. gen. Sylwestra Kaliskiego Warszawa 49 tel arkadiusz.wrzosk@wat.edu.pl 66