Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

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

Download "Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady"

Transkrypt

1 Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

2 Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!! określenie wymagań!!! Podejście przypadków użycia ma przede wszystkim na względzie ten problem.

3 Definicje Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy. Przypadek użycia specyfikuje zachowanie systemu lub jego części. Jest to opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach opartych na UML przypadkom użycia przypisuje się szczególne znaczenie jako środka napędzającego cały proces rozwoju systemu.

4 Przypadki użycia w analizie Eksperci Potrzeby Pomysły Koncepcja zastosowania Doświadczenie w dziedzinie przedmiotowej Model dziedziny Kompletny model analizy Technologie Przypadki użycia Model zastosowania Użytkownicy mocny wpływ słaby wpływ

5 Przypadki użycia w analizie c.d. Cele : głębsze zrozumienie użycia systemu (z punktu widzenia użytkownika) zwiekszenie stopnia świadomości analityków i projektantów umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu weryfikacja poprawności i kompletności projektu ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu dostarczenie podstawy do sporządzenia planu testów systemu

6 Projektowanie mieszkania Co bierzemy pod uwagę? poruszanie się po mieszkaniu miejsce na urządzenia, np. w kuchni szybka droga z garażu do kuchni odpowiednia wielkość pokoi... analiza oparta na przypadkach użycia W ten sposób kształtuje się architekturę mieszkania Konsultacja z architektem (ekspertem)

7 Zalety zastosowania Nie narzucają sposobu implementacji pozwalają zapomnieć o strukturze i architekturze systemu i jego detalach technicznych na etapie analizy Użytkownicy i eksperci mogą rozmawiać z projektantami i programistami bez konieczności analizowania nieistotnych szczegółów Intuicyjna reprezentacja funkcjonalna systemu, nie wprowadza komputerowego żargonu Posiadają notację graficzną Język zunifikowany, znany na całym świecie

8 Aktor Używa systemu na wiele sposobów (przypadków użycia) Jest sprawcą zdarzeń powodujących uruchomienie przypadków użycia Odbiera informacje wyprodukowane przez system Jest modelem (obiektem), nie konkretną osobą reprezentuje rolę, jaką może grać konkretny użytkownik Można tworzyć aktorów abstrakcyjnych (nadklasy)

9 Notacje 1. Graficzna 2. Tekstowa

10 Notacja graficzna - pojęcia Przypadek użycia To unikalna nazwa, która opisuje przypadek z punktu widzenia głównego aktora Aktor Reprezentuje zbiór ról odgrywanych przez użytkowików przypadku użycia. Zwykle jest to człowiek, maszyna, inny system Powinien mieć unikalną, jednoznaczną nazwę

11 Notacja graficzna - pojęcia c.d. Interakcje Pokazuje związek między przypadkiem użycia i aktorem (środowiskiem zewnętrznym) Blok ponownego użycia weryfikacja klienta Pokazuje pewien fragment działalności systemu, który jest używany w kilku przypadkach użycia. (Może być także oznaczony jako samodzielny przypadek użycia).

12 Notacja graficzna - pojęcia c.d. Asocjacje z blokiem ponownego użycia Pokazuje związek przypadku użycia z pewnym blokiem ponownego użycia Nazwa systemu wraz z granicami systemu System obsługi klienta Pokazuje granicę pomiędzy systemem i jego otoczeniem...system informacyjny...

13 Przykład diagramu PU (Siergiej) wpłata pieniedzy klient banku wypłata pieniedzy Woperacjach wpłaty i wypłaty pieniędzy uczestniczą takze inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujacy wpłata pieniedzy klient banku wypłata pieniedzy kasjer

14 Przykład diagramu PU 2 Automat do sprzedaży papierosów uzupełnienie towaru zakup paczki papierosów operacje pieniężne klient sporządzenie raportów operator kontroler

