ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI

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

Download "ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI"

Transkrypt

1 ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 Instytut Informatyki, Politechnika Poznańska ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI Streszczenie Artykuł prezentuje koncepcję generatora diagramów sekwencji z przypadków użycia. Diagramy te dobrze obrazują poszczególne przebiegi scenariusza i pomagają zrozumieć skomplikowane przypadki użycia. Prezentowane narzędzie wchodzi w skład zintegrowanego środowiska UC Workbench będącego platformą wspomagającą pracę analityka w fazie analizy wymagań. 1. WSTĘP W późnych latach osiemdziesiątych Ivar Jacobson ([6]) przedstawił społeczności programistów obiektowych koncepcję przypadków użycia, dwadzieścia lat wcześniej wykorzystywanych przez niego w branży telekomunikacyjnej. Szybko wypełnił on ważną lukę w procesie analizy wymagań i został szeroko uznany jako standard tworzenia specyfikacji wymagań. Przypadki użycia specyfikują system informatyczny w ujęciu behawioralnym. Jeden przypadek użycia zawiera wiele scenariuszy połączonych wspólnym celem biznesowym. Ich główną zaletą jest fakt, że opisywane są w języku naturalnym i bardzo często mają postać następujących po sobie kolejno kroków. Chociaż zaleca się, aby przypadki użycia były w miarę krótkie (od 3 do 9 kroków), napisane przy użyciu prostych zdań (podmiot orzeczenie dopełnienie), jednak mimo to w niektórych sytuacjach powstają scenariusze bardzo skomplikowane. W takich przypadkach przydałaby się wizualizacja zachowania opisanego przypadkami użycia. Celem artykułu jest zaproponowanie wizualizacji przebiegu przypadków użycia za pomocą diagramów sekwencji języka UML tworzonych w procesie animacji. Opisywany animator przypadków użycia jest częścią zintegrowanego narzędzia UC Workbench rozwijanego w Instytucie Informatyki Politechniki Poznańskiej i obejmującego swoim zakresem nie tylko animację, ale również redagowanie przypadków użycia, generowanie dokumentacji wymagań oraz szacowanie pracochłonności. W drugim rozdziale omówiono pojęcie przypadków użycia wraz z prostym przykładem, rozdział trzeci przedstawia koncepcję i ideę narzędzia UC Workbench oraz jego części składowe. Czwarty rozdział prezentuje koncepcję generowania diagramów

2 2 sekwencji w procesie animacji, lecz proces ten byłby niemożliwy, gdybyśmy nie znali dokładnej struktury przypadku użycia. W rozdziale piątym przedstawiono koncepcję semiformalnego języka opisu przypadków użycia, dzięki któremu struktura scenariuszy jest jednoznaczna i zrozumiała przez komputer. W szóstym rozdziale znajduje się opis metody generowania diagramów sekwencji. 2. PRZYPADKI UŻYCIA Przypadek użycia jest zapisem pewnego rodzaju umowy pomiędzy aktorami systemu, a samym systemem. Opisuje zachowanie analizowanego systemu w różnych warunkach, gdzie system odpowiada na żądania jednego z uczestników nazywanego aktorem. Interakcja między aktorem i systemem ma na celu osiągnięcie pewnej wartości biznesowej przy założonym warunku początkowym i końcowym. Zatem przypadki użycia mogą służyć między innymi jako sposób komunikacji osób lub jako forma zapisu wymagań. Przypadki użycia mają być łatwe do zrozumienia oraz mogą być użyte w różnych sytuacjach, dlatego też nie jest narzucony jednolity styl ich pisania. Przypadek użycia dzięki mechanizmowi rozszerzeń, skoków oraz pętli jest zbiorem rozmaitych scenariuszy. Złożoność danego przypadku użycia uzależniona jest, więc przede wszystkim od liczby rozszerzeń i ich stopnia zagłębienia oraz liczby skoków. Struktura przypadku użycia zawiera oprócz scenariusza i jego rozszerzenia dodatkowe atrybuty, które z punktu widzenia animowania przypadków użycia będą nie istotne, zatem nie będą rozpatrywane. Dokładny opis struktury przypadków użycia oraz wskazówki jak dobrze pisać przypadki użycia zawarte są [1] oraz [2]. Poniżej przedstawiony został rzeczywisty przypadek użycia opisujący fragment internetowego sytemu obsługi konferencji, którego zadaniem jest zautomatyzowanie procesu obsługi streszczeń, artykułów i recenzji: UC4: Zarządzanie użytkownikami Aktor: Administrator Scenariusz główny: 1. System wyświetla listę z wszystkimi użytkownikami. 2. Administrator dodaje nowego użytkownika lub usuwa istniejącego. 3. System potwierdza wykonanie operacji. 4. Administrator wylosowuje się z panelu administratora. Rozszerzenia: 2.A. Podane dane użytkownika są niepełne, lub nieprawidłowe. 2.A.1. System wyświetla komunikat o błędzie i wraca do kroku 2. Rys.1. Przykład przypadku użycia.

