Inżynieria Oprogramowania UML Schematy klas dr Krzysztof Podlaski Instytut Fizyki, Uniwersytetu Łódzkiego 18.12.2009 Łódź Inżynieria Oprogramowania, UML 1
Paradygmat obiektowości Małe przypomienie Założenia Abstrakcja Hermetyzacja Polimorfizm Dziedziczenie Inżynieria Oprogramowania, UML 2
Abstrakcja Obiekt to model abstrakcyjny czegoś Ma swój stan Ma pewne umiejętności/zachowania Reprezentuje jakiś obiekt rzeczywisty Często w uproszczeniu Izolacja ważnych cech Pomijamy cechy nie istotne/mniej istotne Inżynieria Oprogramowania, UML 3
Abstrakcja cd. Tworzymy aplikację sterowania ruchem kolejowym Mamy Pociągi, Tory i Semafory Semafor kolejowy Nie interesuje nas jego wygląd A jedynie Położenie (gdzie stoi) Jaki ma stan Zielone/czerwone Inżynieria Oprogramowania, UML 4
Hermetyzacja Obiekt ma pewne prywatne cechy TYLKO ON ma do nich dostęp Pozwala na rozdział uprawnień Zabezpiecza przed błędami Ułatwia testowanie Testujemy kawałkami Wprowadza jasny podział logiczny Podział na moduły Inżynieria Oprogramowania, UML 5
Hermetyzacja cd. Zwykle stan jest prywatny Obiekt posiada metody do jego zmiany Operacje Atomowe/jednostkowe Pełna kontrola stanu Ukrywanie implementacji Pozwala na bardzo abstrakcyjne obiekty Odczyt Z Pliku, Z strony WWW, Z Urządzenia Odczyt strumieniowy. Inżynieria Oprogramowania, UML 6
Polimorfizm Programowanie operacji dla ogólnych typów Rysowanie na ekranie Inaczej rysujemy Koło Inaczej rysujemy Trójkąt To jak co rysujemy zależy od implementacji Wybór może być» Dynamiczny» Statyczny Inżynieria Oprogramowania, UML 7
Dziedziczenie Przejmowanie własności innych obiektów Umożliwia tworzenie bogatego drzewa abstrakcji POJAZD ROWER MOTOCYKL SAMOCHOD» OSOBOWY» CIEZAROWY Inżynieria Oprogramowania, UML 8
Dziedziczenie cd. Budowanie z klocków Uszczegóławianie abstrakcji Nie musimy kopiować kodu Łatwiejsze poprawki Mniej testowania Przeładowywanie metod Jeżeli coś trzeba zmienić to zmieniamy Inżynieria Oprogramowania, UML 9
Klasa Klasa Definicja pewnego typu obiektów Definicja Struktury (pola) Definicja Interfejsu (metody) Interfejs Zbiór akcji/zachowań obiektu Co można z obiektem zrobić Inżynieria Oprogramowania, UML 10
Obiekt Konkretna instancja klasy Obiekt posiada Tożsamość Np. adres w pamięci Stan Pozwala na rozróżnienie obiektów Wartości pól Zachowanie Takie same dla danej klasy Inżynieria Oprogramowania, UML 11
Klasa a Obiekt Klasy są tworzone na poziomie kompilacji Obiekt jest typu jakiejś klasy Obiekty są tworzone dynamicznie W odróżnieniu do zmiennych prymitywnych Do obiektu dowiązania do metod klasy Nie powielamy tych samych informacji Metody/pola statyczne Inżynieria Oprogramowania, UML 12
Programowanie Obiektowe Dwa światy Problem do rozwiązania (abstrakcja problemu) Specyfika maszyny (abstrakcja implementacji) Semafor: własności: stan: (zapalony, zgaszony) czynności: włączanie (zapal, zgaś) sprawdzanie stanu Klasa: Semafor wlaczony on() off() czyzapalony() Inżynieria Oprogramowania, UML 13
Przykładowa implementacja w języku JAVA Semafor wlaczony on() off() czyzapalony() class Semafor { boolean wlaczony; void on() {wlaczony = true;} void off() {wlaczony = false;} boolean czyzapalony {return wlaczony;} } Inżynieria Oprogramowania, UML 14
Klasy a UML UML Umożliwia opis klas Abstrakcja klasy Sama struktura i interfejs Bez implementacji Niezależny od języka programowania Umożliwia generowanie szablonu programu W dowolnym języku» StarUML i inne programy Struktury projektu Zależności pomiędzy klasami Inżynieria Oprogramowania, UML 15
Przykład klasy Nazwa Własności/ Pola/ Atrybuty Operacje -imie: String -nazwisko: String -pesel: String -dataur: String Osoba +getimie(): String +setimie(im: String): String Inżynieria Oprogramowania, UML 16
Składnia Własności klasy dostęp nazwa : typ[krotność] {ograniczenia} = wartość_dom Po kolei Dostęp kto ma dostęp do pola Typ jakiego typu ta własność Krotność ile elementów Ograniczenia dodatkowe warunki Wartość_dom wartość domyślna Inżynieria Oprogramowania, UML 17
Dostęp 4 poziomy widoczności Publiczny/public + Prywatny/private - Chroniony/protected # Pakietowy/package access ~ Inżynieria Oprogramowania, UML 18
Krotność Można ograniczyć ilość 1 * Dokładnie jeden (domyślna watrość/pomija się) Dowolnie wiele od..do (3..12) Nie mniej niż, Nie więcej niż 0..1 (co najwyżej jeden) 1..* (co najmniej jeden) Inżynieria Oprogramowania, UML 19
Krotność cd. Istotne są krotności 1 i * Konkretna dowolna np. 7 nie jest tak wazna Może się zmieniać i zależy od wielu czynników W UML 2.0 nie powinno się tego stosować Inżynieria Oprogramowania, UML 20
Ograniczenia Dodatkowe informacje o atrybutach ordered elementy są uporządkowane unordered unique elementy są unikalne/rozróżnialne nonunique readonly tylko do odczytu frozen stałe bądź nie podlegają zmianom po zainicjowaniu Inżynieria Oprogramowania, UML 21
Elementy statyczne Elementy statyczne Należą do klasy To samo dla wszystkich instancji/obiektów Nie trzeba tworzyć ani jednego obiektu klasy Oznaczamy podkreśleniem Inżynieria Oprogramowania, UML 22
Operacje Operacje klasy dostęp nazwa(par_a, par_b, ) : typ_zwracany {ograniczenia} Spis parametrów par_a,par_b w postaci: kierunek nazwa:typ[krotność]=wart_dom Kierunek» in wejściowy» out wyjściowy» inout w obie strony» return zwracany Inżynieria Oprogramowania, UML 23
Ograniczenia dla operacji Dodatkowe informacje o atrybutach query brak modyfikacji stanu obiektu exception zgłasza wyjątek Inżynieria Oprogramowania, UML 24
Relacje pomiędzy klasami Zaprojektowanie klasy nie są niezależne Wzajemnie się wykorzystywać Mogą być elementami innych (pola) Być tworzone przez inne (Fabryki obiektów) Być Integralną częścią Dziedziczyć po sobie Te relacje znajdują się na diagramie Inżynieria Oprogramowania, UML 25
Zależności na diagramie Pomiędzy elementami <<call> Wywołanie metod innej klasy wewnątrz <<create>> Tworzy instancje klasy <<instance>> Jest instancją <<use>> Wykorzystuje obiekt klasy Inżynieria Oprogramowania, UML 26
-imie: String -nazwisko: String -pesel: String -dataur: String Osoba +getimie(): String +setimie(im: String): String <<call>> ListaOsobowa -pracownicy: Osoba[*] +addnewosoba(o: Osoba): void Inżynieria Oprogramowania, UML 27
Asocjacje Powiązania pomiędzy klasami Mogą zastąpić definiowanie własności Analogia do modelu relacyjnego baz danych Posiada referencje do obiektu klasy Może posiadać kierunek Zwykle jednokierunkowa Strzałka Dwukierunkowa = referencje wzajemne Bez strzałek Inżynieria Oprogramowania, UML 28
-imie: String -nazwisko: String -pesel: String -dataur: String Osoba +getimie(): String +setimie(im: String): String * 1 pracownicy -posiada ListaOsobowa +addnewosoba(o: Osoba): void Inżynieria Oprogramowania, UML 29
Kiedy stosować Atrybuty Dla typów prostych Asocjacje Dla instancji klas Daje nam widoczne powiązania Bez dokładnego czytania Inżynieria Oprogramowania, UML 30
Lepszy opis Asocjacji Klasa asocjacji (klasa asocjacyjna) Klasa opisująca asocjację Łączymy linią przerywaną z asocjacją Obiekt Asocjacyjny Pośrednik relacji Obiekt pośredniczący Zbędny przy prostych relacjach Inżynieria Oprogramowania, UML 31
Agregacja Asocjacja ale Z warunkiem podległości Należy do Ale nie jest wyłącznym właścicielem Nie tworzy obiektu Nie niszczy Nie musi istnieć obiekt nadrzędny Przykład Sklep Komputerowy» Elementy HDD, RAM, Monitory» Zestaw komputerowy Inżynieria Oprogramowania, UML 32
HDD Zestaw Komputerowy Dyski istnieją niezależnie od zestawu Ale są jego integralną częścią Niezbędne do jego istnienie Oznaczamy Pustym Rombem po stronie nadrzędnego obiektu Inżynieria Oprogramowania, UML 33
Kompozycja Relacja silniejsza od agregacji Element jest integralną częścią Nie może istnieć samodzielnie Najczęściej mamy tu wyłączność Przykład Płyta główna i Chipset Komputer i BIOS Inżynieria Oprogramowania, UML 34
Chipset Plyta glówna Nie może istnieć jedno bez drugiego Posiadanie na wyłączność Usunięcie Płyty główniej niszczy Chipset Oznaczamy Pełnym Rombem po stronie nadrzędnego obiektu Inżynieria Oprogramowania, UML 35
Uogólnienie Uszczegółowienie typu Zmniejszenie poziomu abstrakcji Najczęściej kojarzy się z dziedziczeniem W Javie także implementacja Typ niższego rzędu jest typu rzędu wyższego Samochód jest Pojazdem Ale nie każdy pojazd jest Samochodem Inżynieria Oprogramowania, UML 36
Osobowy Pojazd -wlasciciel: Osoba -predkoscmax: double -predkosc: double +stan(): void +przyspiesz(oile: double): void +predkosc(): double +setwlasciciel(os: Osoba): void +getwlasciciel(): Osoba Motocykl Samochód Rower Ciezarowy Inżynieria Oprogramowania, UML 37
Interfejsy i klasy abstrakcyjne Definiowanie szablonu klasy Nie definiujemy wszystkich operacji Interfejs Jedynie deklaracje Nazwa Rodzaje Parametrów Zwracane wartości TYLKO deklaracje Klasa Abstrakcyjna Może mieć część pełnych metod Inżynieria Oprogramowania, UML 38
Obiekt Graficzny Kwadrat +narysuj(): void Kolo +narysuj(): void Trójkat +narysuj(): void Obiekt Graficzny posiada operację narysuj():void Wysoki poziom abstrakcji Nie można podać definicji operacji Inżynieria Oprogramowania, UML 39
Przykład Projektujemy Forum internetowe Jak zbudować klasy Zależności pomiędzy nimi Wymyślamy możliwe klasy Data, User, Rola/Uprawnienia, Stan Użytkownika, Temat, Post Wyszukiwanie Inżynieria Oprogramowania, UML 40
Data -data: longint +tostring(): String +dzientygodnia(): String +dzienmiesiaca(): int +miesiac(): int +rok(): int +ilednitemu(): int Post -tresc: String -data: Data -datamodyfikacji: Data +tohtml(): String Temat -nazwa: String +addpost(post: Post) Dzial -nazwa: String +addtemat(temat: Temat) User #imie: String #login: String #email: String Rola #uprawnienia Moderator -dzial: Dzial Administrator Inżynieria Oprogramowania, UML 41
Dodajemy do tego relacje Post -tresc: String -data: Data -datamodyfikacji: Data +tohtml(): String * 1 +<<posiada>> Temat -nazwa: String +addpost(post: Post) * +<<posiada>> 1 Dzial -nazwa: String +addtemat(temat: Temat) Inżynieria Oprogramowania, UML 42
Relacje cd. Post -data: Data -tresc: String -datamodyfikacji: Data +tohtml(): String +<<autor>> * +<<tworzy>> 1 * User #imie: String #login: String #email: String +<<uprawninienia>> Administrator Moderator +dzial: Dzial Rola 1 #uprawnienia Inżynieria Oprogramowania, UML 43