3 Obiekt a klasa. 3.1 Wstęp. 3.2 Obiekt ToŜsamość obiektu a jego identyfikator

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

Download "3 Obiekt a klasa. 3.1 Wstęp. 3.2 Obiekt ToŜsamość obiektu a jego identyfikator"

Transkrypt

1 3 Obiekt a klasa 3.1 Wstęp Wykład zawiera wprowadzenie do obiektowego modelu danych poprzez omówienie jego dwóch podstawowych pojęć: obiekt i klasa. Zrozumienie tych pojęć oraz związku pomiędzy nimi jest pierwszym krokiem na drodze do zrozumienia i prawidłowego zastosowania podejścia obiektowego. W wykładzie zostaną omówione takŝe inne waŝne elementy obiektowości powiązane z obiektami i klasami, np. atrybut, metoda, hermetyzacja, komunikat, polimorfizm itd. 3.2 Obiekt Obiekt jest to struktura danych stanowiąca w implementacji komputerowej odwzorowanie bytu, który posiada dobrze określone granice i własności, wyróŝnialnego w analizowanym fragmencie dziedziny problemowej. Z koncepcją obiektu ściśle związane są następujące pojęcia: ToŜsamość obiektu, która odróŝnia go od innych obiektów i jest niezaleŝna od wartości jego atrybutów (patrz podrozdział 3.2.8), powiązań z innymi obiektami (patrz podrozdział 3.2.3), od lokalizacji (odwzorowywanego przez obiekt) bytu w świecie rzeczywistym oraz od lokalizacji obiektu w przestrzeni adresowej komputera. Stan obiektu, który jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami. Stan obiektu moŝe zmieniać się w czasie; nie pociąga to jednak za sobą zmiany jego toŝsamości. Zachowanie przypisane do obiektu, tj. zestaw operacji (patrz podrozdział 3.2.9), które moŝna na nim wykonać. Typ przypisany do obiektu, tj. wyraŝenie językowe, które poprzez specyfikację atrybutów określa jego budowę oraz ogranicza kontekst, w którym moŝna odwoływać się do obiektu. Wszystkie atrybuty, powiązania, operacje itd. obiektu nazywane są jego własnościami. Rys. 1 przedstawia obrazowo przykładowy obiekt pracownik, który odwzorowuje pewnego pracownika z dziedziny problemowej. Obiekt ten posiada atrybuty, m.in. imię i nazwisko; na obiekcie moŝna wykonać operacje, m.in. zmień pensję i oblicz staŝ. dismiss calculate employee experience employee Id. = 5789 name = Jerzy = Maltański empl. date = position = księgowy salary = 3500 change salary change position Rys. 1. Przykładowy obiekt pracownik ToŜsamość obiektu a jego identyfikator Byt, odwzorowywany w obiekt w implementacji komputerowej, jest wyróŝnialny w dziedzinie problemowej przez sam fakt swojego istnienia, a nie poprzez jakąkolwiek fizyczną cechę, która odróŝniałaby go od innych bytów. MoŜe się zdarzyć, Ŝe pewne byty są nieodróŝnialne (na przykład mrówki), niemniej jednak obserwator jest świadomy faktu, Ŝe postrzega róŝne byty (róŝne mrówki). W podejściu obiektowym powyŝsza własność określana jest wprowadzonym uprzednio terminem toŝsamości obiektu. ToŜsamość jest zazwyczaj implementowana jako wewnętrzny unikalny i niewidoczny dla uŝytkownika identyfikator

2 obiektu, który jest automatycznie generowany przez system w momencie powołania obiektu do Ŝycia. Mechanizm identyfikatorów pozwala m.in. na rozróŝnianie obiektów i tworzenie powiązań między nimi. Identyfikator jest traktowany jak wewnętrzny atrybut obiektu, który nie ma Ŝadnego znaczenia w dziedzinie problemowej i do którego uŝytkownik nigdy nie odwołuje się w sposób jawny Relatywizm obiektów Obiekt, stanowiący odwzorowanie pewnego bytu ze świata rzeczywistego, powinien przechowywać wszelkie informacje, które odnoszą się do tego bytu. Obiekt przenosi te informacje między innymi poprzez mechanizm atrybutów. Atrybuty obiektu same mogą być obiektami, zwanymi w takiej sytuacji podobiektami; obiekt zawierający atrybuty-podobiekty nazywany jest obiektem złoŝonym. Przyjmuje się, Ŝe nie naleŝy ograniczać ani liczby/rozmiaru atrybutów opisujących obiekt, ani liczby poziomów hierarchii podobiektów, co w efekcie powinno skutkować brakiem ograniczeń na rozmiar obiektu. Ustalenie, które informacje odnoszą się do danego obiektu, a które do innego (np. podobiektu), powinno zaleŝeć wyłącznie od modelu pojęciowego tworzonego przez analityka i nie powinno podlegać Ŝadnym ograniczeniom ze strony środowiska implementacji. Rys. 2 pokazuje przykład obiektu złoŝonego studenci. Obiekt ten składa się z atrybutów-podobiektów student, które z kolei same zawierają własne atrybuty-podobiekty itd. students student name passed courses course course student name nr indeksu nr indeksu passed courses index No. course course course Rys. 2. Obiekt złoŝony studenci Powiązania pomiędzy obiektami Relacja między obiektami, odwzorowująca fizyczny lub pojęciowy związek istniejący między bytami w analizowanej dziedzinie problemowej, nazywana jest powiązaniem. Obiektowość pozwala na tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Tak jak obiekty stanowią odwzorowanie bytów istniejących w dziedzinie problemowej, powiązania odwzorowują związki występujące między bytami. Na poziomie implementacyjnym powiązanie jest daną będącą identyfikatorem pewnego obiektu. Unika się tu uŝywanych w obiektowych językach programowania pojęć wskaźnik czy referencja na rzecz bardziej abstrakcyjnego terminu powiązanie. Rys. 3 przedstawia przykładowe powiązania między obiektami, m.in. powiązanie o nazwie zatrudnia prowadzące od obiektu firma do obiektu pracownik. Powiązania są poŝytecznym mechanizmem, który z jednej strony ułatwia naturalne odwzorowywanie semantycznych związków istniejących między analizowanymi bytami, zaś z drugiej znacznie zwiększa szybkość działania programu. Do wad powiązań zalicza się przede wszystkim: usztywnienie struktury danych, moŝliwość utraty spójności ze względu na potencjalne powiązania prowadzące do nieistniejących obiektów oraz moŝliwość naruszenia reguł hermetyzacji, o której jest mowa w następnym punkcie.