3 Animacja przypadków użycia za pomocą diagramów sekwencji 3 3. KONCEPCJA SYSTEMU UC WORKBENCH UC Workbench jest narzędziem, które szeroko wspomaga proces inżynierii wymagań opartej o przypadki użycia. Analityk ma do dyspozycji edytor za pomocą, którego wprowadza przypadki użycia do systemu. Edytor ten w znacznym stopniu zwalnia go od uciążliwych czynności, które muszą być wykonywane w przypadku stosowania zwykłych edytorów tekstowych (pielęgnacja formatowania i odpowiedniej numeracji kroków). Na podstawie specyfikacji wymagań oraz szkiców ekranów aplikacji generowana jest makieta systemu i dokument specyfikacji wymagań (SRS), które są wręczane klientowi do przeglądu. Wymagania prezentowane klientowi w takiej formie dużo lepiej wpływają na jego wyobraźnię, łatwiej jest mu zrozumieć koncepcję zamawianego systemu, a tym samym znaleźć więcej błędów. Narzędzie umożliwia przyrostową pracę nad przypadkami użycia, zgodnie ze wzorcami BreadthBeforeDepth oraz SpiralDevelopment, zaproponowanymi przez [1]. Rysunek 2 przedstawia kontekst i schemat działania narzędzia UC Workbench i jego wpływ na osoby biorące udział w projekcie. Rys.2. Kontekst i schemat działania narzędzia UC Workbench. 4. KONCEPCJA ANIMATORA PRZYPADKÓW UŻYCIA Przypadki użycia zapisane za pomocą języka naturalnego mogą być niekiedy trudne do zrozumienia i dokładnego przeanalizowania. Dlatego też celem animatora jest pokazanie przypadków użycia w formie ułatwiającej ich zrozumienie. Do tego celu wybrano diagram sekwencji zapisany w języku UML [3]. Informacje dotyczące tworzenia diagramów sekwencji zawarte są również w [4]. Przedstawienie przypadków użycia za pomocą diagramów sekwencji, pokazuje nam zależności czasowe występujące podczas interakcji użytkownika z systemem. Można dzięki temu prześledzić cały przypadek użycia krok po kroku przechodząc po scenariuszu głównym, jak i wyjątkach (rozszerzeniach). Na początku pracy animator pokazuje główny scenariusz przypadku użycia w kolorze szarym, gdyż stanowi to podstawę generowanego diagramu. Każdy krok w scenariuszu

