Projektowanie systemów informacyjnych Wykład 3 Wprowadzenie do obiektowości, cz. 2 Kazimierz Subieta, Ewa Stemposz Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Zagadnienia Krótka charakterystyka UML Mechanizmy rozszerzalności: stereotypy i wartości etykietowane Klasy Metody jako przykład inwariantów klasy Struktury generalizacji-specjalizacji Bezpośrednie i pośrednie wystąpienia klasy Ekstensja klasy Klasa konkretna a klasa abstrakcyjna Rozszerzenia i ograniczenia w podklasie Interfejsy, zależności, uszczegółowienia Asocjacje

UML: Krótka charakterystyka UML (Unified Modeling Language) powstał w rezultacie połączonych wysiłków trzech znanych metodologów: G. Booch’a, I. Jacobsona i J. Rumbaugh’a i cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. UML jest metodyką projektowania, tzn. zestawem pojęć, oznaczeń, diagramów oraz zaleceń praktycznych. Notacja UML, która opiera się o podstawowe pojęcia obiektowości może być wykorzystana w dowolnej metodyce. Pojęcia UML, wynikające z doświadczenia jej twórców, mają w założeniu przykrywać większość istotnych aspektów modelowanych systemów. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór przereklamowany: niestabilny, zbyt ciężki, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, “design by contracts” oraz innych.

UML: Krótka charakterystyka (cd.) Wady i zalety metodyk, których autorami są twórcy UML: OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji). OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji). OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Istnieje wiele aspektów projektowania systemów, które nie zostały przykryte przez żadną z wyżej wymienionych metodyk, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów i inne. Celem UML jest przykrycie również tych aspektów.

Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy zachowania się (behavior): Diagramy stanów Diagramy aktywności Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy, celem jej ułatwienia.

Mechanizmy rozszerzalności: stereotypy Stereotypy są jednym z mechanizmów rozszerzalności UML. Dają możliwość definiowania nowych elementów, co ułatwia przystosowanie UML do specyficznego procesu, do preferencji użytkownika oraz pozwala na uszczegóławianie semantyki modelu: Stereotypy są wyrażeniami językowymi umożliwiającymi meta-klasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementu UML. Element modelu może mieć co najwyżej jeden stereotyp. Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne stereotypy. Stereotypy mogą mieć implikacje semantyczne (ograniczenia). Notacja: <<nazwa stereotypu>> lub ikona.

<<aktor>> Stereotypy (cd.) Przykłady stereotypów: <<używa>> P3 P4 <<rozszerza>> P1 P2 <<aktor>> Klient jest równoważne

Mechanizmy rozszerzalności: wartości etykietowane Wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. Dowolny element modelu, zbudowanego w UML, może być skojarzony z listą wartości etykietowanych. {autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza} Przykłady list wartości etykietowanych: {abstrakcyjna = TRUE} {abstrakcyjna} można skrócić do W ten sposób można na diagramach umieścić dowolną dodatkową informację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości.

Klasy Dwa rozumienia pojęcia klasa - niezbyt zgodne: 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) 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 obiektów Osoba. 2. Klasa jest miejscem przechowywania tych cech grupy obiektów, które są niezmienne (inwariantów) dla wszystkich członków grupy. Klasa nie jest zbiorem obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus ewentualnie własne. Nazwa, czyli językowy identyfikator klasy obiektu Typ, czyli struktura (budowa) obiektu - poprzez atrybuty Metody, czyli operacje, które można wykonać na obiekcie Najważniejsze inwarianty to: Zdarzenia lub wyjątki, które mogą zachodzić w operacjach na obiekcie Obsługa zdarzeń lub wyjątków (reguły aktywne) Lista eksportowa określająca, co jest dostępne z zewnątrz Ograniczenia, którym może podlegać obiekt klasy ...... Możliwe są inne inwarianty:

Metody jako przykład inwariantów klasy Zwykle, mamy do czynienia z wieloma obiektami tej samej klasy, np. z wieloma kontami. Nie byłoby zbyt celowe, aby każdy z takich obiektów przechowywał w sobie własną kopię metod lub informacji o swoim typie (budowie). Ta informacja jest przechowywa w jednym miejscu, w klasie. Obiekty KONTO Klasa wszystkich kont 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:.... .... import inwariantów Numer: 1234567 Stan konta: 454545 Właściciel: Adam Nowak Upoważniony: ....

