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

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

Download "XII International PhD Workshop OWD 2010, 23 26 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

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

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

XII International PhD Workshop OWD 2010, 23 26 October 2010. Metodyka pozyskiwania i analizy wyników badań symulacyjnych ścieżek klinicznych

XII International PhD Workshop OWD 2010, 23 26 October 2010. Metodyka pozyskiwania i analizy wyników badań symulacyjnych ścieżek klinicznych XII International PhD Workshop OWD 2010, 23 26 October 2010 Metodyka pozyskiwania i analizy wyników badań symulacyjnych ścieżek klinicznych Methodology of Acquiring and Analyzing Results of Simulation

Bardziej szczegółowo

Michał Adamczyk. Język UML

Michał Adamczyk. Język UML Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko

Bardziej szczegółowo

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE

Bardziej szczegółowo

UML cz. I. UML cz. I 1/1

UML cz. I. UML cz. I 1/1 UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę

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

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI Inżynieria Rolnicza 7(105)/2008 MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI Agnieszka Buczaj Zakład Fizycznych Szkodliwości Zawodowych, Instytut Medycyny Wsi w Lublinie Halina Pawlak Katedra

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram

Bardziej szczegółowo

Diagramy UML, przykład problemu kolizji

Diagramy UML, przykład problemu kolizji Bogdan Kreczmer bogdan.kreczmer@pwr.edu.pl Katedra Cybernetyki i Robotyki Wydział Elektroniki Politechnika Wrocławska Kurs: Copyright c 2015 Bogdan Kreczmer Niniejszy dokument zawiera materiały do wykładu

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

wbudowane October 7, 2015 KSEM WETI PG Komputery przemysłowe i systemy wbudowane Oprogramowanie systemów wbudowanych - wydajność Wydajność

wbudowane October 7, 2015 KSEM WETI PG Komputery przemysłowe i systemy wbudowane Oprogramowanie systemów wbudowanych - wydajność Wydajność KSEM WETI PG October 7, 2015 Inżynieria wydajności oprogramowania Software performance engineering (SPE) - dyscyplina zajmująca się poprawą dojrzałości procesu budowy i rozwoju dla zwiększenia ich wydajności.

Bardziej szczegółowo

Analiza i projektowanie obiektowe w UML Kod przedmiotu

Analiza i projektowanie obiektowe w UML Kod przedmiotu Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Modelowanie obiektowe - Ćw. 3.

Modelowanie obiektowe - Ćw. 3. 1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Tematy prac magisterskich Rok akademicki 2013/2014

Tematy prac magisterskich Rok akademicki 2013/2014 Dr hab. inż. Jan Werewka, prof. n. AGH Wydział EAIiIB AGH E-mail: werewka@agh.edu.pl www: http://home.agh.edu.pl/werewka Tematy prac magisterskich Rok akademicki 2013/2014 Temat 1 Architektura przedsięwzięcia

Bardziej szczegółowo

Podstawy języka UML2 w realnych projektach

Podstawy języka UML2 w realnych projektach Kod szkolenia: Tytuł szkolenia: UML2/RP Podstawy języka UML2 w realnych projektach Dni: 3 W cenie szkolenia uczestnik otrzymuje licencję na oprogramowanie Enterprise Architect, najlepsze narzędzie do modelowania

Bardziej szczegółowo

Wprowadzenie do UML, przykład użycia kolizja

Wprowadzenie do UML, przykład użycia kolizja Bogdan Kreczmer bogdan.kreczmer@pwr.wroc.pl Zakład Podstaw Cybernetyki i Robotyki Instytut Informatyki, Automatyki i Robotyki Politechnika Wrocławska Kurs: Copyright c 2012 Bogdan Kreczmer Niniejszy dokument

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08 Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

Identyfikacja i modelowanie struktur i procesów biologicznych Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie

Bardziej szczegółowo

Diagramy przypadków użycia

Diagramy przypadków użycia Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy

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

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Dr Katarzyna Grzesiak-Koped

Dr Katarzyna Grzesiak-Koped Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd

Bardziej szczegółowo

WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko

Bardziej szczegółowo

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. 45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć

Bardziej szczegółowo

MODELOWANIE OBIEKTOWE