4 4 odpowiada komunikatowi na diagramie sekwencji (szczegółowy opis w punkcie 6). Następnie przechodzimy po krokach scenariusza głównego podświetlając kolorem czarnym odpowiednie komunikaty. Za każdym razem sprawdzane jest czy nie wystąpi zdarzenie wyjątkowe, w momencie pojawienia się go użytkownik decyduje czy przejść do scenariusza alternatywnego czy pozostać w głównym. Przejście takie uwidaczniane jest na diagramie zaznaczeniem wystąpienia odpowiedniego zdarzenia. Komunikaty pojawiające się po wystąpieniu wyjątku rysowane są kolorem czerwonym po to by odróżnić przechodzenie po scenariuszu alternatywnym. Jeden diagram przedstawia pojedynczy przypadek użycia, dlatego też animator umożliwia nawigacje pomiędzy przypadkami za pomocą drzewa kontekstu, w którym najwyższy poziom odpowiada poziomowi biznesowemu przypadków użycia. Dzięki temu mamy możliwość przejścia po wszystkich przypadkach oraz wszystkich krokach zarówno w scenariuszu głównym jak i alternatywnym sprawdzając kompletność i poprawność analizowanego systemu. Animator przypadków użycia pokazany jest na rysunku 3. Rys.3. Koncepcja działania animatora przypadków użycia. Należy zwrócić uwagę, że każdy komunikat zawierający nazwę posiada numer kroku ułatwiając tym samym jego lokalizacje oraz zrozumienie scenariusza. Opis każdego komunikatu znajdujący się nad każdą strzałką jest jedynie częścią kroku scenariusza. Dopiero po najechaniu myszką na taki komunikat pokazuje nam się treść całego kroku dzięki temu cały diagram nie staje się nieczytelny na skutek zbyt długich opisów nad strzałkami.

5 Animacja przypadków użycia za pomocą diagramów sekwencji 5 5. OPIS PRZYPADKÓW UŻYCIA W JĘZYKU FUSE Tradycyjne przypadki użycia pisane w języku naturalnym mają pewną poważną wadę: trudno jest w sposób automatyczny zanalizować ich strukturę kroków. Dzieje się tak, dlatego, że oprócz standardowego przebiegu scenariusza (sekwencje kroków i rozszerzenia) często pojawiają się dodatkowe opisy w języku naturalnym, np. Kroki 1-3 mogą być powtarzane wiele razy. Taki komentarz jest zrozumiały dla człowieka, lecz trudny do automatycznej analizy przez komputer. Narzędzia wchodzące w skład UC Workbench wymagają znajomości tej struktury do właściwego działania. W celu jej sformalizowania powstał język FUSE (Formal USE case language), który jednak zachowuje główną zaletę przypadków użycia czytelność dla człowieka (nadal wykorzystywany jest język naturalny). Podczas analizy przypadków użycia napotykamy wiele odstępstw od podstawowego modelu (kroki wykonywane sekwencyjnie wraz z rozszerzeniami), które musiały być rozważone podczas opracowywania języka FUSE. Niedeterministyczny wybór jednej z kilku alternatywnych kroków scenariusza to pierwszy problem, jaki napotykamy w tradycyjnych przypadkach użycia, które zakładają, że kroki będą wykonywane po kolei. Często alternatywy te są równorzędne, więc umieszczanie jednego wariantu w scenariuszu głównym, natomiast pozostałych jako rozszerzenia tego scenariusza byłoby rozwiązaniem mało naturalnym. Język FUSE daje do dyspozycji konstrukcję Albo-Lub, która wygląda następująco: 1. Zarz dzanie u ytkownikami: 1.1. Albo: Administrator dodaje nowego u ytkownika Lub: Administrator usuwa jednego z u ytkowników. FUSE pozwala na tworzenie zagnieżdżonych kroków. Konstrukcja ta umożliwia doprecyzowywanie kroków scenariusza, bez konieczności wprowadzania nowych przypadków użycia, co jest bardzo pomocne w przypadku prostych sekwencji kroków. Dopiero w połączeniu z możliwością zagnieżdżania kroków powyższy element jest silnym narzędziem służącym do opisu przypadków użycia. Przykładowy przypadek użycia napisany przy użyciu języka FUSE jest przedstawiony na rysunku 4 (kroki 2.1., 2.2., , oraz są krokami zagnieżdżonymi). 1. System wy wietla list z wszystkimi u ytkownikami. 2. Administrator wykonuje operacj na u ytkownikach: 2.1. Albo: Administrator dodaje nowego u ytkownika Administrator podaje dane nowego u ytkownika System waliduje poprawno nazwy u ytkownika System potwierdza dodanie u ytkownika Lub: Administrator usuwa jednego z u ytkowników. 3. Administrator wylogowuje si z panelu administratora. Rozszerzenia: A. Podane dane s niepe ne, lub nieprawid owe A.1. System wy wietla komunikat o b dzie i wraca do kroku Rys.4. Przykładowy przypadek użycia w języku FUSE.

