Wstęp do systemów informatycznych Diagramy klas. Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie 

Prezentacja na temat: "Wstęp do systemów informatycznych Diagramy klas. Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie "— Zapis prezentacji:

1 Wstęp do systemów informatycznych Diagramy klas

2 Odbiór świata  Myślenie o dziedzinie problemu powinno być możliwie zbliżone do myślenia o systemie  ułatwia to budowę systemu  jego projektowanie  jego zrozumienie  Różne ideologie próbują to ułatwiać  aktualnie dominujące jest programowanie (i projektowanie) obiektowe  w żadnym wypadku nie „zorientowane obiektowo”  ang. Object Oriented Programming

3 Podstawowe pojęcia  Obiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej rzeczywistości.  Tożsamość obiektu - wewnętrzny identyfikator obiektu, który pozwala na odróżnienie go od innych obiektów.  Hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić.

4 Podstawowe pojęcia  Klasa - zbiór własności grupy obiektów o tych samych charakterystykach.  Dziedziczenie - wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe.  Polimorfizm - wybór nazwy dla operacji jest określony wyłącznie semantyką operacji. Decyzja o tym, która z metod implementujących daną operację zostanie wybrana, zależy od przynależności obiektu do odpowiedniej klasy.

5 Obiekt  Byt lub idea zmapowane na konstrukt programistyczny  nazwa  dobrze określone granice  zamknięty  element większej konstrukcji  może być złożony  może być powiązany z innymi obiektami  ma typ

6 Identyfikator obiektu  Fakt istnienia wystarcza do identyfikacji  niezależnie od własności  Dwa byty mogą wyglądać identycznie, lecz być dwoma osobnymi bytami  Implementacja przypisuje obiektowi unikalny identyfikator  może być tymczasowy lub stały  pozwala na odróżnianie i identyfikowanie obiektów

7 Własności obiektu  tożsamość, odróżniająca go od innych obiektów  stan – wartości atrybutów i powiązań z innymi obiektami  zachowanie – zestaw operacji, jakie można wykonać na obiekcie

8 Numer = 1234567 Stan konta = 34567 PLN Właściciel = Jan Kowalski Upoważniony =... Podpis = ….... Wypłać Wpłać Sprawdź stan Upoważnij Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto Nalicz procent Obiekt

9 Relatywizm obiektów  Obiekt powinien zawierać wszystkie informacje związane z bytem, który reprezentuje  istotne w kontekście systemu  przechowywane w atrybutach obiektu  atrybuty mogą mieć wartości będące obiektami (podobiekty)  Model koncepcyjny nie powinien być ograniczony środowiskiem implementacji

10 Pracownicy..... Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Pracownik Zatrudnienia..... Zatrudnienie Stanowisko Nazwisko Dzieci... Dziecko Złożony obiekt

11 Asocjacje  Uogólnienie zbioru połączeń pomiędzy obiektami  Mają nazwę i liczności  ew. też inne własności  Zwykle implementowane jako referencje lub pointery (lub ich kolekcje)

12 PRACOWNIK Nazwisko = Nowak Zarobek = 1500 Pracuje_w o FIRMA Nazwa = Relax Ltd. Szef o Zatrudnia o Asocjacje

13 Klasa - definicje 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach (podobna semantyka, podobne atrybuty, zachowania, podobne związki z innymi obiektami). Własności te są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze Osoba. 2. UML: Klasa jest nazwanym opisem grupy obiektów, które współdzielą ten sam zbiór własności (inwariantów). Klasa nie jest zbiorem obiektów, lecz jest używana do opisywania (deklarowania) obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus (ewentualnie) inwarianty swoje. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus inwarianty własne.

14 Inwarianty  Wybrane możliwe inwarianty klasy:  nazwa  typ (opis struktury danych)  metody  zdarzenia (+obsługa)  wyjątki (+obsługa)  interfejsy  ograniczenia

15 Numer = 1234321 Stan konta = 34567 Właściciel = Jan Kowalski Upoważniony =... Wypłać Wpłać Sprawdź stan Upoważnij Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto Nalicz procent Numer: integer Stan konta: integer Właściciel: string Upoważniony:...... Numer = 1234567 Stan konta = 454545 Właściciel = Adam Nowak Upoważniony =... Klasa wszystkich kont Obiekty KONTO import inwariantów Metody jako inwarianty klasy  nie każdy obiekt musi przechowywać definicje metod – do tego służy klasa

16 Generalizacja, specjalizacja, dziedziczenie  Relacja generalizacji/specjalizacji między klasami łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej bardziej specjalizowanymi (podklasami)  Podklasy mają wszystkie inwarianty nadklasy  plus zwykle swoje własne  mogą niektóre inwarianty przedefiniowywać  Relacja generalizacji/specjalizacji może być (i zwykle jest) implementowana dziedziczeniem  ale są inne możliwości  Dziedziczenie inwariantów jest relacją przechodnią