3 employee company name = Relax Ltd. employs employs boss employee = Nowak salary = 1500 works in employee Rys. 3. Przykład powiązań między obiektami firma i pracownik Hermetyzacja a ukrywanie informacji Pojęcie hermetyzacja (inaczej: enkapsulacja) oznacza zgromadzenie w postaci jednej manipulowalnej bryły zarówno elementów struktury obiektu, jak i operacji, które moŝna na tym obiekcie wykonać. Dwa podstawowe rodzaje hermetyzacji: hermetyzacja ortodoksyjna: i hermetyzacja ortogonalna, są przedstawione w Tab. 1. Hermetyzacja ortodoksyjna (np. Smalltalk) Własności: Na zewnątrz obiektu widoczne są wyłącznie te operacje, które moŝna na nim wykonać. Atrybuty obiektu są ukryte. Hermetyzacja ortogonalna (np. C++, Modula 2, Java) Własności: Dowolna własność obiektu (atrybut, operacja itd.) moŝe być prywatna (ukryta) lub publiczna ( udostępniona do publicznego uŝytku). Efekt: Dostęp do atrybutów obiektu wymaga zdefiniowania specjalnych operacji, z których jedna odczytuje wartość atrybutu, a druga ją zmienia. Tab. 1. Hermetyzacja ortodoksyjna a hermetyzacja ortogonalna Efekt: Potrzebne są specjalne środki do specyfikowania własności prywatnych i publicznych. Według innej definicji, hermetyzacja to oddzielenie specyfikacji obiektu od jego implementacji, co pośrednio prowadzi do ukrycia jego struktury i implementacji operacji; tę własność określa się takŝe terminem ukrywanie informacji. Generalnie, hermetyzacja i ukrywanie informacji są pojęciami róŝnymi, choć mocno powiązanymi. Hermetyzacja i ukrywanie informacji stanowią podstawę dla wprowadzenia innych pojęć z zakresu modelowania pojęciowego, takich jak: moduł, klasa i abstrakcyjny typ danych Klasa Klasa, podobnie jak obiekt, naleŝy do podstawowych pojęć obiektowości. W literaturze poświęconej obiektowości funkcjonuje kilka róŝnych definicji tego pojęcia, z których dwie najbardziej popularne przytaczamy poniŝej: 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach: semantyce, atrybutach, zachowaniu, związkach z innymi obiektami itd. 2. Klasa jest nazwanym opisem grupy obiektów o podobnych własnościach. Zgodnie z tą definicją, klasa nie jest zbiorem obiektów, lecz jest wykorzystywana do deklarowania obiektów. W niniejszym wykładzie będziemy posługiwać się drugą z powyŝszych definicji. NajwaŜniejszymi własnościami klasy, zwanymi inwariantami klas, są:

4 nazwa, czyli językowy identyfikator klasy obiektu; typ, czyli struktura (budowa) obiektu specyfikowana z wykorzystaniem mechanizmu atrybutów; metody, czyli implementacje operacji, które moŝna wykonać na obiekcie. Do innych rodzajów inwariantów zalicza się m.in.: obsługę zdarzeń i wyjątków, które mogą zachodzić w trakcie wykonywania operacji na obiekcie; listę eksportową, czyli listę własności obiektu, które są dostępne z zewnątrz; ograniczenia, którym moŝe podlegać obiekt klasy. Nazwa klasy Głównym zadaniem nazwy klasy jest opisanie obiektów, które ona grupuje. Bardzo często przyjmuje się, Ŝe nazwa klasy powinna określać pojedynczy obiekt tej klasy, w związku z czym zazwyczaj nazwą klasy jest rzeczownik w liczbie pojedynczej, np. Osoba 1 (a nie Osoby), Rachunek (a nie Rachunki), KsiąŜka (a nie KsiąŜki). JeŜeli jednak obiekt odpowiada grupie bytów, np. grupie osób, to do nazwania klasy powinno się uŝyć rzeczownika w liczbie mnogiej (Osoby) albo specjalnej frazy rzeczownikowej, która jest w liczbie pojedynczej (w tym przypadku np. Grupa osób). NaleŜy zwrócić uwagę na sytuację, gdy dany rzeczownik nie posiada liczby pojedynczej, np. Drzwi, Zawody itd. wówczas nazwa klasy jest rzeczownikiem w liczbie mnogiej. Jak moŝna zaobserwować na przykładzie nazwy Grupa osób, znakiem dozwolonym w nazwie klasy (a takŝe nazwie atrybutu, metody itd.) na etapie analizy jest spacja. Nazwy, których składnia nie jest dozwolona w środowisku implementacji, zostaną odpowiednio zmienione w fazie projektowania, w trakcie wykonywania czynności określanych mianem eliminacji ograniczeń środowiska implementacji. Notacja W języku UML na diagramie klas definicja klasy przedstawiana jest w postaci prostokąta składającego się zazwyczaj z trzech pól: pola nazwy klasy, pola atrybutów, pola metod. Elementy pól, czyli nazwa, atrybuty i metody, posiadają następujące specyfikacje: nazwa klasy: stereotyp dostępność nazwa_ klasy lista_wart_etykiet atrybut: stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etykiet metoda: stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykiet gdzie: stereotyp i lista_wart_etykiet oznaczają odpowiednio stereotyp i listę wartości etykietowanych (więcej informacji na ten temat znajduje się w wykładzie omawiającym mechanizmy rozszerzalności); dostępność określa widoczność danego elementu. WyróŜnia się trzy podstawowe rodzaje dostępności, oznaczane w następujący sposób: + : element publiczny jest widoczny z zewnątrz klasy; : element prywatny jest widoczny tylko wewnątrz klasy; # : element chroniony jest widoczny w klasie i jej podklasach (więcej informacji na ten temat znajduje się w wykładzie omawiającym generalizację-specjalizację). lista_arg: definiuje listę parametrów formalnych metody; składnia opisu pojedynczego parametru jest następująca: rodzaj nazwa_arg : typ = wartość_początkowa, gdzie rodzaj określa sposób, w jaki metoda korzysta z danego argumentu: in: metoda moŝe czytać wartość parametru, ale nie moŝe jej zmieniać; out: metoda moŝe zmieniać wartość parametru, ale nie moŝe jej czytać; inout: metoda moŝe zarówno czytać, jak i zmieniać wartość parametru. KaŜdy z elementów specyfikacji klasy, za wyjątkiem nazwy, jest opcjonalny; w szczególności bardzo często na etapie analizy, lub przynajmniej na jej początku, nie określa się dostępności ani typów atrybutów. 1 Nazwy klas, dla odróŝnienia od nazw obiektów, atrybutów itd., będziemy pisać duŝą literą.