6 6 6. GENERACJA DIAGRAMÓW SEKWENCJI Przypadki użycia spisane w języku FUSE za pomocą narzędzia UC Workbench są bardziej formalne i lepiej nadają się do dalszej prezentacji. Dlatego też wykorzystywane są w animatorze przypadków użycia jako dane wejściowe. Na ich podstawie generowany jest diagram sekwencji. Podczas generowania pojawiają się jednak problemy z wyborem typu i opisu komunikatu, z identyfikacją nadawcy i odbiorcy wiadomości, jak również z obsługą wyjątków i skoków. W tym celu wprowadzone zostają specjalne znaczniki umożliwiające określenie dodatkowych informacji niezbędnych do wygenerowania diagramu. Są one widoczne wyłącznie dla analityka i dzięki temu zachowana zostaje czytelność przypadków użycia, które widzą inni uczestnicy projektu. Animator przypadków użycia wykorzystuje dwa typy komunikatów: synchroniczne oraz wewnętrzne operacje. Ważne jest to, że oprócz wewnętrznych operacji występują tylko komunikaty synchroniczne. Wynika to z natury interakcji między dwoma aktorami ([1]) oraz stanowi lepszą podstawę do późniejszego tworzenia testów funkcjonalnych (dla każdej akcji istnieje reakcja systemu). Komunikat będący wewnętrzną operacją występujący po stronie systemu reprezentuje wewnętrzne przetwarzanie natomiast, gdy występuje po stronie użytkownika odzwierciedla operacje biznesowe. Generator diagramu sekwencji na podstawie danego kroku nie jest w stanie określić typu i nazwy komunikatu. W tym celu wprowadzone zostały znaczniki < > i [ ] obejmujące wybrany fragment kroku opisujący nazwę komunikatu. Rysunek 5 przedstawia użycie tych znaczników, gdzie [ ] oznacza komunikat synchroniczny, natomiast < > wewnętrzną operację. Należy zwrócić uwagę, że jeden krok może zawierać więcej niż jeden komunikat Administrator <podaje dane nowego u ytkownika> System [waliduje poprawno nazwy u ytkownika]. Rys.5. Użycie znaczników określających typ i nazwę komunikatu. Generator znając typ i nazwę komunikatu zawartego w danym kroku musi jeszcze zidentyfikować nadawcę oraz odbiorcę komunikatu. Dlatego też w każdym kroku pierwszy wyraz określa nadawcę wiadomości (zgodnie z zaleceniami Cockburna dotyczącymi prostej gramatyki kroku [2]). Rysunek 5 pokazuje na taką sytuację, gdzie dla kroku nadawcą komunikatu jest administrator i ponieważ odbiorca nie jest określony, przyjmowany jest domyślnie system. Krok przedstawia sytuację odwrotną, w której domyślnym odbiorcą jest administrator. Może jednak wystąpić sytuacja, w której w danym kroku nie będzie udziału systemu (poziom biznesowy) i będzie potrzeba ustalenia odbiorcy komunikatu. Taką sytuacje ilustruje rysunek 6, na którym odbiorca określony jest za pomocą znaczników / /. 5. Dostawca <wysy a potwierdzenie> do /klient/a. Rys.6. Użycie znaczników określających odbiorcę komunikatu. W przypadku sekwencyjnego wystąpienia kroków, w których mamy komunikaty synchroniczne posiadające tego samego nadawcę naruszona zostaje zasada, że dla każdej akcji istnieje reakcja. Generator diagramów sekwencji dodaje między nimi komunikat nieposiadający nazwy, aby tworzony diagram był prawidłowy Taka sytuacja pokazana jest na rysunku 7, na którym brakuje kroku reprezentującego reakcje na działanie systemu (por. przedstawienie tego fragmentu scenariusza na diagramie rysunek 8).