Oznaczenia klas (1) Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości. Okno rozmiar czy_widoczne wyświetl() schowaj() rozmiar: Obszar czy_widoczne: Boolean Pole nazwy: stereotyp nazwa_ klasy lista_wart_etyk Pole atrybutów: atrybuty są opisywane (w kolejności tak, jak podano) poprzez stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etyk Pole metod: metody są opisywane, jak poniżej stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykt lista_arg: rodzaj nazwa_arg : typ = wart_początkowa

Oznaczenia klas (2) gdzie: dostępność jest określana przez trzy symbole: + publiczna - prywatna # chroniona rodzaj definiuje sposób, w jaki metoda korzysta z danego argumentu: in: metoda może czytać argument, ale nie może go zmieniać out: może zmieniać, nie może czytać inout: może czytać i zmieniać Wszystkie elementy specyfikacji klasy za wyjątkiem nazw (klasy, atrybutu, metody) są opcjonalne.

<<trwała>> Prostokąt Oznaczenia klas (3) Okno {abstrakcyjna, autor=Kowalski status=przetestowane} +rozmiar: Obszar = (100,100) #czy_widoczne: Boolean = false +rozmiar_domyślny: Prostokąt #rozmiar_maksymalny: Prostokąt -xwskaźnik: XWindow* +wyświetl() +schowaj() +utwórz() -dołączXWindow(xwin: XWindow*) <<trwała>> Prostokąt punkt1: Punkt punkt2: Punkt «konstruktor» Prostokąt(p1: Punkt, p2: Punkt) «zapytania» obszar(): Real aspekt(): Real ... «aktualizacje» przesuń (delta: Punkt) przeskaluj(współczynnik: Real) Stereotypy mogą być użyte dla oznaczenia grupy elementów.

Struktury generalizacji-specjalizacji (1) Generalizacja/specjalizacja jest związkiem pomiędzy klasami. Związek ten łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej klas będących jej specjalizacjami (podklasami). Klasy mogą tworzyć hierarchię lub inną strukturę bez pętli. Import inwariantów do klas (dziedziczenie) jest tranzytywny (przechodni). Pracownik Osoba Asystent Adiunkt Profesor Docent specjalizacja generalizacja

Struktury generalizacji-specjalizacji (2) Osoba K1 K2 Student Pracownik K3 Student_asystent Struktura typu pętla jest zabroniona Struktura typu krata jest dopuszczalna

Struktury generalizacji-specjalizacji (3) OSOBA NAZWISKO ROK_UR Wiek() GRAFIKA ROZMIAR Wyświetl(...) JPEG GIF STUDENT NR_INDEKSU WYDZIAŁ WstawOcenę(...) ZaliczSemestr() PRACOWNIK ZAROBEK DZIAŁ FOTO ZarobekNetto() ZmieńZarobek(...) Atrybut PRACOWNIKa FOTO należy do własnej klasy. Generalnie, struktura klas może być semantycznie bardziej złożona niż hierarchia.

Struktury generalizacji-specjalizacji (4) Wyposażenie nazwa wytwórca koszt aspekt generalizacji (dyskryminator) typ wyposażenia Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie typ zbiornika typ pompy Dyskryminator jest atrybutem opcjonalnym

Struktury generalizacji-specjalizacji (5) Wyposażenie nazwa wytwórca koszt ciśnienie ssania ciśnienie tłoczenia przepływ powierzchnia wymiany średnica rury objętość ciśnienie typ wyposażenia Wyposażenie nazwa wytwórca koszt typ wyposażenia Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wymiennik ciepła powierzchnia wymiany średnica rury Zbiornik objętość ciśnienie

Wieloaspektowe generalizacje-specjalizacje Pojazd napęd napęd teren teren {overlapping} {overlapping} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny Drzewo {disjoint, incomplete} gatunek drzewa disjont - rozłączny (domyślne) overlapping - pokrywające się complete - zupełny (domyślne) incomplete - niezupełny Dąb Brzoza Sosna

Bezpośrednie i pośrednie wystąpienia klasy Wystąpienie klasy (instancja klasy) oznacza obiekt, który jest “podłączony” do danej klasy, jest jej członkiem. Wystąpienia mogą być: bezpośrednie i pośrednie. Obiekt jest wystąpieniem bezpośrednim swojej klasy i wystąpieniem pośrednim wszystkich jej nadklas. W zależności od poziomu szczegółowości możliwe są następujące oznaczenia obiektu: nazwa_obiektu : nazwa_klasy nazwa_atrybutu = wart_atrybutu ... :nazwa_klasy nazwa_atrybutu = wart_atrybutu ... nazwa_obiektu : nazwa_klasy : nazwa_klasy

