Projektowanie systemów informacyjnych

K.Subieta, E. Stemposz. Projektowanie systemów informacyjnych, Wykład 3, Folia 1

Projektowanie systemów informacyjnych

Kazimierz Subieta, Ewa Stemposz

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wprowadzenie do obiektowości, cz. 2

Wykład 3


Zagadnienia

Krótka charakterystyka UMLMechanizmy rozszerzalności: stereotypy i wartości etykietowaneKlasyMetody jako przykład inwariantów klasyStruktury generalizacji-specjalizacjiBezpośrednie i pośrednie wystąpienia klasyEkstensja klasyKlasa konkretna a klasa abstrakcyjnaRozszerzenia i ograniczenia w podklasieInterfejsy, zależności, uszczegółowieniaAsocjacje


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

OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywadostatecznie 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.

Wady i zalety metodyk, których autorami są twórcy UML:

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, rozproszeniei komponenty, przystosowanie notacji do preferencji projektantów i inne. Celem UML jestprzykrycie również tych aspektów.


Diagramy definiowane w UML

Diagramy przypadków użycia (use case)Diagramy klas, w tym diagramy pakietówDiagramy 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.


Stereotypy (cd.)

Przykłady stereotypów:

P1 P2<<używa>>

P3 P4<<rozszerza>>

<<aktor>>

Klient Klientjest 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

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.

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.

Najważniejsze inwarianty to:

Możliwe są inne inwarianty:

Zdarzenia lub wyjątki, które mogą zachodzić w operacjach na obiekcieObsługa zdarzeń lub wyjątków (reguły aktywne)Lista eksportowa określająca, co jest dostępne z zewnątrzOgraniczenia, którym może podlegać obiekt klasy......

Nazwa, czyli językowy identyfikator klasy obiektuTyp, czyli struktura (budowa) obiektu - poprzez atrybuty Metody, czyli operacje, które można wykonać na obiekcie

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.

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.


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 jednymmiejscu, w klasie.

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 jednymmiejscu, w klasie.

Numer: 1234321Stan konta: 34567Właściciel: Jan KowalskiUpoważniony:....

WypłaćWpłać

Sprawdźstan

Upoważnij

Podaj osobyupoważnione

Porównajpodpis

Zlikwidujkonto

Nalicz procent

Numer: integerStan konta: integerWłaściciel: stringUpoważniony:........

Numer: 1234567Stan konta: 454545 Właściciel: Adam NowakUpoważniony:....

Klasa wszystkich kont Obiekty KONTO

importinwariantów


Oznaczenia klas (1)Trzy pola: nazwy, atrybutów i metod. Możliwe są różne poziomy szczegółowości.

Okno Oknorozmiarczy_widoczne

Oknorozmiarczy_widocznewyświetl()schowaj()

Oknorozmiar: Obszarczy_widoczne: Booleanwyświetl()schowaj()

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:

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.

+ publiczna - prywatna # chroniona


Oznaczenia klas (3)

Okno{abstrakcyjna,

autor=Kowalskistatus=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: Punktpunkt2: Punkt

«konstruktor»Prostokąt(p1: Punkt, p2: Punkt)

«zapytania»obszar(): Realaspekt(): 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).

spec

jali

zacj

a

gene

rali

zacj

a

Pracownik

Osoba

Asystent

Adiunkt

Profesor

Docent

Asystent

Adiunkt

Profesor

Docent

Pracownik

Osoba



K1 K2

K3

Struktura typu pętlajest zabroniona

PracownikStudent

Osoba

Student_asystent

Struktura typu kratajest dopuszczalna



OSOBANAZWISKO

ROK_URWiek()

PRACOWNIKZAROBEK

DZIAŁFOTO

ZarobekNetto()ZmieńZarobek(...)

STUDENTNR_INDEKSU

WYDZIAŁWstawOcenę(...)ZaliczSemestr()

JPEG GIF

GRAFIKAROZMIARWyświetl(...)

Atrybut PRACOWNIKaFOTO należy do własnejklasy. Generalnie, strukturaklas może być semantycznie bardziej złożona niż hierarchia.

Atrybut PRACOWNIKaFOTO należy do własnejklasy. Generalnie, strukturaklas może być semantycznie bardziej złożona niż hierarchia.



Pompa

ciśnienie ssaniaciśnienie tłoczeniaprzepływ

Wymiennik ciepła

powierzchnia wymianyśrednica rury

Zbiornik

objętośćciśnienie

typ wyposażenia

typ pompytyp zbiornika

aspekt generalizacji(dyskryminator)

Wyposażenie

nazwawytwórcakoszt

Dyskryminator jest atrybutem opcjonalnym



Wyposażenie

nazwawytwórcakosztciśnienie ssaniaciśnienie tłoczeniaprzepływpowierzchnia wymianyśrednica ruryobjętośćciśnienietyp wyposażenia

Pompa

ciśnienie ssaniaciśnienie tłoczeniaprzepływ

Wymiennik ciepła

powierzchnia wymianyśrednica rury