17 generalizacja specjalizacja Pracownik AsystentAdiunkt ProfesorDocent nazwisko data ur. wiek pole atrybutów pole metod pensja Osoba pole nazwy klasy Dziedziczenie

18 Hermetyzacja  Opakowanie struktury i implementacji jako pojedynczego bloku  Oddzielenie specyfikacji od implementacji  Ukrycie struktury i implementacji obiektu  Jedna z reguł inżynierii oprogramowania (Parnas, 1972): programista powinien wiedzieć o obiekcie tylko tyle, by go efektywnie używać. To, co może być ukryte, powinno być ukryte

19 Hermetyzacja  Trzy podejścia:  Ortodoksyjne (Smalltalk) – metody są widoczne, atrybuty ukryte  Ortogonalne (C#, Java, C++) – dowolna własność może być publiczna lub prywatna  „Uważamy, że programiści są rozsądni” (Python) – wszystko jest publiczne

20 PRAC NAZWISKO Nowak ROK_UR 1961 ZAROBEK 2500 ZmieńZarobek(...)Podatek()ZarobekNetto() Wiek() begin return RokBież() - ROK_UR end; DZIAŁ Zabawki PRAC NAZWISKO Nowak ROK_UR 1951 ZAROBEK 2500 ZmieńZarobek(...) Podatek() ZarobekNetto() DZIAŁ Zabawki Wiek() begin return RokBież() - ROK_UR end; Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu Wiek()

21 Operacje i metody  Operacja – działanie, którego możemy użyć na obiekcie. Własność klasy  Metoda – implementacja operacji w jednej z klas. Wiele metod może implementować operację  Operacja: co mogę zrobić?  Metoda: jak mogę to zrobić?

22 Wołanie metod vs wołanie funkcji  Wołanie funkcji – obiekt jako jeden z parametrów  function(object,arg1,arg2,…)  Wiadomość (wołanie metody) – obiekt przed wywołaniem operacji  object.operation(arg1,arg2,…)  obiekt jest parametrem domyślnym

23 Wołanie metod vs wołanie funkcji  Funkcje – wczesne wiązanie  specyfikuje wołaną implementację  Metody – późne wiązanie  wołana implementacja ustalona w czasie wykonania programu

24 Numer = 123-4321 Stan konta = 34567 PLN Właściciel = Jan Kowalski Upoważniony =... Podpis = … Wypłać Wpłać Sprawdź stan Upoważnij Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto Nalicz procent Wypłać 1000 PLN OK, wypłaciłem Graj Co proszę...?

25 Polimorfizm  „Wiele form” pojedynczego bytu  Wiele form polimorfizmu ;)  np.  metody polimorficzne  polimorfizm parametryczny (parametryzowane typy)

26 Podstawy notacji

27 Okno rozmiar czy widoczne Okno rozmiar czy widoczne wyświetl schowaj Okno Rozmiar : Obszar czy widoczne: Boolean wyświetl() schowaj() Klasy - notacja  Cztery pola:  nazwa klasy  atrybuty  metody  informacje dodatkowe (rzadko używane)

28 Klasy - notacja  Nazwa klasy:  zwykle rzeczownik, w liczbie pojedynczej  nazwa w liczbie mnogiej, jeśli jeden obiekt opisuje całą grupę  Student – obiekt opisuje pojedynczego studenta  Studenci – obiekt opisuje grupę/wszystkich studentów  Jedyna obowiązkowa informacja na diagramie

29 specjalizacja generalizacja Pracownik Osoba AsystentAdiunkt ProfesorDocent AsystentAdiunkt Profesor Docent Pracownik Osoba Dziedziczenie

30 Struktura typu pętla jest zabroniona PracownikStudent Osoba Student_asystent Struktura typu krata jest dopuszczalna K1 K2 K3 Dziedziczenie

31 Asocjacje  Opis zbioru relacji  Wspólna semantyka  Relacja jest instancją asocjacji  Asocjacja binarna – łączy obiekty należące do 2 klas FirmaPracownik pracuje w 1..*1

32 Asocjacje :Osoba imię=Kasia :Firma typ=IT works_in :Osoba imię=Joe :Firma typ=restauracja :Osoba imię= works_in Osoba imię Firma typ works_in Obiekty i relacje na diagramie obiektów Klasy i asocjacje na diagramie klas

33 Liczności AAAA B A BB AB: min = 0, max = 1 BA: min = 1, max = 2 AB: min = 1, max = 3 BA: min = 2, max = 3 A B A B a) b) 0..1 1,2 AAAA B A BB 1..3 2,3 b) a)

34 Liczności 1 1, 2, 3,... 2, 3, 4,... 3, 4, 5 2, 4, 18 1, ? 0, 1 0, 1, 2,... 1 1..* 2..* 3..5 2,4,18 0..1 0..* * UMLznaczenie KrajStolica Firma Pracownik Osoba Adres 1* 0..*0..1 Przykłady:

35 Dziękuję za uwagę Pytania?