Cel drugiego wykładu

Transkrypt

1 Cel drugiego wykładu Tytuł: Diagramy klas w perspektywie implementacyjnej Cel wykładu: Zaprezentować sposób przygotowania diagramu klas UML w perspektywie implementacyjnej z uwzględnieniem takich języków programowania jak C++, Java C#. W dalszej części wykładu będę używał skrótu PI dla określenia perspektywy implementacyjnej. Projektowanie systemów informatycznych, wykład 2 1 Diagramy klas nie dość, że są najczęściej używane, to również stosuje się w nich największy zakres pojęć związanych z modelowaniem i projektowaniem stąd zdecydowałem się przygotować osobny wykład na temat budowania diagramów klas w perspektywie implementacyjnej. Diagramy klas poznali Państwo na wykładzie z modelowania systemów informatycznych w poprzednim semestrze. Jednak wtedy położono nacisk na reprezentację tych diagramów w perspektywie pojęciowej nie zakładając konkretnego języka programowania, platformy programistycznej, systemu operacyjnego, typu komputera na którym będzie działał system. W niniejszym wykładzie zaprezentuję jak przygotowywać diagramy UML przy założeniu, że implementacja programu będzie realizowana w języku C++, Java lub C#. Ponadto zakładamy, że system zaprezentowany na diagramie klas będzie działał na komputerze klasy PC. Przy czym jeżeli jest to konieczne to sprzęt możemy rozbudować do granic możliwości komputerów klasy PC. Ponieważ zakładam, że student przystępujący do studiowania niniejszego wykładu zna podstawy budowy diagramów klas to proponuję aby przed studiowaniem niniejszego wykładu przeczytać dla przypomnienia wykład dotyczący diagramów klas z kursu modelowanie systemów informatycznych, prowadzonego w poprzednim semestrze. Ponadto mam prośbę do czytelników niemniejszego wykładu. Ponieważ jest to wersja 1.0 więc jak to z wersjami 1.0 bywa posiada pewnie wiele błędów edycyjnych. Proszę więc o informowanie mnie o tych błędach co przyczyni się do ich wyeliminowania i stworzenia kolejnych, lepszych wersji. Zgłoszenia błędów będą uwzględniane w ocenie z tego przedmiotu. 1

2 Zakres drugiego wykładu Wykład prezentuje następujące elementy diagramów klas w kontekście PI. Atrybuty oraz asocjacje Operacje Uogólnienie Zależności Agregacja i zwieranie Klasy abstrakcyjne i interfejsy Klasyfikacja Klasy asocjacyjne Szablony klas Wyliczenia Klasa aktywna Projektowanie systemów informatycznych, wykład 2 2 2

3 Atrybuty klasy Cechy klasy są zapisywane w postaci atrybutów klasy lub asocjacji z innymi klasami. Atrybuty reprezentują wartości proste lub niewielkie obiekty, asocjacje obiekty złożone Specyfikacja atrybutu: widoczność nazwa : typ[krotność] = wartość dom {ograniczenia} Skąd atrybut jest widoczny? Ile obiektów trzeba i ile można umieścić w atrybucie? Jaka jest wartość atrybutu, gdy niepodano jej wprost? Przykład użycia: Jakie dodatkowe warunki spełniają wartości atrybutu? - Sygnatura: String [1] = Nie nadany {unique} Projektowanie systemów informatycznych, wykład 2 3 Zwykle atrybut w perspektywie pojęciowej jest opisywany tylko przez dwa elementy: nazwę i typ. Jednak pełna definicja stosowana w perspektywie implementacyjnej obejmuje także widoczność atrybutu, definiującą, z jakich miejsc systemu atrybut jest dostępny, krotność, która określa ile obiektów mieści się w atrybucie, dodatkowe ograniczenia nałożone na atrybut, i wartość domyślną. Elementom, których w definicji atrybutu nie podano wartości, przypisywane są wartości domyślne (widoczność prywatna, krotność 1). Poszczególne elementy definicji atrybutu będą prezentowane na kolejnych slajdach. 3

4 Widoczność atrybutu w PI UML definiuje 4 poziomy widoczności cech i metod, które należy wyspecyfikować w PI + publiczny element jest widoczny z każdego miejsca w systemie # chroniony element jest widoczny we własnej klasie i jej podklasach prywatny element jest widoczny tylko we własnej klasie ~ publiczny wewnątrz pakietu element jest widoczny tylko wewnątrz własnego pakietu Projektowanie systemów informatycznych, wykład 2 4 Podobnie jak w wielu wysokopoziomowych językach programowania, UML posiada 4 poziomy widoczności: publiczny, chroniony, prywatny i publiczny wewnątrz pakietu. Poziomy te zwykle są do opisywania widoczności cech (atrybutów i asocjacji) oraz operacji, jednak dotyczą także np. klas pakietów. Podstawowa zasada dotycząca widoczności jest taka, że każda klasa ma składowe publiczne i prywatne. Składowe publiczne mogą być używane przez dowolną inną klasę, natomiast składowe prywatne mogą być używane jedynie przez klasę-właściciela. Niestety, każdy język ma własne reguły. Mimo że w wielu językach używa się terminów takich jak publiczny", prywatny" i chroniony", to są im nadawane różne znaczenia. Różnice znaczeniowe są małe, ale wprowadzają zamieszanie, szczególnie jeśli używa się kilku języków programowania. Podczas używania zasięgu widoczności, należy użyć reguł języka, w którym pracujemy. Gdy analizujemy model UML nieznanego pochodzenia, wówczas należy zwracać uwagę na znaczenie wskaźników zasięgu widoczności i zdawać sobie sprawę, że to znaczenie różni się w poszczególnych językach programowania. Przykładowo w C++ mamy tylko trzy zakresy widoczności. Nie reprezentowany jest zakres publiczny wewnątrz pakietu. 4

5 Krotność atrybutu w PI (1) Krotność pozwala określić minimalną i maksymalną liczbę obiektów, jakie można powiązać z daną cechą: 1 dokładnie jeden obiekt 0..1 opcjonalnie jeden obiekt 1..* - przynajmniej jeden obiekt 1, 3, 5 konkretne liczby obiektów * - dowolna liczba obiektów Przykłady realizacji krotności w języku C++: Tablica obiektów: Lista wskaźników: Tablica wskaźników: Ksiazka Ksiazki[100]; list< Ksiazka *> Ksiazki; Ksiazka * Ksiazki[100]; Projektowanie systemów informatycznych, wykład 2 5 Krotność cechy wskazuje, ile obiektów można, a ile trzeba w niej zawrzeć. Krotność można określać jako ograniczenie dolne i górne, jednak oczywiste lub powtarzające się wartości graniczne można pomijać, np. zapis 0..* jest skracany do *, a zapis 1..1 do 1. W praktyce programowania istotna jest krotność 0, 1 i dowolna, natomiast wartości dyskretne są mniej ważne, jako szczególne przypadki wymienionych trzech. Często w perspektywie implementacyjnej podaje się zasadę w jaki sposób będą realizowane krotności atrybutów. Ponieważ możliwości jest zwykle kilka, dla przejrzystości należy wybrać jedną reprezentację danego typu krotności w konkretnym języku programowania. 5

