Analiza i projektowanie aplikacji 3. 4.Modelowanie struktury. Diagram klas. 5.Strukturalizowanie modelu PU. Model systemowych PU.
|
|
- Urszula Ostrowska
- 7 lat temu
- Przeglądów:
Transkrypt
1 Analiza i projektowanie aplikacji 3 4.Modelowanie struktury. Diagram klas. 5.Strukturalizowanie modelu PU. Model systemowych PU. 6.Metodyka ZP/RUP o modelowaniu biznesowym i wymaganiach do SI. 1
2 Obiekty i klasy Obiekt: byt o dobrze określonych granicach, który ma tożsamość, cechy statyczne (wartości atrybutów i związki z innymi obiektami), które określają jego stan oraz cechy dynamiczne, które określają jego zachowanie. Obiekt łączy w sobie dane i funkcje. rekućkonto:konto numer:231 właściciel: Ludmiła Rekuć saldo: :Student indeks: nazwisko: Kowalski imie: Jan księgowość 2
3 Obiekty i klasy Klasa: reprezentacja wspólnych cech grupy obiektów, które mają takie same właściwości, stany, zachowanie, związki i znaczenie. Obiekt jest egzemplarzem (instancją, wystąpieniem, urzeczywistnieniem) klasy. Konto numer:int właściciel:string saldo: double depozyt() wypłata() Nazwa klasy jest obowiązkowa Sekcja atrybutów (opcjonalna). Atrybut: nazwana właściwość związana z dziedziną wartości. Uwaga! Wartość atrybutu może byc typu prostego, być obiektem innej lub tej samej klasy, być zbiorem obiektów. Sekcja operacji (opcjonalna). Operacja: nazwana usługa realizowana przez obiekt. 3
4 Identyfikacja klas Dziedzina wiedzy Nazw a atrybut1 atrybut2 atrybut3 oper1() oper2() rzeczowniki rzeczowniki - dopełniacze. czasowniki. 4
5 Związki klas - powiązanie Powiązanie(asocjacja) Zespół 0..1 członek 2..* Osoba Powiązanie klas wskazuje na związek między ich obiektami oznaczane jest linią ciągłą; może mieć nazwę z ewentualnie dodanym kierunkiem odczytu; ma końce (dwa lub więcej) wskazujące na klasy; końce mogą być oznaczone nazwami ról, w których występują w związku obiekty danych klas; na końcu związku może być pokazana liczebność (krotność), która wskazuje, ile obiektów danej klasy może być związana z jednym obiektem po drugiej stronie powiązania (tylko w związkach binarnych, wiążących dwie klasy). 5
6 Powiązanie Oznaczenie liczebności:...z jednym obiektem danej klasy może być związany: jeden lub żaden, opcjonalne powiązanie; 0..* jeden, wiele lub żaden, * wiele lub żaden, wskazuje na niedokładność zbadania; 1..* jeden lub wiele; 1 tylko jeden; Brak wiele lub żaden, wskazuje na niedokładność zbadania;(w UML1.5 - tylko jeden). Miasto 1 od * Trasa 1 do * 6
7 Klasa powiązania Firma * 1..* Osoba pracodawca pracownik Zatrudnienie wynagrodzenie zawrzyjumowę Powiązanie, które ma własne atrybuty i/lub operacje może być modelowane jako klasa. 7
8 Klasa powiązania Klasa powiązania Student * zalicza * Kurs 1 klasa powiązania Zaliczenie ocena * 1 Indeks 1 8
9 Klasa zwykła zamiast klasy powiązania: Firma /pracuje dla Osoba Pracodawca Pracownik 1 * 1 * Stanowisko 0..1 Kierownik powiązanie zwrotne 1.. * Podwładny Kieruje 9
10 Agregacja: związek całość składa się z części lub właściciel i jego własność * * 1 Zdjęcie Osoba * DowódTożsamości Agregacja słaba (współdzielona) - pewien obiekt może należeć do wielu innych, jest częścią wielu, oznacza się niewypełnionym rombem po stronie "całości. Agregacja całkowita - kompozycja - wyłączna własność całości nad częścią; czas życia "części" nie może być dłuższy niż czas życia "całości", oznacza się wypełnionym czarnym rombem po stronie "całości"; 10
11 Agregacja, przykłady Trasa * 2..* {ordered} Przystanek Faktura 1 1..* PozycjaFaktury 11
12 Uogólnienie (generalizacja/specjalizacja) Osoba * uczy Student * Wykładowca Uogólnienie: związek między klasą bardziej ogólną (nadklasą) a bardziej specyficzną (podklasą). Podklasa dziedziczy cechy nadklasy: atrybuty operacje związki ograniczenia Podklasy mogą: - dodać nowe cechy do odziedziczonych; - zmienić odziedziczone operacje zapewniając inną treść operacji przy zachowaniu tego samego nagłówka. 12
13 Uogólnienie przykład Zawodnik nazwisko waga wysokość podajpiłkę() strzelkosza() Obrońca róbprzechwyt( ) róbasystę() Skrzydłowy Środkowy zróbwsad() Źródło: J.Schmuller UML dla każdego, HELION, 2003, str
14 Ograniczenia (w nawiasach klamrowych) dodatkowe wymagania, które nie udaje się wyrazić za pomocą standardowych konstrukcji diagramu. Mogą one dotyczyć operacji, związku miedzy atrybutami, wartości atrybutów, powiązań i tp. Konto * {XOR} 1 Osoba Zespół członek * {podzbiór} Osoba Konto jest związane z osobą lub z firmą * 1 Firma 1 szef szef jest jednym z członków zespołu Faktura nr data 1 1..* {ordered} podstawa PozycjaFaktury lp symbol ilość {XOR} oznacza, że wystąpienia związków są alternatywne. {Ordered} - na końcu powiązania oznacza, że jeden obiekt danej klasy może być związany z kilkoma obiektami klasy docelowej i obiekty te są uporządkowane. 14
15 Przykład diagramu klas Egzemplarz * 1 Umiejscowienie nr 1..* Temat nazwa opis * * Dokument 0..1 poprzednik TypDokumentu 1 * tytuł autor datawydania zawartość jest wersją nazwa * * * zawier a 15
16 Diagram obiektów Na diagramie klas klasy i ich związki. Na diagramie obiektów instancje klas i ich związek w pewnej chwili czasowej. Osoba 1..* pracownik 0..* pracodawca Firma Rekuć:Osoba PWr:Firma Dr inż. Ludmiła Rekuć 16 16
17 Diagram klas - przykład Przedsiębiorstwo 0..1 Dział 1..* 0..* jest nadrzędnym dla kierownik 0..1 Osoba 1..* AdresKontaktowy Dr inż. Ludmiła Rekuć 17 17
18 Diagram obiektów PPP SA:Przedsiębiorstwo SPK:Dział PPK:Dział nazwa = "Sprzedaż" nazwa = "Produkcja" SP1:Dział nazwa = "Sprzedaż internetowa" kierownik :Osoba nazwisko = "Kowal" ID = 4389 stanowisko = "Kierownik sprzedaży" :AdresyKontaktowe adres = "Kluczowa 10" Diagram przedstawia obiekty i ich wiązania w konkretnej chwili. Dr inż. Ludmiła Rekuć 18
19 Strukturalizacja modelu PU Uogólnienie (generalizacja) między aktorami - związek między aktorem bardziej ogólnym (rodzicem) a aktorem bardziej wyspecjalizowanym (dzieckiem). Dziecko dziedziczy role ( a więc i powiązania z PU) rodzica. Dr inż. Ludmiła Rekuć 19 19
20 Zatwierdzenie ocen końcowych Wprowadzenie ocen cząstkowych Pracownik dydaktyczny Wprowadzenie kryteriuw obliczania oceny końcowej «extend» P rzejrzenie planu zajęć z zarzadzaniem ocenam i «extend» M odyfikacja sprawdzianu P rzejrzenie planu zajęć Uprawniony pracownik dydaktyczny Dodanie sprawdzianu S prawdzenie ocen z zajęć Student Dr inż. Ludmiła Rekuć Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody modelowania obiektowego HELION,
21 Strukturalizacja Przypadków Użycia (poszukiwanie i wydzielenie pewnych struktur fragmentów PU) Są trzy główne powody strukturalizacji PU: ułatwienie zrozumienia; ułatwienie wielokrotnego użycia specyfikacji PU; ułatwienie utrzymania modelu. Kiedy należy zająć się strukturalizacją PU? Najlepiej zrobić to po szczegółowym opisaniu możliwych przebiegów PU i ich zrozumieniu. W strukturalizacji wykorzystuje się następujące rodzaje związków PU: zależności: zawierania rozszerzenia uogólnienia (generalizacji/specjalizacji). Dr inż. Ludmiła Rekuć 21 21
22 Uogólnienie (generalizacja) między PU: dwa lub więcej PU są specjalizacjami abstrakcyjnego, ogólnego PU. Należy skorzystać z uogólnienia, jeśli prowadzi to do uproszczenia modelu, a nie do jego skomplikowania! PU-dziecko: dziedziczy wszystkie cechy rodzica (związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu); może mieć dodane inne związki, warunki wstępne i końcowe, kroki podstawowego i alternatywnego przebiegu zdarzeń; może zamienić cechy odziedziczone własnymi specyficznymi (za wyjątkiem związków). Dr inż. Ludmiła Rekuć 22 22
23 Jak opisywać na diagramie uogólnione PU? UML tego nie określa. Znajdź Produkt Znajdź Książkę Znajdź CD Styl opisu może być określony wewnętrznym standardem firmy lub zespołu twórców systemu. W przykładzie zastosowano zasadę: jeśli krok zmieniono - został on wyróźniony poprzez napisanie kursywą; jeśli krok dodano: został on wyróźniony poprzez wytłuszczenie. Dr inż. Ludmiła Rekuć 23 23
24 ID: PU11 Przypadek użycia: ZnajdźProdukt Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1. Klient wybiera "Znajdź produkt" 2. System pyta o kryteria wyszukiwania. 3. Klient wprowadza kryteria. 4. System wyszukuje produkty. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Przypadek użycia: ZnajdźKsiążkę ID: PU67 ISA PU11 Aktorzy: Klient Warunek wstępny: Przebieg zdarzeń: 1.Klient wybiera "Znajdź książkę" 2.System pyta o kryteria wyszukiwania książki: autora, tytul, ISBN lub temat. 3. Klient wprowadza kryteria. 4. System wyszukuje książki. 5. Jeśli system znajduje, to 5.1 System wyświetla listę produktów 6. W przeciwnym przypadku 6.1 System komunikuje, że nie znaleziono. Warunki końcowe: Warunki końcowe: Alternatywne przebiegi: Dr inż. Ludmiła Rekuć 24 24
25 Zależność <<zawiera>> ( ang. <<include>>) między PU Jeśli w PU jest taki fragment przebiegu, że: do zrozumienia PU nie są istotne szczegóły przebiegu tego fragmentu, ważny jest jego wynik, nie sposób realizacji, lub Dr inż. Ludmiła Rekuć jeśli stanowi on wspólny fragment wielu przypadków użycia, można ten fragment wyodrębnić w osobny podprzypadek użycia. Wyodrębniona część jawnie jest częścią PU, zawiera się w nim. Używamy w tym przypadku związku zależności <<include>>. Zależność <<include>> oznacza, że operacje "zawieranego" podprzypadku użycia (strzałka na niego wskazuje) są realizowane zawsze w przypadku zawierającym. Notacja: przerywana linia ze strzałką i tekstem <<include>> (lub spolszczonym <<zawiera>>)
26 Zależność zawierania się między PU na diagramie i w opisach: Zamów Produkt <<include>> Znajdź Produkt Przypadek użycia: ZamówProdukt Przypadek użycia: ZnadźProdukt ID: oznaczeniepu11 Aktorzy: Branżysta Warunek wstępny: zalogowany w systemie Przebieg zdarzeń: include (ZnajdźProdukt) 3 ID: oznaczeniepu16 Aktorzy: Branżysta Warunek wstępny: Przebieg zdarzeń: Dr inż. Ludmiła Rekuć 26 26
27 Związek zależności <<rozszerza>> ( ang. <<extend>>) między PU Jeśli fragment PU jest opcjonalny i nie jest konieczny do zrozumienia głównego celu PU, można ten fragment wydzielić w osobny podpu i uprościć tym samym strukturę podstawowego. W tym przypadku używamy związku <<extend>>. Podstawowy PU "nic nie wie" o możliwym jego rozszerzeniu. Rozszerzający podpu musi się "powołać" na miejsce w podstawowym PU na tzw. punkt rozszerzenia. Miejsce to jest oznaczone, ale nie ponumerowane, jest między ponumierowanymi krokami! Dr inż. Ludmiła Rekuć 27 27
28 Zależność rozszerzania między PU na diagramie i w opisach: Zwrot Ksiązki punkt rozszerzenia przeterminowany <<extend>> (przeterminowany) Ukaranie grzywną Przypadek użycia: ZwrotKsiążki ID: PU11 Aktorzy: Bibliotekarz Warunek wstępny: Przebieg zdarzeń: 1. Bibliotekarz wprowadza ID Czytelnika. 2. System wyświetla listę wypożyczonych książek. 3. Bibliotekarz wskazuje książkę zwracaną. <ukaranie grzywną> 4. Bibliotekarz rejestruje zwrot.... Rozszerzający PU: UkaranieGrzywną ID: PU16 Dołączany segment 1: Jeżeli książka przeterminowana: 1. Bibliotekarz wybiera rejestracje zapłaty grzywny. 2. System wyświetla formularz. 3. Bibliotekarz rejestruje opłatę grzywny.... Dr inż. Ludmiła Rekuć 28 28
29 Strukturalizacja PU PU-1 Przyjmij zamówienie Aktorzy Sprzedawca Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna Sprzedawca wybierając odpowiednią opcję. 2. System prezentuje formularz zamówienia. 3. Sprzedawca podaje dane pozwalające zidentyfikować klienta (PESEL lub Nazwisko/Nazwę firmy). 4. System wypełnia formularz zamówienia danymi klienta. 5. Sprzedawca wprowadza pozycje zamówienia. W tym celu dla każdej zamawianej pozycji: 5.1 podaje symbol (z indeksu) lub nazwę produktu. 5.2 system wyszukuje produkt i podaje jego stan; 5.3 sprzedawca potwierdza wybór i podaje ilość; 5.4 system prezentuje wypełnioną pozycję i umożliwia przejście do następnej lub zakończenie. 6. Sprzedawca potwierdza zamówienie. 7. System zapamiętuje zamówienie, rezerwuje zamówione produkty i wraca do poprzedniej opcji. Warunek końcowy: Zamówienie zarejestrowano, produkty zarezerwowano. Alternatywne przebiegi. A1. Nowy klient:ma miejsce po kroku 3, kiedy klient jest obsługiwany po raz pierwszy. Dr 1. inż. Sprzedawca Ludmiła Rekuć wywołuje opcje Nowy klient.... <<zawiera się>> /<<include>> PU-2 Wyszukaj produkt Aktorzy Warunek wstępny: Przebieg zdarzeń: Po wybraniu odpowiedniej opcji system umożliwia podanie nazwy i/lub indeksu produktu, następnie sprawdza stan magazynu i prezentuje wynik. <<rozszerza>> /<<extend>> PU-3 Zarejestruj klienta rozszerzający PU-1 w pkt. Nowy klient Aktorzy Warunek wstępny: Podstawowy przebieg zdarzeń: 1. PU rozpoczyna się wybraniem odpowiedniej opcji po kroku 3 PU-1, jeśli klient po raz pierwszy składa zamówienie. 2. System prezentuje formularz klienta. 3. Aktor podaje nazwisko klienta, PESEL, adres dostarczania zamówionych produktów,
30 ud Gospodarownie nieruchomościami mieszkania Przeprowadź Dokonaj zakupu Dokonaj Petent Dokonaj zakupu komunalnego gruntu komunlanego wydzierżawienia nieruchomosci Zmień zasady wydzierżawienia nieruchomości sesję rady gminy Uzyskaj dodatek mieszkaniowy Ustal granice podziału dla nieruchomości «extend» Rada gminy 30
31 Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Analiza środowiska Cel: zrozumienie organizacji i wyrażenie w modelach. Produkty: model środowiska ( architektura, procesy, słownik). Wizja SI... Wymagania Cel: pozyskanie wymagań i wyrażenie w modelu. Produkty: model PU, dodatkowa specyfikacja, rozbudowany słownik. Analiza Projektowanie 31
32 Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Zbuduj model biznesowych PU Znajdź aktorów SI Znajdź PU SI Nadaj priorytety PU Opisz wstępnie (zrozum) PU Ustrukturalizuj i udokumentuj model PU SI Zbuduj diagram klas dziedziny problemu (kluczowe abstrakcje) Zaktualizuj Wizję i słownik 32
33 Metodyka RUP(ZP) o modelowaniu biznesowym i wymaganiach Uwaga! Dwa modele PU w procesie wytwarzania SI! Model biznesowych PU buduje się, jeśli procesy organizacji są mało znane, trzeba je zrozumieć, żeby trafniej określić wymagania do systemu informatycznego. Byt typu pracownik modelu biznesowych PU często staje się aktorem w modelu systemowych PU. Nadanie priorytetu systemowym PU Kluczowym, wejściowym artefaktem w ustaleniu priorytetu PU jest Wizja, w której określa się, na czym najbardziej zależy zainteresowanym stronom i wymienia zagrożenia. Możliwe kryteria ustalenia priorytetu PU to: - korzyści uzyskiwane przez zainteresowane strony, - wpływ PU na architekturę, - stopień zagrożenia jaki jest związany z PU. 33
34 Pytania kontrolne 1. Czy każda klasa może mieć obiekty? 2. Czy każda sekcja definicji klasy jest obowiązkowa? 3. Czy prawdziwe jest twierdzenie: należy pokazać wszystkie atrybuty klasy lub nie pokazywać je wcale? 4. Czy klasa powiązania może mieć związki z innymi zwykłymi klasami? 5. Co dziedziczy podklasa po nadklasie? 6. Czy mogą wystąpić dwa obiekty klasy z takimi samymi wartościami atrybutów? 7. Jakie związki mogą wystąpić między PU? 8. Czy związek uogólnienia może wystąpić między aktorem a PU? 9. Co to jest punkt rozszerzenia? 10.Jaka jest różnica między zwiazkami include I extend? 34
Modelowanie obiektowe systemów
Modelowanie obiektowe systemów Dr inż. Ludmiła Rekuć www.ioz.pwr.wroc.pl/pracownicy/l_rekuc Literatura Dąbrowski M.,Stasiak A.,Wolski M. Modelowanie systemów informatycznych w języku UML 2. PWN, 2009 Wrycza
Bardziej szczegółowoPlan wykładu 2. Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja
Plan wykładu 2 Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja 1 Model Przypadków Użycia Reprezentuje użytkowanie systemu. Stosuje sie do systemu biznesowego
Bardziej szczegółowoJę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ółowoDiagramy 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ółowoModelowanie 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ółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoDiagramy 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ółowoProjektowanie 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ółowoDiagramy 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ółowoKomputerowe 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ółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
Bardziej szczegółowoModelowanie 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ółowoPodstawy 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ółowoDiagram 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ółowoDiagramy 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Świat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Diagramy przypadków użycia Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu
Bardziej szczegółowoPrzypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady
Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!!
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoRysunek 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ółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoDiagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoINFORMATYKA 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ółowoModelowanie 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ółowoModelowanie obiektowe
Modelowanie obiektowe ZPO 2018/2019 Dr inż. W. Cichalewski Materiały wykonane przez W. Tylman Diagramy klas Diagramy klas Zawiera informacje o statycznych związkach między elementami (klasami) Są ściśle
Bardziej szczegółowoLaboratorium 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ółowoModelowanie 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ółowoPodstawy 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ółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoPodstawy projektowania systemów komputerowych
Podstawy projektowania systemów komputerowych Diagramy klas UML 1 Widok logiczny Widok logiczny Widok fizyczny Widok przypadków użycia Widok procesu Widok konstrukcji Używany do modelowania części systemu
Bardziej szczegółowoMAS dr. Inż. Mariusz Trzaska
MAS dr. Inż. Mariusz Trzaska Wykład 5 Model obiektowy cz. 3 Zagadnienia Dziedziczenie asocjacji Asocjacje pochodne Redukcja liczności Role wielowartościowe Trochę więcej o agregacji Agregacja rekursywna
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoSystemy 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ółowoModelowanie 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ółowoDiagramy 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ółowoCel 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ółowoNarysować diagram sekwencji pokazujący rejestrację wypożyczenia przez Jana Kowalskiego książki Potop
Egzamin: 31/01/2009 Godzina: 14:15 16:00 Opracowano na podstawie przykładowych zadań MODELOWANIE I ANALIZA SYSTEMÓW OPRACOWANIE ZADAŃ Zadanie 1 Zamodeluj funkcjonalność systemu bibliotecznego Należy: Utworzyć
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoDiagramy 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ółowoUML 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ółowoUML - zarys 2007/2008
UML - zarys 2007/2008 Modelowanie Jest ważne przy tworzeniu wysokiej jakości oprogramowania Jest przydatne przy tworzeniu i analizie działania organizacji Modelujemy aby: Zrozumieć system Określić pożądaną
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoSpis 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ółowoInż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ółowoDiagramy 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ółowoJę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 2 Związki między klasami Asocjacja (ang. Associations) Uogólnienie, dziedziczenie
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoPodstawy modelowania w języku UML
Podstawy modelowania w języku UML dr hab. Bożena Woźna-Szcześniak, prof. UJD Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie Wykład 2 Związki między klasami Asocjacja (ang. Associations)
Bardziej szczegółowoInstrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia
Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),
Bardziej szczegółowoTworzenie warstwy zasobów projektowanie metodą strukturalną
Tworzenie warstwy zasobów projektowanie metodą strukturalną Autor Zofia Kruczkiewicz Programowanie i wdrażanie systemów informatycznych 2011-03-27 1 1. Zasady modelowania wymagań funkcjonalnych systemu
Bardziej szczegółowoUML. 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ółowoInż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ółowoUML cz. II. UML cz. II 1/38
UML cz. II UML cz. II 1/38 UML cz. II 2/38 Klasy Najważniejsze informacje o klasie: różnica pomiędzy klasą a jej instancją (obiektem) na podstawie klasy tworzone są obiekty (instancje klasy) stan obiektu
Bardziej szczegółowoBAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski
BAZY DANYCH model związków encji Opracował: dr inż. Piotr Suchomski Świat rzeczywisty a baza danych Świat rzeczywisty Diagram związków encji Model świata rzeczywistego Założenia, Uproszczenia, ograniczenia
Bardziej szczegółowoMODELOWANIE 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ółowoMariusz Trzaska Modelowanie i implementacja systemów informatycznych
Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się
Bardziej szczegółowoAnaliza 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ółowoAgenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia
Analiza biznesowa Agenda Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia Cele projektu Cechy SMART S Specific Precyzyjne M Measurable Mierzalne A Agreed To Zaakceptowane
Bardziej szczegółowoDIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny
DIAGRAM KLAS Kamila Vestergaard materiał dydaktyczny DEFINICJA D I A G R A M K L A S Diagram klas pokazuje wzajemne powiązania pomiędzy klasami, które tworzą jakiś system. Zawarte są w nim informacje dotyczące
Bardziej szczegółowoInż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ółowoProjektowanie systemów informatycznych
Projektowanie systemów informatycznych Zarządzanie projektem Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski Cel wykładu Przedstawienie inżynierii wymagań jako istotnego i
Bardziej szczegółowoKatMPBSoft marekbilski@katmpbsoft.pl - 1 -
Przedstawiona dokumentacja UML jest ściśle chroniona prawami autorskimi. Jej celem jest jedynie pokazanie w jaki sposób firma KatMPBSoft, takie dokumentacje przygotowuje. Dokumentacja UML nie może być
Bardziej szczegółowoInż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ółowoSpecyfikowanie wymagań przypadki użycia
Specyfikowanie wymagań przypadki użycia Prowadzący Dr inż. Zofia 1 La1 La2 Forma zajęć - laboratorium Wprowadzenie do laboratorium. Zasady obowiązujące na zajęciach. Wprowadzenie do narzędzi wykorzystywanych
Bardziej szczegółowoIX Konferencja Informatyki Stosowanej
IX Konferencja Informatyki Stosowanej IX Konferencja Informatyki Stosowanej konkurs na najlepszy program wykonany przez studenta Dokumentacja techniczna aplikacji nazwa aplikacji.. Autor autor, afiliacja..
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA. laboratorium
INŻYNIERIA OPROGRAMOWANIA laboratorium UML 1/4 UML (Unified Modeling Language) - język modelowania obiektowego systemów i procesów [Wikipedia] Spojrzenie na system z różnych perspektyw dzięki zastosowaniu
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie teoretyczne. Rozważana
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek
TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4
Bardziej szczegółowoJęzyk UML. dr inż. Piotr Szwed C3, pok
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,
Bardziej szczegółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoProjektowanie 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ółowoJęzyk UML. dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Diagramy klas Diagramy klas Diagramy klas są najbardziej charakterystycznym elementem wszystkich języków
Bardziej szczegółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
Bardziej szczegółowoAnaliza procesów: notacja UML, modele przypadków użycia, Rich Picture
45 min Ergonomia pracy umysłowej prof. dr hab. inż. Marcin Sikorski Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture 7 Data wykładu:............. Razem slajdów: 23 Sytuacja problemowa
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram
Bardziej szczegółowoWykorzystanie 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ółowoSpis 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ółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie
Bardziej szczegółowoModelowanie 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ółowoMODELOWANIE 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ółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoPodstawy 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ółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoInż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ółowoKarta 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ółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Inżyniera wymagań Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla
Bardziej szczegółowoTechnologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania
Literatura Marek Kisiel-Dorohinicki doroh@agh.edu.pl Brett D. McLaughlin, Gary Pollice, David West Head First Object-Oriented Analysis and Design Martin Fowler UML Distilled ( UML w kropelce ) Grady Booch,
Bardziej szczegółowoSPECYFIKACJA WYMAGAŃ
SPECYFIKACJA WYMAGAŃ Autorzy: Wersja: 2 Historia zmian dokumentu Osoba
Bardziej szczegółowoUML 1 diagramy interakcji
UML 1 diagramy interakcji Materiał na ćwiczenia z rysowania diagramów interakcji wchodzących w skład UMLa. Forma ćwiczeń. Każdy ze studentów otrzymuje materiały w postaci referencji do odpowiednich diagramów
Bardziej szczegółowoUML 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ółowoDiagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.
Umiejętność czytania oraz tworzenia diagramów klas UML jest podstawą w przypadku zawodu programisty. Z takimi diagramami będziesz spotykał się w przeciągu całej swojej kariery. Diagramy klas UML są zawsze
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoInstrukcja poruszania się po katalogu on-line
Instrukcja poruszania się po katalogu on-line Spis treści Wyszukiwanie proste w katalogu on-line 1 10 Wyszukiwanie poprzez indeksy Wyszukiwanie poprzez słowo w wybranym indeksie Wyszukiwanie poprzez słowo
Bardziej szczegółowoPRAKTYKI USOS 6.1.0
PRAKTYKI Moduł Praktyki pozwala na przechowywanie informacji, które dotyczą praktyk studenckich realizowanych na podstawie umów/porozumień zawartych między uczelnią a innymi jednostkami, zwanymi dalej
Bardziej szczegółowoWymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.
Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji. Wymiar pionowy: oś czasu przedstawiajaca ułożone chronologicznie komunikaty Podstawowe notacje graficzne Konceptualny
Bardziej szczegółowoProgram Partnerski Junkers Platforma
Program Partnerski Junkers Platforma www.junkers-program.pl Jedna z nagród - jazda Lamborghini Gallardo 1. Rejestruj zainstalowane urządzenia 2. Zbieraj punkty 3. Wybieraj nagrody Skok ze spadochronem
Bardziej szczegółowo