Ekstensja klasy Ekstensja klasy (class extent) = aktualny (zmienny w czasie) zestaw wszystkich wystąpień tej klasy. Niektóre metody zawarte w ramach klasy odnoszą się do jej wystąpień: pracownik.wiek pracownik.zwolnij KONTO.Oblicz_procent Niektóre metody zawarte w ramach klasy odnoszą się do jej ekstensji: KL_pracownik.nowy KL_pracownik.zlicz KL_KONTO.Oblicz_sumę Klasa może mieć nie jedną lecz wiele ekstensji.

Operacja abstrakcyjna Operacja abstrakcyjna jest to operacja wyspecyfikowana w nadklasie, której implementacja musi znaleźć się w ramach podklasy. UML pozwala na oznaczenie bytu abstrakcyjnego za pomocą wartości etykietowanej abstrakcyjna = TRUE (TRUE można opuścić) lub napisanie nazwy bytu italikami. Pracownik już-zarobił-w-tym-roku oblicz wypłatę {abstrakcyjna} Pracownik godzinowy stawka godzinowa stawka świąteczna oblicz wypłatę Pracownik etatowy zarobek tygodniowy Pracownik na zlecenie zarobek miesięczny Specyfikacja metody oblicz wypłatę znajduje się w klasie abstrakcyjnej Pracownik. Każda klasa konkretna zawiera właściwą dla siebie implementację tej metody.

Klasy abstrakcyjne, klasy konkretne Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłącznie jako nadklasa dla innych klas. Jest wspólną częścią definicji innych klas. Klasa abstrakcyjna może (ale nie musi) zawierać abstrakcyjne operacje. Klasa konkretna może mieć (ma prawo mieć) wystąpienia bezpośrednie. Klasa konkretna może zawierać implementacje abstrakcyjnych operacji, ale nie musi, ponieważ implementacje mogły być już zawarte w nadklasach. Klasa konkretna nie może posiadać operacji abstrakcyjnych. Sekwencja pierwszy następny Osoba prawna Klasyczne klasyfikacje w biologii: tylko liście w drzewie klas mogą być klasami konkretnymi. Osoba fizyczna Firma Sekwencja int ... implementacje Sekwencja char ...implementacje

Klasy abstrakcyjne, klasy konkretne (cd.) A - klasa abstrakcyjna K - klasa konkretna Klasa abstrakcyjna nie może znaleźć się w liściu drzewa. Klasa konkretna może zająć każde położenie.

Rozszerzenia i ograniczenia w podklasie Obiekt będący bezpośrednim wystąpieniem danej klasy jest jednocześnie wystąpieniem pośrednim wszystkich jej nadklas. Podklasa nie może omijać lub zmieniać atrybutów nadklasy. Podklasa może zmienić (przesłonić) metodę nadklasy, ale bez zmiany jej specyfikacji. Podklasa może dowolnie dodawać nowe atrybuty i metody (rozszerzać). Podklasa może ograniczać wartości atrybutów. Np. Koło jest podklasą klasy Elipsa, gdzie obie średnice elipsy są sobie równe. Ograniczenia mogą spowodować, że część metod przestanie być poprawna. Np. zmiana jednej ze średnic obiektu - dozwolona dla obiektu klasy Elipsa - jest niedopuszczalna w obiekcie podklasy Koło, gdyż muszą tam być zmienione obie średnice.

Interfejsy, zależności, uszczegółowienia Osoba {abstrakcyjna} Firma IPracownik uszczegółowienie Pracownik Uszczegółowienie (refinement), o notacji z premedytacją podobnej do generalizacji, oznacza zgodnie z nazwą, większy poziom szczegółowości. Stereotyp <<interfejs>> poprzedza nazwę klasy, która zawiera jedynie specyfikacje metod, bez ich implementacji. Wszystkie metody są tu publiczne. W UML interfejs nie zawiera atrybutów. Implementacje metod wyspecyfikowanych w Ipracownik zawiera klasa Pracownik. Zależność (dependency) wskazuje tu na klasę, która korzysta z danego interfejsu.

Interfejsy, zależności, uszczegółowienia (cd.) Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. Pracownik IPracownik Osoba Firma Klasa abstrakcyjna i interfejs zostały tu potraktowane w podobny sposób - jako definicje interfejsów do klasy Pracownik. Jednakże, istnieje między nimi pewna różnica. Klasy abstrakcyjne, w przeciwieństwie do interfejsu, mogą zawierać implementacje metod.