15 <<rozszerza>> i <<używa>> Relacje pomiędzy przypadkami użycia rejestracja klienta używa używa używa sprzedaż samochodu używa: wskazuje na wspólny fragment wielu przypadków użycia, wyłączony przed nawias (w tym sensie jest abstrakcyjny, podobieństwo do dziedziczenia) przegląd samochodu rozszerza umycie samochodu rozszerza naprawa samochodu rozszerza przyholowanie samochodu rozszerza: strzałka prowadzi od przypadku użycia, który czasami (nie zawsze) rozszerza przypadki użycia.

16 Powiązania w modelu PU «uses» Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia) na zasadzie podobnej do wywołania procedury. «extends» Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny. Zmiany: «uses» «import», «extends» «extend»

17 Zależności czasowe między PU Właściwie nie występuje w tym modelu nacisk na uwzględnianie zależności czasowych między przypadkami użycia, tzn. nie interesuje nas wzajemna kolejność przypadków użycia (co oznacza, że mogą być konstruowane w dowolnej kolejności), ale jeśli... p1 <<używa>> p2 Przebieg podstawowy - p1 (przypadek bazowy, podstawowy) zawsze używa p2, a więc p1 musi być pierwsze w kolejności działania. p1 <<rozszerza>> p2 Przebieg opcjonalny - p1 (przypadek bazowy) jest czasami rozszerzane o p2, tutaj też p1 musi być pierwsze w kolejności działania.

18 Przykład diagramu 3 (Bartek) Automat do operacji bankowych Baza danych banku Prowadzenie konta klienta <<używa>> Klient Administrator systemu Informowanie o stanie konta klienta Inicjalizacja karty klienta <<używa>> <<używa>> Weryfikacja karty i kodu klienta

19 Notacja tekstowa Przypadek użycia może być wyspecyfikowany przez opisanie ciągu zdarzeń w formie tekstu zrozumiałego nawet dla laika. Wymagane informacje : Jak i kiedy zaczyna się i kończy Kiedy dochodzi do interakcji z aktorami Jakie obiekty są przekazywane Główny ciąg zdarzeń

20 Notacja tekstowa - przykład Weryfikacja użytkownika Główny ciąg zdarzeń : Przypadek użycia zaczyna się, gdy system pyta klienta o PIN. Klient może teraz wprowadzić hasło z klawiatury. Klient potwierdza wprowadzone dane za pomocą klawisza Wykonaj. System sprawdza poprawność PIN`u. Jeśli jest on poprawny, system informuje o tym. Na tym kończy się przypadek użycia. Nadzwyczajny ciąg zdarzeń : Klient może w każdej chwili anulować transakcję, naciskając klawisz Stop. Przypadek użycia wraca teraz do punktu początkowego. Na koncie klienta nie zachodzą żadne zmiany

21 Przykład c.d. Weryfikacja użytkownika Nadzwyczajny ciąg zdarzeń : Przed potwierdzeniem PIN`u Klient może w każdej chwili wprowadzić go jeszcze raz. Nadzwyczajny ciąg zdarzeń : Gdy klient wprowadzi błędny PIN, przypadek użycia wraca do punktu początkowego. Gdy zdarzy się to trzy razy z rzędu, system anuluje całą transakcję i przez 60 sekund nie reaguje na żadne działania klienta.

22 Rozbudowa modelu PU (Siergiej) wpłata pieniedzy wpłata pieniedzy wypłata pieniedzy kasjer wypłata pieniedzy kasjer używa klient banku sprawdź bilans klient banku sprawdź bilans weź pożyczkę zarząd banku weź pożyczkę zarząd banku

23 Charakterystyka PU W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich w postaci scenariuszy. programista edycja programu używa wykonanie programu kompilacja programu używa drukowanie pliku Tworzenia przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. użytkownik

24 Opis przypadków użycia Co powinien zawierać opis przypadku użycia? Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: 1) Jak i kiedy przypadek użycia zaczyna się i kończy? 2) Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. 3) Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie? 4) Wyjątki przy przepływie zdarzeń. 5) Jak i kiedy używane są pojęcia dziedziny problemowej?