6 Ograniczenia w PI (1) Z atrybutem mogą być związane dodatkowe ograniczenia, które określają jego właściwości, np.: {ordered} obiekty wewnątrz cechy są uporządkowane. {unordered} obiekty są nieuporządkowane. {unique} obiekty wewnątrz cechy nie powtarzają się. {nonunique} obiekty wewnątrz cechy mogą się powtarzać. {readonly} wartość atrybutu służy tylko do odczytu. {frozen} wartość atrybutu nie może być zmodyfikowana po jej przypisaniu. Projektowanie systemów informatycznych, wykład 2 6 Niemal każdy element w UML może posiadać dodatkowe właściwości i ograniczenia, które szczegółowo opisują jego zachowanie i przeznaczenie. Są one zapisywane w nawiasach klamrowych. Atrybuty klasy można oznaczyć jako uporządkowane za pomocą ograniczenia {ordered}, co oznacza, że są one w jakiś sposób (zwykle rosnąco, leksykograficznie) posortowane. Ograniczenie {unique} wymaga, aby obiekty pamiętane wewnątrz atrybutu nie powtarzały się. Można podać również {nonunique} aby dopuść powtórzone wartości. Właściwość {readonly} oznacza atrybut, którego wartość jest przeznaczona wyłącznie do odczytu, natomiast {frozen} którego wartość po zdefiniowaniu nie może być zmieniona. W różnych językach programowania można osiągnąć poszczególne ograniczenia w różny sposób. Ważne jest aby w PI podać jakie techniki będą wykorzystane do osiągnięcia zastosowanych ograniczeń. Przykładowo ograniczenie {unique} w języku C++ można osiągnąć wykorzystując kontener: set z biblioteki STL. 6

7 Atrybuty pochodne Atrybut pochodny (wywiedziony) może zostać obliczony na podstawie innych atrybutów. Atrybutów pochodnych nie trzeba implementować. Wypozyczenie -DataPoczatku: Date [1] -DataKonca: Date [1] /Przekroczenie: Bolean MaxWypozyczenie: int Przekroczenie = (DataKonca.Dni() DataPoczatku.Dni()) >MAX_WYPOZYCZENIE Projektowanie systemów informatycznych, wykład 2 7 Na poziomie tworzenia diagramów w PI należy zdecydować o tym, które atrybuty będą pochodnymi (ang. derived) czyli zależnymi od innych atrybutów i ich wartości można obliczyć na podstawie tych atrybutów. Często w fazie implementacji atrybuty pochodne są przekształcane w metody lub ich wartość jest obliczana na bieżąco. Nie ma zatem potrzeby ich zapamiętywania w klasie. Atrybuty pochodne są oznaczane znakiem '/' umieszczonym przed nazwą atrybutu. 7

8 Atrybuty statyczne UML określa jako statyczne te atrybuty, których obszarem działania jest klasa a nie instancja tej klasy. Jest to analogia do statycznych atrybutów w języku C++. Atrybuty statyczne są wyróżniane podkreśleniem. Wypozyczenie -Data początku: Date [1] -Data końca: Date [1] /Przekroczenie: Bolean MaxWypozyczenie: int Projektowanie systemów informatycznych, wykład 2 8 Przypominam, że atrybut statyczny to taki, który charakteryzuje wszystkie obiekty danej klasy. Jest on wspólny dla wszystkich obiektów klasy, ma taką samą wartość dla wszystkich obiektów klasy. 8

9 Asocjacje Innym sposobem zapisania atrybutu jest użycie asocjacji. Większość tych samych informacji, które można przedstawić za pomocą atrybutu, pojawia się również na asocjacji. Poniższe rysunki ilustrują sposób zapisania tych samych cech w dwóch różnych notacjach. a) Zamówienie -dataotrzymania: Data [0 1] -przedpłata: Boolean [1] pozycje: PozycjaZamówienia[*]{Ordered} b) Data 0 1 +dataotrzymania * źródło Zamówienie 1 +przedpłata 1 Boolean cel * Pozycje {ordered} PozycjaZamówienia Projektowanie systemów informatycznych, wykład 2 9 Rysunek a) prezentuje reprezentację parametru klasy w postaci atrybutu. Rysunek b) prezentuje reprezentację parametru klasy w postaci asocjacji. Asocjacja jest rysowana w postaci ciągłej linii między dwiema klasami, ze strzałką skierowaną od klasy źródłowej do klasy docelowej. Nazwa cechy jest umieszczona razem z krotnością w punkcie docelowym asocjacji. Punkt docelowy asocjacji jest przytwierdzony do klasy będącej typem cechy. Chociaż w obu notacjach pojawia się większość tych samych informacji, to jednak niektóre elementy się różnią. W szczególności asocjacje mogą zawierać krotności na obu końcach linii. Wobec istnienia dwóch notacji dla tej samej rzeczy pojawia się oczywiste pytanie dlaczego mielibyśmy używać jednej z nich, a nie drugiej? Zwykle używamy atrybutów dla małych elementów, takich jak daty lub wartości logiczne czyli generalnie typy wartości. Asocjacji natomiast używamy dla bardziej znaczących klas, takich jak klienci lub zamówienia. Wybór w większym stopniu zależy od chęci wyróżnienia czegoś, niż od jakiegokolwiek ukrytego znaczenia. 9

10 Implementacja asocjacji Asocjacje można zaimplementować na wiele sposobów, z reguły poprzez wprowadzenie dodatkowych atrybutów (pól). Mogą one być następujące: obiekty powiązanej klasy wskaźniki (referencje) do obiektów powiązanej klasy identyfikatory obiektów powiązanej klasy klucze kandydujące obiektów powiązanej klasy W zależności od przyjętego sposobu oraz od liczności związków (1:1, 1:n, n:1, m:n) możliwe są bardzo różne deklaracje w przyjętym języku programowania. W języku C++ można zastosować te same implementacje co dla atrybutów zaprezentowane na slajdzie 5. Projektowanie systemów informatycznych, wykład

11 Implementacja atrybutów (1) Niestety, nie ma jednego sposobu interpretowania atrybutów w kodzie programu. Najczęstszą reprezentacją cechy jest pole lub właściwość w danym języku programowania. Poniżej pokazano implementacje przykładowej klasy w różnych językach: Dane osobowe -Imię -Nazwisko -Adres C typedef struct { char Imię[30]; char Nazwisko[30]; TAdres Adres; } TypDaneOsobowe; C++ class DaneOsobowe{ char Imię[30]; char Nazwisko[30]; char Adres[200]; }; Java public class DaneOsobowe{ private String Imię; private String Nazwisko; private String Adres; }; Projektowanie systemów informatycznych, wykład 2 11 Warto zwrócić uwagę na to, że atrybutowi zwykle odpowiadają publiczne właściwości w języku, który obsługuje właściwości, natomiast w języku, który ich nie obsługuje prywatne pola klasy. 11

