Inżynieria oprogramowania. Jan Magott
|
|
- Urszula Borkowska
- 8 lat temu
- Przeglądów:
Transkrypt
1 Inżynieria oprogramowania Jan Magott
2 Wprowadzenie Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, M. Fowler, UML w kropelce, wersja 2.0, LTP, M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania obiektowego, Helion, S. Wrycza, B. Marcinkowski, K. Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion, 2005.
3 Wprowadzenie Literatura do wzorców projektowych E. Gamma, R. Helm, R. Johnson, J. Vlissides, Wzorce projektowe, Elementy oprogramowania obiektowego wielokrotnego użytku, WNT, Warszawa, Shalloway, J. R. Trott, Projektowanie obiektowo zorientowane, Wzorce projektowe, wydanie II, Helion, 2005.
4 Wprowadzenie Programowanie w kodzie maszynowym (0,1) Programowanie w asemblerze Programowanie w języku wysokiego poziomu Programowanie w języku nieobiektowym Strukturalne projektowanie oprogramowania Programowanie w języku obiektowym Metoda Coada/Yourdona obiektowo zorientowanych analizy i projektowania oprogramowania Metoda Boocha, 1994 OMT, 1991 OMT-2 Rumbaugh OOSE, 1992 Jacobson Unified Modeling Language (UML) Booch, Rumbaugh, Jacobson UML 1.0, 1997
5 Wprowadzenie Inżynieria oprogramowania UML Inżynieria systemowa SysML
6 Wprowadzenie Znaczenie języka UML Język komunikacji z użytkownikiem Na etapie specyfikacji wymagań stosowane są diagramy i opis w języku naturalnym. Język wielu perspektyw: Wymagań użytkownika, Struktury abstrakcyjnej, Dynamiki abstrakcyjnej, Architektury implementacji (komponenty programowe), Architektury sprzętowo-programowej wdrożenia (rozmieszczenia komponentów programowych w węzłach fizycznych). Język dokumentacji projektu Język projektowania poprzez modelowanie
7 Wprowadzenie Źródło: A. Bobkowska, M. Gala, Konsekwencje zastosowania modelowania w projektach informatycznych badanie z udziałem praktyków, w: J. Górski, C. Orłowski, Inżynieria oprogramowania w procesach integracji systemów informatycznych, PWNT, Gdańsk, 2010, str
8 Wprowadzenie Korzyści z zastosowania metod modelowania w inżynierii oprogramowania: Pomoc w radzeniu sobie ze złożonością systemu, dzięki mechanizmowi abstrakcji, umożliwiającemu prezentację tylko tych elementów, które są istotne z danego punktu widzenia Możliwość przewidywania własności i skutków działania oprogramowania na podstawie modeli, dzięki czemu modele stosowane są do analizy, weryfikacji, walidacji, oceny i porównania różnych wersji systemu Wspomaganie komunikacji w zespole i z klientem dzięki wspólnym modelom koncepcyjnym Standardowa notacja i zwiększenie precyzji dokumentacji systemu Możliwość automatycznego przekształcania modeli, np. generacji dokumentacji, generacji kodu, sprawdzaniu poprawności syntaktycznej, spójności i innych własności modeli.
9 Wprowadzenie Czynniki powodujące rezygnację z modelowania w praktyce: Ograniczenia czasowe nałożone na termin wykonania Opracowywanie modeli nie powoduje bezpośredniego przyrostu kodu programu
10 Wprowadzenie Badanie ankietowe Kontekst: stanowisko respondenta, specyfika firmy Oczekiwane korzyści i motywacje stosowania modelowania (pytania otwarte) Korzyści i problemy wynikające z zastosowania modelowania T Czy modelowanie jest stosowane przez respondenta? F Przyczyny i konsekwencje braku modelowania Korzyści i problemy wynikające ze stosowania narzędzi UML
11 Wprowadzenie Badanie ankietowe Adres systemu ankietowania Ankieta miała charakter anonimowy. Prośba o wypełnienie wysłana pod 285 adresów należących do 170 przedsiębiorstw informatycznych działających na terenie Polski. Wzięło udział 66 respondentów (współczynnik odpowiedzi 23%) w tym 38 wypełniło kwestionariusz w pełni, a 28 częściowo.
12 Wprowadzenie Poziom stosowania modelowania rośnie wraz ze: wzrostem złożoności systemu, wzrostem liczebności zespołu projektowego, wzrostem sformalizowania metodyki wytwarzania oprogramowania. Poziom stosowania modelowania: Metodyka RUP (Rational Unified Process) opracowana przez twórców języka UML 92% respondentów Podejście tradycyjne 65% Podejście zwinne 51%
13 Wprowadzenie Wg ankiety Wśród języków modelowania najczęściej stosowany jest UML lub jego podzbiór (87%) W pozostałych przypadkach (13%) zadeklarowano stosowanie innych metod (BPMN, SysML, DSM)
14 Wprowadzenie Przykłady szeroko stosowanych w praktyce języków modelowania przepływu prac i procesów biznesowych: BPEL Business Process Execution Language, BPMN - Business Process Modeling Notation, Diagramy czynności (aktywności) języka UML. Według porównania 14 komercyjnych produktów modelowania przepływu prac i procesów biznesowych, BPMN i diagramy czynności języka UML są jednymi z trzech najlepszych pod względem mocy wyrażania przepływu sterowania. Źródło: N. Russel, A.H.M. ter Hofstede, W.M.P. van der Aalst, N. Mulyar, Workflow control-flow patterns, A revised view.
15 Wprowadzenie DSM - Domain Specific Modelling DSL - Domain Specific Language
16 Wprowadzenie Obszary zastosowania modelowania: Modelowanie systemu (86%) Prezentacja wymagań (83%) Modelowanie procesów biznesowych (66%) Modelowanie architektury (40%) Najczęściej modelowanie stosowane jest przez analityków
17 Wprowadzenie Oczekiwane korzyści i motywacje stosowania modelowania (66 respondentów, 38 wypełniło kwestionariusz w pełni): 1. Jednoznaczny i spójny opis systemu (10 respondentów) 2. Komunikacja w ramach zespołu (9) 3. Modelowania statyczne systemu (8) 4. Modelowanie biznesowe systemu (5) 5. Modelowanie zachowania systemu (zamiast opisu słownego) (5) 6. Gromadzenie wiedzy (repozytorium modeli systemu) (5) 7. Zarządzanie wymaganiami / zmianą (5) 8. Redukcja złożoności problemu/systemu (5) 9. Ułatwienie przepływu wiedzy (5) 10. Standaryzacja dokumentacji/formalizacja opisu systemu (5) 11. Komunikacja z klientem (5) 12. Redukcja liczby błędów (szczególnie we wstępnych fazach) (3) 13. Poprawa pielęgnowalności (3) 14. Generacja kodu źródłowego (2) 15. Szybsze wprowadzenie nowych osób do projektu (2) 16. Wymaganie ze strony klienta (model jako produkt) (1)
18 Wprowadzenie Korzyści wynikające z zastosowania modelowania
19 Wprowadzenie Problemy wynikające z zastosowania modelowania Nie stwierdzono: Występowania problemów ze zrozumieniem wykorzystywanej notacji przez zespół wytwórczy Niejasnej formy prezentacji modelu Braku spójności modeli Nieodpowiedniego poziomu szczegółowości modeli Występowanie problemów ze zrozumieniem notacji przez klienta 45% ankietowanych odpowiedziało trudno powiedzieć
20 Korzyści wynikające ze stosowania narzędzi UML
21 Wprowadzenie Przyczyny braku modelowania 20 z 66 respondentów stwierdziło, że nie stosuje modelowania. 14 respondentów (70%) w pełni odpowiedziało na pytania tej ścieżki. Przedstawiciele tej grupy realizują krótkoterminowe, niskobudżetowe projekty, w których uczestniczy mały zespół projektowy. Najczęściej metody modelowania nie są stosowane ze względu na: ograniczenia projektowe (krótkie terminy, brak dostępności zasobów) brak zdefiniowanego procesu wytwórczego z zastosowaniem metod modelowania. W grupie 14 respondentów, 10 z nich (71%) zadeklarowało, że stosuje metodyki zwinne.
22 Wprowadzenie Konsekwencje braku modelowania Fakt, że 71% respondentów zaprzeczyło istnieniu problemów z komunikacją w grupie, można wytłumaczyć stosowaniem innych sposobów komunikacji w zespole. Koniec powołań na źródło: A. Bobkowska, M. Gala, Konsekwencje zastosowania modelowania w projektach informatycznych badanie z udziałem praktyków,
23 Wprowadzenie Przyczyny tworzenia narzędzi programistycznych wspierających rysowanie i analizę diagramów języka UML: Tylko dla prostych diagramów, rysowanie i analiza nie są uciążliwe, Złożoność analizy zgodności między diagramami, Możliwości algorytmizacji analizy diagramów.
24 Wprowadzenie Wymagania stawiane nowoczesnym narzędziom CASE (Computer Aided Software Engineering): Rysowanie diagramów ze sprawdzaniem ich poprawności, Pełnienie roli repozytorium, Umożliwienie nawigacji po komponentach systemu przy pracy z różnymi kategoriami modeli, Umożliwienie jednoczesnej pracy wielu użytkownikom na tym samym modelu, Generowanie kodu, Inżynieria odwrotna, Integrowanie z innymi narzędziami, np. w celu edycji i kompilacji kodu uzupełniającego szkielet kodu, testowania, Praca ze wszystkimi poziomami abstrakcji systemu, od wysokiego poziomu do poziomu kodu, Wymiana fragmentów modelu z innymi narzędziami.
25 Wprowadzenie Diagramy wdrożenia Diagramy składowych Diagramy przypadków użycia Diagramy czynności Diagramy klas Diagramy komponentów Diagramy pakietów Diagramy maszyn stanów Diagramy czasowe Diagramy opisu interakcji Diagramy obiektów Diagramy sekwencji Diagramy komunikacji Repozytorium: struktura, dynamika
26 Wprowadzenie Zadania, dla których narzędzie CASE wykorzystuje repozytorium: Sprawdzanie zgodności diagramu i zgodności między diagramami, Wskazywanie uchybień modeli, Sporządzanie dokumentów z projektu, Stosowanie elementów projektu w innym projekcie.
27 Diagramy przypadków użycia Specyfikacja wymagań za pomocą diagramów przypadków użycia Modelowanie obiektowe można stosować nie tylko do systemów programowych ale również do systemów sprzętowych czy organizacji. Stąd diagramy przypadków użycia mogą być stosowane do specyfikowania wymagań nałożonych na systemy powyższych kategorii. Podczas przyrostowej realizacji projektu ważnymi decyzjami są rozstrzygnięcia, które przypadki użycia powinny być dostarczone na początku i w jakiej kolejności dołączane będą następne przypadki. Na początku specyfikowania wymagań, często korzystne jest opracowanie katalogu pojęć z dziedziny zastosowania (wycinka rzeczywistości), które będą stosowane w wyrażaniu przypadków użycia.
28 Diagramy przypadków użycia Alternatywne określenia dla przypadku użycia: Funkcjonalność, Karta wymagań, Historia użytkownika.
29 Diagramy przypadków użycia Aktor oddziaływuje z modelowanym (projektowanym) systemem. Aktor może być człowiekiem lub innym systemem. Aktor reprezentuje rolę. Indywidualny użytkownik nie jest aktorem. Konkretny użytkownik może pełnić różne role: może być np. Klientem jak również Pracownikiem.
30 Diagramy przypadków użycia Relacja uogólniania między aktorami Klient Klient ubezpieczający podmiot fizyczny Klient ubezpieczający podmiot prawny Relacja uogólniania między klasami klientów agencji ubezpieczeniowej
31 Diagramy przypadków użycia Asocjacja komunikacji między aktorem a przypadkiem użycia Aktor Przypadek użycia Aktor i Przypadek użycia są klasami. Często Aktor wysyła komunikaty do Przypadku użycia i komunikaty otrzymuje. Przypadek użycia reprezentuje kompletną funkcjonalność widzianą ze strony aktora lub innego przypadku użycia. Jest to zbiór sekwencji akcji wykonywanych przez system, w których wyniku otrzymywany jest mierzalny produkt działania systemu.
32 Diagramy przypadków użycia Relacje między przypadkami użycia <<include>>, <<extend>>, grupowania, dziedziczenia.
33 Diagramy przypadków użycia Relacja <<include>> Zakres stosowania: Reprezentacja hierarchii funkcji systemu, Wyodrębnianie części wspólnej dla co najmniej dwu funkcji systemu. Przypadek1 Przypadek2 <<include> > <<include> > Przypadek3 Przypadek3 jest częścią wspólną wydzieloną z dwu funkcji
34 Diagramy przypadków użycia Logowanie <<include>> Usługa Użytkownik <<include>> Wylogowanie Błędny diagram przypadków użycia
35 Diagramy przypadków użycia <<include>> Logowanie Sesja <<include>> Usługa Użytkownik <<include>> Wylogowanie Poprawny diagram przypadków użycia
36 Diagramy przypadków użycia Relacja <<extend>> Zakres stosowania: Wyrażanie wyjątków, alternatywnych przebiegów, Wyrażanie funcji tworzonych na dalszych etapach budowy systemu. <<extend>> Wystawienie gwarancji Sprzedaż towaru <<extend>> Wystawienie pełnego rachunku
37 Diagramy przypadków użycia Grupowanie przypadków użycia Przypadki użycia związane ze sobą mogą być grupowane w pakiet, który może być dostępny jako jednostka. Zarządzanie Zarządzanie finansami Zarządzanie kadrami
38 Diagramy przypadków użycia (Diagramy hierarchii funkcji, diagramy hierarchii procesów biznesowych ich poprzednikami) System informacji geograficznej (SIG) Mapa komputerowa zawiera obiekty takie jak: Punkty (np. budynek), Linie (np. rzeka), Obszary (np. park). Obiekt ma nazwę i opis składający się ze słów kluczowych np.: rodzaj firmy, miejsce jej ulokowania, liczba pracowników. Użytkownik może oglądać obiekty opisane wybranymi przez niego słowami kluczowymi.
39 Dodawanie słowa kluczowego Zarządzanie SIG Edycja słowa kluczowego Usuwanie słowa kluczowego Przeglądanie SIG Projektowanie SIG Prezentacja fragmentów mapy Prezentacja obiektów wybranych słowami kluczowymi Prezentacja opisu obiektu Edycja tła (zdjęcia satelitarnego lub mapy) Modyfikacja obiektów Modyfikacja słów kluczowych Dodawanie obiektu Edycja obiektu u Usuwanie obiektu
40 Diagramy przypadków użycia (Diagramy hierarchii funkcji, diagramy hierarchii procesów biznesowych ich poprzednikami) Diagramy przypadków użycia reprezentują wymagania funkcjonalne. W diagramach przypadków użycia wyodrębnione są klasy obiektów zewnętrznych wchodzących w identyczne interakcje z systemem. Klasy obiektów zewnętrznych względem projektowanego systemu nazywane są aktorami i opatrywane nazwami ról np. Projektant, Użytkownik.
41 Diagramy przypadków użycia (Diagramy hierarchii funkcji, diagramy hierarchii procesów biznesowych ich poprzednikami) Diagram przypadków użycia Przeglądanie SIG Perspektywa aktora Użytkownik Prezentacja fragmentów mapy Prezentacja obiektów wybranych słowami kluczowymi Użytkownik Prezentacja opisu obiektu
42 Diagramy przypadków użycia Diagram przypadków użycia Projektowanie SIG Perspektywa aktora Projektant
43 Diagramy przypadków użycia (Diagramy hierarchii funkcji, diagramy hierarchii procesów biznesowych ich poprzednikami) Diagram przypadków użycia Projektowanie SIG Perspektywa aktora Projektant Edycja tła Projektant Modyfikacja słów kluczowych Modyfikacja obiektów Dodawanie obiektu Edycja obiektu u Usuwanie obiektu Dodawanie słowa kluczowego Edycja słowa kluczowego Usuwanie słowa kluczowego
44 Diagramy przypadków użycia Dziedziczenie Dodawanie osoby Dodawanie klienta Dodawanie pracownika Relacja dziedziczenia między przypadkami użycia
45 Diagramy przypadków użycia Języki opisu przypadków użycia: W języku naturalnym (w aktualnej fazie wykładu) Diagram aktywności (później)
46 Diagramy przypadków użycia Opis przypadku użycia w języku naturalnym 1. Cel 2. Warunki wstępne 3. Przebieg podstawowy 4. Przebiegi alternatywne 5. Przepływ komunikatów (często pomijany) 6. Warunki końcowe
47 Diagramy przypadków użycia Plan 1. Diagram przypadków użycia dla Zarządzania klientami z następującymi przypadkami użycia najwyższego poziomu: Dodaj nowego klienta Usuń klienta Przeglądaj dane klienta Edytuj dane klienta 2. Diagram przypadków Zapisu studenta na wykład
48 Diagramy przypadków użycia Usuń klienta <<include>> Szukaj klienta Pracownik Dodaj nowego klienta <<include>> <<include>> <<include>> <<include>> Modyfikuj dane klienta <include>> Przeglądaj dane klienta Edytuj dane klienta Diagram przypadków użycia dla zarządzania klientami
49 Diagramy przypadków użycia PU (przypadek użycia) Dodaj nowego klienta Cel PU Celem tego PU jest dodanie do bazy danych nowego klienta banku. Warunki wstępne PU jest inicjowany przez Pracownika.
50 Diagramy przypadków użycia PU Dodaj nowego klienta c.d. Przebiegi sposobu realizacji PU Podstawowy 1. Pracownik wydaje polecenie dodania nowego klienta do bazy danych, naciskając przycisk Dodaj klienta w oknie Zarządzaj klientami. 2. Wyświetlane jest okno Klient zawierające pola edycyjne opisujące poszczególne dane klienta. 3. Pracownik edytuje dane klienta, wypełniając poszczególne pola edycyjne okna. 4. Pracownik naciska przycisk Zapisz. 5. Inicjowany jest PU Modyfikuj dane klienta. 6. Następuje powrót z PU Modyfikuj dane klienta. 7. Wyświetlenie Komunikatu wynikowego. 8. Zamykane jest okno Klient i PU zostaje zakończony.
51 Diagramy przypadków użycia PU Dodaj nowego klienta c.d. Przepływ komunikatów 1. Nowy klient - Pracownik inicjuje PU, naciskając przycisk Dodaj klienta w oknie Zarządzaj klientami. 2. Dane klienta - Pracownik podaje dane klienta, wypełniając pola edycyjne okna Klient. 3. Zapisz - Pracownik inicjuje zapis danych do bazy danych, naciskając przycisk Zapisz. 4. Modyfikuj dane klienta - PU inicjuje PU Modyfikuj dane klienta. 5. Komunikat powrotu do PU z PU Modyfikuj dane klienta. 6. Komunikat wynikowy. 7. Zamknij - Pracownik zamyka okno Klient.
52 Diagramy przypadków użycia PU Dodaj nowego klienta c.d. Warunki końcowe PU uznaje się za zakończony po zamknięciu okna Klient. (lub PU uznaje się za zakończony po zapisaniu danych nowego klienta.)
53 Diagramy przypadków użycia PU Edytuj dane klienta Przebiegi sposobu realizacji PU Podstawowy 1. Pracownik wydaje polecenie edytowania danych klienta, naciskając przycisk Edytuj dane klienta w oknie Zarządzaj klientami. 2. Wyświetlane jest okno Klient zawierające pole PESEL. 3. Pracownik wpisuje PESEL i naciska przycisk Szukaj. 4. Inicjowany jest PU Szukaj klienta. 5. Następuje powrót z PU Szukaj klienta. 6. Wyświetlane jest okno Klient zawierające pola edycyjne opisujące poszczególne dane klienta. 7. Pracownik edytuje dane klienta, wypełniając poszczególne pola edycyjne okna. 8. Pracownik naciska przycisk Zapisz. 9. Inicjowany jest PU Modyfikuj dane klienta. 10. Następuje powrót z PU Modyfikuj dane klienta. 11. Wyświetlenie Komunikatu wynikowego. 12. Zamykane jest okno Klient i PU zostaje zakończony.
54 Diagramy przypadków użycia PU Modyfikuj dane klienta Cel PU Celem tego PU jest zmodyfikowanie danych klienta. Warunki wstępne PU inicjowany jest przez PU Dodaj nowego klienta lub przez PU Edytuj dane klienta. W momencie wywołania do PU przekazywane są aktualne dane o kliencie. Jeśli PU inicjującym jest PU Edytuj dane klienta, to przekazywany jest wskaźnik na dane klienta.
55 Diagramy przypadków użycia PU Modyfikuj dane klienta c.d. Przebiegi sposobu realizacji PU 1. PU inicjowany jest przez PU Dodaj nowego klienta lub przez PU Edytuj dane klienta. 2. Jeśli inicjującym jest PU Edytuj dane klienta, to przejście do kroku Inicjowany jest PU Szukaj klienta 4. Następuje powrót z PU Szukaj klienta 5. Jeśli istnieje w bazie klient o podanym numerze PESEL, to wyświetlany jest komunikat: Klient o podanym PESEL istnieje i przejście do kroku PU modyfikuje dane klienta. 7. PU kończy się i następuje powrót do PU, który wywołał PU Modyfikuj dane klienta.
56 Diagramy przypadków użycia PU Modyfikuj dane klienta c.d. Warunki końcowe PU uznaje się za zakończony po modyfikacji danych klienta (co może wystąpić dla obu inicjujących przypadków użycia) lub po stwierdzeniu, że klient o podanym numerze PESEL już w bazie istnieje (co może nastąpić tylko dla inicjacji przez PU Dodaj nowego klienta).
57 Okno główne Wykład Okno wykładu Dodaj wykład Usuń wykład Edytuj dane wykładu Zapisz na wykład Okno zapisu studenta na wykład Wydział ID wykładu Dane wykładu Tak Nie ID studenta Czy spełnione wym. Zapisz
58 Diagramy przypadków użycia Szukaj danych wykładu Szukaj danych studenta <<include>> <<include>> Szukaj danych wydziału Modyfikuj dane zapisu studenta na wykład <<include>> <<include>> Użytkownik Zapisz studenta na wykład Diagram przypadków użycia Zapis studenta na wykład
59 Diagramy przypadków użycia PU Zapisz studenta na wykład Przebieg podstawowy realizacji PU 1. Użytkownik otwiera Okno zapisu studenta na wykład. 2. Użytkownik wybiera Nazwę wydziału. 3. Inicjowany jest PU Szukaj danych wydziału. 4. Następuje powrót z PU Szukaj danych wydziału. 5. Użytkownik podaje ID wykładu lub wybiera przejście do Inicjowany jest PU Szukaj danych wykładu. 7. Następuje powrót z PU Szukaj danych wykładu. 8. Jeśli nie znaleziono wykładu, to PU wyświetla napis Nie znaleziono wykładu. 9. Jeśli PU wyświetla napis Nie znaleziono wykładu, to Użytkownik wybiera przejście do: 2 lub Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
60 Diagramy przypadków użycia PU Zapisz studenta na wykład c.d. Przebieg podstawowy realizacji PU c.d. 10. Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca. 11. Jeśli nie ma wolnych miejsc, to PU wyświetla napis Nie ma wolnych miejsc 12. Jeśli PU wyświetla napis Nie ma wolnych miejsc, to Użytkownik wybiera przejście do: 2 lub Użytkownik podaje ID studenta. 14. Inicjowany jest PU Szukaj danych studenta. 15. Następuje powrót z PU Szukaj danych studenta. 16. PU wyświetla czy student spełnia wymagania zapisu na wykład. 17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań. 18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do Użytkownik wybiera Tak w polu Zapisz.
61 Diagramy przypadków użycia PU Zapisz studenta na wykład c.d. Przebieg podstawowy realizacji PU c.d. 17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań. 18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do Użytkownik wybiera Tak w polu Zapisz. 21. Inicjowany jest PU Modyfikuj dane zapisu studenta na wykład. 22. Następuje powrót z PU Modyfikuj dane zapisu studenta na wykład. 23. Użytkownik zamyka Okno wykładu lub wybiera przejście do: 2 lub PU zostaje zakończony z zamkniętym Oknem wykładu.
62 Diagramy przypadków użycia PU Zapisz studenta na wykład c.d. Alternatywne przebiegi W dowolnym momencie Użytkownik może zamknąć Okno wykładu. Jeśli po wykonaniu jednego z punktów: 1,4, 7, 15, 22, Użytkownik nie wykona żadnej akcji w ciągu 30 s, to PU przechodzi do 24.
63 Diagramy czynności (aktywności) W początkowych wersjach języka UML Diagramy czynności były oparte, podobnie jak maszyny stanowe, na mapach stanów Harel a W wersji UML 2.0 i dalszych Diagramy czynności są oparte na sieciach Petriego
64 Diagramy czynności Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych P(s) Fazy aktywności procesu: CS sekcja krytyczna, RP pozostała część procesu, P(s), V(s) operacje semaforowe. RP CS V(s)
65 Diagramy czynności Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych Fazy aktywności procesu: CS sekcja krytyczna, RP pozostała część procesu, P(s), V(s) operacje semaforowe. P(s) P(s) RP CS CRP CS V(s) V(s) RP Cykliczny proces sekwencyjny reprezentowany siecią Petriego (kółko miejscem, kreska przejściem, znacznik - kropką) CRP zakończenie pozostałej części procesu
66 Diagramy czynności Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych CRP P(s) CS P(s) CRP P(s) V(s) CS CRP P(s) CS V(s) V(s) V(s) RP CRP RP RP Sekwencja odpalanych przejść: P(s) V(s) CRP
67 Diagramy czynności Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych CS proces jest w sekcji krytycznej, RP proces jest w pozostałej części procesu, CRP zakończenie pozostałej części procesu, P(s), V(s) operacje semaforowe, P1 IR krytyczny zasób jest dostępny. a) P2 P(s) P(s) CRP1 CS1 IR CS2 CRP2 Przejścia z etykietami P(s) są przygotowane do odpalenia RP1 V(s) V(s) RP2
68 Diagramy czynności Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych b) P1 P2 P(s) P(s) CRP1 CS1 IR CS2 CRP2 RP1 V(s) V(s) RP2 Przejście V(s) procesu P1 jest przygotowane do odpalenia Sieć Petriego po odpaleniu przejścia P(s) procesu P1
69 Diagramy czynności Prosty protokół komunikacyjny PM produkcja komunikatu, SM wysłanie komunikatu, TM transmisja komunikatu, SA wysłanie potwierdzenia, CCM zakończenie konsumpcji komunikatu, RA odbiór potwierdzenia. CPM zakończenie produkcji komunikatu, WA oczekiwanie na potwierdzenie, RM odbiór komunikatu, CM konsumpcja komunikatu, TA transmisja potwierdzenia, SM TM RM CPM WA CCM TA PM RA SA CM
70 Diagramy czynności p p4 t2 p1 2 t3 p2 t4 p3 2 t1 2 2 t1 p4 t2 p1 2 t3 p2 t4 t1
71 Diagramy czynności p p4 t2 p1 2 t3 p2 t4 p3 2 t1 2 2 t3 p4 t2 p1 2 t3 p2 t4 t1
72 Diagramy czynności 1011 t4 t1 t t2 t3 t t4 Graf osiągalności 1011 znakowanie początkowe t1 t1 t2
73 Okno główne Wykład Okno wykładu Dodaj wykład Usuń wykład Edytuj dane wykładu Zapisz na wykład Okno zapisu studenta na wykład Wydział ID wykładu Dane wykładu Tak Nie ID studenta Czy spełnione wym. Zapisz
74 Diagramy czynności Szukaj danych wykładu Szukaj danych studenta <<include>> <<include>> Szukaj danych wydziału Modyfikuj dane zapisu studenta na wykład <<include>> <<include>> Użytkownik Zapisz studenta na wykład Diagram przypadków użycia Zapis studenta na wykład
75 Diagramy czynności PU Zapisz studenta na wykład Przebieg podstawowy realizacji PU 1. Użytkownik otwiera Okno zapisu studenta na wykład. 2. Użytkownik wybiera Nazwę wydziału. 3. Inicjowany jest PU Szukaj danych wydziału. 4. Następuje powrót z PU Szukaj danych wydziału. 5. Użytkownik podaje ID wykładu lub wybiera przejście do Inicjowany jest PU Szukaj danych wykładu. 7. Następuje powrót z PU Szukaj danych wykładu. 8. Jeśli nie znaleziono wykładu, to PU wyświetla napis Nie znaleziono wykładu. 9. Jeśli PU wyświetla napis Nie znaleziono wykładu, to Użytkownik wybiera przejście do: 2 lub Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
76 Diagramy czynności PU Zapisz studenta na wykład c.d. Przebieg podstawowy realizacji PU c.d. 10. Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca. 11. Jeśli nie ma wolnych miejsc, to PU wyświetla napis Nie ma wolnych miejsc 12. Jeśli PU wyświetla napis Nie ma wolnych miejsc, to Użytkownik wybiera przejście do: 2 lub Użytkownik podaje ID studenta. 14. Inicjowany jest PU Szukaj danych studenta. 15. Następuje powrót z PU Szukaj danych studenta. 16. PU wyświetla czy student spełnia wymagania zapisu na wykład. 17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań. 18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do Użytkownik wybiera Tak w polu Zapisz.
77 Diagramy czynności PU Zapisz studenta na wykład c.d. Przebieg podstawowy realizacji PU c.d. 17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań. 18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do Użytkownik wybiera Tak w polu Zapisz. 21. Inicjowany jest PU Modyfikuj dane zapisu studenta na wykład. 22. Następuje powrót z PU Modyfikuj dane zapisu studenta na wykład. 23. Użytkownik zamyka Okno wykładu lub wybiera przejście do: 2 lub PU zostaje zakończony z zamkniętym Oknem wykładu.
78 Diagramy czynności PU Zapisz studenta na wykład c.d. Alternatywne przebiegi W dowolnym momencie Użytkownik może zamknąć Okno wykładu. Jeśli po wykonaniu jednego z punktów: 1, 4, 7, 15, 22, Użytkownik nie wykona żadnej akcji w ciągu 30 s, to PU przechodzi do 24.
79 Użytkownik System Wybiera Okno zapisu studenta na wykład Wyświetla Okno zapisu studenta na wykład 1 2 Po 30s Wybiera Nazwę wydziału Wykonuje PU Szukaj danych wydziału 1 2 [powrót] Po 30s [kontynuacja] Podaje ID wykładu Wykonuje PU Szukaj danych wykładu 1 Wybiera Przycisk zamykania Okno wykładu 2 Zamyka Okno wykładu
80
81 Reliability enhanced activity diagrams (READ) (M. Kowalski, J. Magott) Podstawy języka READ: 1. Diagramy czynności języka UML 2. Konstrukcje fork i join diagramów czynności rozszerzone w kierunku przejść sieci Petriego 3. Probabilistyczne drzewa niezdatności z zależnościami czasowymi [1] [1] Babczyński, T., Łukowicz, M., Magott, J. (2010). Time coordination of distance protections using probabilistic fault trees with time dependencies. IEEE Transaction on Power Delivery, July, Vol. 25, No. 3,
82 Reliability enhanced activity diagrams (READ) Przydział zestawu naprawczego
83 Reliability enhanced activity diagrams (READ) Zwolnienie zestawu naprawczego
84 Reliability enhanced activity diagram (READ) of computer system maintenance process System komputerowy z CPU, dwoma dyskami i dwoma zestawami naprawczymi
85 Reliability enhanced activity diagrams (READ) of computer system maintenance process Regularna praca Naprawa Stan procesu
86 Diagramy klas Następujący diagram klas pochodzi z: G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002.
87
88 Diagramy klas Relacje między klasami na diagramach klas Rodzaje relacji: Asocjacja (ang. Association), Agregacja (ang. Aggregation) jest szczególnym przypadkiem asocjacji. Uogólnienie (ang. Generalization), Zależność (ang. Dependency), Uszczegółowienie (ang. Refinement).
89 Diagramy klas Asocjacje Obiekt jest instancją klasy. Powiązanie jest instancją asocjacji. Sposoby obrazowania asocjacji: krawędzią, łukiem. Zwykle asocjacja obrazowana jest krawędzią. Krawędź stosowana jest gdy: możliwe jest przejście w obie strony między klasami połączonymi nią lub gdy nie dysponuje się pełną informacją o kierunkach przejść. Klasa1 Klasa2 Łuk może być stosowany w przypadku, gdy na poziomie implementacji klasa Klasa1 ma wskaźnik do klasy Klasa2 ale nie w drugą stronę.
90 Diagramy klas Krotność asocjacji określa z iloma obiektami klasy drugiej może być połączony obiekt pierwszej klasy. Przykłady krotności: lub * 0 Drużyna piłki nożnej 1 11 Zawodnik Diagram klas o znaczeniu: Drużyna piłki nożnej składa się z jedenastu zawodników
91 Diagramy klas Asocjacja rekursywna * krawędź Wierzchołek Diagram klas o znaczeniu: Graf składa się z wierzchołków połączonych krawędziami * Wierzchołek1 : Wierzchołek Wierzchołek2 : Wierzchołek Wierzchołek3 : Wierzchołek Wierzchołek4 : Wierzchołek Wierzchołek5 : Wierzchołek Diagram obiektów reprezentujący konkretny graf
92 Diagramy klas Role w asocjacji łuk źródło Wierzchołek cel
93 Diagramy klas Asocjacja kwalifikowana Lista osób Identyfikator * Osoba Kwalifikator określa jak specyficzny obiekt na końcu asocjacji o krotności "wiele" jest identyfikowany.
94 Diagramy klas Klasa asocjacji Stanowisko Wymagane kwalifikacje Wynagrodzenie Szlifowanie Osoba Firma Klasa Stanowisko opisuje asocjację. Z każdym powiązaniem między obiektami klas: Osoba, Firma jest skojarzony obiekt klasy Stanowisko, który charakteryzuje powiązanie.
95 Diagramy klas Asocjacja binarna a asocjacja trzyarna Drużyna piłki nożnej 1 11 Zawodnik Asocjacja binarna Osoba 1..* Projekt * 1..3 Język Asocjacja trzyarna modelująca przygotowywanie projektów w firmie programistycznej
96 Diagramy klas Osoba 1..* Projekt * 1..3 Język Asocjacja trzyarna modelująca przygotowywanie projektów w firmie programistycznej Osoba znająca dany język programowania może nie realizować projektu w tym języku ale może też realizować więcej niż jeden projekt w tym języku. Osoba pracująca w projekcie może używać jednego, dwu lub trzech języków. Jeśli projekt jest realizowany, to jest wykonywany w co najmniej jednym języku ale żaden z wykonawców nie może pracować w więcej niż trzech językach w ramach jednego projektu.
97 Diagramy klas Asocjacja uporządkowana Osoba 1..* {ordered} * Firma W firmie pracuje co najmniej jedna osoba. Osoba może nie pracować w żadnej firmie. Osoby zaangażowane w firmie mogą być uporządkowane np. alfabetycznie. Sposób uporządkowania można podać pisząc np. : {ordered alphabetically}
98 Diagramy klas Agregacja Agregacja jest szczególnym przypadkiem asocjacji. Dokument zawiera jest częścią 1..* Paragraf całość część Obiekt klasy Dokument składa się z co najmniej jednego obiektu klasy Paragraf
99 Diagramy klas Agregacja dzielona Wydział * * Student Części mogą być częściami różnych klas, co jest wyrażone krotnością * po stronie całości. Student może studiować na więcej niż jednym wydziale.
100 Diagramy klas Uogólnienie Pojazd Pojazd Samochód osobowy Samochód ciężarowy Łódź Samochód osobowy Samochód ciężarowy Łódź Klasa ogólna (nadklasa) a klasy specjalizowane (podklasy) Klasy specjalizowane dziedziczą po klasie ogólnej. Powyższa lista podklas nie daje w sumie mnogościowej - nadklasy. W rozważanym wycinku rzeczywistości uzasadnione może być rozważanie tylko tych powyższych trzech klas.
101 Diagramy klas Pojazd Klasa Pojazd jest abstrakcyjna, natomiast klasy Samochód i Łódź są klasami konkretnymi Napęd jest dyskryminatorem, który odróżnia podklasy między sobą. drive() Napęd Samochód drive() drive() uruchamia koła Napęd drive() Łódź drive() uruchamia śrubę
102 Diagramy klas Ograniczenia dla definiowania uogólnienia
103 Diagramy klas Syntaktyka deklaracji atrybutu [widoczność] nazwa [liczebność] [: typ] [= wartość_początkowa] [{łańcuch_własności}] Uwaga: Obowiązkowa jest tylko nazwa. widoczność: + atrybut publiczny (atrybut jest dostępny z innych klas), - atrybut prywatny (atrybut nie jest dostępny z innych klas), # atrybut chroniony, dostępny w klasach dziedziczących (ang. protected), widoczność atrybutu jest interpretowana jako atrybut publiczny. Przykład Faktura + data : Data = Bieżąca data + nazwaproduktu : String + ilość : integer + cenajednostkowa : Cena + klient : String osobawystawiająca : String
104 Diagramy klas widoczność cd pokreślony opis atrybutu - atrybut o zakresie klasy (atrybut prywatny, którego wartość jest identyczna dla każdego obiektu klasy) Przykład Proces licznik : integer zwiększstanlicznika Atrybut licznik jest używany przez wszystkie procesy do zliczania liczby wykonań operacji zwiększstanlicznika.
105 Diagramy klas Uwaga Można definiować inne kategorie widoczności, jeśli jest to uzasadnione możliwościami języka, w którym system będzie implementowany. {łańcuch_własności} w szczególnym przypadku może być listą wartości typu wyliczeniowego czyli {lista_wartości}
106 Diagramy klas Implementacja klasy w języku Java Faktura public Class Faktura { + data : Data = Bieżąca data public Data data = newdata(); + nazwaproduktu : String public String nazwaproduktu; + ilość : integer public int ilość; + cenajednostkowa : Cena public Cena cenajednostkowa; + klient : String public String klient; osobawystawiająca : String private String osobawystawiająca; liczbafaktur : integer = 0 static private int liczbafaktur = 0; // Operacja konstruktora wywoływana przy tworzeniu obiektu public Faktura() { //Nadawanie wartości początkowych atrybutom //Inicjowanie powiązań z innymi obiektami //Odnotowanie utworzenia faktury liczbafaktur ++; } //inne operacje };
107 Diagramy klas Syntaktyka nagłówka operacji [widoczność] nazwa [(lista_parametrów)] [: typ_wyniku] [{łańcuch_własności}] { łańcuch_własności} może być wyliczeniem typu wyniku Syntaktyka parametru formalnego [tryb] nazwa : typ [= wartość domyślna] tryb: in out inout parametr wejściowy; nie może być modyfikowany, parametr wyjściowy; może być modyfikowany w celu przekazania informacji wywołującemu, parametr wejściowy; może być modyfikowany. Operacje o zakresie klasy mają dostęp tylko do atrybutów o zakresie klasy. Implementacja operacji (kod w języku programowania) jest metodą.
108 Diagram klas
109 Diagramy sekwencji Następujący diagram sekwencji pochodzi z: M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania obiektowego, Helion, 2005.
110
111 Diagramy sekwencji Szukaj danych studenta Edytuj dane studenta <<include>> Użytkownik <<include>> Modyfikuj dane studenta Diagram przypadków użycia Edycja danych studenta
112 Diagramy sekwencji PU Edytuj dane studenta Przebieg podstawowy realizacji PU 1. Użytkownik otwiera Okno edycji danych studenta. 2. Użytkownik podaje ID studenta. 3. Inicjowany jest PU Szukaj danych studenta. 4. Następuje powrót z PU Szukaj danych studenta. 5. Użytkownik podaje Dane korygujące. 6. Inicjowany jest PU Modyfikuj dane studenta. 7. Następuje powrót z PU Modyfikuj dane studenta. 8. Użytkownik zamyka Okno studenta i PU zostaje zakończony.
113 Diagramy sekwencji PU Szukaj danych studenta Przebieg podstawowy realizacji PU w przypadku zainicjowania przez PU Edytuj dane studenta 1. PU jest inicjowany przez PU Edytuj dane studenta. 2. Na podstawie ID studenta szukane są jego dane. 3. Następuje powrót ze wskaźnikiem na studenta o podanym ID studenta i PU zostaje zakończony.
114 Diagramy sekwencji PU Modyfikuj dane studenta Przebieg podstawowy realizacji PU w przypadku zainicjowania przez PU Edytuj dane studenta 1. PU jest inicjowany przez PU Edytuj dane studenta. 2. Dane studenta są modyfikowane. 3. Następuje powrót i PU zostaje zakończony.
115 System okien Okno główne Student Wykład Wykładowca ał Wydział Okno studenta Okno wykładowcy Dodaj studenta Usuń studenta Edytuj dane stu denta Okno wykładu Okno wydziału
116 Okno główne System okien dla Edycji danych studenta Student Wykład Wykładowca ał Wydział Okno studenta Dodaj studenta Usuń studenta Edytuj dane studenta Okno edycji danych studenta Nazwisko Imię PESEL Miejsce urodzenia
117 Okno główne pokażokno 1 wywołuje 1 Okno studenta pokażokno odczytajdanestudenta dodajstudenta usuństudenta edytujdanestudenta Uczelnia odczytajdanestudenta dodajstudenta usuństudenta edytujdanestudenta Student nazwisko:nazwa IDstudenta:Number get() set() Grupa współdziałania dla realizacji Edycja danych studenta
118 :Okno główne :Okno studenta :Uczelnia :Student Diagram sekwencji dla Edycja danych studenta Student pokażokno Edytuj dane studenta edytujdanestudenta IDstudenta edytujdane Studenta get(nazwisko) get(imię) Dane korygujące set(nazwisko) set(imię) zamknij
119 Diagramy maszyn stanowych Następujący diagram maszyny stanowej pochodzi z: M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania obiektowego, Helion, 2005.
120 Diagram maszyny stanowej
Inżynieria oprogramowania. Jan Magott
Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,
Bardziej szczegół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ół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ół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ół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ół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ół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ół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ół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ół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ółowoMichał 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ół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ółowoAnaliza i projektowanie obiektowe w UML Kod przedmiotu
Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,
Bardziej szczegółowoWykł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ół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ółowoKARTA MODUŁU KSZTAŁCENIA
KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator
Bardziej szczegółowoPRZEWODNIK 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ółowoZARZĄDZANIU. Wykład VI. dr Jan Kazimirski
INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens
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ółowoproblem w określonym kontekście siły istotę jego rozwiązania
Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego
Bardziej szczegół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ół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ółowoNazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
Bardziej szczegół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ółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
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ółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegół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ółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
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ółowoPRZEWODNIK 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ółowoModelowanie i analiza systemów informatycznych
Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.
Bardziej szczegółowoDiagramy 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ółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Bardziej szczegółowoProgramowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska
Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego Iwona Kochaoska Programowanie Obiektowe Programowanie obiektowe (ang. object-oriented programming) - metodyka tworzenia programów komputerowych,
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ółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoKonfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
Bardziej szczegół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ółowoDariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
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ół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ółowoInżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
Bardziej szczegółowoProgramowanie obiektowe - 1.
Programowanie obiektowe - 1 Mariusz.Masewicz@cs.put.poznan.pl Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
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ół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ółowoProjekt systemu informatycznego
Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych
Bardziej szczegółowoProgramowanie 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ółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoUnified Modeling Language
Unified Modeling Language Wprowadzenie do UML Igor Gocaliński Odrobina historii Połowa lat 70-tych i koniec 80-tych to początek analizy obiektowej Wiele opracowanych metod w połowie lat 90-tych Metoda
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ół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 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
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ółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
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ół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ółowoIO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl
IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju
Bardziej szczegółowoUniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013
SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
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ół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ół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ółowoPodstawy Programowania Obiektowego
Podstawy Programowania Obiektowego Wprowadzenie do programowania obiektowego. Pojęcie struktury i klasy. Spotkanie 03 Dr inż. Dariusz JĘDRZEJCZYK Tematyka wykładu Idea programowania obiektowego Definicja
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ół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ółowoNarzędzia CASE dla.net. Łukasz Popiel
Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
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ółowoModel przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz
Model przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz Zofia Kruczkiewicz Wyklad_INP002017_4 1 Diagramy czynności I. Diagramy czynności UML II. Przykład diagramów
Bardziej szczegółowoDiagramy czynności tworzenie modelu przypadków użycia Wykład 2
Diagramy czynności tworzenie modelu przypadków użycia Wykład 2 Zofia Kruczkiewicz Zofia Kruczkiewicz - Projektowanie oprogramowania 2.2 1 Diagramy czynności- tworzenie modelu przypadków 1. Diagramy czynności
Bardziej szczegółowoZalety 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ółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
Bardziej szczegół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ółowoUML 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ółowoKurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016
Wstęp - wykład 0 22 lutego 2016 Historia Simula 67 język zaprojektowany do zastosowan symulacyjnych; Smalltalk 80 pierwszy język w pełni obiektowy; Dodawanie obiektowości do języków imperatywnych: Pascal
Bardziej szczegółowoModelowanie. 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Ź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ół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ół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ółowoTechniki modelowania programów Kod przedmiotu
Techniki modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Techniki modelowania programów Kod przedmiotu 11.3-WI-INFD-TMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
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ółowoWzorce projektowe i refaktoryzacja
Wzorce projektowe i refaktoryzacja Paweł Kozioł p.koziol@students.mimuw.edu.pl 18.01.2005 Moja praca magisterska Narzędzie dla środowiska Eclipse wspierające stosowanie wzorców projektowych J2EE Prowadzący:
Bardziej szczegółowoProgramowanie obiektowe
Laboratorium z przedmiotu - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia. Wprowadzenie teoretyczne.
Bardziej szczegółowoUML. dr inż. Marcin Pietroo
dr inż. Marcin Pietroo Pojęcia obiektowości obiekt klasa komunikat hermetyzacja polimorfizm dziedziczenie graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych
Bardziej szczegółowoModelowanie obiektowe - Ćw. 6.
1 Modelowanie obiektowe - Ćw. 6. Treść zajęć: Dokumentacja przypadków użycia diagramy czynności. Poznane wcześniej diagramy przypadków użycia pokazują co system powinien robić. Natomiast diagramy czynności
Bardziej szczegółowoInż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ółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoUML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.
45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć
Bardziej szczegółowoProjektowanie baz danych za pomocą narzędzi CASE
Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software
Bardziej szczegółowoInżynieria oprogramowania I
Kontakt Inżynieria I Andrzej Jaszkiewicz Andrzej Jaszkiewicz p. 424y, Piotrowo 3a tel. 66 52 371 jaszkiewicz@cs.put.poznan.pl www-idss.cs.put.poznan.pl/~jaszkiewicz Literatura A. Jaszkiewicz, Inżynieria,
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ół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ółowoOpis. Liczba godzin zajęć dydaktycznych z
Załącznik nr 5 do Uchwały nr 1202 Senatu UwB z dnia 29 lutego 2012 r. Elementy składowe sylabusu Nazwa jednostki prowadzącej kierunek Nazwa kierunku studiów Poziom kształcenia Profil studiów Forma studiów
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoGrupa treści kształcenia, w ramach której przedmiot jest realizowany Przedmiot kierunkowy
SYLLABUS na rok akademicki 0113/014 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
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ółowoDr Katarzyna Grzesiak-Koped
Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd
Bardziej szczegółowoWytwarzanie oprogramowania
AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia
Bardziej szczegółowo