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 

Slides:



Advertisements
Podobne prezentacje
C++ wykład 2 ( ) Klasy i obiekty.
Advertisements

Programowanie obiektowe
Związki w UML.
Modelowanie klas i obiektów
Projektowanie systemów informacyjnych
Projektowanie systemów informacyjnych
Kamil Łącki Dominik Strzelichowski
Implementacja asocjacji
Projektowanie systemów informacyjnych
© K.Subieta. Obiektowe języki zapytań 03, Folia 1 marzec 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.
Projektowanie systemów informacyjnych
Co UML może zrobić dla Twojego projektu?
Bartosz Walter Prowadzący: Bartosz Walter
Analiza zorientowana obiektowo (Object-Oriented Analysis, OOA)
Zasady zaliczenia Warunki uzyskania zaliczenia:
Projektowanie systemów informacyjnych
DIAGRAMY KLAS i obiektów
Projektowanie systemów informacyjnych
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 8, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład I
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Model dziedziny. Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Samochód Osoba Dom Modelowanie.
Systemy plików ( ISAM i VSAM ) systemy hierarchicznych baz danych ( ISM, System 2000 ) systemy baz danych CODASYL ( m.in. IDS, IDMS ) relacyjne bazy danych.
Wykład 4 Analiza i projektowanie obiektowe
Źródła: podręcznikopracował: A. Jędryczkowski.
Jakub Wołczko W obiektowym świecie… Jakub Wołczko
OMT - Model obiektów, cz.1.
Języki i środowiska programowania systemów rozproszonych, Wykład 04, Slajd Języki i środowiska programowania systemów rozproszonych Wykładowca:
WPROWADZENIE W ŚWIAT OBIEKTÓW
Języki i środowiska programowania systemów rozproszonych, Wykład 03, Slajd Języki i środowiska programowania systemów rozproszonych Wykładowca:
Języki i środowiska programowania systemów rozproszonych, Wykład 05, Slajd Języki i środowiska programowania systemów rozproszonych Wykładowca:
Związki Agregacje Związki n-arne Ograniczenia.
Programowanie obiektowe – język C++
1 Analiza obiektowa Peter Coad / Edward Yourdon Analiza obiektowa wydawnictwo: Oficyna Wydawnicza READ ME, Warszawa 1994 dr Waldemar Wolski.
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
2 Odizolowanie danych od kodu może prowadzić do przypadkowych zmian danych przez funkcje, które nie są z nimi logicznie związane. Ponadto modyfikacja.
Modelowanie obiektowe Diagramy klas
Programowanie w języku C++
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Interakcja człowiek – komputer Podstawy metod obiektowych mgr inż. Marek Malinowski Zakład Matematyki i Fizyki Wydz. BMiP PW Płock.
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram klas Kluczowymi elementami są: klasy (class)
OCL.
Modelowanie obiektowe - system zarządzania projektami.
E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 8, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta.
Programowanie obiektowe
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Geneza obiektowości Obiektowość jest stosunkowo nową ideologią, która wynika z zaobserwowanych wad istniejącego świata i podaje jakąś receptę, jak te wady.
Programowanie Zaawansowane
Modelowanie model związków encji
Wstęp do systemów informatycznych Model przypadków użycia.
Wykład 5 Model obiektowy (3)
E. Stemposz. UML i Analiza Obiektowa, Wykład 4, Slajd 1/20 Wykład 4 Model obiektowy (2) dr inż. Ewa Stemposz
E. Stemposz. UML i Analiza Obiektowa, Wykład 3, Slajd 1/18 Wykład 3 Model obiektowy (1) dr inż. Ewa Stemposz
Asocjacja,Kompozycja,Agregacja
Implementacja asocjacji (z atrybutami i bez) przy użyciu: referencji (kolekcji referencji) tablic asocjacyjnych przygotował: Kamil Kowalczyk.
Temat: Tworzenie bazy danych
Projektowanie systemów informacyjnych
Programowanie Obiektowe – Wykład 6
Projektowanie systemów informacyjnych
Programowanie Obiektowe – Wykład 2
Projektowanie systemów informacyjnych
PGO Dziedziczenie Michail Mokkas.
Zapis prezentacji:

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  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

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ć.

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.

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

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

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

Numer = Stan konta = 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

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

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

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)

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

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.

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

Numer = Stan konta = 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 = Stan konta = 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

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ą

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

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

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

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()

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ć?

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

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

Numer = Stan konta = 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ę...?

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

Podstawy notacji

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)

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

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

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

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

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

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) ,2 AAAA B A BB ,3 b) a)

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

Dziękuję za uwagę Pytania?