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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski

Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML. Jakub Morkis, Piotr Chmielewski Graficzna notacja procesów biznesowych BPMN. Porównanie z notacja UML Jakub Morkis, Piotr Chmielewski BPMN - Historia Formowanie grumy tworzącej notację Sierpień 2001, 58 członków reprezentujących 35 firm,

Bardziej szczegółowo

Diagramy zachowania. Diagramy struktury. Przypadków użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Diagramy zachowania. Diagramy struktury. Przypadków użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview) Modelowanie Podstawowe zasady modelowania: Podjęcie decyzji, jakie modele tworzyć, ma wielki wpływ na to, w jaki sposób zaatakujemy problem i jaki kształt przyjmie rozwiązanie Każdy model może być opracowany

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

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

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

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

Akademia Morska w Szczecinie. Wydział Mechaniczny

Akademia Morska w Szczecinie. Wydział Mechaniczny Akademia Morska w Szczecinie Wydział Mechaniczny ROZPRAWA DOKTORSKA mgr inż. Marcin Kołodziejski Analiza metody obsługiwania zarządzanego niezawodnością pędników azymutalnych platformy pływającej Promotor:

Bardziej szczegółowo

STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA

STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA Tomasz SOBESTIAŃCZYK ZESZYTY NAUKOWE WYDZIAŁU NAUK EKONOMICZNYCH STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA Zarys treści: W pracy podjęto próbę przedstawienie UML 2.3 jako metody w zarządzaniu

Bardziej szczegółowo

Modelowanie danych, projektowanie systemu informatycznego

Modelowanie danych, projektowanie systemu informatycznego Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym

Bardziej szczegółowo

Języki i metodyka oprogramowania

Języki i metodyka oprogramowania Języki i metodyka oprogramowania Automatyka i Robotyka sem.2 (część I) Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Literatura A. Januszkiewicz. Inżynieria oprogramowania. Helion 1997. W. Dąbrowski,

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

Tworzenie modelu konceptualnego systemu informatycznego część 1

Tworzenie modelu konceptualnego systemu informatycznego część 1 Tworzenie modelu konceptualnego systemu informatycznego część 1 1. Elementy diagramów przypadków użycia (usecases) 2. Wytyczne tworzenia diagramów przypadków użycia (use-cases) (wg Booch G., Rumbaugh J.,

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

Rozpoczęcie, inicjacja (ang. inception

Rozpoczęcie, inicjacja (ang. inception Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

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

Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect

Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Karolina Zmitrowicz Zarządzanie wymaganiami w projekcie może być trudne i czasochłonne, może być chaotyczne jeśli brak odpowiedniego

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

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

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND. Dokumentacja projektu. Danilo Lakovic. Joanna Duda. Piotr Leżoń. Mateusz Pytel

SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND. Dokumentacja projektu. Danilo Lakovic. Joanna Duda. Piotr Leżoń. Mateusz Pytel SYSTEMY CZASU RZECZYWISTEGO STEROWNIK WIND Dokumentacja projektu Danilo Lakovic Joanna Duda Piotr Leżoń Mateusz Pytel 1. Wstęp 1.1. Cel dokumentu Poniższy dokument ma na celu przybliżenie użytkownikowi

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

Pracownia Inżynierii Procesowej

Pracownia Inżynierii Procesowej Pracownia Inżynierii Procesowej Aktualizacja oferty styczeń 2016 WŁAŚCICIEL mgr inż. Alicja Wróbel Absolwent Politechniki Opolskiej, Wydziału Zarzadzania i Inżynierii Produkcji Rysunek techniczny 2D 3D

Bardziej szczegółowo

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

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

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska Zagadnienia Wprowadzenie MDD Model Analityczny Projektowy Przykład Podsumowanie Wykorzystano materiały

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

Bardziej szczegółowo

Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych

Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych Załącznik Nr 1 Do pisma IMP PAN l.dz. ZDN/1234/2007 z 2007-06-19 o ogłoszeniu przetargu nieograniczonego na pakiet usług programistycznych, których wartość nie przekracza progu, od którego obowiązuje prawo

Bardziej szczegółowo