12 C# class DaneOsobowe{ private string imie; private string nazwisko; private string adres; Implementacja atrybutów (2) public string Imie{ //właściwość Imie get { return imie;} //zwraca wartość set {imie = value;} //nadaje wartość }//koniec definicji właściwości Imie public string Adres{ //właściwość Adres get { return adres;} //zwraca wartość set { adres = value;} //nadaje wartość }//koniec definicji właściwości Adres };//Koniec definicji klasy DaneOsobowe class Program{ public static void Main(){ DaneOsobowe Kolega = new DaneOsobowe() Kolega.Nazwisko = Nowak ; Kolega.Imie = Jan ; Kolega.Adres = ul. Zielona 5 Łódź ; public string Nazwisko{//właściwość Nazwisko Console.WriteLine(Kolega.Nazwisko + get { return nazwisko;} //zwraca wartość Kolega.Imie + Kolega.Wiek); set { nazwisko = value;} //nadaje wartość }//Koniec funkcji Main }//koniec definicji właściwości Nazwisko }; //Koniec definicji klasy Program Projektowanie systemów informatycznych, wykład 2 12 W C# właściwości są naturalnym rozszerzeniem pól w klasach. Często nazywane są inteligentnymi polami. Zwykle w klasie definiujemy pola prywatne i metody set i get (tzw. akcesory) które realizują dostęp do danych. Język C# udostępnia wbudowany mechanizm nazwany właściwości w celu pośredniego dostępu do danych klasy. Właściwości są definiowane za pomocą słowa kluczowego property. Generalna forma definiowania właściwości jest następująca: <modyfikator_zakresu> <zwracana_wartość> <nazwa_właściwości> { get{instrukcje} set{instrukcje} } Gdzie: <modyfikator_zakresu> może być private, public, protected lub internal <zwracana_wartość> reprezentuje dowolny typ C#. <nazwa_właściwości> nazwa właściwości definiowana przez programistę. W przykładzie na slajdzie została zdefiniowana klasa DaneOsobowe, która posiada trzy prywatne parametry: imie, nazwisko, wiek. Parametry te są prywatne stąd nie mamy do nich dostępu spoza klasy DaneOsobowe. Mamy jednak trzy właściwości za pomocą których możemy modyfikować i odczytywać te parametry. Przykładowo w funkcji Main linia druga (Kolega.Nazwisko= Nowak ) uruchamia akcesor set właściwości Nazwisko. Natomiast odwołanie Kolega.Imie w funkcji WriteLine uruchamia akcesor get właściwości Imie. Należy dodać, że akcesor set ma predefiniowaną zmienną value, która reprezentuje przypisywaną wartość przekazaną do akcesora. Ponadto, warto zwrócić uwagę na to, że mogą być własność tylko do odczytu które to zawierają tylko akcesor get. Właściwości tylko do zapisu posiadają tylko akcesor set. Należy pamiętać o tym, że własności nie przechowują danych one określają tylko miejsce ich przechowywania. Stanowią tylko interface dostępu do danych, które są zdefiniowane w innym miejscu klasy. Takie rozpisywanie się na temat właściwości w C# może Państwa dziwić ponieważ nie jest to główny temat wykładu. Przyznaje, że może trochę za dużo napisałem na ten temat jednak jest to unikatowy mechanizm spotykany jedynie w C# a ten slajd z pewnością przyda się jedynie tym, którzy zdecydują się na przygotowanie diagramów klas przy założeniu implementacji programu w języku C#. 12