25 Dokumentacja PU 1. Krótki opis przypadku użycia 2. Przepływ zdarzeń opisany nieformalnie 3. Asocjacje pomiędzy przypadkami użycia 4. Uczestniczące obiekty 5. Specjalne wymagania (np. czas odpowiedzi, wydajność) 6. Obrazy interfejsu użytkownika 7. Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów) 8. Diagramy interakcji dla każdego aktora

26 Metoda oparta na PU Metoda dotyczy analizy wymagań i opiera się na kilku krokach. Jednocześnie jest budowany obiektowy model dziedziny. Metoda jest oparta na ścisłej współpracy z przyszłym użytkownikiem. Nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Krok Sporządzenie słownika pojęć Udokumentowany w: Słownik pojęć Ustalenie aktorów Ustalenie przypadków użycia Dokument opisu aktorów Opis każdego przypadku użycia: * podział na nazwane części * wyspecyfikowanie w szczegółach * znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia

27 Sporządzenie słownika pojęć Polega na wyłowieniu wszystkich terminów z początkowych wymagań. Słownik dotyczy dziedziny problemowej. Terminy ze słownika powinny być normą przy opisie problemu, sytuacji lub modelu. Powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, aktywności, zdarzeń, itd. Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: * na rzeczowniki: mogą one oznaczać aktorów lub obiekty dziedziny problemowej * na frazy opisujące funkcje, akcje, zachowanie się: mogą one być podstawą wyróżnienia przypadków użycia.

28 Ustalenie aktorów Jaka grupa potrzebuje wspomagania ze strony systemu? Jacy użytkownicy są konieczni do tego, aby system? Funkcje należy rozbić na odnoszące się do - dziedziny przedmiotowej (np. osoba rejestrująca) i - wspomagania systemu (np. administrator systemu) Z jakiego sprzętu zewnętrznego (komputerów, sieci, itp.) musi korzystać system aby realizować swoje funkcje. Wyszukanie potencjalnych aktorów musi być powiązane z ustaleniem granic systemu, tj. odrzucenia obszarów dziedziny problemowej, którymi system nie zajmuje się.

29 Ustalenie aktorów c.d. Po wyszukaniu aktorów, należy ustalić: - czy jest to aktor konkretny (Jan Kowalski), czy też określenie roli (magazynier) -nazwę dla każdego aktora/roli - zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy warto ustalić hierarchię dziedziczenia dla aktorów. -opisać relacje pomiędzy konkretnymi użytkownikami i aktorami -czy użytkownik może łączyć funkcje kilku aktorów i jakich

30 Analiza aktorów Jakie jest główne zadanie dla każdego aktora? Czy aktor będzie czytał/pisał/zmieniał informację w systemie? Czy aktor ma informować system o zmianach na zewnątrz? Użytkownik Aktor Przypadek użycia Jest związany z: Może grać rolę Jan Kowalski Administrator systemu Przeładowanie systemu Adam Malina Pracownik Wejście z kartą i kodem Gość Osoba informowana Informacja ogólna Konkretny klient Klient Wypłata z konta

31 Ustalenie przypadków użycia Dla każdego aktora, znajdź zadania i funkcje, które powinien wykonywać w związku z jego działalnością w zakresie dziedziny przedmiotowej jak i systemu informacyjnego. Staraj się powiązać w jeden przypadek użycia zespół funkcji i zadań wspólnie realizujących ten sam cel. Unikaj rozbicia jednego przypadku użycia na wiele pod-przypadków, o ile każdy z nich realizuje cel cząstkowy, który musi być uzupełniony przez inne funkcje lub zadania. Nazwy dla przypadków użycia: powinny być krótkie ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta. Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika. Uporządkuj aktorów i przypadki użycia w postaci diagramu. Niektóre z powstałych w ten sposób przypadków użycia mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione.