5 Definicję klasy moŝna przedstawić w sposób mniej lub bardziej szczegółowy, co ilustruje Rys. 4. W razie potrzeby definicja klasy moŝe zostać rozszerzona o dodatkowe pole opisujące inne własności klasy. Student Student index No. grades Student index No. grades Student index No.: integer : string grades : string calculate avg () calculate avg (): real Rys. 4. RóŜne poziomy szczegółowości w przedstawianiu definicji klasy Dla zwiększenia czytelności diagramów zaleca się, aby dla nazwy klasy stosować większą czcionkę niŝ dla innych elementów definicji klasy. Ponadto, nazwa klasy powinna być umieszczona pośrodku pola, natomiast pozostałe elementy wyrównane do lewej strony Wystąpienie klasy Pojęcie wystąpienie klasy (inaczej: instancja klasy) oznacza obiekt, który jest podłączony do danej klasy, jest jej członkiem. W zaleŝności od wymaganego poziomu szczegółowości moŝliwe są róŝne oznaczenia wystąpienia klasy, patrz Rys. 5. Do obiektu moŝna przypisać nazwę (Rys. 5 (a) i (c)), ale nie jest to konieczne (Rys. 5 (b) i (d)). (a) object name : class name (b) : class name attribute name = attribute value... attribute name = attribute value... (c) object name : class name (d) : class name Rys. 5. Notacja na oznaczenie instancji klasy Zagadnienie wystąpienia klasy jest bardziej złoŝone w sytuacji, gdy klasa uczestniczy w związku generalizacjispecjalizacji. Problem ten jest omówiony w wykładzie poświęconym generalizacji-specjalizacji Ekstensja klasy Ekstensja klasy jest to aktualny (zmienny w czasie) zestaw wszystkich wystąpień tej klasy. Ekstensja jest implementowana w postaci specjalnej struktury danych (konkretnego bytu programistycznego dołączonego do klasy), która przechowuje wszystkie obiekty będące członkami klasy. Rys. 6 przedstawia przykładową ekstensję klasy Student. Przerywana linia zakończona grotem oznacza związek zaleŝności pomiędzy elementami modelu w tym przypadku pomiędzy obiektami a ich klasą.

6 Student name index No. grades age () grades s avg () : Student : Student name = Wanda name = Zenon = Niemiec = Nowak index No. = index No. = grades = 4, 5, 5, 3 grades = 3.5, 4, 4 extent of the Student class : Student name = Barbara = Wyka index No. = grades = 5, 4.5, 5, 3.5 Rys. 6. Klasa Student i jej przykładowa ekstensja Zagadnienie ekstensji jest bardziej złoŝone w sytuacji, gdy klasa uczestniczy w związku generalizacji-specjalizacji. Problem ten jest omówiony w wykładzie poświęconym generalizacji-specjalizacji Atrybuty Atrybut obiektu jest nazwaną wartością; wartość atrybutu moŝe być literałem lub obiektem (który w takiej sytuacji jest podobiektem). Podstawowa róŝnica pomiędzy atrybutem-literałem a atrybutem-podobiektem polega na tym, Ŝe atrybutliterał nie posiada toŝsamości, w związku z czym nie moŝna tworzyć prowadzących do niego powiązań. Definicje atrybutów, będąc inwariantami obiektów, są przechowywane w klasie (Rys. 7 (a)), natomiast wartości atrybutów nie naleŝą do inwariantów i są przechowywane nie w klasach, ale w obiektach (Rys. 7 (b) i (c)). Person : string age : integer :Person = Nowak age = 53 :Person = Stycz age = 24 Rys. 7. Definicje i przykładowe wartości atrybutów (a) (b) (c) Ilustrację moŝliwych rodzajów atrybutów na przykładzie hipotetycznej klasy Pracownik przedstawia Rys. 8: proste przechowują pojedyncze atomowe, niepodzielne wartości, np.: imię, nazwisko, nazwisko panieńskie, wiek, płeć; złoŝone przechowują wartości, które potencjalnie mogą nie być atomowe, np.: data urodzenia, adres zamieszkania, lista poprzednich miejsc pracy, adres firmy; opcjonalne nie kaŝdy obiekt danej klasy posiada wartość dla tego atrybutu, np.: nazwisko panieńskie, lista poprzednich miejsc pracy; na diagramie opcjonalność atrybutu jest oznaczana poprzez umieszczenie [0..1] po jego nazwie; powtarzalne potencjalnie mogą przechowywać wiele wartości tego samego typu, np.: lista poprzednich miejsc pracy; na diagramie powtarzalność atrybutu jest oznaczana poprzez umieszczenie [0..*] po jego nazwie; pochodne 2 są wypadkową innych wartości, np. wiek; nazwy atrybutów pochodnych są poprzedzane ukośnikiem ( / ); 2 Specyfikowanie atrybutów pochodnych w sytuacji, gdy ze względu na czytelność diagramu zalecane jest usuwanie z niego wszelkich elementów nadmiarowych, wydaje się być irracjonalne. Tak jednak być nie musi, gdyŝ analityk wprowadzając do diagramu atrybut pochodny moŝe sugerować, Ŝe warto przechowywać wartości obliczone przez metody (metody omówione są w dalszej części wykładu) skojarzone z tym atrybutem. Taka sytuacja moŝe mieć miejsce wówczas, gdy wartość atrybutu rzadko ulega zmianie, jest często wykorzystywana, a jej obliczenie jest kosztowne.