13 Implementacja atrybutów (3) W języku nie obsługującym właściwości na ogół do pól klasy uzyskuje się dostęp za pomocą specjalnych metod nadających i pobierających wartości. Atrybut tylko do odczytu nie będzie mieć metody nadającej wartość (w wypadku klas) ani takiej akcji (w wypadku właściwości). Przykładowy kod w języku C++ zaprezentowano poniżej: class PozycjaZamowienia{ private: const char Imie[20]; const char Nazwisko[20]; int Wiek; public: Osoba(char* Imie, char* Nazwisko, int Wiek) //Konstruktor {strcpy(this.imie, Imie); strcpy(this.nazwisko, Nazwisko); this.wiek=wiek;} char* pobierzimie() { return Imie;} char* pobierznazwisko() {return Nazwisko; } int pobierzwiek() {return Wiek; } void ustawwiek(int Wiek) {this.wiek = Wiek;} }; Projektowanie systemów informatycznych, wykład 2 13 Ze względu na ograniczenia rozmiaru slajdu niektóre instrukcje w powyższym kodzie zostały zapisane w jednej linii. W sytuacji gdy nie mamy takiego ograniczenia instrukcje powinny być zapisywane w osobnych liniach a klamry otwierająca { i zamykająca } tego samego poziomu w tej samej kolumnie. Klamry poziomów zagnieżdżonych powinny mieć większe wcięcia itd.. 13

14 Implementacja atrybutów (4) Jeśli atrybut jest wielowartościowy, to dane przez niego reprezentowane są kolekcją. A zatem klasa Zamówienie (patrz slajd 8) byłaby kolekcją obiektów Pozycja zamówienia. Ponieważ krotność ta jest uporządkowana, to i kolekcja Zamówienie musi być zbiorem uporządkowanym. Wielowartościowe cechy wymagają innego typu interfejsu niż cechy jednowartościowe (np. w Javie): class Zamowienie { private Zbior pozycjezamowienia = new ZbiorUporzadkowany(); public Zbior pobierzpozycjezamowienia() { return Kolekcje.ZbiorNiemodyfikowalny(pozycjeZamowienia); } public void dodajpozycjezamowienia (PozycjaZamowienia arg) { pozycjezamowienia.dodaj (arg); } public void usunpozycjezamowienia (PozycjaZamowienia arg) { pozycjezamowienia.usun(arg); } Projektowanie systemów informatycznych, wykład 2 14 W większości wypadków cechom wielowartościowym nie nadaje się wartości za pomocą operatora przypisania, lecz używa się w tym celu metod dodających i usuwających wartości. Kontrola nad cechą pozycjezamowienia wymaga, aby w zamówieniu można było sprawdzić przynależność do tej kolekcji. W efekcie nie powinno być możliwe uzyskiwanie bezpośredniego dostępu do samej kolekcji. W tym wypadku użyto zabezpieczenia tej kolekcji w postaci zewnętrznego interfejsu tylko do odczytu. Można też utworzyć nie aktualizowany iterator lub utworzyć kopię. Można zezwolić klientom na modyfikowanie obiektów składowych, ale nie powinni oni móc bezpośrednio zmieniać samej kolekcji. Jeśli w kolekcji nie ma ustalonego porządku, to aby zachować ścisłość, nie powinna ona mieć znaczącej kolejności i powinna być zaimplementowana jako zwykły zbiór. Jednak zwykle implementuje się nieuporządkowane atrybuty jako listy. Jeżeli potrafimy określić liczbę elementów kolekcji wtedy warto użyć tablicy o stałym rozmiarze (zwykle działają szybciej niż struktury danych o zmiennym rozmiarze). Ponieważ wielowartościowe atrybuty implikują stosowanie kolekcji, zwykle nie umieszcza się klas kolekcji na diagramie klas. Przedstawia się je jedynie na diagramach implementacji bardzo niskiego poziomu. Przykłady te uwydatniają fakt, że nie ma jednoznacznej zależności między UML-em a kodem, chociaż istnieje pewne podobieństwo. Jednak konwencje przyjęte przez zespół projektantów pomogą zbliżyć się do uzyskania takiej zależności. Niezależnie od tego, czy cecha jest zaimplementowana jako pole, czy jako wartość obliczana, reprezentuje ona coś, co obiekt może zawsze podać. Nie należy używać cechy do modelowania przechodniej relacji, takiej jak przekazanie obiektu jako parametr podczas wykonania metody, używanego tylko w obrębie tej interakcji. 14

15 Implementacja asocjacji dwukierunkowych Osoba 0 1 właściciel * Samochód class Samochod { Osoba wlasciciel; public: Void UstawWlasciciela(Osoba w){ for(vector<samochod>::iterator it = wlasciciel.samochody.begin(); it < wlasciciel.samochody.end(); it++) if(&(*it)==this) wlasciciel.samochody.erase(it); wlasciciel=w; wlasciciel.samochody.push_back(this) } Osoba PodajWlasciciel {return wlasciciel;}; void DodajSamochod() {wlasciciel.dodajsamochod(this);} }; Class Osoba { vector<samochod> samochody; public: void DodajSamochod(samochod s) {s.ustawwlasciciela(this));} vector<samochod> PobierzSamochody(void) {return samochody;} friend class samochod; }; Projektowanie systemów informatycznych, wykład 2 15 Asocjacja dwukierunkowa jest to para połączonych ze sobą cech będących swoimi odwrotnościami. Klasa Samochód ma cechę właściciel:osoba[l], a klasa Osoba ma cechę samochody:samochód[*]. Implementacja dwukierunkowej asocjacji jest dość skomplikowana na slajdzie zaprezentowano przykład w języku C++ implementacji dwukierunkowej asocjacji miedzy klasami Osoba i Samochod. W takiej sytuacji zwykle wybieramy klasę implementującą właściwość pojedynczej krotności jako nadrzędną, która zarządza asocjacją. W naszym przykładzie jest to klasa Samochod. Do zarządzania asocjacją służą funkcje publiczne UstawWlasciciela, PodajWlasciciela oraz DodajSamochod. W takiej sytuacji klasa Osoba musi zrezygnować z kapsułkowania parametru samochody na rzecz klasy Samochod. W języku C++ można to zaimplementować poprzez deklarację przyjaźni klasy Samochod z klasą Osoba (friend class samochod). 15

16 Operacje w IP (1) Reprezentacja operacji klasy w IP polega na uszczegółowieniu perspektywy poprzez podanie nagłówków metod oraz ich parametrów zgodnie ze pełną specyfikacją UML: specyfikator-dostępu nazwa (lista-parametrów): wyrażenie-typu-wyniku {opis-cechy} specyfikator-dostępu może być publiczny (+), prywatny (-) jak na slajdzie 5 nazwa to napis alfanumeryczny; lista-parametrów zawiera ciąg parametrów dla operacji; wyrażenie-typu-wyniku to typ zwracanej wartości, jeśli taka istnieje; opis-cechy zawiera wartości pewnych własności dla danej operacji. Projektowanie systemów informatycznych, wykład 2 16 UML definiuje kwerendę (ang. query) jako operację, która pobiera wartość z klasy, nie zmieniając jej stanu innymi słowy nie powoduje efektów ubocznych. Można taką operację opatrzyć ograniczeniem {query}. Operacje, które zmieniają stan klasy określane są terminem modyfikatory. Nazywa się je też poleceniami. Ściśle rzec biorąc, nazwanie operacji kwerendą lub modyfikatorem zależy od tego, czy operacja ta zmienia wynik stanu obserwowalnego. Stan obserwowalny oznacza to, co jest widoczne z zewnątrz. Operacja aktualizująca pamięć podręczną zmieniłaby stan wewnętrzny, ale nie miałaby wpływu widocznego z zewnątrz. Należy zwracać szczególną uwagę na kwerendy, ponieważ można zmienić porządek ich wykonania bez zmiany zachowania się systemu. Dość często spotykaną konwencją jest pisanie operacji tak, aby modyfikatory nie zwracały wartości. Wówczas można uznać, że wszystkie operacje zwracające wartość są kwerendami. Meyer nazywa to Zasadą rozdzielania poleceń od kwerend 16

17 Operacje w IP (2) Lista Parametrów Parametry na liście parametrów są zapisywane w podobny sposób, jak dla atrybutów. Mają one następującą postać: kierunek nazwa: typ = wartość-domyślna Nazwa, typ i wartość-domyślna zachowują się tak, jak w atrybutach. Kierunek oznacza, czy parametr jest parametrem wejściowym (in), wyjściowym (out), czy zarówno wejściowym, jak i wyjściowym. Jeśli nie podano kierunku, to zakłada się, że parametr jest wejściowy. Przykładową operacją na koncie może być: +saldozdnia (data: Data) : Waluta Projektowanie systemów informatycznych, wykład

18 Operacje w IP (3) Pozostałe kwestie dotyczące uszczegółowienia charakterystyki operacji w IP: Określenie (np. dla języka C++), które z metod będą realizowane jako funkcje wirtualne (późno wiązane) a które jako zwyczajne funkcje (wiązane statyczne). Zastąpienie niektórych prostych metod bezpośrednim dostępem do atrybutów. Np. metody PobierzNazwisko, UstawNazwisko, etc. Projektowanie systemów informatycznych, wykład

19 Uogólnienie W perspektywie IP najczęstszą interpretacją uogólnienia jest dziedziczenie Klient instytucjonalny jest klasą pochodną klasy Klient. W najważniejszych językach obiektowych klasa pochodna dziedziczy wszystkie własności klasy podstawowej i może przedefiniować dowolną metodę tej klasy. Inną techniką realizacji uogólnienia jest np. wykorzystanie interfejsów, które pozwalają utworzyć relację uogólnienia/uszczegółowienia pomiędzy typami (dziedziczenie interfejsu) lub klasą i interfejsem (implementacja interfejsu). Projektowanie systemów informatycznych, wykład 2 19 Uogólnienie jest przedmiotem różnych interpretacji na różnych poziomach modelowania. W modelu pojęciowym można powiedzieć, że Klient instytucjonalny jest typem pochodnym Klienta, jeżeli wszystkie instancje Klienta instytucjonalnego są z definicji, również instancjami Klienta. Klient instytucjonalny jest wówczas specyficznym typem Klienta. Jest ważne, że wszystko, co możemy powiedzieć o Kliencie asocjacje, atrybuty, operacje jest również prawdziwe w stosunku do Klienta instytucjonalnego. Jeszcze inny sposób myślenia jest oparty na zasadzie podstawiania. Powinna być możliwa zamiana klienta na klienta instytucjonalnego w każdym fragmencie kodu, który wymaga klienta, i wszystko powinno dalej działać bez problemu. W istocie znaczy to tylko tyle, że jeśli koduje się dla klienta, to można potem dowolnie stosować jakikolwiek jego typ pochodny. klient instytucjonalny może reagować na niektóre polecenia inaczej niż inny klient (w wyniku zastosowania polimorfizmu), ale obiekt wywołujący nie powinien się kłopotać tą różnicą. Chociaż dziedziczenie jest mechanizmem o bardzo dużych możliwościach, to dodaje ono dużo dodatkowego obciążenia, które nie zawsze jest konieczne do uzyskania podstawiania. Dobrym przykładem jest sytuacja, która miała miejsce na początku istnienia Javy, kiedy to wielu użytkownikom nie podobała się implementacja wbudowanej klasy Vector i oczekiwali, że zostanie ona zastąpiona czymś nieco mniej skomplikowanym. Jedynym sposobem, na który mogli utworzyć klasę zastępczą dla wektora było utworzenie klasy pochodnej, a to oznaczało dziedziczenie wielu niechcianych danych i metod. Do uzyskania klasy zastępczej można użyć innych mechanizmów, które nie pociągają za sobą dużego obciążenia (Więcej informacji w [5], patrz wykład 1, slajd 4). Wiele osób lubi stosować rozróżnienie między tworzeniem podtypu, czyli dziedziczeniem interfejsu, a tworzeniem podklasy, czyli dziedziczeniem implementacji. Klasa jest podtypem, jeśli może zastąpić swój typ nadrzędny, niezależnie od tego, czy stosuje dziedziczenie, czy nie. Tworzenie podklasy jest synonimem zwykłego dziedziczenia. 19

20 Zależności Między dwoma elementami istnieje zależność, jeśli zmiany definicji jednego elementu mogą spowodować zmiany drugiego. W wypadku klas zależności istnieją z wielu powodów jedna klasa wysyła komunikat do drugiej; jedna klasa zawiera drugą jako część swoich danych; jedna klasa wymienia drugą jako parametr operacji. Jeśli interfejs klasy ulega zmianie, to komunikat przez nią wysłany nie musi być poprawny. klient Okno korzyści Pracownik dostawca Bramka danych pracownika Zależność Bramka danych korzyści Projektowanie systemów informatycznych, wykład 2 20 Kolejna kwestia dotycząca uszczegółowiania diagramów klas dotyczy specyfikacji zależności. Wraz z rozrostem systemów komputerowych należy coraz więcej uwagi poświęcać zależnościom. Jeśli wymkną się one spod kontroli, to każda zmiana w systemie może mieć na niego duży wpływ i zmuszać do wprowadzania kolejnych modyfikacji. Im większy błąd, tym trudniej będzie cokolwiek zmienić. UML pozwala na uwidocznienie zależności między wszystkimi rodzajami elementów. Zależności używa się zawsze wtedy, gdy trzeba pokazać, jak zmiany w jednym elemencie mogą wpłynąć na inne elementy. Na slajdzie zaprezentowano rysunek gdzie pokazane są pewne zależności, które można by było spotkać w wielowarstwowej aplikacji. Klasa Okno korzyści (interfejs użytkownika lub inaczej klasa prezentacji) jest zależna od klasy Pracownik głównego obiektu, który przechwytuje najważniejsze zachowania systemu, w tym wypadku zdarzenia zachodzące w firmie. Oznacza to, że jeśli klasa Pracownik zmieni swój interfejs, to być może trzeba będzie też zmienić klasę Okno korzyści. Ważne w tej sytuacji jest to, że zależność jest jednokierunkowa i przechodzi od klasy prezentacji do klasy głównej. Dzięki temu wiadomo, że można swobodnie modyfikować klasę Okno korzyści i zmiany te nie będą miały żadnego wpływu na obiekty klasy Pracownik lub inne obiekty główne. Ścisłe rozdzielenie logiki prezentacji od głównej logiki systemu, gdy prezentacja zależy od części głównej, ale nie na odwrót, jest bardzo korzystną regułą i warto ją stosować. Drugą rzeczą godną uwagi na slajdzie jest to, że nie istnieje bezpośrednia zależność między klasą Okno korzyści a dwiema klasami Bramek danych. Jeśli zmienią się te klasy, to może zajść potrzeba zmodyfikowania klasy Pracownik. Jeśli jednak zmiana dotyczy tylko implementacji klasy Pracownik, a nie jej interfejsu, to na tym zmiany się kończą. 20

21 Typy zależności w UML Słowo kluczowe «call» «create» «derive» «instantiate» Opis Klasa źródłowa wywołuje czynność w klasie docelowej. Klasa źródłowa tworzy instancję klasy docelowej. Klasa źródłowa jest pochodną klasy docelowej. Klasa źródłowa jest instancją klasy docelowej. (Zauważmy, że w takim wypadku klasa źródłowa jest instancją klasy, co oznacza, że klasa docelowa jest metaklasą.) «permit» «realize» «reflne» «substitute» «trace» «use» Klasa docelowa zezwala klasie źródłowej na uzyskiwanie dostępu do swoich prywatnych składowych. Klasa źródłowa jest implementacją specyfikacji lub interfejsu zdefiniowanego przez klasę docelową Oznacza relację między różnymi poziomami semantycznymi. Na przykład klasa źródłowa mogłaby być klasą projektu, a klasa docelowa odpowiadającą jej klasą analizy. Klasa źródłowa jest substytutem dla klasy docelowej. Używane do śledzenia takich elementów, jak wymogi dotyczące klas lub tego, jak zmiany w jednym modelu łączą się ze zmianami gdzie indziej. Oznacza, że do zaimplementowania klasy źródłowej jest wymagana klasa docelowa. Projektowanie systemów informatycznych, wykład 2 21 Zwykle zależność opisujemy dodatkowym słowem kluczowym aby dodać więcej szczegółów. W UML-u jest wiele rodzajów zależności i każda ma swoją własną semantykę i słowa kluczowe. Z punktu widzenia PI ważne jest aby ustalić jak będą implementowane zależności wykorzystane na diagramie klas. 21

22 Agregacja, zawieranie (1) Agregacja reprezentuje relację typu całość-część, w której część może należeć do kilku całości, a całość nie zarządza czasem istnienia części. Zawieranie (kompozycja) jest relacją typu całość-część, w której całość jest wyłącznym właścicielem części, tworzy je i zarządza nimi. Ogród -Szerokość -Długość Roślina -Gatunek PlanWzrostu Projektowanie systemów informatycznych, wykład 2 22 Agregacja jest silniejszą formą asocjacji. W przypadku tej relacji równowaga między powiązanymi klasami jest zaburzona: istnieje właściciel i obiekt podrzędny, które są ze sobą powiązane czasem swojego życia. Właściciel jednak nie jest wyłącznym właścicielem obiektu podrzędnego, zwykle też nie tworzy i nie usuwa go. Relacja agregacji jest zaznaczana linią łączącą klasy/obiekty, zakończoną białym rombem po stronie właściciela. Zawieranie jest najsilniejszą relacją łączącą klasy. Reprezentuje relacje całość-część, w których części są tworzone i zarządzane przez obiekt reprezentujący całość. Ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są bardzo ściśle ze sobą związane i pokrywają się: w momencie usunięcia obiektu całości obiekty części są również usuwane. Typowa fraza związana z taką relacją to "...jest częścią...". Zawieranie jest przedstawiane na diagramie podobnie jak agregacja, przy czym romb jest wypełniony. Zgodnie z definicją agregacji ogród zawiera różne rośliny ale rośliny w ogrodzie mogą być wymieniane. Nawet usunięcie ogrodu nie musi oznaczać usunięcia roślin, które mogą być przesadzone. Stąd czas życia obiektów klasy Roślina i obiektu Ogród nie są zależne. Miedzy klasami Ogród i PlanWzrostu występuje relacja zawieranie co oznacza, że obiekt klasy PlanWzrostu jest częścią klasy Ogród a ich czasy życia są ściśle ze sobą powiązane. Tworzenie obiektu Ogród pociąga za sobą tworzenie obiektu PlanWzrostu. Podobnie kasowanie obiektu Ogród pociąga za sobą kasowanie obiektu PlanWzrostu zawartego w kasowanym ogrodzie. 22

23 Implementacja agregacji i zawierania class Ogrod { public: Ogrod(); virtual ~Ogrod(); protected: Roslina* KopiaRoslin[100]; PlanWzrostu Plan; }; Projektowanie systemów informatycznych, wykład 2 23 Relacja agregacji w języku C++ zwykle jest reprezentowana poprzez wskaźnik (w C# lub Java referencję) do obiektu lub zbioru obiektów klasy podrzędnej. W niniejszym przykładzie jest to tablica wskaźników do obiektów klasy Roslina. Obiekty zawarte w tablicy KopiaRoslin nie muszą być tworzone lub kasowane wraz z obiektem klasy Ogrod. Relacja zawierania w języku C++ zwykle jest reprezentowana przez umieszczenie wartości obiektu klasy podrzędnej w klasie nadrzędnej. W naszym przykładzie obiekt Plan jest tworzony i kasowany wraz z powiązanym obiektem klasy Ogrod. Dzieje się tak dlatego, że obiekt Plan jest atrybutem klasy Ogrod. Stąd jest tworzony w momencie tworzenia obiektu klasy Ogrod i kasowany w momencie kasowania obiektu klasy Ogrod. 23

24 klasy abstrakcyjne i interfejsy (1) Klasa abstrakcyjna jest to klasa, dla której nie można bezpośrednio utworzyć instancji (język C++). Zamiast niej tworzy się instancję podklasy. Klasa abstrakcyjna ma co najmniej jedną operację abstrakcyjną. Operacja abstrakcyjna nie ma implementacji, jest to czysta deklaracja, która umożliwia dowiązanie się klientów do klasy abstrakcyjnej. Najczęstszym sposobem wskazania w UML-u abstrakcyjnej klasy lub operacji jest zapisanie jej nazwy kursywą. W ten sposób można też oznaczać abstrakcyjne cechy lub metody dostępowe. Kursywa czasem jest myląca przy pisaniu na tablicy, więc można zamiast niej użyć etykiety {abstract}. Interfejs jest klasą, która nie ma implementacji. To znaczy, że wszystkie cechy interfejsu są abstrakcyjne. Pojęcie interfejsu odpowiada ściśle definicji interfejsu w językach C# oraz Java, a także w innych typach języków. Interfejs oznacza się słowem kluczowym «interface». Projektowanie systemów informatycznych, wykład 2 24 Celem tworzenia klas abstrakcyjnych i interfejsów jest identyfikacja wspólnych zachowań różnych klas, które są realizowane w różny od siebie sposób. Użycie tych mechanizmów pozwala na wykorzystanie relacji uogólniania do ukrywania (hermetyzacji) szczegółów implementacji poszczególnych klas. Klasa abstrakcyjna reprezentuje wirtualny byt grupujący wspólną funkcjonalność kilku klas. Posiada ona sygnatury operacji (czyli deklaracje, że klasy tego typu będą akceptować takie komunikaty), ale nie definiuje ich implementacji. Podobną rolę pełni interfejs. Różnica polega na tym, że klasa abstrakcyjna może posiadać implementacje niektórych operacji, natomiast interfejs jest czysto abstrakcyjny (choć, oczywiście interfejs i klasa w pełni abstrakcyjna są pojęciowo niemal identyczne). Ponieważ klasy abstrakcyjne nie mogą bezpośrednio tworzyć swoich instancji (podobnie jak interfejsy, które z definicji nie reprezentują klas, a jedynie ich typy) dlatego konieczne jest tworzenie ich podklas, które zaimplementują odziedziczone abstrakcyjne metody. W przypadku interfejsu sytuacja jest identyczna. Między klasą a interfejsem mogą istnieć dwa rodzaje relacji: zapewnianie i żądanie. Klasa zapewnia interfejs, jeśli może być substytutem tego interfejsu. W językach Java i.net klasa może w tym celu zaimplementować interfejs lub podtyp interfejsu. W języku C++ tworzy się podklasę klasy będącej interfejsem. Klasa żąda interfejsu, jeśli do jej funkcjonowania jest potrzebna instancja tego interfejsu. W szczególności oznacza to, że na interfejs jest nałożona zależność. 24

25 Przykład wykorzystania interfejsów <<interface>> Kolekcja RównaSię Dodaj Klasa abstrakcyjna <<interface>> Lista Zamówienie PozycjeZamówienia[*] Zależność Wymaga interfejsu (Wymaga. Int. Lista) Pobierz Zależność Zapewnia interfejs (implementuje) (Zapewnia Int. Lista) ListaAbstrakcyjna RównaSię Pobierz Dodaj ListaTablicowa metoda abstrakcyjna przeciążenie Pobierz Dodaj Projektowanie systemów informatycznych, wykład 2 25 Na rysunku zaprezentowano przykład wykorzystania interfejsów i klas abstrakcyjnych. Można napisać klasę Zamówienie tak, aby zawierała listę pozycji zamówienia. Ponieważ używana jest lista, to klasa Zamówienie jest zależna od interfejsu Lista. Przypuśćmy, że używa ona metodę równasię, dodaj i pobierz. W Klasie Zamówienie parametr PozycjeZamówienia jest referencją do typu Lista. Jednak do tego parametru zostanie wpisana referencja do instancji klasy ListaTablicowa. Przypominam, że takie przypisanie jest możliwe ponieważ referencja do klasy pochodnej w C++,C# i Java może być niejawnie konwertowana do referencji do klasy podstawowej. Ponieważ ListaTablicowa jest pochodną od ListyAbstrakcyjnej, która z kolei jest implementacją interfejsu to ListaTablicowa jest pochodną interfejsu Lista. Sama klasa ListaTablicowa będąca pochodną klasy ListaAbstrakcyjna, implementuje niektóre, lecz nie wszystkie, funkcje klasy Lista. W szczególności metoda Pobierz jest abstrakcyjna. Z tego względu ListaTablicowa musi zaimplementować funkcję Pobierz, ale może też przeciążyć inne operacje klasy ListaAbstrakcyjna. W tym wypadku przeciąża metodę Dodaj, natomiast dziedziczy implementację metody RównaSię. Dlaczego nie mielibyśmy uniknąć tych interfejsów i po prostu sprawić, aby klasa Zamówienie użyła ListyTablicowej bezpośrednio? Użycie interfejsu daje bardzo pożądaną możliwość łatwej zmiany implementacji, gdyby w przyszłości zaszła taka potrzeba. Nowa implementacja mogłaby poprawić wydajność, zapewnić jakieś funkcje obsługi bazy danych i inne korzyści. Programując interfejs a nie implementację, unikamy konieczności zmiany całego kodu w wypadku wystąpienia potrzeby użycia innej implementacji klasy Lista. Zawsze należy starać się programować w ten sposób, dbając o możliwie największą elastyczność rozwiązania. Chciałbym też zwrócić uwagę na pewne pragmatyczne rozwiązanie stosowane w tego typu sytuacjach. Gdy programiści używają kolekcji w sposób pokazany na rysunku zwykle inicjalizują kolekcję deklaracją następującej postaci: private Lista pozycjezamowienia = new ListaTablicowa(); //Java Zauważmy, że to prowadzi do powstania zależności z Zamówienia do konkretnej ListyTablicowej. Teoretycznie jest to problem, ale mało kto przejmuje się nim w praktyce. Ze względu na to, że typ pozycjezamówienia jest zadeklarowany jako Lista, żadna inna część klasy Zamówienie nie zależy od klasy ListaTablicowa. Gdyby zaszła konieczność zmiany implementacji, to powinniśmy się martwić tylko o ten jeden wiersz kodu inicjalizującego. Czy nie jest to genialne? Wprowadzenie do programu nowej klasy Listy np. ListaJednokierunkowa wymaga zmiany tylko jednej linii kodu. Jest dosyć często spotykaną praktyką odwoływanie się do konkretnej klasy podczas tworzenia obiektu, a następnie używanie tylko interfejsu. 25

26 Klasyfikacja Klasyfikacja określa związek między obiektem a jego typem (klasą). Obiekt może należeć jednocześnie do wielu typów. Klasyfikacja obiektu określa, z którymi typami (klasami) jest powiązany poprzez dziedziczenie, interfejsy etc. Ogólne Specjalizowane {disjoint,complette} Wydawnictwo {overlapping,incomplete} {overlapping} obiekt może należeć do kilku klas {disjoint} obiekt może należeć tylko do jednej klasy {complete} nie istnieje więcej podklas {incomplete} mogą powstać kolejne podklasy Książka Czasopismo Projektowanie systemów informatycznych, wykład 2 26 Klasyfikacja obiektu reprezentuje (w odróżnieniu od relacji uogólnienia/uszczegółowienia) związek pomiędzy obiektami a klasami. Klasyfikacja obiektu określa, z którymi typami (klasami) jest powiązany poprzez dziedziczenie, interfejsy etc. Ponieważ obiekt może jednocześnie uczestniczyć w wielu niezależnych klasyfikacjach (a zatem posiadać wiele typów, niekoniecznie poprzez dziedziczenie), dlatego do szczegółowego określenia klasyfikacji stosowane są uściślające słowa kluczowe: {overlapping} oznacza, że obiekt może jednocześnie należeć do kilku klas/posiadać wiele typów. Na przykład Wydawnictwo, mimo że posiada dwie podklasy: Książka Czasopismo, może wystąpić w postaci łączącej obie te cechy. Przeciwieństwem jest słowo kluczowe {disjoint}, które narzuca rozłączność typów danych. {complete} oznacza, że wymienione dotychczas podklasy w ramach jednej specjalizacji są wyczerpujące i nie istnieje kategoria, która znalazłaby się poza nimi. W przykładzie Wydawnictwo może być Ogólne lub Specjalizowane, i nie przewiduje się istnienia nowej podklasy. {Incomplete} przewiduje taką możliwość. 26

27 Klasy asocjacyjne Klasy asocjacyjne są związane z relacją asocjacji i opisują jej właściwości. Mają dostęp do obiektów uczestniczących w relacji Na rysunku widać, że Osoba może uczestniczyć w wielu spotkaniach. Dodatkowo jest potrzebne przechowywanie informacji o tym, jak uważna na danym spotkaniu była konkretna osoba. Możemy w tym celu dodać do asocjacji atrybut aktywność". Osoba 2..* * Spotkanie Obecność aktywność Klasa asocjacyjna Projektowanie systemów informatycznych, wykład 2 27 Klasy asocjacyjne są reprezentowane graficznie jako klasy połączone linią przerywaną z relacją asocjacji, której dotyczą. 27

28 Samoistne klasy asocjacyjne a) Osoba Obecność 1 2..* aktywność * 1 Spotkanie b) Firma * * Kontrakt Rola opis c) Osoba * * Umiejętności Kwalifikacje poziom Projektowanie systemów informatycznych, wykład 2 28 Rysunek a) pokazuje jeszcze jeden sposób reprezentacji tej informacji uczynienie z klasy Obecność samoistnej klasy. Należy zwrócić uwagę na krotności zapisane przy asocjacjach. Jaka jest korzyść wynikająca z istnienia klas asocjacyjnych? Klasa asocjacyjna wnosi dodatkowe ograniczenie - może istnieć tylko jedna instancja klasy asocjacyjnej między dowolnymi dwoma obiektami połączonymi asocjacją. Samoistna klasa asocjacyjna nie wprowadza tego ograniczenia. Na rysunku b) i c) przedstawiono dwa diagramy. Są one bardzo podobne. Można sobie jednak wyobrazić sytuację, w której jedna Firma odgrywa różne role w tym samym Kontrakcie, ale trudniej uznać, że pewna Osoba ma kilka poziomów Kwalifikacji dla tej samej Umiejętności. W UML-u rysunek b) jest niepoprawny. Diagram z rysunku b) nie pozwala, aby Firma miała więcej niż jedną Rolę w tym samym Kontrakcie. Ponieważ domyślnie przyjmuje się tutaj krotność 1 dla instancji klasy Rola w klasach Firma i Kontrakt. Jeśli jest potrzebna taka możliwość, to klasa Rola musi być samoistną klasą w stylu tej z rysunku a). Rysunek c) jest poprawny ponieważ dla każdej kombinacji Osoby i Umiejętności może istnieć tylko jeden poziom Kwalifikacji. 28