32 Specyfikacja każdego PU Wyodrębnij przypadki bazowe, tj. takie, które stanowią istotę zadania lub funkcji, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. Nazwij te przypadki bazowe ; nazwy powinny być proste i zrozumiałe. Ustal wzajemne powiązanie przypadków bazowych, poprzez ustalenie ich sekwencji, alternatywy, zależności, związku przyczyna-skutek, itd. Dodaj zachowanie skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków bazowych z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę. Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków wielokrotnego użycia. Struktura nie może być zbyt duża i złożona. Staraj się wyizolować bloki wielokrotnego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków występujących w ich specyfikacji. Wydzielenie bloku wielokrotnego użycia może być powiązane z określeniem nieco bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji.

MAS dr. Inż. Mariusz Trzaska

MAS dr. Inż. Mariusz Trzaska MAS dr. Inż. Mariusz Trzaska Wykład 2 Model przypadków użycia Zagadnienia Prezentowanie diagramów Stereotypy; komentarze Klasyfikatory; wystąpienia klasyfikatorów Związki pomiędzy elementami modelowania

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

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

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

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

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

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

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

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

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

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

Rysunek 1: Przykłady graficznej prezentacji klas.

Rysunek 1: Przykłady graficznej prezentacji klas. 4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez

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

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żynierski Projekt Zespołowy

Inżynierski Projekt Zespołowy Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,

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

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

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

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

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements

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

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

Diagramy klas. WYKŁAD Piotr Ciskowski

Diagramy klas. WYKŁAD Piotr Ciskowski Diagramy klas WYKŁAD Piotr Ciskowski przedstawienie statyki systemu graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi obiekty byt, egzemplarz

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

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

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

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

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

Systemy informatyczne. Modelowanie danych systemów informatycznych

Systemy informatyczne. Modelowanie danych systemów informatycznych Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji

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

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

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

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

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

Modelowanie testów. czyli po co testerowi znajomość UML

Modelowanie testów. czyli po co testerowi znajomość UML Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015 Naturalny opis świata Powstaje pytanie, jak opisać ten świat, aby opis był jak najbardziej zbliżony do rzeczywistości,

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

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

UML. zastosowanie i projektowanie w języku UML

UML. zastosowanie i projektowanie w języku UML UML zastosowanie i projektowanie w języku UML Plan Czym jest UML Diagramy przypadków użycia Diagramy sekwencji Diagramy klas Diagramy stanów Przykładowe programy Visual Studio a UML Czym jest UML UML jest

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

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

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

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Modelowanie obiektowe - Ćw. 5.

Modelowanie obiektowe - Ćw. 5. 1 Modelowanie obiektowe - Ćw. 5. Treść zajęć: Dokumentacja przypadków użycia tworzenie scenariuszy. Diagramy przypadków użycia przedstawiają bardzo ogólny obraz systemu, nie pozwalają jednak na przedstawienie

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

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami

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

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. PRACA DYPLOMOWA WYŻSZE STUDIA ZAWODOWE MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. Marcin Brudka 3901 Promotor: Prof. dr hab. inż. Piotr

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

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

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

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

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

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

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni Akademia Morska w Gdyni Gdynia 2004 1. Podstawowe definicje Baza danych to uporządkowany zbiór danych umożliwiający łatwe przeszukiwanie i aktualizację. System zarządzania bazą danych (DBMS) to oprogramowanie

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

Zagadnienia (1/3) Inżynieria Oprogramowania

Zagadnienia (1/3) Inżynieria Oprogramowania Zagadnienia (1/3) Pozyskiwanie i analiza Reprezentacje na poszczególnych etapach projektu Najczęściej pojawiające się problemy podczas pozyskiwania oraz metody ich rozwiązywania Reprezentacja z punktu

Bardziej szczegółowo

AKADEMIA GÓRNICZO-HUTNICZA

AKADEMIA GÓRNICZO-HUTNICZA AKADEMIA GÓRNICZO-HUTNICZA Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI Event Visualizator sprawozdanie z przebiegu projektu wersja 1.1 z dnia 15.06.2011 Kierunek,

Bardziej szczegółowo

- Przypadki Użycia - Diagramy Przypadków Użycia