7 klasowe ich wartości są identyczne dla wszystkich obiektów w danej ekstensji, np. adres firmy 3 ; na diagramie nazwy atrybutów klasowych są podkreślane; atrybut będący obiektem, np. zdjęcie. Rys. 8. Przykład klasy i jej atrybutów Employee name maiden name [0..1] birth date /age address gender list of previous jobs [0..*] company address photo Rys. 9 przedstawia klasę Pracownik, której atrybut foto przechowuje wartość będącą wystąpieniem klasy JPEG, modelującej pliki graficzne w formacie JPEG. Jak juŝ wspomnieliśmy w podrozdziale 3.2.2, obiekt, którego przynajmniej jeden atrybut jest instancją pewnej klasy, jest obiektem złoŝonym. Zgodnie z zasadą relatywizmu obiektów nie są nakładane Ŝadne ograniczenia ani na liczbę, ani na rozmiar/strukturę atrybutów obiektu. Atrybuty mogą być przedstawiane na diagramach na róŝnych poziomach szczegółowości wszystkie elementy wchodzące w skład specyfikacji atrybutu, oprócz jego nazwy, (czyli m.in. stereotyp, dostępność, typ) mogą być opuszczone. Reguły nazewnictwa dla atrybutów są podobne do reguł nazewnictwa dla klas, tzn. nazwa powinna odzwierciedlać semantykę atrybutu i powinna być moŝliwie krótka. Ponadto, na etapie analizy nazwa moŝe zawierać znaki, które nie są dozwolone w środowisku implementacji (np. spacje). Rys. 9. Przykład atrybutu będącego obiektem Klucz Employee salary : real department : string photo : JPEG PoniewaŜ jedną z podstawowych własności obiektu jest jego toŝsamość, nie zachodzi potrzeba definiowania na etapie analizy klucza, czyli specjalnego atrybutu (atrybutów) unikalnie identyfikującego (identyfikujących) obiekt. Problem zilustrowany jest na Rys. 10, gdzie zdefiniowano atrybut id osoby. Gdyby atrybut ten miał słuŝyć wyłącznie do identyfikacji obiektu, czyli spełniać rolę podobną do roli pełnionej przez klucz główny w modelu relacyjnym, to jego wprowadzenie naleŝałoby uznać za błąd. JeŜeli jednak ten atrybut nie pełniłby takiej roli, ale miałby znaczenie w dziedzinie problemowej, np. odpowiadałby numerowi PESEL, to umieszczenie go wśród inwariantów klasy jest oczywiście jak najbardziej poprawne. Rys. 10. Przykład klucza implementującego toŝsamość Operacje a metody Person person id : integer pesel : string : string age : integer Wszystkie obiekty, będące członkami danej klasy, podlegają tym samym operacjom. Operację naleŝy traktować jak swego rodzaju byt wirtualny, którego istnienie oznacza, Ŝe dla kaŝdego obiektu, członka danej klasy, musi być udostępnione zachowanie specyfikowane przez operację. Na przykład, zgodnie z Rys. 1 na kaŝdym obiekcie będącym 3 Oczywiście pod warunkiem, Ŝe wszyscy pracownicy pracują w tej samej firmie.

8 członkiem klasy Pracownik moŝna wykonać jedną z operacji: oblicz staŝ, przenieś na inne stanowisko itd. Operacja moŝe posiadać argumenty (np. operacja zmień pensję, dla której atrybutem byłaby wysokość nowej pensji) i/lub moŝe zwracać wartość (np. operacja oblicz staŝ zwracająca liczbę przepracowanych lat). Dana operacja moŝe być stosowana do obiektów róŝnych klas. Przykładem jest operacja drukuj występująca w klasach modelujących róŝne rodzaje plików na Rys. 11. Jej istnienie oznacza, Ŝe dla kaŝdego z przedstawionych na rysunku rodzajów pliku powinno być udostępnione zachowanie umoŝliwiające wydrukowanie jego zawartości, niezaleŝnie od jej formatu. Bardziej złoŝony przypadek, gdy operacja moŝe być zastosowana do obiektów klas uczestniczących w związku generalizacji-specjalizacji, jest omówiony w wykładzie poświęconym generalizacji-specjalizacji. Z pojęciem operacji ściśle związane jest pojęcie metody, która jest implementacją operacji w klasie; w pewnym uproszczeniu oznacza to, Ŝe operacja określa co naleŝy zrobić, a metoda specyfikuje jak to naleŝy zrobić. Jedna operacja moŝe posiadać wiele implementacji. W przykładzie z Rys. 11 istnieje jedna operacja drukuj i trzy metody drukuj implementujące operację drukowania dla róŝnych rodzajów plików. Zazwyczaj wszystkie metody implementujące daną operację mają taką samą sygnaturę (czyli taką samą nazwę, taką samą liczbę i typy argumentów oraz taki sam typ zwracanego wyniku), nie jest to jednak wymagane. ASCII file print Postscript file print Image file print Rys. 11. Ilustracja pojęć operacja i metoda Metody, podobnie jak atrybuty, mogą być przedstawiane na diagramach na róŝnych poziomach szczegółowości (Rys. 12); dotyczy to głównie argumentów i wartości zwracanej. Brak specyfikacji argumentów metody na etapie analizy moŝe oznaczać zarówno to, Ŝe metoda ich nie posiada, jak i to, Ŝe w danym momencie nie są one istotne. To samo dotyczy wartości zwracanej oraz typów argumentów. Reguły nazewnictwa dla metod są podobne do reguł nazewnictwa dla atrybutów. Person age change job change address Geometric object color position move (delta : Vector) is inside (p : Point) : Boolean rotate (angle) Rys. 12. RóŜne poziomy szczegółowości w przedstawianiu metod Rodzaje metod MoŜna wyróŝnić następujące rodzaje metod: metoda obiektu operuje na atrybutach, powiązaniach itd. jednego obiektu; argumentem domyślnym metody obiektu jest obiekt, dla którego została ona wywołana. metoda klasowa operuje na ekstensji klasy, czyli posiada dostęp do atrybutów, powiązań itd. wszystkich obiektów danej klasy; argumentem domyślnym metody klasowej jest ekstensja klasy. Szczególnym przypadkiem metody klasowej są konstruktory, czyli metody odpowiedzialne za tworzenie nowych obiektów. Metody klasowe są oznaczane na diagramie klas UML przez podkreślenie sygnatury. Metoda, niezaleŝnie od tego, czy jest wykonywana w kontekście obiektu czy ekstensji klasy, moŝe być metodą abstrakcyjną. Metoda abstrakcyjna posiada sygnaturę, ale nie moŝe posiadać implementacji. Metody abstrakcyjne mogą być definiowane jedynie w klasach abstrakcyjnych (patrz wykład poświęcony generalizacji-specjalizacji). Z perspektywy pojęciowej głównym zadaniem tego rodzaju metod jest definiowanie zbioru zachowań dla hierarchii klas, co z perspektywy projektowej moŝna określić jako specyfikowanie interfejsów (patrz wykład poświęcony powiązaniom i asocjacjom). Metody abstrakcyjne są omawiane takŝe w wykładzie poświęconym generalizacji-specjalizacji. Jako przykład rozwaŝmy metody klasy Pracownik z Rys. 13: Klasa nie posiada metod abstrakcyjnych, gdyŝ jako jedyna klasa na diagramie musi być klasą konkretną (patrz patrz wykład poświęcony generalizacji-specjalizacji). Klasa posiada metody obiektu, np.: policz wiek (), czy pracował w (nazwa firmy). Klasa posiada metody klasowe, np.: policz wiek (imię, nazwisko), znajdź najstarszego ().