7 Animacja przypadków użycia za pomocą diagramów sekwencji 7 1. System <wy wietla formularz do wprowadzania danych>. 2. System <potwierdza wprowadzenie danych>. Rys.7. Naruszenie zasady interakcji. Rys.8. Diagram sekwencji obrazujący dodanie dodatkowego komunikatu. Pojawiające się rozszerzenia w przypadkach użycia są rysowane na diagramie sekwencji w postaci strzałki z odpowiednim komentarzem. W momencie, gdy osiągalne jest dane zdarzenie animator pyta się użytkownika czy ma ono wystąpić. Miejsce pojawienia się zdarzenia określane jest na podstawie jego nazwy. Gdy pierwszym wyrazem jest nazwa aktora to występuje po jego stronie na diagramie, w przeciwnym razie domyślną stroną jest system. Sytuacje taką ilustruje nam rysunek 9, na którym zdarzenie występuje po stronie systemu. W przypadkach użycia występują również skoki do innych kroków, których generator nie jest sam w stanie zidentyfikować. W tym celu wprowadzony został kolejny znacznik { } zawierający numer kroku do którego nastąpi skok. Rysunek 9 ilustruje nam skok do kroku System <wy wietla list z wszystkimi u ytkownikami>. 2. Administrator wykonuje operacj na u ytkownikach: 2.1. Albo: Administrator dodaje nowego u ytkownika Administrator <podaje dane nowego u ytkownika> System [waliduje poprawno nazwy u ytkownika] System <potwierdza dodanie u ytkownika> Lub: Administrator <usuwa jednego z u ytkowników>. 3. Administrator <wylogowuje si z panelu administratora>. Rozszerzenia: A. Podane dane s niepe ne, lub nieprawid owe A.1. System <wy wietla komunikat o b dzie> i wraca do kroku {2.1.1.} Rys.9. Przykładowy przypadek użycia w języku FUSE z użyciem znaczników. Generator diagramów użycia napotykając na konstrukcję Albo-Lub pyta się użytkownika, którą drogę w scenariuszu ma wybrać, symulując tym samym niedeterministyczny wybór jednej z kilku alternatywnych kroków scenariusza głównego. Przypadek użycia zapisany w języku FUSE przedstawiony na rysunku 4 wzbogacony odpowiednimi znacznikami widnieje na rysunku 9. Na tej podstawie animator przypadków

8 8 użycia wygeneruje diagram przedstawiony na rysunku 10. Należy zwrócić uwagę na pierwszy komunikat bez nazwy. Został on dodany przez animator w celu uzupełnienia brakującej akcji (istnieje reakcja systemu bez poprzedzającej akcji użytkownika). Rys.10. Diagram wygenerowany na podstawie przypadku przedstawionego na rysunku YY. 7. ZAKOŃCZENIE Pierwsza wersja narzędzia UC Workbench, którego częścią jest opisany animator przypadków użycia została sprawdzona w warunkach akademickich i jest obecnie stosowana w firmie PB Polsoft, zatrudniającej ponad 100 programistów. Sam animator, będący na razie w fazie prototypowej, jest intensywnie rozwijany. Wierzymy, że poza funkcją obrazowania poszczególnych scenariuszy przypadków użycia, zastosowanie generatora diagramów będzie dużo szersze od tego pokazanego w artykule (np. generowanie scenariuszy testowych). BIBLIOGRAFIA [1] Adolph S., Bramble P., Cockburn A., Pols A.: Patterns for Effective Use Cases. Addisson- Wesley, 2002 [2] Cockburn A.: Writing Effective Use Cases. Addisson-Wesley, 2000 [3] [4] Sinan Si Alhir: UML In A Nutshell A Desktop Quick Reference. O Reilly, 1998 [5] Schneider G., Winters J.: Applying Use Cases. A Practical Guide. Addisson-Wesley, 2001 [6] Jacobson I. Object-Oriented Software Engineering. Addisson-Wesley, 1992 USE CASES ANIMATION WITH SEQUENCE DIAGRAMS Summary