- Przypadki Użycia - Diagramy Przypadków Użycia - Przypadki Użycia - Diagramy Przypadków Użycia Wersja elektroniczna: mgr inż. Kamil Kuliberda; na podstawie UML przewodnik użytkownika, Grady Booch, Jamek Rumbaugh, Ivar Jacobson. Przypadki Użycia Poruszone

Bardziej szczegółowo

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie klas i obiektów Jarosław Kuchta Podstawowe pojęcia (1) Byt, encja (entity) coś co istnieje, posiada własne cechy i wyodrębnioną tożsamość (identity); bytem może być rzecz, osoba, organizacja,

Bardziej szczegółowo

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) 1. Wstęp: 1.1. Cel. Niniejszy dokument przestawia specyfikację wymagań systemowych (zarówno funkcjonalnych jak i niefunkcjonalnych)

Bardziej szczegółowo

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

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

Programowanie komputerów

Programowanie komputerów Programowanie komputerów Wykład 1-2. Podstawowe pojęcia Plan wykładu Omówienie programu wykładów, laboratoriów oraz egzaminu Etapy rozwiązywania problemów dr Helena Dudycz Katedra Technologii Informacyjnych

Bardziej szczegółowo

PRYWATNA WYŻSZA SZKOŁA BUSINESSU, ADMINISTRACJI I TECHNIK KOMPUTEROWYCH S Y L A B U S

PRYWATNA WYŻSZA SZKOŁA BUSINESSU, ADMINISTRACJI I TECHNIK KOMPUTEROWYCH S Y L A B U S PRYWATNA WYŻSZA SZKOŁA BUSINESSU, ADMINISTRACJI I TECHNIK KOMPUTEROWYCH ZATWIERDZAM Prorektor ds. dydaktyki i wychowania S Y L A B U S 1 Tytuł (stopień) naukowy oraz imię i nazwisko wykładowcy: dr hab.,

Bardziej szczegółowo

TWORZENIE GRY. projektowanie konstruowanie. użycie. R. Duke, Gaming the Future s Language, SAGE Publications, New York, 1974

TWORZENIE GRY. projektowanie konstruowanie. użycie. R. Duke, Gaming the Future s Language, SAGE Publications, New York, 1974 TWORZENIE GRY Projektowanie gry jest połączeniem naśladownictwa istniejących już formatów gier, nieuchwytnej, ale prawdziwej sztuki i pewnych zasad projektowania, z których część jest już dobrze określona

Bardziej szczegółowo

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

Laboratorium 6 DIAGRAM KLAS (Class Diagram) Laboratorium 6 DIAGRAM KLAS (Class Diagram) Opisuje strukturę programu (a także zależności między nimi), co znajduje odzwierciedlenie w kodzie. Charakteryzuje zależności pomiędzy składnikami systemu: klasami,

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

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania... Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...

Bardziej szczegółowo

RELACYJNE BAZY DANYCH

RELACYJNE BAZY DANYCH RELACYJNE BAZY DANYCH Aleksander Łuczyk Bielsko-Biała, 15 kwiecień 2015 r. Ludzie używają baz danych każdego dnia. Książka telefoniczna, zbiór wizytówek przypiętych nad biurkiem, encyklopedia czy chociażby

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

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

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych Wydział Elektroniki Politechniki Wrocławskiej Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych Projekt z przedmiotu Komputerowe Systemy Zarządzania (INE3608) pt. System. Opracowanie:

Bardziej szczegółowo

Diagram maszyny stanowej - POJĘCIA

Diagram maszyny stanowej - POJĘCIA Diagram maszyny stanowej - POJĘCIA Stan : sytuacja w cyklu życia bytu (obiektu, PU, podsystemu, aktora, operacji itp), kiedy spełnia on pewne warunki, realizuje pewną czynność lub czeka na pewne zdarzenie.

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

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

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

Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów

Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów Główny Inspektorat Ochrony Środowiska Projekt Wstępny Systemu Informatycznego Transgranicznego Przemieszczania Odpadów Specyfikacja procesów biznesowych SPIS TREŚCI 1 Wstęp... 4 1.1 Przeznaczenie dokumentu...