9 Zwróćmy uwagę na metody o nazwie policz wiek, które są róŝnymi implementacjami operacji obliczającej wiek pracownika: Metoda policz wiek (imię, nazwisko) jest niepoprawną implementacją, gdyŝ będąc metodą obiektu jest niepotrzebnie sparametryzowana wartościami jego atrybutów wiek i nazwisko. Metoda policz wiek () jest poprawną implementacją, gdyŝ wszystkie informacje potrzebne do obliczenia wieku są przechowywane w obiekcie, który jest domyślnym argumentem metody; w związku z tym metoda nie musi być sparametryzowana. Metoda policz wiek (imię, nazwisko) jest poprawną implementacją, gdyŝ będąc metodą klasową musi ona otrzymać informację, dla którego pracownika ma obliczyć wiek. Nie jest to jednak rozwiązanie optymalne, poniewaŝ niepotrzebnie operuje na ekstensji w sytuacji, gdy wystarczy odwołać się bezpośrednio do obiektu (tak jak w rozwiązaniu powyŝej). Zwróćmy uwagę na to, Ŝe metody policz wiek () i policz wiek (imię, nazwisko) mimo róŝnych sygnatur implementują tę samą operację. Rys. 13. Przykładowa klasa Pracownik Wiązanie statyczne i dynamiczne Employee name birth date /age address gender list of previous jobs [0..*] company address calculate age (name, ) calculate age () calculate age (name, ) has worked in (company name) find the oldest employee () Wiązanie jest to mechanizm zamiany identyfikatora symbolicznego (nazwy) bytu programistycznego (stałej, zmiennej, procedury itd.) występującego w programie na wartość, adres lub wewnętrzny identyfikator tego bytu. WyróŜnia się dwa rodzaje wiązań: wiązanie wczesne (statyczne) jest wykonywane przed uruchomieniem programu, czyli podczas kompilacji i konsolidacji: Zalety: większa szybkość działania programu oraz moŝliwość pełnej statycznej kontroli typów. Wady: brak moŝliwości rozbudowy aplikacji podczas jej działania. wiązanie późne (dynamiczne) jest wykonywane w czasie działania programu: Zalety: moŝliwość przesłaniania w trakcie działania aplikacji oraz moŝliwość komponowania programu w trakcie jego działania, co umoŝliwia szybkie wprowadzenie zmiany do oprogramowania. Wady: wolniejsze działanie programu, utrudniona kontrola typów. Późne wiązanie jest nieodzowne dla: implementacji komunikatów (patrz następny podrozdział), dynamicznie tworzonych perspektyw, dynamicznie tworzonych procedur bazy danych, języków zapytań, migracji obiektów, ewolucji schematu bazy danych.

10 Komunikat Komunikat oznacza wywołanie operacji, która ma zostać wykonana na obiekcie. Komunikat specyfikuje zarówno obiekt będący jego adresatem, jak i operację (z listą argumentów), która ma być wykonana; nie określa jednak, która z metod implementujących daną operację ma zostać wywołana. Decyzja o wyborze metody zostaje podjęta na podstawie przynaleŝności obiektu do klasy w trakcie działania programu: wybierana jest metoda z tej klasy, która znajduje się najbliŝej klasy obiektu będącego adresatem komunikatu w sensie hierarchii dziedziczenia (patrz wykład poświęcony generalizacji-specjalizacji). NaleŜy zwrócić uwagę na róŝnicę pomiędzy wołaniem funkcji a wysłaniem komunikatu. W przypadku wołania funkcji obiekt jest jednym z jej argumentów: funkcja (obiekt, arg1, arg2,...) Natomiast w przypadku komunikatu specyfikacja obiektu występuje przed specyfikacją sygnatury operacji (a nie na liście jej argumentów): obiekt.operacja (arg1, arg2,...) W implementacji obiekt będzie domyślnym argumentem dla metody implementującej operację. RóŜnica w obu sposobach wykonywania operacji na obiekcie nie jest róŝnicą wyłącznie syntaktyczną znacznie waŝniejsze konsekwencje takiego podejścia omawia Tab. 2. Wołanie funkcji X = dochody (emeryt) Y = dochody (pracownik) X = emeryt.dochody () Wysłanie komunikatu Y = pracownik.dochody () Efekt: Przełączanie, czyli wybór do wykonania fragmentu kodu odpowiedniego dla danego rodzaju obiektu, jest wykonywane w ciele funkcji dochody. Funkcję pisze zwykle jeden programista, stosownie do wymagań określonych w danym momencie. KaŜda zmiana związana z nowym rodzajem obiektów skutkuje zmodyfikowaniem istniejącej (jednej) funkcji dochody, co potencjalnie moŝe stanowić źródło błędów. Stosowane jest wiązanie statyczne. Tab. 2. Główne róŝnice pomiędzy wołaniem funkcji a wysłaniem komunikatu Polimorfizm Efekt: Istnieje tyle metod implementujących operację dochody, ile jest klas, które ją definiują. W ciele Ŝadnej z metod nie ma przełączania; za kaŝdym razem, w zaleŝności od rodzaju obiektu będącego adresatem komunikatu, wywoływana jest inna metoda dochody implementująca operację dochody. Metody (i ich twórcy) nie muszą o sobie nic wiedzieć. KaŜda zmiana związana z nową klasą wymaga zaimplementowania nowej metody; Ŝadna z istniejących juŝ metod nie musi być modyfikowana. Stosowane jest wiązanie dynamiczne. Termin polimorfizm oznacza wiele form (postaci) jednego bytu. Słowo polimorfizm teŝ jest polimorficzne, poniewaŝ istnieje kilka rodzajów polimorfizmu: Polimorfizm metod: jedna operacja (byt wirtualny) moŝe posiadać wiele form (metod implementujących). Innymi słowy, operacja wywoływana za pośrednictwem komunikatu moŝe być róŝnie wykonana, w zaleŝności od rodzaju obiektu, do którego ten komunikat został wysłany. Polimorfizm typów: oznacza istnienie funkcji, które mogą zarówno przyjmować wartości róŝnych typów jako swoje argumenty, jak teŝ i zwracać wartości róŝnych typów. Polimorfizm typów uwaŝany jest za podstawę programowania ogólnego (generycznego) w polimorficznych językach programowania. Przykładowo, funkcja zwróć pierwszy element listy (lista) zwraca pierwszy element dowolnej listy, niezaleŝnie od tego, czy jest to lista liczb całkowitych, lista liczb rzeczywistych czy teŝ przechowuje wartości innego typu. Polimorfizm parametryczny: rodzaj polimorfizmu typów, który oznacza, Ŝe typ bytu programistycznego moŝe być parametryzowany innym typem, np. klasa Wektor(int) czy Wektor(char).

