Inżynieria oprogramowania wykład VII Faza analizy analiza obiektowa Język UML wprowadzenie, diagramy struktury
|
|
- Arkadiusz Małecki
- 6 lat temu
- Przeglądów:
Transkrypt
1 Inżynieria oprogramowania wykład VII Faza analizy analiza obiektowa Język UML wprowadzenie, diagramy struktury prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO
2 W niniejszym wykładzie wykorzystano m.in. materiały dydaktyczne ze strony projektu Opracowanie programów nauczania na odległość na kierunku studiów wyższych Informatyka autorstwa p. Bartosza Waltera: K. Bartecki, Inżynieria oprogramowania, VII/2
3 Faza analizy systemowej ciąg dalszy Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Przypomnienie: Jej celem jest udzielenie odpowiedzi na pytanie: jak system ma działać? W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący od szczegółów implementacyjnych. K. Bartecki, Inżynieria oprogramowania, VII/3
4 Metody analizy systemowej podział STRUKTURALNE Wyróżniają w systemie dwa rodzaje składowych: pasywne (dane), aktywne (operacje funkcje). OBIEKTOWE Opisują system jako układ współdziałających z sobą obiektów, łączących w jedną całość dane i operacje na tych danych wykonywane. K. Bartecki, Inżynieria oprogramowania, VII/4
5 Różnica między podejściem strukturalnym a obiektowym Podejście strukturalne (C): Podejście obiektowe (C): struct Punkt { int x, y; }; void narysuj(struct Punkt P) { // ciało funkcji } class Punkt { int x, y; public: void narysuj() { // ciało funkcji } }; K. Bartecki, Inżynieria oprogramowania, VII/5
6 Pojęcie obiektu oraz klasy (przypomnienie) Obiekt: to konkretny lub abstrakcyjny byt, wyróżnialny w modelowanej rzeczywistości, posiada określone granice i atrybuty (właściwości), może świadczyć określone usługi, czyli wykonywać określone operacje oraz przejawiać określone zachowanie. Klasa to: opis takich cech grupy podobnych obiektów, które są dla nich niezmienne np. zestaw atrybutów i operacji (metod), czyli usług, które mogą one świadczyć. K. Bartecki, Inżynieria oprogramowania, VII/6
7 Analiza obiektowa Popularność obiektowych metod analizy ściśle wiąże się z rosnącą popularnością obiektowych języków programowania oraz środowisk implementacji. Programowanie obiektowe ułatwia m.in.: hermetyzację (ukrywanie) danych (ang. data encapsulation), ponowne wykorzystanie kodu (ang. code reuse), szybkie prototypowanie aplikacji (ang. rapid prototyping), programowanie oparte na zdarzeniach (ang. eventdriven programming). K. Bartecki, Inżynieria oprogramowania, VII/7
8 Hermetyzacja danych polega na tym, że dane obiektu (reprezentowane przez jego atrybuty) są ukryte ( prywatne ) i traktowane jako nierozdzielna całość z publicznymi usługami (operacjami), udostępnionymi przez obiekt. Dzięki hermetyzacji zwiększamy odporność programu na błędy poprzez: ochronę przed nieświadomym popsuciem obiektu użytkownik klasy nie ma dostępu do jej prywatnych pól, zapewnienie właściwego interfejsu użytkownik ma do dyspozycji tylko niezbędne operacje, co ułatwia mu korzystanie z klasy, ochronę przed konsekwencjami zmiany implementacji twórca klasy może zmienić zestaw prywatnych atrybutów oraz implementację prywatnych metod, nie zmieniając interfejsu publicznego wszystkie programy napisane przy wykorzystaniu tego interfejsu nie będą wymagały żadnych zmian. K. Bartecki, Inżynieria oprogramowania, VII/8
9 Ponowne wykorzystanie kodu polega na wykorzystaniu już istniejących klas przy tworzeniu nowych klas, co znacznie oszczędza pracę przy kodowaniu, a także czyni programowanie mniej podatne na błędy. Istnieją dwa sposoby ponownego wykorzystania kodu klas: kompozycja, czyli definiowanie w nowo tworzonej klasie pól obiektowych reprezentowanych przez klasę już istniejącą, np.: public class RegisteredUser { } private Person person; private Address address; private String ; //... dziedziczenie, czyli przejęcie właściwości i funkcjonalności obiektów innej klasy i ewentualną ich modyfikację w taki sposób, aby były one bardziej wyspecjalizowane (tzw. związek generalizacjispecjalizacji): public class AppartmentAddress extends Address { } //... K. Bartecki, Inżynieria oprogramowania, VII/9
10 Szybkie prototypowanie aplikacji oraz programowanie oparte na zdarzeniach jest obecnie możliwe głównie dzięki wykorzystaniu narzędzi RAD (ang. Rapid Application Development), czyli narzędzi do szybkiego wytwarzania aplikacji. Narzędzia RAD wywodzą się z klasycznych zintegrowanych środowisk programistycznych (ang. Integrated Development Environment, IDE) i oparte są na bibliotekach obiektowych, pozwalających łatwo tworzyć graficzny interfejs użytkownika (ang. Graphical User Interface, GUI), a także umożliwiają dostęp do baz danych. Pierwszym popularnym środowiskiem o cechach RAD był Visual Basic firmy Microsoft (koniec lat 80. XX wieku, oficjalna premiera w 1991). Przykłady popularnych narzędzi RAD: o CBuilder (Borland, od 2009 Embarcadero Technologies), o Delphi (Borland, od 2009 Embarcadero Technologies), o Visual Studio (Microsoft), o NetBeans (Sun Microsystems, od 2010 Oracle Corporation), o Lazarus (projekt open source, oparty na kompilatorze Free Pascal, zgodny z Delphi). K. Bartecki, Inżynieria oprogramowania, VII/10
11 Wygląd pierwszej wersji narzędzia Visual Basic z roku 1991 K. Bartecki, Inżynieria oprogramowania, VII/11
12 Analiza obiektowa c.d. Na początku lat 90. ubiegłego wieku istniało wiele notacji i metodyk analizy obiektowej, stosujących elementy o zbliżonej semantyce (np. pojęcie klasy), ale różniące się sposobem ich reprezentacji. Należały do nich m.in.: OMT (ang. Object Modelling Technique), J. Rumbaugh, 1991; OOSE (ang. ObjectOriented Software Engineering), I. Jacobson, 1992; OOAD (ang. ObjectOriented Analysis and Design), G. Booch, 1994; OOA, OOD (ang. ObjectOriented Analysis, ObjectOriented Design), P. Coad i E. Yourdon, K. Bartecki, Inżynieria oprogramowania, VII/12
13 Około roku 1995 Booch, Jacobson i Rumbaugh ( trzej amigos ) podjęli działania nad ujednoliceniem swoich notacji, tworząc jedną metodę tak powstała najpierw Metoda Zunifikowana (ang. Unified Method), a następnie Zunifikowany Język Modelowania (ang. Unified Modeling Language, UML). K. Bartecki, Inżynieria oprogramowania, VII/13
14 Historia UML UML 2.2 UML K. Bartecki, Inżynieria oprogramowania, VII/14
15 Drzewo genealogiczne UML K. Bartecki, Inżynieria oprogramowania, VII/15
16 UML zawiera dwie podstawowe składowe: notację poszczególnych elementów używanych na diagramach, metamodel, czyli definicje pojęć języka i powiązania między nimi. Z punktu widzenia analityka istotniejsze jest czytelne i jednoznaczne opisanie modelu tak, aby inne osoby mogły zrozumieć jego znaczenie. Zatem ważniejsza dla niego jest notacja, zaś metamodel powinien być zrozumiały intuicyjnie. Z kolei przy generowaniu kodu i przejściu do implementacji, ważniejsze jest ścisłe rozumienie znaczenia poszczególnych elementów czyli metamodel. Uwaga: UML nie jest metodyką obiektową nie określa metody modelowania. UML jest językiem modelowania obiektowego. K. Bartecki, Inżynieria oprogramowania, VII/16
17 W najnowszej wersji UML (2.5) wyróżnia się 14 rodzajów diagramów, podzielonych na dwie główne grupy: diagramy opisujące strukturę systemu (ang. structure diagrams), diagramy opisujące zachowanie systemu (ang. behavior diagrams). K. Bartecki, Inżynieria oprogramowania, VII/17
18 Diagramy struktury: diagram klas (ang. class diagram), diagram obiektów (ang. object diagram), diagram komponentów (ang. component diagram), diagram wdrożeniowy (ang. deployment diagram), diagram pakietów (ang. package diagram) od UML 2.0, diagram struktur złożonych (ang. composite structure diagram) od UML 2.0, diagram profili (ang. profile diagram) od UML 2.2. K. Bartecki, Inżynieria oprogramowania, VII/18
19 Diagramy dynamiki: diagram przypadków użycia (ang. use case diagram), diagram czynności (ang. activity diagram), diagram maszyny stanowej (ang. state machine diagram) wcześniej nazywany diagramem stanów. W ramach diagramów dynamiki wyróżnia się tzw. diagramy interakcji: diagram sekwencji (ang. sequence diagram), diagram komunikacji (ang. communication diagram) wcześniej nazywany diagramem współpracy lub współdziałania, diagram zależności czasowych (ang. timing diagram) od UML 2.0, diagram przeglądu interakcji (ang. interaction overview diagram) od UML 2.0. K. Bartecki, Inżynieria oprogramowania, VII/19
20 W praktyce rzadko wymagane jest opracowywanie wszystkich diagramów. Najczęściej wykorzystywane diagramy: klas, przypadków użycia, sekwencji, aktywności. Pozostałe często bywają pomijane, zwłaszcza przy projektowaniu niewielkich systemów informatycznych. K. Bartecki, Inżynieria oprogramowania, VII/20
21 Przykładowe diagramy języka UML K. Bartecki, Inżynieria oprogramowania, VII/21
22 W ramach diagramów struktury UML na wykładzie omówione zostaną: diagram klas, diagram obiektów, diagram pakietów, diagram komponentów, diagram wdrożeniowy. K. Bartecki, Inżynieria oprogramowania, VII/22
23 Diagram klas jest podstawowym diagramem przedstawiającym logiczną strukturę systemu, przedstawia występujące w systemie klasy i zachodzące pomiędzy nimi statyczne relacje, klasy na diagramie reprezentowane przez prostokąty mogą one zawierać, oprócz nazwy klasy, informację o jej danych składowych (atrybutach) i operacjach dostarczanych przez klasę (metodach), spośród wszystkich diagramów UML jest on najbardziej pojemny i z tego względu jest najczęściej stosowany do generowania kodu na podstawie modelu. K. Bartecki, Inżynieria oprogramowania, VII/23
24 Tworzenie diagramu klas obejmuje: identyfikację klas, identyfikację związków pomiędzy klasami, identyfikację i definiowanie pól danych (atrybutów), identyfikację i definiowanie operacji (metod) i komunikatów. Kolejność wykonywania tych czynności nie jest ściśle ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. K. Bartecki, Inżynieria oprogramowania, VII/24
25 Przykładowy diagram klas K. Bartecki, Inżynieria oprogramowania, VII/25
26 nazwa atrybuty operacje Klasa jest reprezentowana na diagramie przez prostokąt z wydzielonymi przedziałami: nazwą, atrybutami i operacjami. K. Bartecki, Inżynieria oprogramowania, VII/26
27 Cechy klasy reprezentują informację, jaką klasa przechowuje, mogą zostać zapisane w postaci dwóch równoważnych notacji: o jako atrybuty klasy (umieszczane w przedziale atrybutów), o jako związki pomiędzy klasami (zapisywane w postaci linii łączącej klasy). pierwsza notacja jest zwykle stosowana do typów prostych, natomiast druga do typów złożonych (klas). na przykład, na naszym diagramie nr zamówienia, który jest typu prostego (long int) został zapisany jako atrybut klasy Zamówienie, zaś Klient został uwzględniony poprzez związek łączący te dwie klasy. Zamówienie nr zamówienia kwota zamówienia data zamówienia czy opłacone Zamowienie (long nr) ~Zamowienie ()... : long : float : std::string : bool 0..* skladane 1..1 skladajacy nazwisko_imie adres telefon Klient : std::string : std::string : std::string : std::string Klient (std::string ni, std::string ad, std::string em, ~Klient () K. Bartecki, Inżynieria oprogramowania, VII/27
28 Atrybut zwykle jest opisywany tylko przez dwa elementy: nazwę i typ. Jednak pełna jego definicja może obejmować także dodatkowe informacje: K. Bartecki, Inżynieria oprogramowania, VII/28
29 K. Bartecki, Inżynieria oprogramowania, VII/29
30 Operacje klasy reprezentują usługi, jakie klasa oferuje, realizacje operacji czyli metody dostarczają implementacji tych usług, oprócz nazwy operacji wraz listą jej parametrów oraz informacją o zwracanym przez nią typie, jej definicja na diagramie może obejmować pewne dodatkowe informacje: K. Bartecki, Inżynieria oprogramowania, VII/30
31 Związki klas to ogólne określenie relacji zachodzących między klasami, gdy jedna z nich w pewien sposób używa innej klasy. Diagramy klas mogą uwzględniać następujące rodzaje związków: zależność (ang. dependency), asocjacja (ang. association), agregacja (ang. aggregation), kompozycja (ang. composition), generalizacjaspecjalizacja (ang. generalizationspecialization). K. Bartecki, Inżynieria oprogramowania, VII/31
32 Związek zależności K. Bartecki, Inżynieria oprogramowania, VII/32
33 Właściwości związku zależności Zależność pomiędzy klasami A i B informuje, że jedna z nich, aby używać obiektów innej, musi mieć o niej informacje. Zależność występuje, gdy zmiana specyfikacji klasy A, może powodować konieczność wprowadzania zmiany w klasie B. Najczęściej używa się zależności do pokazania, że klasa A używa klasy B jako parametru jakiejś operacji, lub że operacje klasy A tworzą lokalne obiekty klasy B. Obie klasy są zależne od siebie nawzajem w celu zapewnienia poprawnego działania systemu. Zależności często opisuje się frazami: korzysta z, oddziałuje na, ma wpływ na, tworzy. K. Bartecki, Inżynieria oprogramowania, VII/33
34 Przykład implementacji związku zależności w kodzie Javy import B; public class A { public void method1(b b) // obiekt klasy B jako parametr { //... } // metody klasy A public void method2() { B tempb = new B() } // metoda klasy A tworzy } // lokalny obiekt klasy B K. Bartecki, Inżynieria oprogramowania, VII/34
35 Związek asocjacji Zamówienie nr zamówienia kwota zamówienia data zamówienia czy opłacone Zamowienie (long nr) ~Zamowienie ()... : long : float : std::string : bool 0..* skladane 1..1 skladajacy nazwisko_imie adres telefon Klient : std::string : std::string : std::string : std::string Klient (std::string ni, std::string ad, std::string em, ~Klient () K. Bartecki, Inżynieria oprogramowania, VII/35
36 Właściwości związku asocjacji Asocjacje są relacjami silniejszymi niż zależności wskazują, że jeden obiekt jest związany z innym przez pewien okres czasu, jednak czas życia obu obiektów nie jest od siebie zależny: usunięcie jednego nie powoduje usunięcia drugiego. W przypadku asocjacji żaden obiekt nie jest właścicielem drugiego: nie tworzy go, nie zarządza nim, a moment usunięcia drugiego obiektu nie jest z nim związany. Asocjacje mogą posiadać nazwy, zwykle w formie czasownika, pozwalającego przeczytać w języku naturalnym jej znaczenie, np. A posiada B. K. Bartecki, Inżynieria oprogramowania, VII/36
37 Właściwości związku asocjacji c.d. Najczęściej używa się związku asocjacji do pokazania, że obiekt klasy A może zawierać (lub być związany z) jednym lub wieloma obiektami klasy B. Asocjacja jest równoważna atrybutowi i reprezentuje cechę klasy. Przyjmuje się konwencję, w której cechy reprezentujące typy proste (liczby, napisy, znaki) są modelowane jako atrybuty, natomiast obiekty dostępne poprzez referencje są przedstawiane poprzez asocjacje. K. Bartecki, Inżynieria oprogramowania, VII/37
38 Krotność danego końca asocjacji to dopuszczalna liczba obiektów klasy znajdującej się przy tym końcu, skojarzonych z jednym obiektem klasy na drugim końcu tej asocjacji. Krotności są pojedynczymi liczbami albo zakresami liczb: Krotność Znaczenie 0..1 Brak obiektu lub jeden obiekt. 0..* Bez ograniczenia liczby obiektów (łącznie z ich brakiem). 1 Dokładnie jeden obiekt. 1..* Przynajmniej jeden obiekt. n m.. n Dokładnie n obiektów. Od m do n obiektów. K. Bartecki, Inżynieria oprogramowania, VII/38
39 Przykłady krotności asocjacji 1 K. Bartecki, Inżynieria oprogramowania, VII/39
40 Przykład implementacji związku asocjacji w kodzie Javy import B; public class A { } private B b; public B getb() { return b; } // obiekt klasy B jako składowa // (cecha) klasy A A B K. Bartecki, Inżynieria oprogramowania, VII/40
41 Nawigowalność asocjacje skierowane Nawigowalność pomiędzy klasą A i klasą B oznacza, że od obiektu klasy A można przejść do obiektu klasy B, ale nie odwrotnie Innymi słowy: obiekty klasy A posiadają odwołanie do obiektu (lub obiektów) klasy B, ale nie odwrotnie. Nawigowalność oznaczana jest na diagramach strzałką skierowaną od klasy A do klasy B. Nawigowalność (asocjacja) dwukierunkowa oznacza, że nawigując od obiektu klasy A do obiektu klasy B, a następnie z powrotem, w zbiorze wyników można znaleźć początkowy obiekt klasy A. Innymi słowy: zarówno obiekty klasy A posiadają odwołanie do obiektu (lub obiektów) klasy B, jak i obiekty klasy B posiadają odwołanie do obiektu (lub obiektów) klasy A. W przypadku nawigowalności dwukierunkowej strzałki pomija się (tak było do UML 2.4). K. Bartecki, Inżynieria oprogramowania, VII/41
42 Notacja nawigowalności obowiązująca od UML w wersji 2.4 nieokreślona nawigowalność między A1 a B1 oraz B1 a A1 nawigowalność między A2 a B2 oraz nieokreślona nawigowalność między B2 a A2 brak nawigowalności między B3 a A3 oraz nieokreślona nawigowalność między A3 a B3 nawigowalność między A4 a B4 oraz brak nawigowalności między B4 a A4 obustronna nawigowalność między A5 a B5 obustronny brak nawigowalności między A6 a B6 K. Bartecki, Inżynieria oprogramowania, VII/42
43 Przykład implementacji asocjacji skierowanej w kodzie języka C nr klienta nazwisko Klient : int : std::string 1..1 składanie 0..* Zamówienie nr zamówienia kwota zamówienia : int : float class Klient { public: // private: int nrklienta; std::string nazwisko; }; class Zamowienie { public: // private: Klient* klient; int nr_zamowienia; float kwota_zamowienia; }; K. Bartecki, Inżynieria oprogramowania, VII/43
44 Przykład implementacji asocjacji skierowanej w kodzie języka C nr klienta nazwisko Klient : int : std::string 1..1 składanie 0..* Zamówienie nr zamówienia Kwota zamówienia : int : float class Klient { public: // private: std::list<zamowienie> zamowienia; int nr_klienta; std::string nazwisko; }; class Zamowienie { public: // private: int nr_zamowienia; float kwota_zamowienia; }; K. Bartecki, Inżynieria oprogramowania, VII/44
45 Przykładowa implementacja asocjacji dwukierunkowej w C nr klienta nazwisko Klient : int : std::string 1..1 składanie 0..* Zamówienie nr zamówienia Kwota zamówienia : int : float class Klient { public: // private: std::list<zamowienie> zamowienie; int nr_klienta; std::string nazwisko; }; class Zamowienie { public: // private: Klient* klient; int nr_zamowienia; float kwota_zamowienia; }; K. Bartecki, Inżynieria oprogramowania, VII/45
46 Klasa asocjacyjna tekst tytułu cena tytułu <<Constructor>> <<Destructor>> : std::string : float Tytuł Tytul (std::string t, float c) ~Tytul () zwróć tekst () zwróć cenę () : std::s : float klasa asocjacyjna 0..* dotyczy 1..* przedmiotem Pozycja nr pozycji liczba sztuk : short : short nr zamówienia kwota zamówienia data zamówienia czy opłacone <<Constructor>> <<Destructor>> Zamówienie : long : float : std::string : bool Zamowienie (long nr) ~Zamowienie ()... K. Bartecki, Inżynieria oprogramowania, VII/46
47 Klasa asocjacyjna właściwości Klasa asocjacyjna umożliwia opisanie za pomocą atrybutów i operacji nie obiektu, ale samej asocjacji pomiędzy klasami. Informacje przechowywane w klasie asocjacyjnej nie są związane z żadną z klas uczestniczących w asocjacji, dlatego wygodnie jest stworzyć dodatkową klasę i powiązać ją z relacją asocjacji. Klasa asocjacyjna na etapie modelowania logicznego może zostać przekształcona do postaci zwykłej (nieasocjacyjnej) klasy. K. Bartecki, Inżynieria oprogramowania, VII/47
48 Zamiana klasy asocjacyjnej w zwykłą klasę na diagramie implementacyjnym K. Bartecki, Inżynieria oprogramowania, VII/48
49 Asocjacja kwalifikowana K. Bartecki, Inżynieria oprogramowania, VII/49
50 Asocjacja kwalifikowana właściwości Asocjacja kwalifikowana jest rozszerzeniem zwykłej asocjacji o możliwość określenia, który z atrybutów jednej z klas decyduje o związku między tymi klasami. Na przykład, jeden Klient może złożyć wiele różnych Zamówień. Jednak dany Klient może złożyć tylko jedno Zamówienie o danym numerze dlatego atrybut nr_zamówienia klasy Zamówienie jest kwalifikatorem tej asocjacji. W efekcie pomiędzy pojedynczym obiektem klasy Klient a pojedynczym obiektem klasy Zamówienie występuje asocjacja o liczebności jeden do jednego. K. Bartecki, Inżynieria oprogramowania, VII/50
51 Związek agregacji liczba tytułów : int <<Constructor>> <<Destructor>> <<Implement>> Katalog tytułów Katalog_tytulow () ~Katalog_tytulow () dodaj tytuł (Tytul t) usuń tytuł (Tytul t) sortuj () zwróć liczbę ()... : bool : bool : bool : int 0..* zawiera 0..* zawarty tekst tytułu cena tytułu <<Constructor>> <<Destructor>> : std::string : float Tytuł Tytul (std::string t, float c) ~Tytul () zwróć tekst () zwróć cenę () : std::s : float K. Bartecki, Inżynieria oprogramowania, VII/51
52 Agregacja właściwości Agregacja jest silniejszą formą asocjacji, agregacja to związek, w którym jedna z klas należy do kolekcji, której właścicielem jest obiekt innej klasy (np. Klasa może stanowić agregację Uczniów), w przypadku agregacji istnieje właściciel i obiekt podrzędny (obiekty podrzędne), właściciel jednak nie jest wyłącznym właścicielem obiektu podrzędnego (dany obiekt podrzędny może mieć wielu różnych właścicieli), zwykle też nie tworzy i nie usuwa go, w konsekwencji, właściciel i obiekt podrzędny nie są ze sobą powiązane czasem swojego życia, związek agregacji na diagramie zaznacza się białym rombem po stronie klasy reprezentującej właściciela. K. Bartecki, Inżynieria oprogramowania, VII/52
53 Związek kompozycji Książka tytuł autor : String : String 1..1 składa się z 1..* wchodzi w skład Tom numer liczba stron : int : int K. Bartecki, Inżynieria oprogramowania, VII/53
54 Kompozycja właściwości Kompozycja jest najsilniejszą relacją łączącą klasy, reprezentuje relacje całośćczęść, w których części są tworzone i zarządzane przez obiekt reprezentujący całość, ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są bardzo ściśle ze sobą związane i pokrywają się, w momencie usunięcia obiektu reprezentującego całość, obiekty reprezentujące części są również usuwane, związek kompozycji na diagramie zaznacza się zaczernionym rombem po stronie klasy reprezentującej całość. K. Bartecki, Inżynieria oprogramowania, VII/54
55 Agregacja i kompozycja przykłady implementacji w C class University { private: std:string univname Department faculty[10]; create_dept() { // Composition faculty[0]=department(..); faculty[1]=department(..);... } }; class Department { private: std::string depname; University* univ; Professor* members[20];... }; class Professor { private: std::string profname; Department* affiliation[];... }; K. Bartecki, Inżynieria oprogramowania, VII/55
56 Związek generalizacjispecjalizacji (uogólnieniauszczegółowienia) tekst tytułu cena tytułu <<Constructor>> <<Destructor>> : std::string : float Tytuł Tytul (std::string t, float c) ~Tytul () zwróć tekst () zwróć cenę () : std::string : float generalizacja specjalizacje Książka autor liczba stron : std::string : short Czasopismo częstotliwość : bool K. Bartecki, Inżynieria oprogramowania, VII/56
57 Uogólnienie (generalizacjaspecjalizacja) właściwości Jest to związek występujący między klasą bardziej ogólną (nadklasą, rodzicem, generalizacją) a klasą bardziej szczegółową (podklasą, dzieckiem, specjalizacją), podklasa jest w pełni zgodna z klasą nadrzędną (posiada wszystkie jej cechy i operacje) i ponadto zawiera dodatkowe cechy i/lub operacje, uogólnienie często jest traktowane jako synonim dziedziczenia. K. Bartecki, Inżynieria oprogramowania, VII/57
58 Przykład złożonej hierarchii generalizacjispecjalizacji K. Bartecki, Inżynieria oprogramowania, VII/58
59 Generalizacjaspecjalizacja implementacja w kodzie Javy, C i C# Java C C# public class B2 { // } class B2 { // }; class B2 { // } public class A2 extends B2 { // } class A2 : public B2 { // }; class A2 : B2 { // } K. Bartecki, Inżynieria oprogramowania, VII/59
60 Klasa abstrakcyjna Klasa abstrakcyjna jest pewnym uogólnieniem (generalizacją) innych klas, lecz nie posiada swoich instancji, czyli obiektów. Celem tworzenia klas abstrakcyjnych i interfejsów jest identyfikacja wspólnych zachowań różnych klas, które są realizowane w różny od siebie sposób. Posiada ona deklaracje metod, ale nie definiuje ich implementacji. Metody te implementowane są w jej klasach pochodnych specjalizacjach. K. Bartecki, Inżynieria oprogramowania, VII/60
61 Przykładowe klasy abstrakcyjne K. Bartecki, Inżynieria oprogramowania, VII/61
62 Przykład definicji klasy abstrakcyjnej w kodzie języka C class Abstrakcyjna { public: virtual void metoda () = 0; // metoda czysto wirtualna }; class Nieabstrakcyjna : public Abstrakcyjna // dziedziczenie { public: void metoda () // implementacja metody czysto wirtualnej { // instrukcje metody } }; int main() { // Abstrakcyjna obiektx; // błąd, klasa jest abstrakcyjna Nieabstrakcyjna obiekty; // poprawne return 0; } K. Bartecki, Inżynieria oprogramowania, VII/62
63 Przykład definicji klasy abstrakcyjnej w kodzie języka Java abstract class Figura { } abstract public double pole(); class Kolo extends Figura { public double promien; public Kolo( double p ) { this.promien = p; } // dziedziczenie public double pole() { // implementacja metody czysto wirtualnej return 3.14 * promien * promien; } } public class Program { public static void main( String[] args ) { // Figura f = new Figura(); // niemożliwe: Figura jest klasą abstrakcyjną Kolo k = new Kolo( 2 ); System.out.println( k.pole() ); } } K. Bartecki, Inżynieria oprogramowania, VII/63
64 Interfejs jest pojęciem bardzo podobnym do klasy abstrakcyjnej. Deklaruje on zestaw operacji, które określają usługi oferowane przez klasę, bez podawania ich implementacji. Sortowalna interfejs sortuj ()... : bool liczba klientów : int <<Constructor>> <<Destructor>> <<Implement>> Lista klientów Lista_klientow () ~Lista_klientow () dodaj klienta (Klient t) usuń klienta (Klient t) sortuj () zwróć liczbę ()... : bool : bool : bool : int <<implementuje>> <<implementuje>> liczba tytułów : int <<Constructor>> <<Destructor>> <<Implement>> Katalog tytułów Katalog_tytulow () ~Katalog_tytulow () dodaj tytuł (Tytul t) usuń tytuł (Tytul t) sortuj () zwróć liczbę ()... : bool : bool : bool : int klasy dziedziczące (implementujące) interfejs K. Bartecki, Inżynieria oprogramowania, VII/64
65 Zasadnicze różnice między interfejsem a klasą abstrakcyjną: Klasa abstrakcyjna może posiadać implementacje niektórych operacji, natomiast interfejs jest czysto abstrakcyjny i zawiera tylko deklaracje swoich operacji. Klasa dziedzicząca po klasie abstrakcyjnej może (ale nie musi) implementować wszystkie operacje, natomiast w przypadku dziedziczenia po interfejsie wszystkie przejęte po nim operacje muszą zostać zdefiniowane w klasie pochodnej. O ile klasy potomne tej samej klasy abstrakcyjnej są pod względem logicznym zwykle od siebie zależne, o tyle klasy dziedziczące po interfejsie nie muszą być z sobą logicznie związane. W języku C interfejs może być zdefiniowany jako klasa abstrakcyjna, zaś w Javie, C#, Object Pascalu oraz PHP stosuje się w tym celu specjalną deklarację ze słowem interface. K. Bartecki, Inżynieria oprogramowania, VII/65
66 Alternatywna ( lizakowa ) notacja interfejsu Interfejs można na diagramie przedstawić także w postaci uproszczonej wówczas ma on postać kuli i nie widać na nim żadnych operacji. Sortowalna sortuj ()... : bool Sortowalna W przypadku, gdy interfejs ma na diagramie postać kuli, związek realizacji pomiędzy klasą a interfejsem przedstawia się za pomocą linii ciągłej. liczba klientów : int <<Constructor>> <<Destructor>> <<Implement>> Lista klientów Lista_klientow () ~Lista_klientow () dodaj klienta (Klient t) usuń klienta (Klient t) sortuj () zwróć liczbę ()... : bool : bool : bool : int <<implement>> Sortowalna sortuj ()... : bool liczba klientów : int <<Constructor>> <<Destructor>> <<Implement>> Lista klientów Lista_klientow () ~Lista_klientow () dodaj klienta (Klient t) usuń klienta (Klient t) sortuj () zwróć liczbę ()... : bool : bool : bool : int Sortowalna W powyższym przypadku mówimy, że interfejs Sortowalna jest dostarczany (ang. provided) lub implementowany przez klasę Lista klientów. K. Bartecki, Inżynieria oprogramowania, VII/66
67 Alternatywna ( lizakowa ) notacja interfejsu c.d. Jeśli pewna klasa korzysta z (wymaga) usług innych klas za pośrednictwem interfejsu, wówczas mówimy o interfejsie wymaganym (ang. required). Interfejs taki ma na diagramie symbol łuku. Lista klientów liczba klientów : int <<Constructor>> <<Destructor>> <<Implement>> Lista_klientow () ~Lista_klientow () dodaj klienta (Klient t) usuń klienta (Klient t) sortuj () zwróć liczbę ()... : bool : bool : bool : int <<implement>> Sortowalna sortuj ()... : bool <<require>> Sortownia interfejs dostarczany interfejs wymagany liczba klientów : int <<Constructor>> <<Destructor>> <<Implement>> Lista klientów Lista_klientow () ~Lista_klientow () dodaj klienta (Klient t) usuń klienta (Klient t) sortuj () zwróć liczbę ()... : bool : bool : bool : int Sortowalna Sortownia K. Bartecki, Inżynieria oprogramowania, VII/67
68 Przykład implementacji interfejsu w kodzie języka PHP interface Sendable { public function getto(); } class Phone implements Sendable { public function getto() { return ' ' ; } } class implements Sendable { public function getto() { return 'address@example.com'; } } class Sender { public function sendto(sendable $obj) { // operacje } } $p = new Phone(); $e = new (); $s = new Sender(); $s>sendto($p); $s>sendto($e); Phone <<Implement>> getto () Sendable <<Implement>> getto () : Sender sendto (Sendable obj) K. Bartecki, Inżynieria oprogramowania, VII/68
69 Przykładowy diagram klas K. Bartecki, Inżynieria oprogramowania, VII/69
70 Diagram obiektów prezentuje możliwą konfigurację obiektów w określonym momencie, jest instancją diagramu klas, w której zamiast klas przedstawiono ich instancje, czyli obiekty, jest wizualizacją hipotetycznego stanu systemu podczas jego działania, służy do tworzenia przykładów, pomagających zrozumieć diagram klas oraz występujących w nim powiązań, używa notacji zapożyczonej z diagramów klas, chociaż większość z nich używa wyłącznie oznaczeń obiektów i asocjacji. K. Bartecki, Inżynieria oprogramowania, VII/70
71 Diagram klas nr klienta nazwisko Klient : int : std::string 1..1 składanie 0..* Zamówienie nr zamówienia Kwota zamówienia : int : float i przykładowy diagram obiektów Z1:Zamówienie nr klienta nazwisko K1:Klient = 1 = Kowalski nr zamówienia Kwota zamówienia Z2:Zamówienie nr zamówienia Kwota zamówienia = 1 = = 2 = nr klienta nazwisko K2:Klient = 2 = Nowak Z3:Zamówienie nr zamówienia Kwota zamówienia = 3 = K. Bartecki, Inżynieria oprogramowania, VII/71
72 Diagram klas i przykładowy diagram obiektów K. Bartecki, Inżynieria oprogramowania, VII/72
73 Przykładowy diagram obiektów K. Bartecki, Inżynieria oprogramowania, VII/73
74 Diagram pakietów (źródło: W miarę wzrostu wielkości modelowanego systemu, rośnie liczba wykorzystywanych elementów (klas, interfejsów, komponentów, itp.) W celu zachowania czytelności diagramów, podobne znaczeniowo elementy (np. klasy) można grupować w formie tzw. pakietów. Pakiet jest przedstawiany w postaci dużego prostokąta z małym prostokątem u góry, zwanym etykietą. Wewnątrz symbolu pakietu mogą być widoczne jego składniki, wraz ze specyfikacją ich widoczności poza pakietem (publiczna lub prywatna). W skład pakietu mogą wchodzić inne pakiety. K. Bartecki, Inżynieria oprogramowania, VII/74
75 Na diagramie mogą występować zależności między pakietami, wynikające z relacji między ich elementami składowymi. Dzięki zależnościom uwidaczniany jest jedynie fakt występowania relacji między elementami pakietów, a nie ich szczegółowy rodzaj, np. nie pokazujemy tu asocjacji między dwiema klasami umieszczonymi w dwóch różnych pakietach. Zależności przedstawiane są na diagramie w postaci strzałek z przerywaną linią i mogą być opatrywane następującymi stereotypami: «import», «access» lub «merge». Zależność «import» między pakietem A oraz pakietem B (z grotem skierowanym w stronę A) oznacza, że do przestrzeni nazw pakietu A dodawane są nazwy wszystkich elementów pakietu B. Zależność «import» jest przechodnia: jeśli A importuje B oraz B importuje C, to oznacza że A importuje również (pośrednio) C. <<import>> <<import>> A B C K. Bartecki, Inżynieria oprogramowania, VII/75
76 Zależność «access» działa podobnie jak «import», ale jest nieprzechodnia. Przykład: w celu użycia w pakiecie Program typu Integer, należy użyć pełnej nazwy kwalifikowanej, tzn. Types::Integer, gdyż ta składowa pakietu Types jest publiczna, ale nie jest importowana przez pakiet Program, w celu użycia w pakiecie Program typu Time można używać jego nazwy bez kwalifikatora wskazującego na pakiet Types, podobnie jest z użyciem w pakiecie Program typu String, jednak nie będzie on widoczny z zewnątrz jako składowa pakietu Program oraz nie będzie mógł być dalej z niego importowany. K. Bartecki, Inżynieria oprogramowania, VII/76
77 W przypadku zależności typu «merge» zawartość jednego pakietu (B) jest rozszerzana o zawartość innego pakietu (A). Uwaga: to nie jest UML Jest to operacja zbliżona do związku generalizacjispecjalizacji w jej wyniku otrzymujemy nowy pakiet (resulting package), zawierający wszystkie składowe pakietów: rozszerzanego (receiving package) i rozszerzającego (merged package). K. Bartecki, Inżynieria oprogramowania, VII/77
78 Przykładowy diagram pakietów K. Bartecki, Inżynieria oprogramowania, VII/78
79 Przykładowy diagram pakietów (brak oznaczenia zależności domyślnie oznacza «import») K. Bartecki, Inżynieria oprogramowania, VII/79
80 Przykładowy diagram pakietów K. Bartecki, Inżynieria oprogramowania, VII/80
81 Przykładowy diagram pakietów K. Bartecki, Inżynieria oprogramowania, VII/81
82 Przykładowy diagram pakietów zawierających przypadki użycia K. Bartecki, Inżynieria oprogramowania, VII/82
83 Diagram komponentów (żródło: Komponent to wymienialny, wykonywalny fragment systemu, z ukrytymi (hermetyzowanymi) szczegółami implementacyjnymi (np. biblioteka.dll, podprogram). Komponent udostępnia zestaw interfejsów (interfejsy dostarczane), może też wymagać pewnych interfejsów do funkcjonowania (interfejsy wymagane). Komponenty służą do ponownego wykorzystania poprzez połączenie ich z innymi komponentami, zwykle poprzez ich odpowiednie skonfigurowanie, bez potrzeby rekompilacji. Diagram komponentów służy do pokazania związków pomiędzy komponentami i interfejsami. K. Bartecki, Inżynieria oprogramowania, VII/83
84 Rodzaje komponentów w UML executable komponent wykonywalny, library biblioteka statyczna lub dynamiczna, table tabela bazy danych, file dokument zawierający kod źródłowy lub dane, document dokument. K. Bartecki, Inżynieria oprogramowania, VII/84
85 Typy interfejsów w komponentach provided interfejs dostarczany, required interfejs wymagany. K. Bartecki, Inżynieria oprogramowania, VII/85
86 Zależności między komponentami Komponenty są powiązane relacją zależności z innymi komponentami, ponieważ wymagają ich do realizacji własnej funkcjonalności. Zależność między komponentami A i B oznacza, że A korzysta z B i zmiana w B może spowodować konieczność zmiany w A. Duża liczba powiązań pomiędzy komponentami, a w szczególności zależności cykliczne, utrudniają wyznaczanie obszarów zmienności i ich hermetyzację, a co za tym idzie podnoszą koszt pielęgnacji oprogramowania. System o dobrze zdefiniowanych interfejsach komponentów pozwala na ich wymianę bez potrzeby modyfikacji pozostałej części systemu. K. Bartecki, Inżynieria oprogramowania, VII/86
87 Przykłady zależności między komponentami K. Bartecki, Inżynieria oprogramowania, VII/87
88 Przykłady zależności między komponentami K. Bartecki, Inżynieria oprogramowania, VII/88
89 Widoki komponentów widok czarnej skrzynki nie pokazuje szczegółów wewnętrznych, widok białej skrzynki pokazuje składowe komponentu. K. Bartecki, Inżynieria oprogramowania, VII/89
90 Porty pozwalają łączyć interfejsy wewnętrzne z odpowiedzialnymi za nie fragmentami wewnętrznymi komponentu. K. Bartecki, Inżynieria oprogramowania, VII/90
91 Przykładowy diagram komponentów K. Bartecki, Inżynieria oprogramowania, VII/91
92 Przykładowy diagram komponentów K. Bartecki, Inżynieria oprogramowania, VII/92
93 Diagram wdrożeniowy (źródło: Odzwierciedla fizyczną strukturę całego systemu informatycznego, z uwzględnieniem oprogramowania i sprzętu. Jednostki oprogramowania są reprezentowane przez artefakty, czyli programy wykonywalne, biblioteki, pliki źródłowe, dane oraz archiwa. Stronę sprzętową reprezentują węzły, czyli poszczególne urządzenia obliczeniowe, komunikacyjne i przechowujące, powiązane ścieżkami komunikacyjnymi (np. połączeniem TCP/IP). Diagramy wdrożeniowe mogą być powiązane z diagramami komponentów. Diagramy wdrożeniowe istotną rolę odgrywają przy wdrażaniu dużych, rozproszonych systemów. K. Bartecki, Inżynieria oprogramowania, VII/93
94 Przykłady graficznej notacji artefaktów Przykłady graficznej notacji węzłów K. Bartecki, Inżynieria oprogramowania, VII/94
95 Przykładowy diagram wdrożeniowy K. Bartecki, Inżynieria oprogramowania, VII/95
96 Przykładowy diagram wdrożeniowy K. Bartecki, Inżynieria oprogramowania, VII/96
97 Przykładowy diagram wdrożeniowy K. Bartecki, Inżynieria oprogramowania, VII/97
98 Przykładowy diagram wdrożeniowy K. Bartecki, Inżynieria oprogramowania, VII/98
UML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegół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ół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ół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ół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ół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 8 Diagram pakietów I Diagram pakietów (ang. package diagram) jest diagramem
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ół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ółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoUML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.
UML a kod w C++ i Javie Projektowanie oprogramowania Dokumentowanie oprogramowania Diagramy przypadków użycia Przewoznik Zarzadzanie pojazdami Optymalizacja Uzytkownik Wydawanie opinii Zarzadzanie uzytkownikami
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ół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ół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ółowoDiagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.
Umiejętność czytania oraz tworzenia diagramów klas UML jest podstawą w przypadku zawodu programisty. Z takimi diagramami będziesz spotykał się w przeciągu całej swojej kariery. Diagramy klas UML są zawsze
Bardziej szczegółowoJęzyk JAVA podstawy. Wykład 4, część 1. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna
Język JAVA podstawy Wykład 4, część 1 1 Język JAVA podstawy Plan wykładu: 1. Podstawy modelowania obiektowego 2. Konstruktory 3. Dziedziczenie, związki pomiędzy klasami, UML 4. Polimorfizm 5. Klasy abstrakcyjne
Bardziej szczegółowoDokumentacja do API Javy.
Dokumentacja do API Javy http://java.sun.com/j2se/1.5.0/docs/api/ Klasy i obiekty Klasa jest to struktura zawierająca dane (pola), oraz funkcje operujące na tych danych (metody). Klasa jest rodzajem szablonu
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ół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 10 Diagramy wdrożenia I Diagramy wdrożenia - stosowane do modelowania
Bardziej szczegółowoPoczątki Javy. dr Anna Łazińska, WMiI UŁ Podstawy języka Java 1 / 8
Początki Javy Java została pierwotnie zaprojektowana dla telewizji interaktywnej, ale była to zbyt zaawansowaną technologią dla branży cyfrowej telewizji kablowej. James Gosling, Mike Sheridan i Patrick
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ół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ółowoAnaliza i projektowanie aplikacji Java
Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie
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ół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ółowoInterfejsy. Programowanie obiektowe. Paweł Rogaliński Instytut Informatyki, Automatyki i Robotyki Politechniki Wrocławskiej
Programowanie obiektowe Interfejsy Paweł Rogaliński Instytut Informatyki, Automatyki i Robotyki Politechniki Wrocławskiej pawel.rogalinski pwr.wroc.pl Interfejsy Autor: Paweł Rogaliński Instytut Informatyki,
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ół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ół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ółowoLaboratorium nr 12. Temat: Struktury, klasy. Zakres laboratorium:
Zakres laboratorium: definiowanie struktur terminologia obiektowa definiowanie klas funkcje składowe klas programy złożone z wielu plików zadania laboratoryjne Laboratorium nr 12 Temat: Struktury, klasy.
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ół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ółowoJAVA W SUPER EXPRESOWEJ PIGUŁCE
JAVA W SUPER EXPRESOWEJ PIGUŁCE Obiekt Obiekty programowe to zbiór własności i zachowań (zmiennych i metod). Podobnie jak w świecie rzeczywistym obiekty posiadają swój stan i zachowanie. Komunikat Wszystkie
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ół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ół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ół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ół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ółowoProgramowanie obiektowe
Laboratorium z przedmiotu Programowanie obiektowe - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie
Bardziej szczegół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ół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ółowoJęzyk programowania. Andrzej Bobyk http://www.alfabeta.lublin.pl. www.alfabeta.lublin.pl/jp/
Język programowania Andrzej Bobyk http://www.alfabeta.lublin.pl www.alfabeta.lublin.pl/jp/ Literatura K. Reisdorph: Delphi 6 dla każdego. Helion, Gliwice 2001 A. Grażyński, Z. Zarzycki: Delphi 7 dla każdego.
Bardziej szczegółowoDziedziczenie. Streszczenie Celem wykładu jest omówienie tematyki dziedziczenia klas. Czas wykładu 45 minut.
Dziedziczenie Streszczenie Celem wykładu jest omówienie tematyki dziedziczenia klas. Czas wykładu 45 minut. Rozpatrzmy przykład przedstawiający klasy Student oraz Pracownik: class Student class Pracownik
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ółowoLaboratorium z przedmiotu: Inżynieria Oprogramowania INP
Laboratoria 5-7- część 1 Identyfikacja klas reprezentujących logikę biznesową projektowanego oprogramowania, definicja atrybutów i operacji klas oraz związków między klasami - na podstawie analizy scenariuszy
Bardziej szczegółowoKompozycja i dziedziczenie klas
Związki między klasami: jest i zawiera Programowanie obiektowe Przkład: Pojazd Kompozycja i dziedziczenie klas Silnik Pojazd silnikowy Rower Wóz konny Paweł Rogaliński Instytut Informatyki, Automatyki
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ół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ółowoUML a kod. C++, Java i C#
UML a kod C++, Java i C# UML a kod w C++ i Javie Projektowanie oprogramowania! Dokumentowanie oprogramowania Diagramy przypadków użycia Klasy użytkowników i wykorzystywane funkcje Mogą sugerować podział
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ółowoWykład 7: Pakiety i Interfejsy
Wykład 7: Pakiety i Interfejsy Plik Źródłowy w Javie Składa się z: instrukcji pakietu (pojedyncza, opcjonalna) instrukcji importujących (wielokrotne, opcjonalne) deklaracji klasy publicznej (pojedyncza,
Bardziej szczegółowoJava. język programowania obiektowego. Programowanie w językach wysokiego poziomu. mgr inż. Anna Wawszczak
Java język programowania obiektowego Programowanie w językach wysokiego poziomu mgr inż. Anna Wawszczak 1 Język Java Język Java powstał w roku 1995 w firmie SUN Microsystems Java jest językiem: wysokiego
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ółowoSTANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA
Tomasz SOBESTIAŃCZYK ZESZYTY NAUKOWE WYDZIAŁU NAUK EKONOMICZNYCH STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA Zarys treści: W pracy podjęto próbę przedstawienie UML 2.3 jako metody w zarządzaniu
Bardziej szczegółowoJava - tablice, konstruktory, dziedziczenie i hermetyzacja
Java - tablice, konstruktory, dziedziczenie i hermetyzacja Programowanie w językach wysokiego poziomu mgr inż. Anna Wawszczak PLAN WYKŁADU zmienne tablicowe konstruktory klas dziedziczenie hermetyzacja
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ół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ółowoProgramowanie w Javie 1 Wykład i Ćwiczenia 3 Programowanie obiektowe w Javie cd. Płock, 16 października 2013 r.
Programowanie w Javie 1 Wykład i Ćwiczenia 3 Programowanie obiektowe w Javie cd. Płock, 16 października 2013 r. Programowanie obiektowe Programowanie obiektowe (z ang. object-oriented programming), to
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ół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ół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ółowo1. Które składowe klasa posiada zawsze, niezależnie od tego czy je zdefiniujemy, czy nie?
1. Które składowe klasa posiada zawsze, niezależnie od tego czy je zdefiniujemy, czy nie? a) konstruktor b) referencje c) destruktor d) typy 2. Które z poniższych wyrażeń są poprawne dla klasy o nazwie
Bardziej szczegółowoPakiety i interfejsy. Tomasz Borzyszkowski
Pakiety i interfejsy Tomasz Borzyszkowski Pakiety podstawy W dotychczasowych przykładach nazwy klas musiały pochodzić z jednej przestrzeni nazw, tj. być niepowtarzalne tak, by nie doprowadzić do kolizji
Bardziej szczegółowoPHP 5 język obiektowy
PHP 5 język obiektowy Wprowadzenie Klasa w PHP jest traktowana jak zbiór, rodzaj różnych typów danych. Stanowi przepis jak stworzyć konkretne obiekty (instancje klasy), jest definicją obiektów. Klasa reprezentuje
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ół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ół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ół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ółowoTutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.
AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...
Bardziej szczegółowoProgramowanie obiektowe. Wprowadzenie
1 Programowanie obiektowe Wprowadzenie 2 Programowanie obiektowe Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
Bardziej szczegółowoInformatyka I. Klasy i obiekty. Podstawy programowania obiektowego. dr inż. Andrzej Czerepicki. Politechnika Warszawska Wydział Transportu 2018
Informatyka I Klasy i obiekty. Podstawy programowania obiektowego dr inż. Andrzej Czerepicki Politechnika Warszawska Wydział Transportu 2018 Plan wykładu Pojęcie klasy Deklaracja klasy Pola i metody klasy
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ółowoProgramowanie obiektowe
Laboratorium z przedmiotu - zestaw 03 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas abstrakcyjnych i interfejsów. Wprowadzenie teoretyczne. Rozważana
Bardziej szczegółowoProgramowanie obiektowe. Literatura: Autor: dr inŝ. Zofia Kruczkiewicz
Programowanie obiektowe Literatura: Autor: dr inŝ. Zofia Kruczkiewicz Java P. L. Lemay, Naughton R. Cadenhead Java Podręcznik 2 dla kaŝdego Języka Programowania Java Linki Krzysztof Boone oprogramowania
Bardziej szczegółowoProgramowanie w Internecie. Java
Programowanie w Internecie Java Autor: dr inż. Zofia Kruczkiewicz Literatura: L. Lemay, R. Cadenhead P. Naughton Krzysztof Barteczko Boone Barry Java 2 dla każdego Podręcznik Języka Programowania Java
Bardziej szczegółowoTypy klasowe (klasy) 1. Programowanie obiektowe. 2. Założenia paradygmatu obiektowego:
Typy klasowe (klasy) 1. Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która definiuje programy za pomocą obiektów
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe Wykład 5 Marcin Młotkowski 23 marca 2017 Plan wykładu 1 2 3 4 5 Marcin Młotkowski Programowanie obiektowe 2 / 50 Historia Początkowe założenia Projekt OAK Sterowanie urządzeniami
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ółowoTechnologie i usługi internetowe cz. 2
Technologie i usługi internetowe cz. 2 Katedra Analizy Nieliniowej, WMiI UŁ Łódź, 15 luty 2014 r. 1 Programowanie obiektowe Programowanie obiektowe (z ang. object-oriented programming), to paradygmat programowania,
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ółowoWzorce Strukturalne. Adapter: opis. Tomasz Borzyszkowski
Adapter: opis Wzorce Strukturalne Tomasz Borzyszkowski Alternatywna nazwa: Wrapper (opakowanie) Rola obiektu Adapter: pełni wobec Klienta rolę otoczki, która umożliwia przetłumaczenie jego żądań na protokół
Bardziej szczegółowoInformatyka I. Dziedziczenie. Nadpisanie metod. Klasy abstrakcyjne. Wskaźnik this. Metody i pola statyczne. dr inż. Andrzej Czerepicki
Informatyka I Dziedziczenie. Nadpisanie metod. Klasy abstrakcyjne. Wskaźnik this. Metody i pola statyczne. dr inż. Andrzej Czerepicki Politechnika Warszawska Wydział Transportu 2017 Dziedziczenie klas
Bardziej szczegółowoInstrukcja 2 Laboratorium z Podstaw Inżynierii Oprogramowania
Instrukcja 2 Laboratorium z Podstaw Inżynierii Oprogramowania Opis biznesowy świata rzeczywistego Wymagania funkcjonalne i niefunkcjonalne aplikacji Diagram przypadków życia Diagramy klas i sekwencji:
Bardziej szczegółowoPolimorfizm, metody wirtualne i klasy abstrakcyjne
Programowanie obiektowe Polimorfizm, metody wirtualne i klasy abstrakcyjne Paweł Rogaliński Instytut Informatyki, Automatyki i Robotyki Politechniki Wrocławskiej pawel.rogalinski pwr.wroc.pl Polimorfizm,
Bardziej szczegółowoWprowadzenie do systemów informacyjnych
Uwagi ogólne: Wprowadzenie do systemów informacyjnych Projektowanie obiektowe Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka.
Bardziej szczegółowoWstęp do programowania obiektowego. Wykład 2
Wstęp do programowania obiektowego Wykład 2 1 CECHY I KONCEPCJA PROGRAMOWANIA OBIEKTOWEGO 2 Cechy programowania obiektowego Dla wielu problemów podejście obiektowe jest zgodne z rzeczywistością (łatwe
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe IV. Interfejsy i klasy wewnętrzne Małgorzata Prolejko OBI JA16Z03 Plan Właściwości interfejsów. Interfejsy a klasy abstrakcyjne. Klonowanie obiektów. Klasy wewnętrzne. Dostęp do
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 11 Diagramy struktur złożonych Klasyfikator - definiuje cechy strukturalne
Bardziej szczegółowoProgramowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat
Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie
Bardziej szczegółowoIdentyfikacja i modelowanie struktur i procesów biologicznych
Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie
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 1 Cel Język UML to język modelowania systemów
Bardziej szczegółowoDziedziczenie. Tomasz Borzyszkowski
Dziedziczenie Tomasz Borzyszkowski Podstawy Zobacz: Dziedzictwo1.java Dziedzictwo2.java Dziedziczenie jest jedną z podstawowych cech OOP ponieważ umożliwia łatwe implementowanie klasyfikacji hierarchicznych.
Bardziej szczegółowoProgramowanie obiektowe
Programowanie obiektowe Literatura: Autor: dr inŝ. Zofia Kruczkiewicz Java P. L. Krzysztof Lemay, Naughton Barteczko R. Cadenhead JAVA, Java Podręcznik 2 wykłady dla kaŝdego Języka i ćwiczenia Programowania
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ółowoObszar statyczny dane dostępne w dowolnym momencie podczas pracy programu (wprowadzone słowem kluczowym static),
Tworzenie obiektów Dostęp do obiektów jest realizowany przez referencje. Obiekty w języku Java są tworzone poprzez użycie słowa kluczowego new. String lan = new String( Lancuch ); Obszary pamięci w których
Bardziej szczegółowoProjektowanie obiektowe. Roman Simiński Wzorce projektowe Wybrane wzorce strukturalne
Projektowanie obiektowe Roman Simiński roman.siminski@us.edu.pl www.siminskionline.pl Wzorce projektowe Wybrane wzorce strukturalne Fasada Facade Pattern 2 Wzorzec Fasada Facade Pattern koncepcja 3 Wzorzec
Bardziej szczegółowoAplikacje w środowisku Java
Aplikacje w środowisku Java Materiały do zajęć laboratoryjnych Klasy i obiekty - dziedziczenie mgr inż. Kamil Zieliński Katolicki Uniwersytet Lubelski Jana Pawła II 2018/2019 W ramach poprzedniego laboratorium
Bardziej szczegółowoIdentyfikacja i modelowanie struktur i procesów biologicznych
Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie
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ółowoKlasy abstrakcyjne i interfejsy
Klasy abstrakcyjne i interfejsy Streszczenie Celem wykładu jest omówienie klas abstrakcyjnych i interfejsów w Javie. Czas wykładu 45 minut. Rozwiązanie w miarę standardowego zadania matematycznego (i nie
Bardziej szczegółowo