Asocjacje Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli zbiory powiązań pomiędzy obiektami tych klas, np. asocjacja Pracuje_dla pomiędzy klasą Osoba i klasą Firma. Czarny trójkącik określa kierunek (czytania) wyznaczony przez nazwę asocjacji. W danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby. Nazwy asocjacji, takie jak np. Pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym opisującym dziedzinę przedmiotową. Firma Osoba Pracuje_dla 1..* Asocjacje mogą być wyposażone w oznaczenia liczności. Liczność oznacza, ile obiektów innej klasy może być powiązane z jednym obiektem danej klasy; zwykle określa się to poprzez parę liczb (znaków), oznaczającą minimalną i maksymalną liczbę takich obiektów.

Liczność asocjacji UML znaczenie 1 1..* 2..* 3-5 2,4,18 0..1 0..* * 1 Liczność jest oznaczana na końcach asocjacji binarnych, tzn. takich, które łączą dwie lub jedną klasę. UML znaczenie Państwo Stolica 1 1..* 2..* 3-5 2,4,18 0..1 0..* * 1 1,2,3,... 2,3,4,... 3,4,5 2,4,18 0,1 0,1,2,... 1 * Firma Pracownik 0..* 0..1 Osoba Adres

Asocjacje skierowane Zamówienie dataZłożenia czyZapłacone sumaDoZapłaty realizuj() zamknij() Klient nazwisko adres wiarygodność() * 1 1 Na diagramach UML można zaznaczać kierunek nawigacji wzdłuż danej asocjacji. W takim przypadku asocjacja jest rysowana w postaci strzałki; nawigacja jest możliwa zgodnie z jej kierunkiem, ale nie odwrotnie. * PozycjaZamówienia ilość cena czyZrealizowana * 1 Produkt

Role asocjacji, oznaczanie asocjacji Asocjacje mogą być także wyposażone w nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik. podwładny * Pracuje_dla 1..* Firma * Osoba pracodawca pracownik 0..1 szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Jak oznaczać asocjacje binarne? można opuszczać nazwę asocjacji, gdy jest oczywista (?) i jest jedyną asocjacją łączącą dwie klasy Firma Pracownik 1..*

Oznaczanie asocjacji (cd.) Osoba Komitet Jest_członkiem * Jest_przewodniczącym 1 Na diagramie powyżej dwie asocjacje łączą te same klasy; w takim wypadku obie asocjacje muszą być oznaczone. do oznaczenia asocjacji można użyć nazwy lub dwóch ról lub jednej roli. Pracownik szef * 0..1 Z diagramów, z założenia, usuwa się wszelką informację redundantną (dla zwiększenia ich czytelności) - dlatego używanie nazwy i ról asocjacji jednocześnie nie jest polecane.

Atrybuty asocjacji W odróżnieniu od OMT, w UML atrybuty asocjacji muszą tworzyć nową klasę. Plik Użytkownik Prawo dostępu Dostęp Dostępny dla { dostęp oznacza: czytanie lub czytanie-pisanie} * Pracuje_w Osoba nazwisko pesel adres Firma nazwa adres 1..* 0..1 szef 0..1 Zatrudnienie zarobek stanowisko * Kieruje pracownik Ocena wydajności ocena

Kiedy stosować atrybuty asocjacji Osoba nazwisko pesel adres Firma nazwa Pracuje_w Zatrudnienie zarobek stanowisko 0..1 1..* Zalecane jest, by przypisywać do klasy tylko te atrybuty, które są dla tej klasy stabilne. Eksperyment myślowy: co będzie, jeżeli liczność asocjacji się zmieni? Dość często okazuje się wtedy, że atrybut jest atrybutem asocjacji, a nie klasy. Osoba nazwisko pesel adres zarobek stanowisko Firma nazwa Pracuje_w 0..1 1..* Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów.

Atrybuty i asocjacje pochodne Cecha pochodna jest zdefiniowana poprzez funkcję działającą na jednym lub więcej bytach modelu, które też mogą być pochodne. Cecha pochodna oznaczana jest ukośnikiem /. atrybut pochodny: /wiek Osoba data_urodzenia /wiek {wiek = data_bieżąca - data_urodzenia} zatrudnia Wydział * Sekcja * Pracownik * * zlokalizowana_w pracuje_w Budynek Asocjacja pracuje_w jest asocjacją pochodną, którą można wyznaczyć poprzez asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną można też oznaczyć poprzedzając ukośnikiem rolę asocjacji.

Przykładowy diagram klas Osoba zapisany_na poprzedza Student Pracownik 1..* * Kurs Profesor * zawiera prowadzi następuje_po jest_składową prowadzony_dla 1..* 1..* Wykład * prowadzony_przez