11 Klasa parametryzowana Klasa parametryzowana jest specjalnym rodzajem klasy, z którą związany jest pewien parametr (lub ich lista). Klasy parametryzowane są uŝyteczne z dwóch zasadniczych powodów: podnoszą poziom abstrakcji oraz zwiększają potencjał ponownego uŝycia. Klasa parametryzowana moŝe być przedstawiana na diagramach na dwa sposoby, co ilustruje Rys. 14. Podstawowe zastosowanie klas parametryzowanych polega na wykorzystaniu ich do definiowania zbiorów (szerzej: kolekcji). W naszym przykładzie kaŝdy obiekt klasy Kolekcja <Płyta>, lub równowaŝnie Kolekcja płyt, jest zbiorem obiektów będących członkami klasy Płyta. Zwróćmy uwagę na stereotyp «bind» przy strzałce oznaczającej zaleŝność, którego parametr Płyta jest uŝyty do sparametryzowania klasy Kolekcja w celu zdefiniowania klasy Kolekcja płyt. (a) Collection <CD> Collection T current parameterization parameter (b) add (T) delete (T) «bind» (CD) CD collection Rys. 14. Klasa parametryzowana 3.3 Podsumowanie Koncepcja obiektowości zawiera duŝą liczbę pojęć, z których dwa najwaŝniejsze to obiekt i klasa. Wraz z nimi w wykładzie omówiono równieŝ takie pojęcia jak atrybut, metoda, hermetyzacja, komunikat oraz polimorfizm. JuŜ te kilka koncepcji sprawia, Ŝe w porównaniu do innych podejść, w tym do podejścia relacyjnego, obiektowość znacznie lepiej pozwala opisać dziedzinę problemową. Siła wyrazu obiektowości jest wzmacniana poprzez pojęcia przedstawiane w kolejnych wykładach. 3.4 Przykładowe pytania i problemy do rozwiązania 1. Jak jest definiowane pojęcie obiektu? Podaj przykłady obiektów występujących w dziedzinie problemowej szkoła wyŝsza. 2. Krótko omów najwaŝniejsze pojęcia związane z koncepcją obiektu. 3. Na czym polega relatywizm obiektów? 4. Jaka jest róŝnica pomiędzy obiektem a klasą? 5. Jaki aspekt dziedziny problemowej moŝna modelować za pomocą metod? 6. W oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt DVD (wykład 2, podrozdział 2.12), wykonaj następujące zadania: Zidentyfikuj obiekty. Zdefiniuj klasy wraz z ich atrybutami i metodami.

Paweł Kurzawa, Delfina Kongo

Paweł 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ółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Podstawy Programowania Obiektowego

Podstawy 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ółowo

Podstawy projektowania systemów komputerowych

Podstawy 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ółowo

Rysunek 1: Przykłady graficznej prezentacji klas.

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

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia. Wprowadzenie teoretyczne.

Bardziej szczegółowo

Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska

Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego. Iwona Kochaoska Programowanie współbieżne Wykład 8 Podstawy programowania obiektowego Iwona Kochaoska Programowanie Obiektowe Programowanie obiektowe (ang. object-oriented programming) - metodyka tworzenia programów komputerowych,

Bardziej szczegółowo

Charakterystyka oprogramowania obiektowego

Charakterystyka oprogramowania obiektowego Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu Ŝycia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym

Bardziej szczegółowo

Wykład 8: klasy cz. 4

Wykład 8: klasy cz. 4 Programowanie obiektowe Wykład 8: klasy cz. 4 Dynamiczne tworzenie obiektów klas Składniki statyczne klas Konstruktor i destruktory c.d. 1 dr Artur Bartoszewski - Programowanie obiektowe, sem. 1I- WYKŁAD

Bardziej szczegółowo

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com

Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,

Bardziej szczegółowo

Po lewej przykłady klas. Stereotypy zostały tu wykorzystane do metaklasyfikacji metod.

Po lewej przykłady klas. Stereotypy zostały tu wykorzystane do metaklasyfikacji metod. 1. Klasa; notacja w UML 2. Dziedziczenie: jednoaspektowe wieloaspektowe wielokrotne dynamiczne 3. Klasa parametryzowana 4. Rozszerzenia i ograniczenia w podklasie 5. Wystąpienie klasy 6. Klasa abstrakcyjna

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

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

Bardziej szczegółowo

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Dariusz 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ółowo

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016

Kurs 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ółowo

Świat rzeczywisty i jego model

Ś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ółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Programowanie obiektowe - 1.

Programowanie 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ółowo

1 Projektowanie systemu informatycznego

1 Projektowanie systemu informatycznego Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................

Bardziej szczegółowo

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

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

Bardziej szczegółowo

4 Związek generalizacji-specjalizacji

4 Związek generalizacji-specjalizacji 4 Związek generalizacji-specjalizacji 4.1 Wstęp Wykład omawia jeden z podstawowych związków pomiędzy klasami związek generalizacji-specjalizacji. Generalizacja-specjalizacja jest bardzo silnym narzędziem

Bardziej szczegółowo

Modelowanie danych, projektowanie systemu informatycznego

Modelowanie danych, projektowanie systemu informatycznego Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym

Bardziej szczegółowo

Informatyka 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 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ółowo

Modelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1)

Modelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1) Modelowanie związków encji Oracle Designer: Modelowanie związków encji Technika określania potrzeb informacyjnych organizacji. Modelowanie związków encji ma na celu: dostarczenie dokładnego modelu potrzeb

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla studentów Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas Materiały dla studentów Projekt współfinansowany

Bardziej szczegółowo

Analiza 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 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ółowo

hierarchie klas i wielodziedziczenie

hierarchie klas i wielodziedziczenie Programowanie Obiektowe (język C++) Wykład 15. hierarchie klas i wielodziedziczenie Tomasz Marks - Wydział MiNI PW -1- Tomasz Marks - Wydział MiNI PW -2- Hierarchie klas Dziedziczenie wprowadza relację

Bardziej szczegółowo

Technologia informacyjna

Technologia informacyjna Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,

Bardziej szczegółowo

Diagramy klas. WYKŁAD Piotr Ciskowski

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

Bardziej szczegółowo

Materiały do zajęć VII

Materiały do zajęć VII Spis treści I. Klasy Materiały do zajęć VII II. III. Konstruktor Właściwości i indeksatory Klasy Programowanie obiektowe wiadomości wstępne Paradygmat programowania obiektowego Abstrakcja Hermetyzacja

Bardziej szczegółowo

Modelowanie obiektowe

Modelowanie 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ółowo

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej

Bardziej szczegółowo