29 Implementacja klas asocjacyjnych Implementowanie klas asocjacyjnych nie jest oczywiste. Eksperci radzą, aby implementować klasy asocjacyjne tak, jakby były one samoistnymi klasami, ale zapewnić klasom połączonym przez klasę asocjacyjną metody pobierające informacje. Na przykład dla rysunku ze slajdu 26 należy utworzyć następujące metody dla klasy Osoba: class Osoba List pobierzaktywnosc() List pobierzspotkania() Projektowanie systemów informatycznych, wykład 2 29 Dzięki implementacji zaprezentowanej na slajdzie klient klasy Osoba może uzyskać informacje na temat osób obecnych na spotkaniu. Jeśli klasy potrzebują dalszych szczegółów, to informacje na temat Obecności mogą już uzyskać same. W wypadku zastosowania takiego rozwiązania należy pamiętać o narzuceniu ograniczenia, że może istnieć tylko jeden obiekt Obecność dla każdej pary Osoba-Spotkanie. Należy rejestrować każde utworzenie obiektu Obecność przez którąkolwiek z metod. W perspektywie IP należy ustalić w jaki sposób klasy asocjacyjne będą implementowane oraz w jaki sposób będzie realizowane ograniczenie istnienia jednego obiektu klasy asocjacyjnej dla każdej pary klas powiązanych tą asocjacją. 29