MODELOWANIE OBIEKTOWE (Wykład na podstawie literatury: M.Śmiałek Zrozumieć UML 2.0, Helion 2005) UML Unified Modeling Language (język do specyfikowania, wizualizowania, konstruowania i dokumentacji tzw. artefactów oraz czynności

Bardziej szczegółowo

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Dr inż. Jacek WARCHULSKI Dr inż. Marcin WARCHULSKI Mgr inż. Witold BUŻANTOWICZ Wojskowa Akademia Techniczna SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Streszczenie: W referacie przedstawiono możliwości

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

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.

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

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML VIII Konferencja PLOUG Koœcielisko PaŸdziernik 2002 Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML Piotr Wilk Premium Technology Sp. z o.o. PWilk@PremiumTechnology.pl Modelowanie

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

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy

Bardziej szczegółowo

UPEDU: Analiza i projektowanie (ang. analysis and design discipline)

UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Wydział Informatyki PB Analogia do powstawania kryształu Inżynieria oprogramowania II Wykład 7: UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Marek Krętowski e-mail: mkret@wi.pb.edu.pl

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków

Bardziej szczegółowo

Inżynieria oprogramowania. Jan Magott

Inżynieria oprogramowania. Jan Magott Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,

Bardziej szczegółowo

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

koniec punkt zatrzymania przepływów sterowania na diagramie czynności Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami

Model referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary

Bardziej szczegółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan prezentacji Wprowadzenie do modelowania Wprowadzenie do języka UML Diagram klas Diagram pakietów Diagram przypadków użycia Diagram czynności Terminologia Terminologia Aplikacja

Bardziej szczegółowo

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS Andrzej Zalewski, Marcin Szlenk, Szymon Kijas a.zalewski@elka.pw.edu.pl s.kijas@elka.pw.edu.pl Praca naukowa finansowana ze środków budżetowych na naukę

Bardziej szczegółowo

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na

Bardziej szczegółowo

Podstawy modelowania programów Kod przedmiotu

Podstawy modelowania programów Kod przedmiotu Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki

Bardziej szczegółowo

Model przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Model przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Sposoby weryfikacji architektury oprogramowania: - badanie prototypu

Bardziej szczegółowo

problem w określonym kontekście siły istotę jego rozwiązania

problem w określonym kontekście siły istotę jego rozwiązania Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego

Bardziej szczegółowo

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy

Bardziej szczegółowo

Modelowanie obiektowe - Ćw. 6.

Modelowanie obiektowe - Ćw. 6. 1 Modelowanie obiektowe - Ćw. 6. Treść zajęć: Dokumentacja przypadków użycia diagramy czynności. Poznane wcześniej diagramy przypadków użycia pokazują co system powinien robić. Natomiast diagramy czynności

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

Bardziej szczegółowo

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.

Bardziej szczegółowo

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

Bardziej szczegółowo

Szczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów:

Szczegółowy opis przedmiotu umowy. 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

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

Podstawy modelowania biznesowego w inżynierii oprogramowania

Podstawy modelowania biznesowego w inżynierii oprogramowania Podstawy modelowania biznesowego w inżynierii oprogramowania 1. Rola modelowania biznesowego w inżynierii oprogramowania 2. Przegląd notacji (BPMN, UML w zast. biznesowym) 3. Powiązania modeli biznesowych

Bardziej szczegółowo

Część I Istota analizy biznesowej a Analysis Services

Część I Istota analizy biznesowej a Analysis Services Spis treści Część I Istota analizy biznesowej a Analysis Services 1 Analiza biznesowa: podstawy analizy danych... 3 Wprowadzenie do analizy biznesowej... 3 Wielowymiarowa analiza danych... 5 Atrybuty w

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

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko

Bardziej szczegółowo

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4

Procesy biznesowe w praktyce. Przykłady użycia z wykorzystaniem jbpm 4.4 Procesy biznesowe w praktyce Przykłady użycia z wykorzystaniem jbpm 4.4 1 Agenda Definicja i zastosowanie procesu biznesowego Języki dziedzinowe (DSL) a rozwiązania BPM JBPM: jbpm 4.4 krótka charakterystyka

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA

Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia

Bardziej szczegółowo

Modele bezpieczeństwa logicznego i ich implementacje w systemach informatycznych / Aneta Poniszewska-Marańda. Warszawa, 2013.

Modele bezpieczeństwa logicznego i ich implementacje w systemach informatycznych / Aneta Poniszewska-Marańda. Warszawa, 2013. Modele bezpieczeństwa logicznego i ich implementacje w systemach informatycznych / Aneta Poniszewska-Marańda. Warszawa, 2013 Spis treści I. Bezpieczeństwo systemów informatycznych Rozdział 1. Wstęp 3 1.1.

Bardziej szczegółowo

Zalety projektowania obiektowego

Zalety projektowania obiektowego Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy

Bardziej szczegółowo

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i

Bardziej szczegółowo

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski INŻYNIERIA OPROGRAMOWANIA wykład 6A: ANALIZA i PROJEKTOWANIE wg RUP dr inż. Leszek Grocholski ( na podstawie książek o RUP ) Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski OBIEKTOWE

Bardziej szczegółowo

Szkolenia SAS Cennik i kalendarz 2017

Szkolenia SAS Cennik i kalendarz 2017 Szkolenia SAS Spis treści NARZĘDZIA SAS FOUNDATION 2 ZAAWANSOWANA ANALITYKA 2 PROGNOZOWANIE I EKONOMETRIA 3 ANALIZA TREŚCI 3 OPTYMALIZACJA I SYMULACJA 3 3 ROZWIĄZANIA DLA HADOOP 3 HIGH-PERFORMANCE ANALYTICS

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

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

Architektura oprogramowania w praktyce. Wydanie II.

Architektura oprogramowania w praktyce. Wydanie II. Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura oprogramowania?

Bardziej szczegółowo

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modelowanie systemów biznesowych Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 stycznia 2010 Spis treści 1 Czym jest system biznesowy? Po co model bizensowy? Czym

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań Albert Ambroziewicz, Michał Śmiałek Politechnika Warszawska KKIO 0, SCR 0 27-29.09.200 Treść prezentacji Wprowadzenie powtarzalność rozwiązań w IO Koncepcja

Bardziej szczegółowo

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie

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

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