Bardziej szczegółowo

APLIKACJA KLIENT-SERWER DO SPORZĄDZANIA I PRZEPROWADZANIA TESTÓW ONLINE - METODYKA ROZWOJU I OPISU APLIKACJI Z WYKORZYSTANIEM UML

APLIKACJA KLIENT-SERWER DO SPORZĄDZANIA I PRZEPROWADZANIA TESTÓW ONLINE - METODYKA ROZWOJU I OPISU APLIKACJI Z WYKORZYSTANIEM UML Scientific Bulletin of Che lm Section of Mathematics and Computer Science No. 1/2008 APLIKACJA KLIENT-SERWER DO SPORZĄDZANIA I PRZEPROWADZANIA TESTÓW ONLINE - METODYKA ROZWOJU I OPISU APLIKACJI Z WYKORZYSTANIEM

Bardziej szczegółowo

2012-03-27. Aktorzy. Wystąpienia aktorów. Opracowano w Lab. Informatyki AGH (Kraków)

2012-03-27. Aktorzy. Wystąpienia aktorów. Opracowano w Lab. Informatyki AGH (Kraków) Podstawowe pojęcia Przypadki użycia (use cases) Aktor spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Opracowano w Lab. Informatyki AGH (Kraków)

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

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

Projektowani Systemów Inf.

Projektowani Systemów Inf. Projektowani Systemów Inf. Wykład VII Bezpieczeństwo Copyrights by Arkadiusz Rzucidło 1 Bezpieczeństwo Bezpieczeństwo związane z danymi Konstrukcja magazynów danych Mechanizmy zapisu i modyfikacji danych

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

MOJA FIRMA PLUS. bankowość elektroniczna dla małych i średnich firm

MOJA FIRMA PLUS. bankowość elektroniczna dla małych i średnich firm MOJA FIRMA PLUS bankowość elektroniczna dla małych i średnich firm Co to jest pakiet Moja Firma Plus? Usługa bankowości elektronicznej MOJA FIRMA PLUS umożliwia łatwy i szybki dostęp do rachunków za pomocą

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

PROJEKT INŻYNIERIA OPROGRAMOWANIA. Temat: System obsługi kasy - projekt wzorcowy

PROJEKT INŻYNIERIA OPROGRAMOWANIA. Temat: System obsługi kasy - projekt wzorcowy Wydział Elektroniki Politechniki Wrocławskiej Kierunek:., Specjalność:... PROJEKT INŻYNIERIA OPROGRAMOWANIA Temat: System obsługi kasy - projekt wzorcowy Opracowanie: dr inż. Paweł Skrobanek Wrocław 2006

Bardziej szczegółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan szkolenia Plan szkolenia Godzina (czas) 10:20 11:20 (60 min) 11:20 11:40 (20 min) 11:40 13:10 (90 min) 13:10 13:30 (20 min) 13:30 15:00 (90 min) Temat Wprowadzenie do UML (Definicja,

Bardziej szczegółowo

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji HumanTechnology Projektowanie interakcji czyli łatanie dziury w procesie produkcji Czym jest projektowanie interakcji? Projektowanie interakcji, czyli współdziałania człowieka z komputerem, wykorzystuje

Bardziej szczegółowo

MOJA FIRMA PLUS. bankowość elektroniczna dla małych i średnich firm

MOJA FIRMA PLUS. bankowość elektroniczna dla małych i średnich firm MOJA FIRMA PLUS bankowość elektroniczna dla małych i średnich firm CO TO JEST PAKIET MOJA FIRMA PLUS? Usługa bankowości elektronicznej MOJA FIRMA PLUS umożliwia łatwy i szybki dostęp do rachunków za pomocą

Bardziej szczegółowo

MODELOWANIE PRZEPŁYWU DANYCH

MODELOWANIE PRZEPŁYWU DANYCH MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu

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