30 Szablony klas Kilka języków, a w szczególności C++, zawiera pojęcie klasy parametryzowalnej czyli szablonu klasy (ang. template). Szablony wprowadzono również w języku Java pod nazwą typów generycznych. Pojęcie to w oczywisty sposób najbardziej przydaje się przy pracy ze zbiorami w językach z pełnym sprawdzaniem typów. W ten sposób, definiując szablon klasy Zbiór, można zdefiniować ogólne zachowanie zbiorów. class Zbiór <T> { void wstaw(t nowyelement); void usuń(t element); W ten sposób można, korzystając z ogólnej definicji, tworzyć klasy zbiorcze bardziej konkretnych elementów. Zbiór <Pracownik> zbiórpracowników; Projektowanie systemów informatycznych, wykład 2 30 Jeśli mamy klasę parametryzowaną Zbiór<T> to parametrem tej klasy jest T. Jeżeli za parametr T wstawimy nazwę klasy np. LiczbaZespolona to będziemy mieli nowa klasę Zbiór<LiczbaZespolona>, która reprezentuje zbiór liczb zespolonych. Każde wstawienie nowej nazwy klasy za parametr T powoduje utworzenie nowej klasy. Stąd nazwy klas generowanych przez klasę parametryzowaną nie składają się tylko z nazwy klasy parametryzowanej ale równie z z nazwy parametru w nawiasach. Przykłady pełnych nazw takich klas są następujące: Zbiór<LiczbaZespolona> - zbiór liczb zespolonych Zbiór<int> - zbiór liczb całkowitych Wykorzystanie szablonów klas jest bardzo pożądane. Szablon klas umożliwia automatyczną generację klas dla różnych wartości parametrów. Bez szablonu, klasy te musiałyby być definiowane ręcznie. Aby klasa była wygenerowana automatycznie na podstawie szablonu wystarczy wydać odpowiednie polecenie np.: Zbiór<int> TablicaInt generuje klasę Zbior<int> i definiuje nowy obiekt tej klasy o nazwie TablicaInt. Podobnie Zbiór<LiczbaZespolona> TablicaZesp generuje klasę Zbiór<LiczbaZespolona> i definiuje nowy obiekt TablicaZesp. Nowa klasa parametryzowana generowana jest przez kompilator przy pierwszej definicji obiektu tej klasy w programie. 30

31 Szablony klas w UML a) b) Szablon Ustaw(T) Usuń(T) Zbiór Zbiór<T::Pracownik> T Parametr szablonu c) Zbiór T Ustaw(T) Usuń(T) <<bind>> ZbiórPracowników <T::Pracownik> Projektowanie systemów informatycznych, wykład 2 31 W UML-u szablon deklaruje się za pomocą notacji przedstawionej na rysunku a). T na rysunku zastępuje parametr typu. (Może być ich kilka.) Użycie szablonu, takie jak na przykład Zbiór<Pracownik>, jest nazywane elementem związanym. Element związany można przedstawić na dwa sposoby. Pierwszy jest odbiciem składni C++ (zobacz rysunek b)). Wyrażenie z elementami związanymi zapisuje się w nawiasach ostrych w następujący sposób: <nazwa-parametru::wartośćparametru>. Jeśli jest tylko jeden parametr, to według konwencji często pomija się jego nazwę. Notacja alternatywna, zaprezentowana na rysunku c) akcentuje związek z szablonem i umożliwia zmianę elementu związanego. Słowo kluczowe «bind» (ang. wiązanie) jest stereotypem relacji uszczegółowiania. Na rysunku c) klasa Zbiór może przechowywać obiekty pewnego typu. Typ ten może stać się parametrem tej klasy: w ten sposób utworzono szablon zbioru dla potencjalnie dowolnego typu. Klasa stanowiąca ukonkretnienie szablonu (ZbiórPracowników) została sparametryzowana (związana) typem Pracownik, dzięki czemu może być już wykorzystana do tworzenia obiektów. Inaczej mówiąc relacja ta wskazuje, że ZbiórPracowników będzie zgodny z interfejsem Zbioru. W terminach poziomu specyfikacji ZbiórPracowników jest typem pochodnym Zbioru. Jest to inny sposób definiowania zbiorów dla elementów konkretnych typów zamiast deklaracji wszystkich koniecznych podtypów. Element związany to jednak nie to samo, co typ pochodny. Nie wolno uzupełniać elementu związanego całkowicie określonego przez jego szablon o dodatkowe elementy. Można dodawać tylko informacje ograniczające. Jeśli trzeba dodać dodatkowe elementy, to należy utworzyć typ pochodny. 31