Zbiornik

objętośćciśnienie

typ wyposażenia

Wyposażenie

nazwawytwórcakoszt


Wieloaspektowe generalizacje-specjalizacje

Pojazd

{overlapping}

Pojazd wiatrowy

Pojazdsilnikowy

Pojazdlądowy

Pojazdwodny

napędnapęd terenteren

{overlapping}

Drzewo

Dąb Brzoza Sosna

{disjoint, incomplete}gatunek drzewa

disjont - rozłączny (domyślne)overlapping - pokrywające sięcomplete - zupełny (domyślne)incomplete - niezupełny


Bezpośrednie i pośrednie wystąpienia klasy

Wystąpienie klasy (instancja klasy) oznacza obiekt, który jest “podłączony” do danejklasy, 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.

nazwa_obiektu : nazwa_klasynazwa_atrybutu = wart_atrybutu...

:nazwa_klasynazwa_atrybutu = wart_atrybutu...

nazwa_obiektu : nazwa_klasy : nazwa_klasy

W zależności od poziomu szczegółowości możliwe są następujące oznaczenia obiektu:


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ń: 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: 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 bytuabstrakcyjnego za pomocą wartości etykietowanej abstrakcyjna = TRUE (TRUE można opuścić) lub napisanie nazwy bytu italikami.

Pracownikjuż-zarobił-w-tym-roku

oblicz wypłatę {abstrakcyjna}

Pracownik godzinowystawka godzinowastawka świątecznaoblicz wypłatę

Pracownik etatowyzarobek tygodniowyoblicz wypłatę

Pracownik na zleceniezarobek miesięcznyoblicz wypłatę

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łączniejako 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żeposiadać operacji abstrakcyjnych.

Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłączniejako 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żeposiadać operacji abstrakcyjnych.

Osoba prawna

Osoba fizyczna Firma

Sekwencja

pierwszynastępny

Sekwencja int

... implementacje

Sekwencja char

...implementacje

Klasyczne klasyfikacjew biologii: tylko liście w drzewie klas mogąbyć klasami konkretnymi.


Klasy abstrakcyjne, klasy konkretne (cd.)

A - klasa abstrakcyjna

K - klasa konkretna

K1

K2 K3

K4 K5

K

A,K

A,K

KK

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}

Pracownik

IPracownik<<interfejs>>

Firma

zależność

uszczegółowienie

Uszczegółowienie (refinement), o notacji z premedytacją podobnej do generalizacji, oznaczazgodnie 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.


AsocjacjeOznaczenia 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 OsobaPracuje_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

Liczność jest oznaczana na końcach asocjacji binarnych, tzn. takich, które łączą dwie lubjedną klasę.

11,2,3,...2,3,4,...3,4,52,4,1810,10,1,2,...0,1,2,...

11..*2..*3-52,4,18

0..10..**

UML znaczeniePaństwo Stolica

Firma Pracownik

Osoba Adres

1 *

0..* 0..1


Asocjacje skierowaneZamówieniedataZłożeniaczyZapłacone

sumaDoZapłatyrealizuj()zamknij()

Klientnazwisko

adreswiarygodność()

* 1

Produkt* 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ówieniailośćcena

czyZrealizowana


Role asocjacji, oznaczanie asocjacjiAsocjacje mogą być także wyposażone w nazwy ról (przy odpowiednich końcach),

np. pracodawca i pracownik.

Firma OsobaPracuje_dla

* 1..*pracodawca pracownik

szef

podwładny*

0..1

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 Pracownik1..*


Oznaczanie asocjacji (cd.)

Osoba Komitet

Jest_członkiem* *

Jest_przewodniczącym1 *

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ększeniaich 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ępuDostęp

Dostępny dla

{ dostęp oznacza: czytanie lubczytanie-pisanie}

*

*

Osoba

nazwiskopeseladres

Firma

nazwaadres

Zatrudnieniezarobekstanowisko

szef

pracownik

Pracuje_w

Ocena wydajnościocena

Kieruje

0..1

*

0..11..*


Kiedy stosować atrybuty asocjacji

Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów.

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

nazwiskopeseladres

Firma

nazwaadres

Pracuje_w

Zatrudnieniezarobekstanowisko

0..11..*

Osoba

nazwiskopeseladreszarobekstanowisko

Firma

nazwaadres

Pracuje_w

0..11..*


Atrybuty i asocjacje pochodneCecha 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 /.

Osobadata_urodzenia/wiek

{wiek = data_bieżąca - data_urodzenia}

Wydział Sekcja Pracownik

Budynek

zatrudnia

zlokalizowana_w

pracuje_w

* *

**

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.

atrybut pochodny: /wiek


Przykładowy diagram klas

poprzedza

następuje_po

zawiera

jest_składową

zapisany_na

prowadzony_dla

prowadzony_przez

prowadzi

PracownikStudent

Osoba

Kurs

Profesor

Wykład

1..*

*

1..* 1..*

*

*

Documents

Projektowanie systemów informacyjnych