1 / 36

Projektowanie systemów informacyjnych

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

dinah
Download Presentation

Projektowanie systemów informacyjnych

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

  8. Przykłady list wartości etykietowanych: {autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza} można skrócić do {abstrakcyjna = TRUE} {abstrakcyjna} 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. 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.

  9. 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 jestzbiorem 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:

  10. Numer: 1234321 Stan konta: 34567 Właściciel: Jan Kowalski Upoważniony: .... Wypłać Wpłać Porównaj podpis Sprawdź stan Numer: integer Stan konta: integer Właściciel: string Upoważniony:.... .... Nalicz procent Zlikwiduj konto Numer: 1234567 Stan konta: 454545 Właściciel: Adam Nowak Upoważniony: .... Podaj osoby upoważnione Upoważnij 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 import inwariantów

  11. Okno Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() Oznaczenia klas (1) Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości. 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

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

  13. 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) Oznaczenia klas (3) Stereotypy mogą być użyte dla oznaczenia grupy elementów.

  14. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor 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). specjalizacja generalizacja

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

  16. OSOBA NAZWISKO ROK_UR Wiek() STUDENT NR_INDEKSU WYDZIAŁ WstawOcenę(...) ZaliczSemestr() Struktury generalizacji-specjalizacji (3) GRAFIKA ROZMIAR Wyświetl(...) JPEG GIF 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.

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

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

  19. Wieloaspektowe generalizacje-specjalizacje Pojazd napęd teren teren napęd {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

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

  21. Niektóre metody zawarte w ramach klasy odnoszą się do jej wystąpień: pracownik.wiek pracownik.zwolnij KONTO.Oblicz_procent 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 ekstensji: KL_pracownik.nowy KL_pracownik.zlicz KL_KONTO.Oblicz_sumę Klasa może mieć nie jedną lecz wiele ekstensji.

  22. Pracownik już-zarobił-w-tym-roku oblicz wypłatę {abstrakcyjna} Pracownik godzinowy stawka godzinowa stawka świąteczna oblicz wypłatę Pracownik etatowy zarobek tygodniowy oblicz wypłatę Pracownik na zlecenie zarobek miesięczny oblicz wypłatę 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. Specyfikacja metody oblicz wypłatęznajduje się w klasie abstrakcyjnej Pracownik. Każda klasa konkretna zawiera właściwą dla siebie implementację tej metody.

  23. Klasy abstrakcyjne, klasy konkretne Klasa abstrakcyjnanie 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 konkretnamoż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

  24. K1 A,K K2 K3 A,K K K4 K5 K K 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.

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

  26. Interfejsy, zależności, uszczegółowienia zależność <<interfejs>> 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.

  27. IPracownik Firma Pracownik Osoba Interfejsy, zależności, uszczegółowienia (cd.) Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. 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.

  28. Pracuje_dla 1..* Firma Osoba 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ą. 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.

  29. Liczność asocjacji 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,... 2,3,4,... 3,4,5 2,4,18 1 0,1 0,1,2,... 0,1,2,... 1 1..* 2..* 3-5 2,4,18 0..1 0..* * 1 * Firma Pracownik 0..* 0..1 Osoba Adres

  30. PozycjaZamówienia ilość cena czyZrealizowana 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. * * 1 Produkt

  31. 1..* Firma Pracownik 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

  32. Jest_członkiem * * Osoba Komitet * Jest_przewodniczącym 1 * Pracownik 0..1 szef Oznaczanie asocjacji (cd.) 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. 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.

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

  34. Firma nazwa adres Osoba nazwisko pesel adres Pracuje_w 1..* 0..1 Zatrudnienie zarobek stanowisko Pracuje_w Firma nazwa adres Osoba nazwisko pesel adres zarobek stanowisko 0..1 1..* Kiedy stosować atrybuty asocjacji 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. Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów.

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

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

More Related