9 Animacja przypadków użycia za pomocą diagramów sekwencji 9 This paper presents concept of sequence diagram generator from use cases. Sequence diagrams visualize complex scenarios and helps to understand them. Presented tool is a part of UC Workbench an integrated environment for use case engineering.

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

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 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

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

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

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

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

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

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

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie

Bardziej szczegółowo

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI DIAGRAMY INTERAKCJI DIAGRAMY STEROWANIA INTERAKCJĄ Diagramy sterowania interakcją dokumentują logiczne związki między fragmentami interakcji. Podstawowe kategorie pojęciowe diagramów sterowania interakcją

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

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

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw

Bardziej szczegółowo

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

Bardziej szczegółowo

wersja dokumentu 1.0 data wydania 2008.11.14

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

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

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

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

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

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

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 projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.

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

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia

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

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej

Bardziej szczegółowo

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

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

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 i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II) Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II) Jacek Cichosz www.zssk.pwr.wroc.pl Katedra Systemów i Sieci Komputerowych Politechnika Wrocławska Narzędzia modelowania

Bardziej szczegółowo

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

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

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Warszawa, 09 grudnia 2014 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.3 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...

Bardziej szczegółowo

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju

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

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams Cele przedsięwzięcia Określanie wymagań Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy

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

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 czynności Na podstawie UML 2.0 Tutorial

Diagramy czynności Na podstawie UML 2.0 Tutorial Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/

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

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

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

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Opracował: Jan Front

Opracował: Jan Front Opracował: Jan Front Sterownik PLC PLC (Programowalny Sterownik Logiczny) (ang. Programmable Logic Controller) mikroprocesorowe urządzenie sterujące układami automatyki. PLC wykonuje w sposób cykliczny

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 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

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

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS 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

Bardziej szczegółowo

GML w praktyce geodezyjnej

GML w praktyce geodezyjnej GML w praktyce geodezyjnej Adam Iwaniak Kon-Dor s.c. Konferencja GML w praktyce, 12 kwietnia 2013, Warszawa SWING Rok 1995, standard de jure Wymiany danych pomiędzy bazami danych systemów informatycznych

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem

Inżynieria Programowania Zarządzanie projektem Inżynieria Programowania Zarządzanie projektem Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 12 października 2015 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4 5 Plan wykładu 1 2 3 4

Bardziej szczegółowo

Wszystko na temat wzoru dokumentu elektronicznego

Wszystko na temat wzoru dokumentu elektronicznego Stowarzyszenie PEMI Wszystko na temat wzoru dokumentu elektronicznego Czym jest, kto go tworzy, kto publikuje, kto może z niego skorzystać? Mirosław Januszewski, Tomasz Rakoczy, Andrzej Matejko 2007-07-25

Bardziej szczegółowo

1 Podstawy c++ w pigułce.

1 Podstawy c++ w pigułce. 1 Podstawy c++ w pigułce. 1.1 Struktura dokumentu. Kod programu c++ jest zwykłym tekstem napisanym w dowolnym edytorze. Plikowi takiemu nadaje się zwykle rozszerzenie.cpp i kompiluje za pomocą kompilatora,

Bardziej szczegółowo

REFERAT O PRACY DYPLOMOWEJ

REFERAT O PRACY DYPLOMOWEJ REFERAT O PRACY DYPLOMOWEJ Temat pracy: Projekt i budowa systemu zarządzania treścią opartego na własnej bibliotece MVC Autor: Kamil Kowalski W dzisiejszych czasach posiadanie strony internetowej to norma,

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

