Programowanie Obiektowe Język UML
|
|
- Anatol Król
- 7 lat temu
- Przeglądów:
Transkrypt
1 Programowanie Obiektowe Język UML
2 Wstęp UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcą i syntezą notacji występujących w obiektowych metodykach analizy i projektowania systemów informatycznych, które pojawiły się w końcu lat 80-tych i na początku lat 90- tych. Jest on oparty o pojęcia obiektowości, takie jak obiekty, klasy, atrybuty, związki, agregacje, dziedziczenie, metody i inne. UML powstał w wyniku połączonych wysiłków trzech znanych metodologów: Grady Boocha, Ivara Jacobsona i Jamesa Rumbaugh'a. Są oni autorami popularnych metodyk: OODA (Booch), Objectory (Jacobson) i OMT (Rumbaugh). UML jest zestawem pojęć oraz notacji graficznych (diagramów), które pozwalają wszechstronnie odwzorować modelowaną dziedzinę problemu, założenia projektowanego systemu informatycznego, oraz większość istotnych aspektów jego konstrukcji. UML jest obecnie wspomagany przez wiele narzędzi CASE. Został on także zaakceptowany jako przemysłowy standard przez ciało standardyzacyjne OMG rozwijające standard CORBA. 2
3 Diagram przypadków w użyciau Przypadki użycia (use cases) były w sposób intuicyjny stosowane w tradycyjnym projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk obiektowych. Kariera przypadków użycia w literaturze z zakresu projektowania SI zaczęła się od wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako specjalnego paradygmatu projektowania. Przypadek użycia jest to pewna nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Dla dużych systemów o wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomnieć o strukturze/architekturze systemu i jego detalach technicznych i skoncentrować się na zewnętrznych funkcjach systemu. 3
4 Diagram przypadków w użyciau Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść technokratycznych, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek -przyszły użytkownik systemu - a nie budowa mechanizmu systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami a systemem komputerowym. 4
5 Diagram przypadków w użyciau Podejście od strony przypadków użycia ma przede wszystkim na względzie określenie wymagań na projektowany system. Celem tej metody jest: Głębsze zrozumienie użycia systemu będącego przedmiotem procesu projektowania. Zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu. Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu. Weryfikacja poprawności i kompletności projektu. Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu. Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu. Dostarczenie podstawy do sporządzenia planu testów systemu. 5
6 Diagram przypadków w użyciau Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza jakichkolwiek szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Diagram przypadków użycia zawiera znaki graficzne oznaczające aktorów (ludziki) oraz przypadki użycia (owale z wpisanym tekstem). Aktor Przypadek uzycia Te oznaczenia połączone są liniami odwzorowującymi powiązania poszczególnych aktorów z poszczególnymi przypadkami użycia. Przypadek uzycia Aktor 6
7 Diagram przypadków w użyciau Podstawowym zastosowaniem takich diagramów jest dialog z użytkownikami zmierzający do sformułowania wymagań na system. Stąd wynika, że diagramy i opis przypadków użycia muszą być bardzo naturalne, proste i nie mogą wprowadzać elementów komputerowej egzotyki i żargonu. W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich przy pomocy notacji wprowadzanych w innych diagramach UML. Należy podkreślić, że tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z projektowanym systemem. Każdy aktor używać lub będzie używać systemu na kilka specyficznych sposobów (przypadków użycia). Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja lub inny system komputerowy. 7
8 Diagram przypadków w użyciau Należy zwrócić uwagę, że metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. Jeden aktor może odpowiadać wielu osobom, np. urzędnik. Aktor jest: pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia. odbiorcą informacji wyprodukowanych przez przypadki użycia. Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik, urzędnik, klient. Można tworzyć aktorów abstrakcyjnych, na podobieństwo klas abstrakcyjnych. Np. aktor urzędnik jest nadklasą dla aktorów kasjer i dyrektor ; powiązania z konkretnymi przypadkami użycia mogą być ustalone zgodnie z tą hierarchią klas aktorów. 8
9 Diagram przypadków w użyciau Przypadek użycia reprezentuje: sekwencję operacji lub transakcji wykonywanych przez system w trakcie interakcji z użytkownikiem; np. potwierdzenie pisma, złożenie zamówienia. przepływ zdarzeń w systemie i są uruchamiane (inicjowane) przez aktorów. Przypadek użycia jest zwykle charakteryzowany przez krótką nazwę. Opis przypadku użycia może być jednak dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: Jak i kiedy przypadek użycia zaczyna się i kończy. Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie. Wyjątki przy przepływie zdarzeń. 9
10 Diagram przypadków w użyciau Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy: Krótki opis przypadku użycia. Przepływ zdarzeń opisany nieformalnie. Związki pomiędzy przypadkami użycia. Uczestniczące obiekty. Specjalne wymagania (np. czas odpowiedzi, wydajność). Obrazy interfejsu użytkownika. Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów). Diagramy interakcji dla każdego aktora. 10
11 Diagram przypadków w użyciau UML wprowadza także bardzo proste powiązania pomiędzy przypadkami użycia, oznaczane strzałkami dodatkowymi napisami «extend» (rozszerza), <<include>> (zawiera). Przypadek użycia podłączony przez strzałkę «extend» oznacza, że niekiedy (nie zawsze) dany przypadek użycia jest rozszerzony przez inny przypadek użycia. Przypadek użycia podłączony przez strzałkę «include» oznacza, że pewien przypadek zawiera zachowanie innego przypadku, który warto jest wyodrębnić ze względu na późniejszą możliwość uniknięcia wielokrotnej implementacji tego fragmentu. <<extend>> Request Catalog Place Order <<include>> <<include>> Order Product Arrange Payment 11
12 Diagram przypadków w użyciau Pewne fragmenty diagramu przypadków są grupowane jako podsystemy. Graficznie granice systemu (system boundary) oznaczane sa jako prostokąt otaczający wszystkie elementy wchodzące w skład systemu. <<extend>> Request Catalog Customer Place Order <<include>> <<include>> Salesperson Order Product Arrange Payment Selling system 12
13 Diagram przypadków w użyciau Między aktorami i przypadkami użycia mogą zachodzić relacje generalizacji. Relacja ta oznacza iż pewien byt jest uogólnieniem innego lub innych. Z drugiej strony można powiedzieć, że określone byty są szczególnymi przypadkami swojej generalizacji. Oddanie indeksu Przekazanie dokumentu Oddanie karty zaliczeniowej Przekazanie podania Kierownik Przekazanie podania o urlop Osoba Pracownik Kierownik katedry Pracownik naukowy 13
14 Diagram przypadków w użyciau Między aktorami, a przypadkami mogą istnieć relacje o różnej krotności. Krotność powiązania dotyczy obu stron relacji wiążącej. Wyróżnia się następujące krotności: 1 dokładnie jeden lub 1 1..* 1 lub więcej n..m nie mniej niż n i nie więcej niż m * dowolna ilość 1 * Request Catalog * 1 1 <<extend>> Customer Salesperson * Place Order <<include>> <<include>> Order Product Arrange Payment Selling system 14
15 Diagram przypadków w użyciau W celu umieszczenia dodatkowych komentarzy umieszcza się notki zakotwiczone do bytów których dotyczą. Asocjacja jeden do wielu Pracownik sklepu lub akwizytor 1 * Request Catalog * 1 1 <<extend>> Customer Salesperson * Place Order <<include>> <<include>> Order Product Arrange Payment Selling system Granice systemu 15
16 Diagram klas Diagram klas (dawniej: diagram asocjacji klas lub model obiektowy) jest pojęciem kluczowym we wszystkich metodykach obiektowych. Często diagram klas odpowiada diagramowi encja-związek rozbudowanym o dodatkowe elementy. W odróżnieniu od diagramów encja-związek diagramy klas posiadają metody przypisane do specyfikowanych klas. Poza tym pojawiają się w diagramach klas różnorodne pomocnicze oznaczenia. Diagram klas pokazuje klasy w postaci pewnych oznaczeń graficznych powiązanych w sieć zależnościami należącymi do trzech kategorii: Dziedziczenie (inheritance) - ustalenie związku generalizacji/specjalizacji pomiędzy klasami. Asocjacja (association) - dowolny związek pomiędzy obiektami dziedziny przedmiotowej, który ma znaczenie dla modelowania. Agregacja (aggregation) - stosunek całość-część pomiędzy obiektami z modelowanej dziedziny przedmiotowej jest to szczególny przypadek asocjacji. 16
17 Diagram klas Diagram klas w identycznej wersji jest stosowany zarówno do zapisu wyników analizy jak i do specyfikowania założeń projektowych. Diagramy klas są podstawą dowolnej analizy i dowolnego projektu. Żaden projekt obiektowy nie może się obejść bez diagramu klas. Podstawowe zastosowania diagramów klas: Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań, które aktualnie podlegają analizie. Model pojęciowy nie musi być związany z jakimkolwiek oprogramowaniem. Sformalizowana specyfikacja danych i metod. Jest ona bardziej związana z oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne. Często podkreślaną zaletą obiektowości jest hermetyzacja, polegająca na oddzieleniu specyfikacji od implementacji. Dla wielu celów zależy nam wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów, metod, itd.), bez wchodzenia w szczegóły. Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++. 17
18 Diagram klas Klasa: Elementy składowe diagramów klas. Podstawowa postać graficzna: Klasa Postacie graficzne przykładowych stereotypów klas: Aktor: Aktor biznesowy: Klasa Klasa Dokument biznesowy: Klasa Tabela: Klasa 18
19 Diagram klas Elementy składowe klasy: Klasa abstrakcji: Klasa Atrybuty: Atrybut_Publiczny Atrybut_Prywatny : int = 5 Atrybut_Chroniony : unsigned Statyczny : float Klasa Operacje: Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0) Operacja_Prywatna() : int Operacja_Chroniona(Parametr) 19
20 Diagram klas Szablon klasy: T Atrybut_Publiczny Atrybut_Prywatny : int = 5 Atrybut_Chroniony : unsigned Statyczny : float Klasa <<bind>> Przypisanie Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0) Operacja_Prywatna() : int Operacja_Chroniona(Parametr) Dodaj(T) : bool 20
21 Diagram klas Pakiet: Pakiety służą do grupowania elementów diagramów. Pakiet A Pakiet B Klient Dostawca 21
22 Diagram klas Interfejs: Interfejs reprezentuje zestaw operacji, które określają usługi oferowane przez klasę. Nie posiadają atrybutów i powiązań. Posiadają tylko operacje. Mogą one posiadać związki generalizacji. Interfejs Atrybut_Publiczny Atrybut_Prywatny : int = 5 Atrybut_Chroniony : unsigned Statyczny : float Klasa Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0) Operacja_Prywatna() : int Operacja_Chroniona(Parametr) 22
23 Diagram klas Użycie interfejsu przez klasę. Postać rozwinięta: Kartoteka <<use>> <<Interface>> DanePersonalne getimie() : AnsiString getnazwisko() : AnsiString Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString getimie() : AnsiString getnazwisko() : AnsiString Postać uproszczona: Kartoteka <<use>> Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString DanePersonalne getimie() : AnsiString getnazwisko() : AnsiString getimie() : AnsiString getnazwisko() : AnsiString 23
24 Diagram klas Związki: W diagramie klas występują następujące typy powiązań. powiązanie, zależność, generalizacja, realizacja. 24
25 Diagram klas Powiązanie: Powiązanie jest związkiem strukturalnym, który pokazuje że obiekty jednego elementu są połączone z obiektami innego. Książka Biblioteka Połączenie można uzupełnić o następujące elementy: nazwa, rola, liczebność, nawigacja, agregacja, rodzaj agregacji, kwalifikacja, klasa powiązania, ograniczenia. 25
26 Diagram klas Nazwa powiązania: Element Udostępnianie Zbiór Rola: Element +Książka Udostępnianie #Biblioteka Zbiór 0..* 1 Liczebność: Element +Książka Udostępnianie +Biblioteka Zbiór 0..* 1 Nawigacja: Element +Książka Udostępnianie +Biblioteka Zbiór 0..* 1 26
27 Diagram klas Agregacja: Element +Książka Udostępnianie +Biblioteka Zbiór 0..* 1 Agregacja całkowita: Element +Książka Udostępnianie +Biblioteka Zbiór 0..* 1 Kwalifikacja: Klasa powiązania: Element Element +Książka Udostępnianie +Biblioteka ID_Elementu : long 0..* 1 +Książka ID_Elementu : long 0..* Udostępnianie #Biblioteka 1 Zbiór Zbiór Położenie 27
28 Diagram klas Ograniczenia: Element +Książka ID_Elementu : long 0..n {ordered} Udostępnianie #Biblioteka 1 Zbiór Położenie Rodzaje ograniczeń: implicit związek nie jest jawny (pojęciowy), ordered zbiór obiektów jest uporządkowany, changeable wiązanie między obiektami mogą być dodawane, usuwane i modyfikowane, addonly nowe wiązania można dodawać do zbioru wartości atrybutu, ale raz dodane nie mogą być modyfikowane ani usuwane, frozen wartość nie może być zmieniana po zainicjowaniu obiektu, żadne nowe elementy nie mogą być dodane do zbioru wartości. 28
29 Diagram klas Ograniczenia: Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString Pracuje {subset} Kieruje 0..* 0..* Przedsiębiortstwo getimie() : AnsiString getnazwisko() : AnsiString 1 0..* Konto {xor} Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString 0..* {subset} Kieruje 0..* Przedsiębiortstwo getimie() : AnsiString getnazwisko() : AnsiString 1 0..* 29
30 Diagram klas Zależność: Zależność jest to związek użycia. Zmiany dokonane w definicji jednego elementu mogą mieć wpływ na inny element. Pakiet A Pakiet B Kartoteka <<use>> <<Interface>> DanePersonalne getimie() : AnsiString getnazwisko() : AnsiString Klient Dostawca 30
31 Diagram klas Stereotypy ograniczeń: bind derive friend use access import 31
32 Diagram klas Stereotyp zależności: bind Źródło tworzy egzemplarz wzorca docelowego z użyciem danych parametrów aktualnych. T Atrybut_Publiczny Atrybut_Prywatny : int = 5 Atrybut_Chroniony : unsigned Statyczny : float Klasa <<bind>> Przypisanie Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0) Operacja_Prywatna() : int Operacja_Chroniona(Parametr) Dodaj(T) : bool 32
33 Diagram klas Stereotyp zależności: derive Źródło można wyznaczyć na podstawie celu. DataUrodzenia <<derive>> Wiek Stereotyp zależności: friend Źródło można szczególny dostęp do wnętrza celu. Pracownik ID_Pracownik : long Stanowisko : AnsiString <<friend>> ListaPłac 33
34 Diagram klas Stereotyp zależności: use Znaczenie bytu źródłowego zależy od znaczenia części publicznej celu Stereotyp zależności: access Kartoteka <<use>> <<Interface>> DanePersonalne getimie() : AnsiString getnazwisko() : AnsiString Źródło ma prawo dostępu do bytów pakietu docelowego. Pakiet A <<access>> Pakiet B Stereotyp zależności: import Zawartość publiczna pakietu docelowego zostaje dołączona do źródła. Pakiet A <<import>> Pakiet B 34
35 Diagram klas Generalizacja: Generalizacja jest to związek między elementem ogólnym, a specyficznym jego rodzajem. Potomek dziedziczy strukturę i zachowanie po przodku (uwzględniając zakresy widoczności). Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString getimie() : AnsiString getnazwisko() : AnsiString Kierownik Pracownik ID_Pracownik : long Stanowisko : AnsiString {incomplete} <<implementation>> Nadzór PracownikNaukowy StopienNaukowy : AnsiString Dziekan Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne). 35
36 Diagram klas Ograniczenia generalizacji: disjoint obiekty przodka mogą mieć nie więcej niż jednego potomka jako typ. overlapping obiekty mogą posiadać dwóch lub więcej potomków jako typ complete wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i nie wolno dodawać żadnych nowych potomków. incomplete nie wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i wolno dodawać nowych potomków. Kierownik Pracownik ID_Pracownik : long Stanowisko : AnsiString {incomplete} <<implementation>> Nadzór PracownikNaukowy StopienNaukowy : AnsiString Dziekan Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne). 36
37 Diagram klas Realizacja: Realizacja jest to związek znaczeniowy między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego: Realizacja <<Interface>> DanePersonalne getimie() : AnsiString getnazwisko() : AnsiString Osoba Numer : long Imie : AnsiString Nazwisko : AnsiString getimie() : AnsiString getnazwisko() : AnsiString Picture Display 37
38 Diagram obiektów Diagram obiektów służy do modelowania statycznych aspektów perspektywy projektowej lub procesowej. Wyobrażają one stan systemu w danej chwili. Uwzględnia się na nim: zbiór obiektów, stan obiektów, związki między obiektami. k2 : Konto p1 : Przedsiębiortstwo o1 : Osoba o2 : Osoba o3 : Osoba o4 : Osoba k1 : Konto k4 : Konto k3 : Konto 38
39 Diagram sekwencji Diagram sekwencji (diagram przebiegu) służy do modelowania dynamicznych aspektów perspektywy projektowej lub procesowej. Uwypukla się na nim kolejność komunikatów w czasie. k : Klient : BazaDanych Uwzględnia się na nich: obiekty, czas życia obiektów, komunikaty. 1: <<create>> 2: Set(x,y,z) t : Transakcja 3: Weryfikacja Rodzaje komunikatów: przejście do następnego kroku, wywołanie procedury, asynchroniczne przejście, powrót z procedury. 6: Potwierdzenie 7: <destroy>> 4: Write(a,5,8) 5: Write(b,Kowalski) 39
40 Diagram sekwencji Przykład: : Klient : Bankomat : BazaDanych 1: Włożenie karty 2: Prośba o PIN 3: Podanie PIN 6: Pytanie o kwotę 4: Weryfikacja PIN 5: Potwierdzenie PIN 7: Podanie kwoty 8: <<create>> : Transakcja 9: Realizacja 10: Werfikacja 13: Wypłata gotówki 12: Zakończona 14: <<destroy>> 11: Transakcja zapisana 40
41 Diagram kooperacji Diagram kooperacji służy do pokazania organizacji obiektów uczestniczących w interakcji. : Transakcja 7: Podanie kwoty 8: <<create>> 12: Zakończona 9: Realizacja 10: Weryfikacja 3: Podanie PIN 11: Transakcja zapisana 14: <<destroy>> 1: Włożenie karty 4: Weryfikacja PIN : Klient : Bankomat : BazaDanych 2: Prośba o PIN 5: Potwierdzenie PIN 6: Pytanie o kwotę 13: Wypłata gotówki 41
42 Diagram czynności ci Diagram czynności służy do modelowania dynamicznych aspektów systemu. Przedstawia się na nim sekwencyjne lub współbieżne kroki procesu. Można też zobrazować zmiany zachodzące w obiektach w różnych fazach przepływu sterowania. Punkt startowy: Przepływ obiektu: Punkt końcowy: Stan obiektu: Obiekt [Stan obiektu] Czynność: Czynność Tor Przejście: Tor: Punkt synchronizacji: Decyzja: 42
43 Diagram czynności ci Przykład: Klient Sprzedawca Magazyn Żądanie obsługi Odbiór zlecenia Płatność Realizacja zlecenia Dostarczenie Odbiór 43
44 Diagram czynności ci Przykład: Klient Sprzedawca Magazyn Klient Sprzedawca Magazyn Żądanie obsługi Żądanie obsługi Zlecenie [złożone] Odbiór zlecenia Odbiór zlecenia Zlecenie [wprowadzone] Realizacja zlecenia Płatność Realizacja zlecenia Płatność Zlecenie [zrealizowane] Dostarczenie Dostarczenie Zlecenie [dostarczone] Odbiór Odbiór 44
45 Diagram czynności ci Przykład: Włącz zasilanie [System niesprawny] Wyłącz zasilanie Zatrzymaj się [System sprawny] Uruchom silnik Sprawdz drogę [Cel osiągnięty] Wyszukaj nową drogę [Droga zajęta] [Droga wolna] Jedz [Cel nieosiagniety] 45
46 Diagram stanów Diagram stanów służy do modelowania dynamicznych aspektów systemu. Uwzględnia się historię życia egzemplarzy, klasy, przypadku użycia lub systemu. Egzemplarze reagują na zdarzenia, jak sygnały wywołania operacji i upływ czasu. Po zajściu zdarzenia są wykonywane czynności, które zależą od bieżącego stanu obiektu. Czynności powodują zmianę stanu lub przekazanie wartości. Stan jest to okoliczność lub sytuacja, w jakiej się znajduje. Stan początkowy: Stan końcowy: Stan: Błąd logowania do / ShowMessage("Login error") Przejście Zdarzenie: Wprowadzono hasło 46
47 Diagram stanów Przykład: WyszukanieUżytkownika do / SearchUser Zakończono wyszukiwanie [Znaleziono] Wprowadzono Login Zakończono wyszukiwanie [Nie znaleziono] Wprowadzanie loginu entry / ShowLoginWindow Zmiana użytkownika/ Logout Błąd logowania do / ShowMessage("Login error") po 10 sek./ Terminate program Zakończenie programu/ Terminate Program Praca z programem Zakończono weryfikację [Błędne hasło]/ disable program Wprowadzanie Hasła do / ShowPassWindow Wprowadzono hasło Weryfikacja hasła do / Verify Zakończono weryfikację/ enable program 47
Rysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
Bardziej szczegół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ół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ół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 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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ół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ółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
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ół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ół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ółowoWprowadzenie do UML, przykład użycia kolizja
Bogdan Kreczmer bogdan.kreczmer@pwr.wroc.pl Zakład Podstaw Cybernetyki i Robotyki Instytut Informatyki, Automatyki i Robotyki Politechnika Wrocławska Kurs: Copyright c 2012 Bogdan Kreczmer Niniejszy dokument
Bardziej szczegółowoInżynieria oprogramowania. Część 5: UML Diagramy klas
UNIWERSYTET RZESZOWSKI KATEDRA INFORMATYKI Opracował: mgr inż. Przemysław Pardel v1.01 2010 Inżynieria oprogramowania Część 5: UML Diagramy klas ZAGADNIENIA DO ZREALIZOWANIA (3H) 1. Diagram klas... 3 Zadanie
Bardziej szczegółowoInżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji
Inżynieria oprogramowania Jarosław Kuchta Modelowanie interakcji Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja
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ół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ół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ół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ółowoDiagramy UML, przykład problemu kolizji
Bogdan Kreczmer bogdan.kreczmer@pwr.edu.pl Katedra Cybernetyki i Robotyki Wydział Elektroniki Politechnika Wrocławska Kurs: Copyright c 2015 Bogdan Kreczmer Niniejszy dokument zawiera materiały do wykładu
Bardziej szczegół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ół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ół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ół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ółowoMAS dr. Inż. Mariusz Trzaska
MAS dr. Inż. Mariusz Trzaska Wykład 2 Model przypadków użycia Zagadnienia Prezentowanie diagramów Stereotypy; komentarze Klasyfikatory; wystąpienia klasyfikatorów Związki pomiędzy elementami modelowania
Bardziej szczegółowoDiagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Diagramy interakcji Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania.
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ół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ółowokoniec punkt zatrzymania przepływów sterowania na diagramie czynności
Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy
Bardziej szczegół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ół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ół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ół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ół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ół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ółowoInżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia
Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu
Bardziej szczegół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ół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ół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ół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ół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ół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ółowoTechnologie obiektowe
WYKŁAD dr inż. Paweł Jarosz Instytut Informatyki Politechnika Krakowska mail: pjarosz@pk.edu.pl LABORATORIUM dr inż. Paweł Jarosz (3 grupy) mgr inż. Piotr Szuster (3 grupy) warunki zaliczenia Obecność
Bardziej szczegółowoOprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria:
1. Podaj definicję inżynierii oprogramowania. Inżynieria oprogramowania to wiedza techniczna, dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu
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ół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ół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 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ółowoPodstawy języka UML2 w realnych projektach
Kod szkolenia: Tytuł szkolenia: UML2/RP Podstawy języka UML2 w realnych projektach Dni: 3 Opis: Adresaci Szkolenia: Szkolenie adresowane jest do osób, które chciałby poznać podstawy UML2. Przede wszystkim
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 sekwencji. wymienianych między nimi
Diagramy sekwencji Graficzne przedstawienie interakcji pomiędzy instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi Przykład diagramu sekwencji Układ diagramu wymiar
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ół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ółowoMODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.
PRACA DYPLOMOWA WYŻSZE STUDIA ZAWODOWE MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. Marcin Brudka 3901 Promotor: Prof. dr hab. inż. Piotr
Bardziej szczegół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ółowoNIFIED M L ODELLING ANGUAGE. Diagramy czynności
U M L NIFIED ODELLING ANGUAGE Diagramy czynności 1 Czym jest diagram czynności? Jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu. Przedstawia przepływ sterowania
Bardziej szczegółowoProgramowanie współbieżne i rozproszone
Programowanie współbieżne i rozproszone WYKŁAD 11 dr inż. CORBA CORBA (Common Object Request Broker Architecture) standard programowania rozproszonego zaproponowany przez OMG (Object Management Group)
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 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ół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ół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ółowoModelowanie aktywności. Jarosław Kuchta Programowanie Współbieżne
Modelowanie aktywności Jarosław Kuchta Programowanie Współbieżne Pojęcia podstawowe (1/3) behawioryzm ogół zachowania obiektów, reakcje obiektów na zdarzenia. stan sytuacja w czasie życia obiektu, w którym
Bardziej szczegółowoMiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska
MiASI Modelowanie systemów biznesowych Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 stycznia 2010 Spis treści 1 Czym jest system biznesowy? Po co model bizensowy? Czym
Bardziej szczegół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ółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt
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ółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
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ółowoAPIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI
APIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI dr inż. Grażyna Hołodnik-Janczura W8/K4 CO SIĘ MOŻE DZIAĆ PODCZAS WYKONYWANIA BIZNESOWEJ FUNKCJI
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ółowoUML- Unified Modeling Language Ujednolicony Język Modelowania
UML- Unified Modeling Language Ujednolicony Język Modelowania UML jest standardowym językiem do specyfikacji, wizualizacji, budowy i dokumentowania wszystkich artefaktów (wytworów) dowolnego systemu. UML
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ół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ół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ół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 języka UML2 w realnych projektach
Kod szkolenia: Tytuł szkolenia: UML2/RP Podstawy języka UML2 w realnych projektach Dni: 3 W cenie szkolenia uczestnik otrzymuje licencję na oprogramowanie Enterprise Architect, najlepsze narzędzie do modelowania
Bardziej szczegółowoAnaliza i projektowanie obiektowe
Analiza i projektowanie obiektowe Procesy budowy systemów informatycznych Fazy procesu budowy SI Specyfikacja wymagań o Analiza dziedziny modelowanie podstawowych pojęć i terminów Analiza systemowa modelowanie
Bardziej szczegółowo