32 Wyliczenia Wyliczenia, (zobacz poniższy rysunek) są stosowane do pokazywania stałego zbioru wartości, mniemających żadnych cech poza ich symbolicznymi wartościami. Są one zapisywane jako klasa ze słowem kluczowym «enumeration». <<enumeration>> Kolor czerwony zielony niebieski Projektowanie systemów informatycznych, wykład

33 Klasa aktywna W perspektywie implementacyjnej należy wyspecyfikować na diagramach klasy aktywne. Klasa aktywna ma instancje, z których każda wykonuje i kontroluje swój własny wątek sterujący. Wywołania metod mogą być realizowane w wątku klienta lub w wątku obiektu klasy aktywnej. Dobrym przykładem jest tutaj procesor poleceń, który przyjmuje obiekty poleceń z zewnątrz, a następnie wykonuje polecenia w obrębie swojego własnego wątku sterującego. W UML-u 2.0 klasa aktywna ma dodatkowe pionowe linie z boku. Procesor poleceń Projektowanie systemów informatycznych, wykład

34 Podsumowanie Na niemniejszym wykładzie zaprezentowano elementy diagramu klas istotne z punktu widzenia PI. Pojawiło się również szereg przykładów implementacji tych elementów w różnych językach programowania ponieważ w PI trzeba podjąć decyzje o konwencjach implementacji tych elementów pod warunkiem, że nie jest to oczywiste. Przykładowo implementacja klasy abstrakcyjnej w C++ jest trywialna ponieważ ten termin w UML definiowany jest tak samo. Konwencja dotycząca implementacji asocjacji z wielokrotną krotnością już nie jest oczywista. Dziękuję za uwagę. Projektowanie systemów informatycznych, wykład