Projektowanie baz danych za pomocą narzędzi CASE

Projektowanie baz danych za pomocą narzędzi CASE Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software

Bardziej szczegółowo

Spis treści. Rozdział 1. Aplikacje konsoli w stylu ANSI C i podstawowe operacje w Visual C++... 7

Spis treści. Rozdział 1. Aplikacje konsoli w stylu ANSI C i podstawowe operacje w Visual C++... 7 Spis treści Wprowadzenie...n...n... 5 Jak korzystać z tej książki?...t... 6 Rozdział 1. Aplikacje konsoli w stylu ANSI C i podstawowe operacje w Visual C++... 7 Podsumowanie...t...t...15 Rozdział 2. Rozdział

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd

Bardziej szczegółowo

Elektroniczny Urząd Podawczy

Elektroniczny Urząd Podawczy Elektroniczny Urząd Podawczy Dzięki Elektronicznemu Urzędowi Podawczemu Beneficjent może wypełnić i wysłać formularz wniosku o dofinansowanie projektów w ramach Regionalnego Programu Operacyjnego Województwa

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

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

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki. Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.

Bardziej szczegółowo

Podręcznik użytkownika Obieg dokumentów

Podręcznik użytkownika Obieg dokumentów Podręcznik użytkownika Obieg dokumentów Opracowany na potrzeby wdrożenia dla Akademii Wychowania Fizycznego im. Eugeniusza Piaseckiego w Poznaniu W ramach realizacji projektu: Uczelnia jutra wdrożenie

Bardziej szczegółowo

Instrukcja Użytkownika (Nauczyciel Akademicki) Akademickiego Systemu Archiwizacji Prac

Instrukcja Użytkownika (Nauczyciel Akademicki) Akademickiego Systemu Archiwizacji Prac Instrukcja Użytkownika (Nauczyciel Akademicki) Akademickiego Systemu Archiwizacji Prac Akademicki System Archiwizacji Prac (ASAP) to nowoczesne, elektroniczne archiwum prac dyplomowych zintegrowane z systemem

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Wykorzystanie przypadków użycia do opisywania procesów biznesowych

Wykorzystanie przypadków użycia do opisywania procesów biznesowych OPISYWANIE PROCESÓW BIZNESOWYCH PRZY POMOCY PRZYPADKÓW UŻYCIA 1 Wykorzystanie przypadków użycia do opisywania procesów biznesowych Łukasz Olek 1 Lukasz.Olek@cs.put.poznan.pl Streszczenie Procesy biznesowe

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

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

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Instrukcja użytkownika NAUCZYCIELA AKADEMICKIEGO SYSTEMU ARCHIWIZACJI PRAC

Instrukcja użytkownika NAUCZYCIELA AKADEMICKIEGO SYSTEMU ARCHIWIZACJI PRAC Instrukcja użytkownika NAUCZYCIELA AKADEMICKIEGO SYSTEMU ARCHIWIZACJI PRAC 1. Logowanie do systemu ASAP Logowanie do systemu ASAP odbywa się na stronie www. asap.pwsz-ns.edu.pl W pola login i hasło znajdujące

Bardziej szczegółowo

The development of the technological process in an integrated computer system CAD / CAM (SerfCAM and MTS) with emphasis on their use and purpose.

The development of the technological process in an integrated computer system CAD / CAM (SerfCAM and MTS) with emphasis on their use and purpose. mgr inż. Marta Kordowska, dr inż. Wojciech Musiał; Politechnika Koszalińska, Wydział: Mechanika i Budowa Maszyn; marteczka.kordowska@vp.pl wmusiał@vp.pl Opracowanie przebiegu procesu technologicznego w

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa pliku Tom 6 Opis oprogramowania, Część 2 Generator danych

Bardziej szczegółowo

Przewodnik Użytkownika systemu POL-index. Opis formatu POL-index