Dziedziczenie jednobazowe, poliformizm

Dziedziczenie jednobazowe, poliformizm Dziedziczenie jednobazowe, poliformizm 1. Dziedziczenie jednobazowe 2. Polimorfizm część pierwsza 3. Polimorfizm część druga Zofia Kruczkiewicz, ETE8305_6 1 Dziedziczenie jednobazowe, poliformizm 1. Dziedziczenie

Bardziej szczegółowo

Technologie obiektowe

Technologie 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ółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie 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ółowo

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1 Bazy danych wprowadzenie teoretyczne Piotr Prekurat 1 Baza danych Jest to zbiór danych lub jakichkolwiek innych materiałów i elementów zgromadzonych według określonej systematyki lub metody. Zatem jest

Bardziej szczegółowo

Definiowanie własnych klas

Definiowanie własnych klas Abstrakcja Programowanie obiektowe Definiowanie własnych klas Paweł Rogaliński Instytut Informatyki, Automatyki i Robotyki Politechniki Wrocławskiej Świat rzeczywisty jest bardzo złoŝony i nie jest moŝliwe

Bardziej szczegółowo

1. 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? 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ółowo

Programowanie obiektowe

Programowanie 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ółowo

Ję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. 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ółowo

Informatyka 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 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ółowo

Program 6. Program wykorzystujący strukturę osoba o polach: imię, nazwisko, wiek. W programie wykorzystane są dwie funkcje:

Program 6. Program wykorzystujący strukturę osoba o polach: imię, nazwisko, wiek. W programie wykorzystane są dwie funkcje: Program 6 Program wykorzystujący strukturę osoba o polach: imię, nazwisko, wiek. W programie wykorzystane są dwie funkcje: Funkcja pobierz_osobe wczytuje dane osoby podanej jako argument. Funkcja wypisz_osobe

Bardziej szczegółowo

Aplikacje w środowisku Java

Aplikacje 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ółowo

Diagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.

Diagram 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ółowo

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Diagramu 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ółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Projektowanie 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ółowo

Projektowanie logiki aplikacji

Projektowanie logiki aplikacji Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy

Bardziej szczegółowo

Programowanie obiektowe

Programowanie 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ółowo

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ Opis działania raportów w ClearQuest Historia zmian Data Wersja Opis Autor 2008.08.26 1.0 Utworzenie dokumentu. Wersja bazowa dokumentu. 2009.12.11 1.1

Bardziej szczegółowo

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Iteracyjno-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ółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1 Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym

Bardziej szczegółowo

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80

Bardziej szczegółowo

UML 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. 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ółowo

Modelowanie obiektowe - Ćw. 3.

Modelowanie 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ółowo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Mariusz 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ółowo

Dziedziczenie. 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. 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ółowo

Obiekt klasy jest definiowany poprzez jej składniki. Składnikami są różne zmienne oraz funkcje. Składniki opisują rzeczywisty stan obiektu.

Obiekt klasy jest definiowany poprzez jej składniki. Składnikami są różne zmienne oraz funkcje. Składniki opisują rzeczywisty stan obiektu. Zrozumienie funkcji danych statycznych jest podstawą programowania obiektowego. W niniejszym artykule opiszę zasadę tworzenia klas statycznych w C#. Oprócz tego dowiesz się czym są statyczne pola i metody

Bardziej szczegółowo

1. Mapowanie diagramu klas na model relacyjny.