Przewodnik Użytkownika systemu POL-index. Opis formatu POL-index Przewodnik Użytkownika systemu POL-index Opis formatu POL-index Opis formatu POL-index UWAGA: ze względu na krótki termin, jaki upłynął od komunikatu Ministra Nauki i Szkolnictwa Wyższego uruchamiający

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Spis treści. Część I Diagramy języka UML 2.1 11. Wstęp 7. Rozdział 1. Studia przypadków 13. Rozdział 2. Diagramy przypadków użycia 29

Spis treści. Część I Diagramy języka UML 2.1 11. Wstęp 7. Rozdział 1. Studia przypadków 13. Rozdział 2. Diagramy przypadków użycia 29 Spis treści Wstęp 7 Część I Diagramy języka UML 2.1 11 Rozdział 1. Studia przypadków 13 1.1. Składanie zleceń przez Dom Maklerski 13 1.2. System Informatyczny GPW 16 1.3. Integracja systemów firm z systemem

Bardziej szczegółowo

Zintegrowany System Informatyczny Moduł Operacji Lotniczych (ZSI-MOL)

Zintegrowany System Informatyczny Moduł Operacji Lotniczych (ZSI-MOL) Zintegrowany System Informatyczny Moduł Operacji Lotniczych (ZSI-MOL) Instrukcja Użytkownika Publicznego Wydanie 1 zmiana 0 NIP: 5252259585 REGON: 015336777 KRS: 0000155328 DUNS: 367459273 WYKAZ WPROWADZONYCH

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

Przejrzystość, intuicyjny charakter i łatwość oprogramowania sterowników FATEK.

Przejrzystość, intuicyjny charakter i łatwość oprogramowania sterowników FATEK. Darmowe oprogramowanie narzędziowe sterowników PLC FATEK. Przejrzystość, intuicyjny charakter i łatwość oprogramowania sterowników FATEK. WinProllader jest prostym interfejsem użytkownika służącym do programowania

Bardziej szczegółowo

Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM

Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM Poznań 2011 Spis treści 1. Wstęp...3 2. Tworzenie informacji o zasobach czasopisma...4 3. Rekord karty wpływu...5 4. Tworzenie

Bardziej szczegółowo

Systemy ekspertowe i ich zastosowania. Katarzyna Karp Marek Grabowski

Systemy ekspertowe i ich zastosowania. Katarzyna Karp Marek Grabowski Systemy ekspertowe i ich zastosowania Katarzyna Karp Marek Grabowski Plan prezentacji Wstęp Własności systemów ekspertowych Rodzaje baz wiedzy Metody reprezentacji wiedzy Metody wnioskowania Języki do

Bardziej szczegółowo

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Projektowanie systemów informatycznych. Diagramy przypadków użycia Informacje ogólne i przykłady Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski jako narzędzie modelowania wymagań Nazwa use case diagrams. Cel stosowania Określenie wymagań

Bardziej szczegółowo

Definicje. Algorytm to:

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

Bardziej szczegółowo

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna 1. Wstęp Wprowadzenie do PKI Infrastruktura klucza publicznego (ang. PKI - Public Key Infrastructure) to termin dzisiaj powszechnie spotykany. Pod tym pojęciem kryje się standard X.509 opracowany przez

Bardziej szczegółowo

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10.1. Co to są dokumenty i zapisy w systemie zarządzania bezpieczeństwem i higieną pracy? W każdym systemie zarządzania dokumentacja

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Inżynieria oprogramowania wykład IV Faza określenia wymagań

Inżynieria oprogramowania wykład IV Faza określenia wymagań Inżynieria oprogramowania wykład IV Faza określenia wymagań prowadzący: dr inż. Krzysztof Bartecki Faza określenia wymagań Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza

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

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

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II

Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Zespół TI Instytut Informatyki Uniwersytet Wrocławski ti@ii.uni.wroc.pl http://www.wsip.com.pl/serwisy/ti/ Rozkład materiału do nauczania informatyki w liceum ogólnokształcącym Wersja II Rozkład wymagający

Bardziej szczegółowo