1. Mapowanie diagramu klas na model relacyjny. Rafał Drozd 1. Mapowanie diagramu klas na model relacyjny. 1.1 Asocjacje Wpływ na sposób przedstawienia asocjacji w podejściu relacyjnym ma przede wszystkim jej liczność (jeden-do-jednego, jeden-do-wielu,

Bardziej szczegółowo

Java - tablice, konstruktory, dziedziczenie i hermetyzacja

Java - 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ółowo

Definiowanie własnych klas

Definiowanie własnych klas Programowanie obiektowe Definiowanie własnych klas Paweł Rogaliński Instytut Informatyki, Automatyki i Robotyki Politechniki Wrocławskiej pawel.rogalinski @ pwr.wroc.pl Definiowanie własnych klas Autor:

Bardziej szczegółowo

KaŜdy z formularzy naleŝy podpiąć do usługi. Nazwa usługi moŝe pokrywać się z nazwą formularza, nie jest to jednak konieczne.

KaŜdy z formularzy naleŝy podpiąć do usługi. Nazwa usługi moŝe pokrywać się z nazwą formularza, nie jest to jednak konieczne. Dodawanie i poprawa wzorców formularza i wydruku moŝliwa jest przez osoby mające nadane odpowiednie uprawnienia w module Amin (Bazy/ Wzorce formularzy i Bazy/ Wzorce wydruków). Wzorce formularzy i wydruków

Bardziej szczegółowo

Inżynieria oprogramowania. Część 5: UML Diagramy klas

Inż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ółowo

MODELOWANIE OBIEKTOWE

MODELOWANIE OBIEKTOWE (Wykład na podstawie literatury: M.Śmiałek Zrozumieć UML 2.0, Helion 2005) UML Unified Modeling Language (język do specyfikowania, wizualizowania, konstruowania i dokumentacji tzw. artefactów oraz czynności

Bardziej szczegółowo

Programowanie i projektowanie obiektowe

Programowanie i projektowanie obiektowe Programowanie i projektowanie obiektowe Obiekty i klasy w Pythonie Paweł Daniluk Wydział Fizyki Jesień 2013 P. Daniluk (Wydział Fizyki) PO w. III Jesień 2013 1 / 23 Klasy i obiekty Klasy w implementacji

Bardziej szczegółowo

Informacje ogólne. Karol Trybulec p-programowanie.pl 1. 2 // cialo klasy. class osoba { string imie; string nazwisko; int wiek; int wzrost;

Informacje ogólne. Karol Trybulec p-programowanie.pl 1. 2 // cialo klasy. class osoba { string imie; string nazwisko; int wiek; int wzrost; Klasy w C++ są bardzo ważnym narzędziem w rękach programisty. Klasy są fundamentem programowania obiektowego. Z pomocą klas będziesz mógł tworzyć lepszy kod, a co najważniejsze będzie on bardzo dobrze

Bardziej szczegółowo

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

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

Bardziej szczegółowo

PHP 5 język obiektowy

PHP 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ółowo

Programowanie 2. Język C++. Wykład 3.

Programowanie 2. Język C++. Wykład 3. 3.1 Programowanie zorientowane obiektowo... 1 3.2 Unie... 2 3.3 Struktury... 3 3.4 Klasy... 4 3.5 Elementy klasy... 5 3.6 Dostęp do elementów klasy... 7 3.7 Wskaźnik this... 10 3.1 Programowanie zorientowane

Bardziej szczegółowo

Zagadnienia (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) 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ółowo

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne) Bazy danych 1 Wykład 5 Metodologia projektowania baz danych (projektowanie logiczne) Projektowanie logiczne przegląd krok po kroku 1. Usuń własności niekompatybilne z modelem relacyjnym 2. Wyznacz relacje

Bardziej szczegółowo

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu

Dane wejściowe. Oracle Designer Generowanie bazy danych. Wynik. Przebieg procesu Dane wejściowe Oracle Designer Generowanie bazy danych Diagramy związków encji, a w szczególności: definicje encji wraz z atrybutami definicje związków między encjami definicje dziedzin atrybutów encji

Bardziej szczegółowo

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Kurs 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ółowo

Typy klasowe (klasy) 1. Programowanie obiektowe. 2. Założenia paradygmatu obiektowego:

Typy 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ółowo

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu Podstawy baz danych PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań

Bardziej szczegółowo

Podczas dziedziczenia obiekt klasy pochodnej może być wskazywany przez wskaźnik typu klasy bazowej.

Podczas dziedziczenia obiekt klasy pochodnej może być wskazywany przez wskaźnik typu klasy bazowej. Polimorfizm jest filarem programowania obiektowego, nie tylko jeżeli chodzi o język C++. Daje on programiście dużą elastyczność podczas pisania programu. Polimorfizm jest ściśle związany z metodami wirtualnymi.

Bardziej szczegółowo

Klasa jest nowym typem danych zdefiniowanym przez użytkownika. Najprostsza klasa jest po prostu strukturą, np

Klasa jest nowym typem danych zdefiniowanym przez użytkownika. Najprostsza klasa jest po prostu strukturą, np Klasy Klasa jest nowym typem danych zdefiniowanym przez użytkownika Wartości takiego typu nazywamy obiektami Najprostsza klasa jest po prostu strukturą, np struct Zespolona { Klasy jako struktury z operacjami

Bardziej szczegółowo

Metody getter https://www.python-course.eu/python3_object_oriented_programming.php 0_class http://interactivepython.org/runestone/static/pythonds/index.html https://www.cs.auckland.ac.nz/compsci105s1c/lectures/

Bardziej szczegółowo

UML cz. II. UML cz. II 1/38

UML 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ółowo

Polimorfizm. dr Jarosław Skaruz

Polimorfizm. dr Jarosław Skaruz Polimorfizm dr Jarosław Skaruz http://jareks.ii.uph.edu.pl jaroslaw@skaruz.com O czym będzie? finalne składowe klasy abstrakcyjne interfejsy polimorfizm Finalne składowe Domyślnie wszystkie pola i metody

Bardziej szczegółowo

MAS dr. Inż. Mariusz Trzaska

MAS dr. Inż. Mariusz Trzaska MAS dr. Inż. Mariusz Trzaska Wykład 4 Model obiektowy cz. 2 Zagadnienia Asocjacja binarna Agregacja a kompozycja Modelowanie generalizacji-specjalizacji Obejście dziedziczenia wielokrotnego Asocjacja kwalifikowana

Bardziej szczegółowo

Rozdział 4 KLASY, OBIEKTY, METODY

Rozdział 4 KLASY, OBIEKTY, METODY Rozdział 4 KLASY, OBIEKTY, METODY Java jest językiem w pełni zorientowanym obiektowo. Wszystkie elementy opisujące dane, za wyjątkiem zmiennych prostych są obiektami. Sam program też jest obiektem pewnej

Bardziej szczegółowo

TECHNOLOGIE OBIEKTOWE. Wykład 3

TECHNOLOGIE 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ółowo

Technologie i usługi internetowe cz. 2

Technologie 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ółowo

Podstawy programowania. Wykład PASCAL. Zmienne wskaźnikowe i dynamiczne. dr Artur Bartoszewski - Podstawy prograowania, sem.

Podstawy programowania. Wykład PASCAL. Zmienne wskaźnikowe i dynamiczne. dr Artur Bartoszewski - Podstawy prograowania, sem. Podstawy programowania Wykład PASCAL Zmienne wskaźnikowe i dynamiczne 1 dr Artur Bartoszewski - Podstawy prograowania, sem. 1- WYKŁAD Rodzaje zmiennych Zmienne dzielą się na statyczne i dynamiczne. Zmienna

Bardziej szczegółowo

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

ZARZĄ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ółowo

Ję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/ 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ółowo

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 Utrwalanie danych zastosowanie obiektowego modelu danych warstwy biznesowej do generowania schematu relacyjnej bazy danych Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 1. Relacyjne

Bardziej szczegółowo

Programowanie obiektowe

Programowanie 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ółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Dziedziczenie. dr Jarosław Skaruz

Dziedziczenie. dr Jarosław Skaruz Dziedziczenie dr Jarosław Skaruz http://jareks.ii.uph.edu.pl jaroslaw@skaruz.com Dziedziczenie specjalizacja Dziedziczenie generalizacja Generalizacja-specjalizacja jest takim związkiem pomiędzy klasami,

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

Laboratorium 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ółowo

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji.

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji. JAVA Java jest wszechstronnym językiem programowania, zorientowanym obiektowo, dostarczającym możliwość uruchamiania apletów oraz samodzielnych aplikacji. Java nie jest typowym kompilatorem. Źródłowy kod

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 7 Modelowanie klas i stanów, generacja kodu. Materiały dla studentów

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 7 Modelowanie klas i stanów, generacja kodu. Materiały dla studentów Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 7 Modelowanie klas i stanów, generacja kodu Materiały dla studentów Projekt współfinansowany

Bardziej szczegółowo

Podstawy inżynierii oprogramowania

Podstawy 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ółowo

Oracle PL/SQL. Paweł Rajba.

Oracle PL/SQL. Paweł Rajba. Paweł Rajba pawel@ii.uni.wroc.pl http://www.kursy24.eu/ Zawartość modułu 8 Wprowadzenie Definiowanie typu obiektowego Porównywanie obiektów Tabele z obiektami Operacje DML na obiektach Dziedziczenie -

Bardziej szczegółowo

Definicje klas i obiektów. Tomasz Borzyszkowski

Definicje klas i obiektów. Tomasz Borzyszkowski Definicje klas i obiektów Tomasz Borzyszkowski Podstawy Do tej pory używaliśmy klas jedynie po to, by zdefiniować metodę main(). Klasy mają znacznie szersze zastosowanie w Java. W OOP (także w Java) klasy

Bardziej szczegółowo