Projektowanie i programowanie aplikacji biznesowych dodatek z zakresu analizy i projektowania systemów informatycznych (wybrane zagadnienia)

Transkrypt

1 Projektowanie i programowanie aplikacji biznesowych dodatek z zakresu analizy i projektowania systemów informatycznych (wybrane zagadnienia) Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1

2 Zagadnienia Czynniki jakości oprogramowania Kryzys oprogramowania Zadania inżynierii oprogramowania Model przypadków użycia Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 2

3 Jakość oprogramowania - czynniki Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów. Łatwość użycia jest miarą stopnia łatwości korzystania z oprogramowania. Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania. Ponowne użycie charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych. Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji. Efektywność opisuje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania. Przenaszalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe. Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 3

4 Źródła złożoności oprogramowania Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Oprogramowanie Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, itd. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 4

5 Kohezja i skojarzenia Kohezja (cohesion) oznacza zwartość, spoistość. Terminu tego używa się np. w odniesieniu do komponentu oprogramowania (klasy, modułu, itp.) na oznaczenie wzajemnego zintegrowania jego elementów składowych. Duża kohezja oznacza silną interakcję wewnątrz i relatywnie słabszą interakcję z zewnętrzem. Komponenty powinna cechować duża kohezja, co oznacza, że komponent stanowi dobrą, intuicyjną abstrakcję czegoś, czyli posiada precyzyjnie określoną semantykę, jest dobrze wyizolowany z kontekstu (maksymalnie od niego niezależny) oraz posiada dobrze zdefiniowany interface. Skojarzenie (coupling) określa stopień powiązania między komponentami, np. dla klas: jak często obiekty jednej klasy występują razem z obiektami innych klas, jak często obiekty jednej klasy wysyłają komunikaty do obiektów innej klasy, itp. Możliwe są skojarzenia silne, słabe czy w ogóle brak skojarzenia. Duża liczba silnych skojarzeń miedzy elementami składowymi (high coupling) jest tym, czego powinno się unikać. Analiza stopnia kohezji i wzajemnych skojarzeń stanowi podstawę do konstruowania architektury systemu, czyli wyróżniania elementów składowych systemu, określania ich wzajemnych interakcji oraz sposobów przesyłania między nimi danych. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 5

6 Zadania inżynierii oprogramowania Zadania stojące przed inżynierią oprogramowania w walce z narastającą złożonością oprogramowania: Redukcja złożoności oprogramowania. Propagowanie wykorzystywania technik i narzędzi ułatwiających pracę nad złożonymi systemami. Upowszechnianie metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń. Usystematyzowanie procesu wytwarzania oprogramowania, tak aby ułatwić jego planowanie i monitorowanie. Wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 6

7 Modele wg Jacobsona Model przypadków użycia: definiuje zewnętrze (aktorów = systemy zewnętrzne = kontekst) oraz wnętrze (przypadki użycia), określające zachowanie się systemu w interakcji z jego zewnętrzem. Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (czyli dziedziny problemowej) w obiekty istniejące w systemie. Obiektowy model analityczny: efekt fazy analizy dla konkretnego zastosowania. Model projektowy (logiczny): opisuje założenia przyszłej implementacji. Model implementacyjny (fizyczny): reprezentuje konkretną implementację systemu. Model testowania: określa plan testów, specyfikuje dane testowe i raporty. Modele wymagają odpowiednich procesów ich tworzenia Proces analizy wymagań, składa się z dwóch podprocesów: - proces modelowania przypadków użycia - Proces analizy związany z obiektowym modelem analitycznym Proces projektowania Proces implementacji Proces testowania Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 7

8 Model analityczny Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu Przyczyny: - Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować. - Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie. Dostępne środki mogą nie pozwolić na realizację systemu w całości. Celem budowy modelu analitycznego może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne. Dziedzina problemu Model analityczny Zakres odpowiedzialności systemu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 8

9 Model wymagań Składowe: - Model przypadków użycia - Obiektowy model analityczny Model przypadków użycia wykorzystuje dwa podstawowe pojęcia: Aktor Reprezentuje rolę, którą może odgrawać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) Przypadek użycia Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora w procesie interakcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 9

10 Notacja wypłata pieniędzy klient weryfikacja klienta «include» System obsługi klienta wnętrze systemu Przypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność ( wypłata pieniędzy ) czy polecenie ( wypłać pieniądze ) - zdania są podzielone. Aktor: Powinien mieć unikalną nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem. Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia. Relacja typu «include» lub «extend»: Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 10

11 Aktor - konkretny byt czy rola? Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, czyli określenia przyszłych użytkowników systemu. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor strażnik budynku. Aktor jest tu pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą danych wyprodukowanych przez przypadki użycia. Sprawca zdarzeń? Czy np. klient, nie posiadający bezpośredniego dostępu do funkcji systemu jest tu aktorem? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 11

12 Analiza aktorów Wyjaśnienie różnic pomiedzy konkretnymi użytkownikami a aktorami Użytkownik Aktor Przypadek użycia Może grać rolę zleca Jan Kowalski Administrator systemu Przeładowanie systemu Adam Malina Gość Konkretny klient Pracownik Osoba informowana Klient Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 12

13 Przykład diagramu przypadków użycia? wpłata pieniędzy klient wypłata pieniędzy Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy - zdania są podzielone. W operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujący nasz model. wpłata pieniędzy klient wypłata pieniędzy kasjer Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 13

14 Przykład diagramu przypadków użycia Automat do sprzedaży papierosów uzupełnienie towaru klient zakup paczki papierosów operacja pieniężna operator wnętrze systemu sporządzenie raportu otoczenie systemu granica systemu kontroler Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 14

15 Zależności między przypadkami użycia Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu «include» czy «extend». p1 jest tu przypadkiem bazowym i zawsze występuje jako pierwsze w kolejności działania. p1 «include» p2 Przebieg podstawowy (sekwencyjny): p1 zawsze włącza (używa) p2. p1 «extend» p2 Przebieg opcjonalny (alternatywny): p1 jest czasami rozszerzane o p2 (inaczej: p2 czasami rozszerza p1). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 15

16 Automat do operacji bankowych Relacja: «include» podsystem zarządzania bazą danych banku prowadzenie konta klienta «include» klient informowanie o stanie konta klienta inicjalizacja karty klienta «include» «include» weryfikacja karty i kodu klienta administrator systemu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 16

17 Relacje: «include» i «extend» rejestracja klienta «include» «include» «include» sprzedaż samochodu «include»: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony przed nawias ); wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane) przegląd samochodu umycie samochodu «extend» «extend» naprawa samochodu «extend» przyholowanie samochodu «extend»: strzałka prowadzi od przypadku użycia, który czasami rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane) Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 17

18 Rozbudowa modelu przypadków użycia wpłata pieniędzy wpłata pieniędzy kasjer wypłata pieniędzy kasjer «include» wypłata pieniędzy «extend» «include» klient banku sprawdź stan konta klient banku sprawdź stan konta uaktualnianie stanu konta weź pożyczkę zarząd banku weź pożyczkę zarząd banku Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy nimi. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 18

19 Diagram interakcji dla przypadku użycia Przesyłanie komunikatów pomiędzy blokami: Aktor Blok 1 Blok 2 Blok 3 Blok 4 czas k1 k2 k3 k4 k5 Blok i - obiekt k i - komunikat, czyli polecenie wykonania operacji; komunikat nosi nazwę tej operacji Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 19

20 Przykład diagramu interakcji wpłata pieniędzy scenariusz Wypełnij formularz wpłaty Podaj formularz i gotówkę do kasy Zwiększ konto klienta Zwiększ bilans kasy Zwiększ bilans banku Wydaj pokwitowanie dla klienta :Klient :Formularz :Kasa :Konto :Bank wypełnij podaj formularz zwiększ zwiększ bilans zwiększ bilans wydaj pokwitowanie Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 20

21 Stopień szczegółowości diagramów Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na system - spojrzenia z pozycji aktorów, którzy go używają. Nie włącza zbyt wielu szczegółów, co pozwala wnioskować o fukcjonalności systemu na odpowiednio wysokim poziomie. Podstawowym (choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi użytkownikami zmierzający do sformułowania poprawnych wymagań na system. Model zbyt szczegółowy - utrudnia analizę, zbyt ogólny - nie pozwala na wykrycie bloków ponownego użycia. edycja programu «include» kompilacja programu «include» Tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Zazwyczaj różni analitycy tworzą różne modele. wykonanie programu programista drukowanie pliku użytkownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 21

22 Kolejne kroki w konstrukcji modelu Konstrukcja modelu przypadków użycia opiera się na kilku krokach i wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika. Jednocześnie powinien być budowany model obiektowy. Krok: Udokumentowany w: Sporządzenie słownika pojęć Określenie aktorów Określenie przypadków użycia Słownik pojęć Dokument opisu aktorów 4 Tworzenie opisu każdego przypadku użycia plus: podział na nazwane części znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia + dokument opisu przypadków użycia Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 22

23 Sporządzanie słownika pojęć Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć. Słownik dotyczy dziedziny problemowej. Tworzenie go polega na wyłowieniu wszystkich terminów z wymagań użytkownika. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp. Terminy w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Posługiwanie się terminami ze słownika powinny być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu. Przykład: Konto - pojedyncze konto w banku, w stosunku do którego wykonywane są bieżące transakcje. Konta mogą być różnych typów, a w szczególności: konta indywidualne, małżeńskie, firmowe i inne. Każdy klient może posiadać więcej niż jedno konto. Na co należy zwrócić uwagę przy kwalifikowaniu terminów do słownika: - na rzeczowniki - mogą one oznaczać aktorów lub byty z dziedziny problemowej - na frazy opisujące funkcje, akcje, zachowanie się - mogą one być podstawą wyróżnienia przypadków użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 23

24 Określanie aktorów Przy określaniu aktorów istotne są odpowiedzi na następujące pytania: Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu (np. osoba wysyłająca korespondencję)? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje (np. administrator systemu)? Z jakich elementów zewnętrznych (innych systemów, komputerów, czujników, sieci, itp.) musi korzystać system, aby realizować swoje funkcje. Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem granic systemu, tj. odrzucaniem obszarów dziedziny problemowej, którymi system nie będzie się zajmować (zakres odpowiedzialności systemu). Po wyszukaniu aktorów, należy ustalić: Nazwę dla każdego aktora/roli, Zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami (np. sekretarka pracownik administracji pracownik dowolna osoba). Niekiedy warto ustalić hierarchię dziedziczenia dostępu do funkcji systemu dla aktorów. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 24

25 Struktury dziedziczenia dla aktorów osoba pracownik gość księgowa pracownik administracji Np. pracownik administracji dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego pracownika oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 25

26 Określanie przypadków użycia Dla każdego aktora, znajdź funkcje (zadania), które powinien wykonywać w zwiazku z jego działalnością w zakresie zarówno dziedziny przedmiotowej, jak i wspomagania działalności systemu informacyjnego. Staraj się powiązać w jeden przypadek użycia zespół funkcji realizujących podobne cele. Unikaj rozbicia jednego przypadku użycia na zbyt wiele pod-przypadków. Nazwy dla przypadków użycia: powinny być krótkie, ale jednoznacznie określające charakter zadania lub funkcji. Nazwy powinny odzwierciedlać czynności z punktu widzenia aktorów, a nie systemu, np. wpłacanie pieniędzy, a nie przyjęcie pieniędzy od klienta. Opisz przypadki użycia przy pomocy zdań w języku naturalnym, używając terminów ze słownika. Uporządkuj aktorów i przypadki użycia w postaci diagramu. Niektóre z powstałych w ten sposób przypadków użycia mogą być mutacjami lub szczególnymi przypadkami innych przypadków użycia. Przeanalizuj powiązania aktorów z przypadkami użycia i ustal, które z nich są zbędne lub mogą być uogólnione. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 26

27 Określanie przypadków użycia Nazwij te przypadki bazowe. Ustal powiązania przypadków bazowych z innymi przypadkami, poprzez ustalenie ich wzajemnej zależności: sekwencji czy alternatywy. Dodaj zachowania skrajne, wyjątkowe, uzupełniające lub opcjonalne. Ustal powiązanie przypadków bazowych z tego rodzaju zachowaniem. Może ono byc także powiązane w pewną strukturę. Wyodrębnij przypadki bazowe, czyli te, które stanowią istotę zadań, są normalnym, standardowym użyciem. Pomiń czynności skrajne, wyjątkowe, uzupełniające lub opcyjne. Staraj się, aby bloki specyfikowane wewnątrz każdego przypadku użycia nie były zbyt ogólne lub zbyt szczegółowe. Zbyt szczegółowe bloki utrudniają analizę. Zbyt ogólne bloki zmniejszają możliwość wykrycia bloków ponownego użycia. Struktura nie może być zbyt duża i złożona. Staraj się wyizolować bloki ponownego użycia. Przeanalizuj podobieństwo nazw przypadków użycia, podobieństwo nazw i zachowania bloków ponownego użycia występujących w ich specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane z określeniem bardziej ogólnej funkcji lub dodaniu nowej specjalizacji do istniejącej funkcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 27

28 Dokumentowanie przypadków użycia Dokumentacja przypadków użycia powinna zawierać: 1. Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje zachodzące między przypadkami. 2. Krótki, ogólny opis każdego przypadku użycia: - jak i kiedy przypadek użycia zaczyna się i kończy, - opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane, - kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie oraz jak i kiedy zapamiętuje dane w systemie, - wyjątki występujące przy obsłudze przypadku, - specjalne wymagania, np. czas odpowiedzi, wydajność, - jak i kiedy używane są pojęcia dziedziny problemowej. 3. Opis szczegółowy każdego przypadku użycia: - scenariusz(e), - specyfikację uczestniczących obiektów, - diagram(y) interakcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 28

29 Zadania modelu przypadków użycia Główne zadanie modelu przypadków użycia to prawidłowe określenie wymagań funkcjonalnych na projektowany system. Prawidłowe określenie funkcjonalności systemu uznawane jest za jeden z podstawowych problemów w procesie konstrukcji. Model przypadków użycia pozwala na: - lepsze zrozumienie możliwych sposobów wykorzystania projektowanego systemu (przypadków użycia), co oznacza zwiększenie stopnia świadomości analityków i projektantów co do celów systemu, czyli innymi słowy jego funkcjonalności, - umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu, - ustalenie praw dostępu do zasobów, - zrozumienie strukturalnych własności systemu, a przez to ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu, - dostarczenie podstawy do sporządzenia planu testów systemu, - weryfikację poprawności i kompletności projektu. Przypadki użycia odwzorowywują strukturę systemu tak, jak ją widzą jego użytkownicy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 29

30 Przypadki użycia w analizie Eksperci Doświadczenie w dziedzinie przedmiotowej Model dziedziny Model analizy Przypadki użycia Model zastosowania Użytkownicy mocny wpływ słaby wpływ Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 30

31 Wprowadzenie do obiektowości Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 31

32 Geneza obiektowości Obiektowość jest nową ideologią, która wynika z zaobserwowanych wad istniejącego świata i podaje jakąś receptę, jak te wady usunąć, a więc przede wszystkim stara się o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a myśleniem o danych i procesach, które zachodzą na danych. Mentalna percepcja świata rzeczywistego Model pojęciowy Schemat struktury danych W modelu relacyjnym model pojęciowy stara się odwzorować świat rzeczywisty, lecz jest ograniczony dostępną bazą implementacyjną. W rezultacie, schemat struktury danych gubi semantykę danych. Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 32

33 Źródła obiektowości Języki programowania operujące na złożonych strukturach danych, wprowadzające klasy, metody, dziedziczenie i hermetyzację (Simula 67, Smalltalk). Skierowanie uwagi na czynniki ludzkie w tworzeniu oprogramowania. Metodyki projektowania oprogramowania, od początku bazujące na wyróżnianiu obiektów i ich klas w otaczającej nas rzeczywistości. Współczesne źródła obiektowości Bazy danych, od początku bazujące na obiektach (IMS, CODASYL). Krytyka wad relacyjnego modelu baz danych. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 33

34 Obszary oddziaływania obiektowości Metodyki analizy i projektowania SI (Rumbaugh, Booch, Jacobson, Yourdon,...) i oparte o nie narzędzia CASE. Najbardziej istotna zmiana w stosunku do metodyk wykorzystujących model encja-związek to możliwość związania z obiektami operacji, które można na nich wykonywać. Języki programowania (Smalltalk, C++, Java, Eiffel,...) Klasy, dziedziczenie, hermetyzacja, metody, późne wiązanie. Bazy danych i składy trwałych obiektów (standard ODMG- 2.0, ObjectStore, O2, Poet, Versant,...) Przeniesienie obiektowych technologii programowania na grunt baz danych. Współdziałanie systemów heterogenicznych (OMG CORBA,OLE/DCOM/ActiveX) Obiekty i klasy jako podstawa wymiany informacji pomiędzy systemami. Wizyjne środowiska programistyczne (Smalltalk, CA OpenRoad, IBM VisualAge itp.) Przeniesienie technik obiektowych do programowania wizyjnego. Inne: biblioteki oprogramowania, grafika, miary i oceny oprogramowania, reinżynieria biznesu (BPR) Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 34

35 Obiektowe języki programowania Smalltalk Jezyk zrobiony w latach w Xerox Palo Alto Research Center w Kalifornii. Zawiera klasy, podklasy, wirtualne funkcje, przesyłanie komunikatów, meta-klasy. Wszystko jest obiektem, a w szczególności liczby i klasy. Istotą sukcesu Smalltalk a jest to, że nie jest on tylko językiem, ale także mocnym zintegrowanym środowiskiem programistycznym z doskonałym interfejsem okienkowym. Prostota, możliwość szybkich dynamicznych zmian, elastyczna natura Smalltalk a uczyniła go doskonałym narzędziem do szybkiego tworzenia prototypów. Mniej są znane przemysłowe aplikacje na dużą skalę. C++ Język hybrydowy, pochodna języka C. Łączy własności C niskiego poziomu, takie jak arytmetyka wskaźników, z konstrukcjami wysokiego poziomu, takimi jak klasy, podklasy, hermetyzacja, funkcje wirtualne. (Eklektyczna natura C++ jest przedmiotem krytyki.) Duże zastosowania na skalę przemysłową. Jednocześnie, jest on krytykowany z powodu wolnego tworzenia aplikacji, zawodności, słabej przenaszalności, dużego ryzyka wadliwego działania programów. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 35

36 Obiektowe języki programowania Java Mieszanina C++, Smalltalk a i Objective-C, z obcięciem własności niskiego poziomu. Język pomyślany jako narzędzie do programowania stron Webu (ale oczywiście, jest to tylko jedno z zastosowań). Istotną własnością Java jest to, że programy kompiluje się nie do poziomu kodu maszynowego, a do poziomu znakowego języka pośredniego, czyli. tzw. apletów (applets), które są następnie interpretowane. Daje to efekt dużej przenaszalności programów oraz zwiększenia bezpieczeństwa (security), co jest szczególnie istotne w środowiskach rozproszonych, takich jak np. Internet. Ponadto mrowie języków: OO-COBOL Eiffel Ada95 CLOS Beta Object Pascal Trellis-Owl Modula-3 Agora Sather Objective-C Self Python Actor DSM Sina Theta Dylan LENS Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 36

37 Podstawowe zasady obiektowości Obiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej rzeczywistości. Tożsamość obiektu - wewnętrzny identyfikator, który pozwala na odróżnienie go od innych obieków. Hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić. Klasa - Zgrupowanie obiektów o tych samych charakterystykach. Dziedziczenie - Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe. Polimorfizm - Wybór nazwy dla operacji jest określony wyłącznie semantyką operacji. Decyzja o tym, która metoda implementująca daną operację, zależy od przynależności obiektu do odpowiedniej klasy (mechanizmy pozwalające programiście używać wartości, zmiennych i podprogramów na kilka różnych). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 37

38 Obiekt Byt (rzecz lub pojęcie) obserwowalny w dziedzinie problemowej (czyli w tym fragmencie świata rzeczywistego, którego dotyczy dany system informacyjny), odróżnialny od innych bytów, posiadający dobrze określone granice oraz nazwę jest odwzorowywany na obiekt w implementacji komputerowej. Obiekt może być złożony, tj. może składać się z innych obiektów. Pojęcie obiektu sprzyja lepszemu rozumieniu modelowanego świata rzeczywistego - byty ze świata rzeczywistego odpowiadają obiektom w programie. Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jak zwartą bryłą: usuwać, wyszukiwać, wiązać, kopiować, blokować, indeksować,... Obiekt ma przypisany typ, tj. wyrażenie językowe, które określa jego budowę (poprzez specyfikację atrybutów) oraz ogranicza kontekst, w którym odwołanie do obiektu może być użyte w programie. Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi, odpowiadającymi relacjom zachodzącym między odpowiednimi bytami w dziedzinie problemowej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 38

39 Tożsamość obiektu Obiekt jest wyróżnialny w otaczającym nas świecie poprzez fakt swojego istnienia, a nie przez jakąkolwiek wartość, która odróżnia go od innych obiektów. Może się zdarzyć, że z punktu widzenia naszych obserwacji (tj. stanu obiektu) dwa obiekty są nieodróżnialne. Niemniej jednak są to dwa różne obiekty. W implementacji obiektowej bazy danych system automatycznie nadaje unikalny identyfikator dla każdego obiektu. Mechanizm identyfikatorów pozwala zarówno na rozróżnianie obiektów, jak i umożliwia budowanie do nich referencji. Identyfikator jest atrybutem wewnętrznym obiektu, nie ma żadnego znaczenia dla dziedziny problemowej a programista/użytkownik nigdy nie operuje jego wartością explicite. Identyfikator może być trwały, tj. niezmienny dla całego życia obiektu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 39

40 Własności obiektu Obiekt jest charakteryzowany poprzez: Tożsamość, która odróżnia go od innych obiektów. Tożsamość obiektu jest niezależna zarówno od wartości atrybutów obiektu, jak i od lokacji bytu odwzorowywanego przez obiekt w świecie rzeczywistym czy też lokacji samego obiektu w przestrzeni adresowej komputera. (W praktyce: tożsamość = trwały wewnętrzny identyfikator obiektu) Stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu). Stan obiektu w danym momencie jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami. Obiekt ma przypisane zachowanie, tj. zestaw operacji, które wolno do stosować do danego obiekru. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 40

41 Przykład obiektu Wpłać Wypłać Sprawdź stan Nalicz procent Numer: Stan konta: PLN Właściciel: Jan Kowalski Upoważniony:... Podpis:... Porównaj podpis Zlikwiduj konto Obiekt KONTO Upoważnij Podaj osoby upoważnione Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 41

42 Atrybuty obiektu, obiekty złożone Obiekt może składać się z pewnej liczby komponentów (atrybutów), które także mogą być złożone. Komponenty obiektu mogą być traktowane jako obiekty ( pod-obiekty ) lub mogą być uważane za kategorię różną od danego obiektu. Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt, liczby poziomów hierarchii komponentów lub rozmiarów/typów komponentów. Obiekt złożony reprezentujący pewien byt świata rzeczywistego powinien zawierać wewnątrz siebie wszelkie informacje, które odnoszą się do tego bytu. Ustalenia, które informacje odnoszą się do danego obiektu, a które do innego, zależą od modelu pojęciowego projektanta lub programisty i nie powinny podlegać ograniczeniom ze strony bazy realizacyjnej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 42

43 Przykład obiektu złożonego Pracownicy Pracownik Nazwisko Dzieci Dziecko Dziecko... Zatrudnienia Zatrudnienie Zatrudnienie Pracownik Nazwisko Dzieci Dziecko Dziecko... Zatrudnienia Zatrudnienie Zatrudnienie... Stanowisko... Stanowisko... Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 43

44 Powiązania pomiędzy obiektami Możliwe jest tworzenie bezpośrednich powiązań prowadzących od jednego obiektu do innego. Powiązanie jest daną zawierającą identyfikator obiektu. Unika się tu pojęcia wskaźnika, na rzecz czegoś bardziej abstrakcyjnego - powiązania. FIRMA Nazwa Relax Ltd. Zatrudnia o Zatrudnia o Zatrudnia o Szef o PRACOWNIK Nazwisko Nowak Zarobek 1500 Pracuje_w o Zalety powiązań: naturalne odwzorowanie semantycznych związków istniejących w dziedzinie problemowej między analizowanymi bytami poprzez powiązania między obiektami; łatwe nawigowanie dzięki wyrażeniom ścieżkowym; zwiększenie szybkości działania. Wady: zwiększona sztywność struktury danych; możliwość utraty spójności wskutek zwisających wskaźników; możliwość naruszenia reguł hermetyzacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 44

45 Klasa; dwie niezbyt zgodne definicje 1. Klasa jest nazwanym zbiorem obiektów o podobnych własnościach (podobna semantyka, podobne atrybuty, zachowania, podobne związki z innymi obiektami). Własności te są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze Osoba. 2. Klasa jest miejscem przechowywania tych własności grupy obiektów, które są niezmienne (inwariantne) dla wszystkich członków grupy. Klasa nie jest zbiorem obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus ewentualnie swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus inwarianty własne. Najważniejsze inwarianty to: Możliwe są inne inwarianty: Nazwa, czyli językowy identyfikator klasy obiektu Typ, czyli struktura (budowa) obiektu - poprzez atrybuty Metody, czyli operacje, które można wykonać na obiekcie 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 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 45

46 Metody jako przykład inwariantów klasy Zwykle, mamy do czynienia z wieloma obiektami tej samej klasy, np. z wieloma kontami. Nie celowe jest, aby każdy z takich obiektów przechowywał w sobie własną kopię metod lub informacji o swoim typie (budowie). Ta informacja jest przechowywana w jednym miejscu, w klasie. Klasa wszystkich kont Obiekty KONTO Sprawdź stan Nalicz procent Wpłać Upoważnij Wypłać Numer: integer Stan konta: integer Właściciel: string Upoważniony: Podaj osoby upoważnione Porównaj podpis Zlikwiduj konto import inwariantów Numer: Stan konta: Właściciel: Jan Kowalski Upoważniony:... Numer: Stan konta: Właściciel: Adam Nowak Upoważniony:... Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 46

47 specjalizacja Dziedziczenie generalizacja Generalizacja-specjalizacja jest takim związkiem pomiędzy klasami, który łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej klas (tzw. podklas), będących jej specjalizacjami. Klasa, będąca specjalizacją danej klasy, oprócz własności nadklasy może posiadać (i z reguły posiada) też swoje własności. Związek generalizacji-specjalizacji może być modelowany za pomocą struktur dziedziczenia, co nie jest jedynym możliwym rozwiązaniem. Dziedziczenie inwariantów do klas jest tranzytywne (przechodnie). pole atrybutów Osoba nazwisko data ur. wiek pole nazwy klasy pole metod Pracownik pensja Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 47 Asystent Adiunkt Profesor

48 Hermetyzacja; ukrywanie informacji Hermetyzacja: zgromadzenie elementów struktury i implementacji obiektu w postaci jednej manipulowalnej bryły; oddzielenie specyfikacji obiektu od jego implementacji. Hermetyzacja pośrednio oznacza także ukrycie struktury i implementacji obiektu. Tę własność określa się jako ukrywanie informacji. Hermetyzacja i ukrywanie informacji są różnymi pojęciami, choć mocno powiązanymi. Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o obiekcie programistycznym, ile potrzeba, aby go efektywnie użyć. Wszystko, co może być przed nim ukryte, powinno być ukryte. Hermetyzacja i ukrywanie informacji jest podstawą pojęć: modułu, klasy i ADT. Hermetyzacja ortodoksyjna (Smalltalk) Na zewnątrz są widoczne metody; atrybuty obiektu są ukryte. Ergo: prawie każdy atrybut atr jest obsługiwany przez dwie metody: czytaj_atr, zmień_atr Hermetyzacja ortogonalna (C++) Dowolna własność obiektu (atrybut, metoda,...) może być prywatna (ukryta) lub publiczna Specjalne środki do specyfikowania własności prywatnych i publicznych. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 48

49 Hermetyzacja ortogonalna Patrz Modula-2: dowolna własność może być prywatna, lub może być wyeksportowana do publicznego użytku. PRAC NAZWISKO Nowak ROK_UR 1961 ZAROBEK 2500 DZIAŁ Zabawki ZarobekNetto() ZmieńZarobek(...) Podatek() Wewnętrzna struktura obiektu Wiek() begin return RokBież() - ROK_UR end; PRAC NAZWISKO Nowak ROK_UR 1951 ZAROBEK 2500 DZIAŁ Zabawki ZarobekNetto() ZmieńZarobek(...) Podatek() Wiek() begin return RokBież() Wiek() - ROK_UR end; Zewnętrzna struktura obiektu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 49

50 Operacja a metoda Operacja jest funkcją, która może być zastosowana do obiektu. Operacja jest własnością klasy obiektów, ponieważ jest przechowywana w klasie zatrudnij zwolnij wypłać dewidendę możliwe operacje na obiektach klasy Firma Wszystkie obiekty, będące członkami danej klasy, podlegają tym samym operacjom. Dana operacja może być stosowana do obiektów wielu różnych klas, połączonych związkiem generalizacji-specjalizacji. Metoda jest implementacją operacji w jednej z klas połączonych związkiem generalizacji-specjalizacji, co oznacza, że może być wiele metod implementujących daną operację. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 50

51 Operacja a metoda drukuj Plik ASCII Plik postscript Plik graficzny Jedna operacja drukuj, ale różne sposoby drukowania. Trzy metody implementujące operację drukuj. Plik Plik ASCII Plik postscript Plik graficzny drukuj drukuj drukuj Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 51

52 Komunikat Wpłać Wypłać Wypłać 1000 PLN OK, wypłaciłem Sprawdź stan Nalicz procent Numer: Stan konta: PLN Właściciel: Jan Kowalski Upoważniony:... Podpis: Porównaj podpis Zlikwiduj konto Upoważnij Podaj osoby upoważnione Graj Co proszę...? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 52

53 Komunikat a wołanie funkcji Komunikat: obiekt-adresat poprzedza wywołanie operacji: obiekt.operacja (arg1, arg2,...) - obiekt jest tu domyślnym argumentem metody Wołanie funkcji: obiekt jest komunikowany jako parametr: funkcja (obiekt, arg1, arg2,...) Nie jest to wyłącznie różnica syntaktyczna, gdyż: Dla metody, środowisko na którym działa, może zmieniać się dynamicznie (późne wiązanie metod, w odróżnieniu od wczesnego wiązania dla funkcji). Komunikat nie określa, która z metod implementujących daną operację ma być wywołana; wysłanie komunikatu do konkretnego obiektu powoduje wywołanie metody, implementującej żądaną operację, związanej z danym obiektem. Przykład: operacja drukuj wykonywana iteracyjnie dla zbioru plików o różnym formacie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 53

54 Komunikat a wołanie funkcji X = dochody( emeryt ) Y = dochody( pracownik ) Przełączanie, związane z rodzajem obiektu, następuje w ciele funkcji dochody. Funkcję zwykle pisze jeden programista, na wszystkie okazje. Każda zmiana, związana z nowym rodzajem obiektów, wymaga zmian w ciele funkcji. X = emeryt.dochody() Y = pracownik.dochody() Nie ma przełączenia; za każdym razem, w zależności od rodzaju obiektu - adresata komunikatu, wywoływana jest inna metoda dochody. Obie metody implementują operację dochody. Obie metody (i ich programiści) nie muszą nic o sobie wiedzieć. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 54

55 Polimorfizm Z greckiego, polimorfizm - oznacza wiele form (postaci) jednego bytu. Słowo polimorfizm też jest polimorficzne. Polimorfizm metod - (co zostało już wyjaśnione wcześniej w punkcie Operacja a metoda ) polega na tym, że operacja wywoływana za pośrednictwem komunikatu może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany; innymi słowy: może istnieć wiele metod implementujących daną operację. Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach programowania - oznacza istnienie funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z polimorfizmem typów (a w szczególności ML) uważane są za zbyt wyrafinowane dla przeciętnego programisty. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 55

56 Polimorfizm Dość powszechne jest plątanie polimorfizmu metod z polimorfizmem typów. Argumentacja, że polimorfizm metod jest szczególnym przypadkiem polimorfizmu typów (obiekt, do którego jest wysłany komunikat jest dodatkowym parametrem metody) jest niezbyt przekonywująca. Polimorficzne języki programowania (ML, Quest, Napier88,...) nie muszą być obiektowe, ale mogą być obiektowe (Fibonacci). Polimorfizm parametryczny. Rodzaj polimorfizmu typów, który oznacza, że typ bytu programistycznego może być parametryzowany innym typem, np. klasa WEKTOR (int) czy WEKTOR (char). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 56

57 Obiektowość a redukcja złożoności Potencjał obiektowości dla potrzeb redukcji złożoności oprogramowania: Modelowanie świata rzeczywistego jest ułatwione dzięki zastosowaniu podejścia obiektowego. Klasy, grupujące obiekty odwzorowywujące byty ze świata rzeczywistego, są najbardziej stabilnym elementem dziedziny problemu. Doświadczenie wykazuje, że oprogramowanie oparte o klasy powstałe w wyniku analizy dziedzinowej jest bardziej odporne na zmiany wymagań niż oprogramowanie skonstruowane w oparciu o jednostki funkcjonalne. Hermetyzacja wspomaga redukcję złożoności poprzez zachęcanie konsumentów, by opierali się raczej na interfejsie do obiektu niż jego wewnętrznej organizacji. Abstrahowanie od szczegółów implementacyjnych znacząco ułatwia proces rozumienia. Ponadto, hermetyzacja pozwala na ukrycie poprawek czy modyfikacji przed konsumentem oprogramowania. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 57

58 Obiektowość a redukcja złożoności Dziedziczenie pozwala na specjalizowanie strukury i zachowania obiektu podklasy bez ingerowania w struktury i zachowania obiektów nadklas. Poprzez dostarczenie opisu wyjaśniającego zasady organizacji struktury dziedziczenia, można pośrednio wpływać na jej racjonalny rozwój, nawet nie zawsze w kierunku przewidzianym przez jej twórcę. Polimorfizm metod wspiera redukcję złożoności pozwalając, by nowe bardziej wyspecjalizowane komponenty mogły być wykorzystywane w tym samym środowisku, co mniej wyspecjalizowane, bez potrzeby zmiany środowiska przy każdej zmianie komponentów. Polimorfizm parametryczny wspomaga redukcję złożoności umożliwiając definiowanie rodziny klas o takim samym interfejsie i implementacji, różniących się jedynie typem wyspecyfikowanym jako parametr klasy, np. klasa WEKTOR(int) czy WEKTOR(char). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 58

59 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 59 Wprowadzenie do UML

60 Zagadnienia Cykl życiowy produktu informatycznego Modelowanie pojęciowe Metodyka UML: - Krótka charakterystyka - Modele i diagramy - Mechanizmy rozszerzalności Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 60

61 Cykl życiowy produktu informatycznego Fazy cyklu życiowego produktu informatycznego: Faza strategiczna czas Faza specyfikacji i analizy wymagań --> projektowanie (modelowanie) pojęciowe Faza projektowania --> projektowanie logiczne Faza konstrukcji (implementacji) --> projektowanie fizyczne Faza testowania Faza konserwacji Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 61

62 Modelowanie pojęciowe Pojęcia: modelowanie pojęciowe (conceptual modeling) oraz model pojęciowy (conceptual model) odnoszą się do procesów myślowych, do wyobrażeń towarzyszących pracy nad oprogramowaniem. Projektant, programista, itp. muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą więc w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania czy jakimkolwiek narzędziem w ogóle. Modelowanie pojęciowe może być (i powinno być) wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię, służące do opisu odwzorowywanej rzeczywistości w postaci: struktur danych, operacji na danych czy zachodzących procesów. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 62

63 Metodyka Metodyka (metodologia), w inżynierii oprogramowania, jest zestawem pojęć, oznaczeń, języków, modeli, diagramów, technik i sposobów postępowania służących do modelowania dziedziny problemowej stanowiącej przedmiot projektowanego systemu. Metodyka jest wykorzystywana zarówno do projektowania pojęciowego, jak i logicznego czy fizycznego. Metodyka ustala fazy realizacji projektu, a ponadto dla każdej z faz projektu wyznacza: - role uczestników projektu, - scenariusze postępowania, - reguły przechodzenia do następnej fazy, - modele, które powinny być wytworzone, - dokumentację, która powinna powstać, - notację, którą należy stosować. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 63

64 Metodyka (2) Notacja, czyli zbiór oznaczeń, jest tu wykorzystywana do dokumentowania wyników poszczególnych faz projektu - pośrednich i końcowych. Notacja służy więc jako środek wspomagający ludzką pamięć i wyobraźnię, a także jako środek ułatwiający komunikację zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem. Rodzaje notacji: * tekstowa * specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny * notacje graficzne Szczególne znaczenie mają notacje graficzne, ich zalety potwierdzają badania psychologiczne. Inżynieria oprogramowania wzoruje się tu na innych dziedzinach techniki, takich jak np. elektronika i mechanika. Dana notacja może być wykorzystywana w innych metodykach. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 64

65 Pragmatyka języka do modelownia Język do modelowania, jak każdy inny język, oprócz semantyki i składni posiada jeszcze jeden ważny aspekt: pragmatykę. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami (notacją). Składnia określa, jak wolno łączyć ze sobą przyjęte oznaczenia. Pragmatyka określa, w jaki sposób należy używać przyjętych oznaczeń, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny - zgodnie z intencją autorów języka. Język niewiele znaczy bez znajomości sposobów wykorzystywania go w procesie wytwarzania produktu programistycznego. W metodykach pragmatyka stosowanego języka jest sprawą podstawową. Jest ona zazwyczaj trudna do objaśnienia: można to robić wyłącznie na przykładach przypominających realne sytuacje. Niestety, realne sytuacje są zazwyczaj bardzo skomplikowane, czego efektem jest pewien infantylizm przykładów zamieszczanych w podręcznikach. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 65

66 Unified Modeling Language (UML) UML - Unified Modeling Language (zunifikowany język modelowania) Czym jest UML? - Językiem pozwalającym tworzyć modele systemów (np. informatycznych) - Pozwala obrazować, specyfikować, tworzyć i dokumentować elementów systemu - Ułatwia wymianę informacji pomiędzy przyszłymi użytkownikami systemu, menadżerami, analitykami, projektantami, programistami i testerami - Ułatwia wykorzystanie zalet programowania obiektowego - UML jest jedynie językiem modelowania używanym w procesie analizy i projektowania systemów komputerowych Czym nie jest UML? - Językiem programowania - choć generowanie kodu jest możliwe na podstawie niektórych diagramów, rzadko jest to stosowane - Narzędziem - choć zawiera specyfikacje dla narzędzi - Metodyką - nie definiuje procesu tworzenia oprogramowania - nie jest sposobem na analizę i projektowanie systemów komputerowych Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 66

67 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 67 Historia UML

68 Twórcy UML Za twórców UML uważa się: - G. Booch - I. Jacobson - J. Rumbaugh nazywanych "trzema muszkieterami", którzy w 1995r. spotkali się w Rational Software Corporation i połączyli swoje indywidualnie rozwijane metody modelowania doprowadzając do powstania standardu UML Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 68

69 UML: Krótka charakterystyka UML cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 69

70 UML: Krótka charakterystyka 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 70

71 Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas Diagramy dynamiczne (behavior): - Diagramy stanów - Diagramy aktywności - Diagramy interakcji: Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy pakietów Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 71

72 Model a diagram; modele w UML Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości. Diagram - środek służący do opisu modelu. Dany model może być opisany przy pomocy wielu diagramów. Dany element modelu może pojawiać się na wielu diagramach jednego modelu. Dwa najważniejsze modele w UML, wykorzystywane w fazie analizy, to: - model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia), - model obiektowy przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. Głównym zadaniem pomocniczego modelu dynamicznego (zachowań) jest wypełnienie diagramu klas metodami wynikłymi z analizy zachowania systemu w trakcie wykonywania zadań, gdzie zadaniem może być np. realizacja przypadku użycia czy też jednego konkretnego scenariusza danego przypadku użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 72

73 Stereotypy Stereotypy stanowią jeden z mechanizmów rozszerzalności UML. Jak każdy mechanizm rozszerzalności, dają możliwość definiowania nowych elementów, co ułatwia przystosowanie UML do modelowania specyficznego procesu, do specyficznych preferencji użytkownika czy też pozwala na uszczegóławianie semantyki modelu: Stereotypy są wyrażeniami językowymi umożliwiającymi metaklasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementów 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 73

74 Stereotypy Przykłady stereotypów: P1 «include» P2 P3 «extend» P4 «aktor» Klient jest równoważne Klient Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 74

75 Wartości etykietowane Wartości etykietowane są następnym z mechanizmów rozszerzalności UML 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 może być skojarzony z listą wartości etykietowanych. Przykłady list wartości etykietowanych: {autor = Jan Nowak, termin zakończenia = 31 Maja 1999, status = analiza} {abstract = TRUE} można skrócić do {abstract} 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. Uwaga! Wartości etykietowane służą raczej do opisu pojedynczego elementu modelu niż do metaklasyfikcji (patrz: stereotypy). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 75

76 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 76 Model obiektowy

77 Zagadnienia Klasa; notacja w UML Dziedziczenie: - jednoaspektowe - wieloaspektowe - wielokrotne - dynamiczne Klasa parametryzowana Rozszerzenia i ograniczenia w podklasie Wystąpienie klasy Klasa abstrakcyjna a klasa konkretna Metoda abstrakcyjna Interfejs, zależność, uszczegółowienie Ekstensja klasy Własności klas: atrybuty, metody Przesłanianie a przeciążanie Typ; kontrola typów Własność zamienialności Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 77

78 Klasa; notacja Cztery pola: nazwy, atrybutów, metod i dla użytkownika, np. w celu specyfikowania odpowiedzialności klasy. Możliwe są różne poziomy szczegółowości. Okno Pole nazwy klasy: Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() stereotyp nazwa_ klasy lista_wart_etyk Pole atrybutów: stereotyp dostępność nazwa_atrybutu : typ = wart_początkowa lista_wart_etyk Pole metod: stereotyp dostępność nazwa_metody (lista_arg) : typ_wart_zwracanej lista_wart_etykt Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 78

79 Klasa; notacja gdzie: dostępność jest określana przez trzy symbole: + publiczna - prywatna # chroniona lista_arg: rodzaj nazwa_arg : typ = wart_początkowa 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 nazwy klasy są opcjonalne. Nazwa klasy to z reguły rzeczownik w liczbie pojedynczej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 79

80 Przykłady klas 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 zostały tu użyte do metaklasyfikacji metod. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 80

81 specjalizacja Dziedziczenie generalizacja Dziedziczenie pozwala na tworzenie drzewa klas lub innych struktur bez pętli. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Profesor Asystent Adiunkt Profesor Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 81

82 Dziedziczenie Osoba K1 K2 Student Pracownik K3 Student_asystent Struktura typu pętla jest zabroniona Struktura typu krata jest dopuszczalna Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 82

83 Dziedziczenie OSOBA NAZWISKO ROK_UR Wiek() GRAFIKA ROZMIAR Wyświetl(...) STUDENT NR_INDEKSU WYDZIAŁ WstawOcenę(...) ZaliczSemestr() PRACOWNIK ZAROBEK DZIAŁ FOTO ZarobekNetto() ZmieńZarobek(...) JPEG GIF FOTO, atrybut klasy PRACOWNIK, jest obiektem, członkiem klasy JPEG. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 83

84 Dziedziczenie Wyposażenie nazwa wytwórca koszt aspekt specjalizacji (dyskryminator) typ wyposażenia Pompa ciśnienie ssania ciśnienie tłoczenia przepływ typ pompy Wymiennik ciepła powierzchnia wymiany średnica rury typ zbiornika Zbiornik objętość ciśnienie Dziedziczenie jednoaspektowe - aspekt specjalizacji (dyskryminator) jest tu atrybutem opcjonalnym. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 84

85 Dziedziczenie Pompa ciśnienie ssania ciśnienie tłoczenia przepływ Wyposażenie nazwa wytwórca koszt Wymiennik ciepła powierzchnia wymiany średnica rury typ wyposażenia Zbiornik objętość ciśnienie 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 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 85

86 Dziedziczenie wieloaspektowe Pojazd {overlapping} napęd teren teren Dwa aspekty dziedziczenia: napęd i teren. {overlapping} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny Dla dziedziczenia wieloaspektowego aspekty dziedziczenia nie mogą być opuszczane. {disjoint, incomplete} Drzewo gatunek drzewa Dąb Brzoza Sosna disjont (domyślne) - podział rozłączny overlapping - podział nierozłączny; przecięcie zbiorów obiektów klas, np. Pojazd lądowy i Pojazd wodny, nie jest zbiorem pustym; complete (domyślne) - podział całkowity incomplete - niektóre klasy, np. nieistotne dla rozważanego problemu, zostały pominięte Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 86

87 Dziedziczenie wielokrotne Dziedziczenie wielokrotne (wielodziedziczenie) ma miejsce, gdy klasa dziedziczy inwarianty z więcej niż jednej klasy. Osoba Nazwisko Pracownik Zarobek Student Nr_indeksu Pracujący Student Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 87

88 Problemy dziedziczenia wielokrotnego Pojazd {prędkość eksploatacyjna wynosi 50% prędkości maksymalnej} Pojazd lądowy max_prędkość prędk_eksploat() Pojazd wodny max_prędkość prędk_eksploat() Samochód Amfibia Jacht Konflikt nazw: Który atrybut max_prędkość ma odziedziczyć amfibia? Czy znaczenie metody prędk_eksploat() zależy od ścieżki dziedziczenia? (O2: mechanizm zmiany nazwy dziedziczonej cechy; Eiffel: konflikt jest traktowany jako błąd.) Najczęściej wielodziedziczenie jest konsekwencją braku koncepcji ról. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 88

89 Dziedziczenie dynamiczne Kobieta «dynamic» zawód Manager Mężczyzna płeć {mandatory} Osoba Inżynier Sprzedawca Dyskryminator zawód został tu opatrzony stereotypem «dynamic». Osoba może zmieniać zawód, co można modelować poprzez tzw. Dziedziczenie dynamiczne. Przydatne dla modelowania koncepcyjnego, ale może być trudne w implementacji. mandatory - obowiązujący, obowiązkowy Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 89

90 Klasa parametryzowana Klasy parametryzowane są użyteczne z dwóch zasadniczych powodów: podnoszą poziom abstrakcji i wpływają na zmniejszenie długości kodu źródłowego programu. Klasy parametryzowane posiadają duży potencjał ponownego użycia. Klasa parametryzowana może być wstawiana do diagramów UML na dwa sposoby: Zbiór <Pracownik> szablon Zbiór wstaw (T) usuń (T) T «bind» <Pracownik> Aktualny parametr parametrzacji Zbiór Pracowników Podstawowe zastosowanie klas parametryzowanych polega na wykorzystaniu ich do definiowania zbiorów (szerzej - kolekcji). Każdy obiekt klasy Zbiór <Pracownik>, czy analogicznie Zbiór Pracowników, jest zbiorem. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 90

91 Rozszerzenia i ograniczenia w podklasie Podklasa nie może omijać lub zmieniać atrybutów nadklasy. Podklasa może zmienić ciało metody z nadklasy, ale bez zmiany jej specyfikacji. Podklasa może dowolnie dodawać nowe atrybuty i metody (rozszerzać zbiór własności nadklasy). 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ć zmieniane obie średnice jednocześnie. Czy Koło powinno być podklasą klasy Elipsa czy też powinno być odwrotnie? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 91

92 Wystąpienie klasy Pojęcie 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 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 92

93 Klasa abstrakcyjna a konkretna Klasa abstrakcyjna nie ma (nie może mieć) bezpośrednich wystąpień i służy wyłącznie jako nadklasa dla innych klas. Stanowi jakby wspólną część definicji grupy klas o podobnej semantyce. Klasa konkretna może mieć (ma prawo mieć) wystąpienia bezpośrednie. Sekwencja Klasyczne klasyfikacje w biologii: tylko liście w drzewie klas mogą być klasami konkretnymi. Osoba prawna pierwszy następny Osoba fizyczna Firma Sekwencja int Sekwencja char... implementacje...implementacje Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 93

94 Klasa abstrakcyjna a konkretna A, K K1 A - klasa abstrakcyjna K - klasa konkretna K K2 K3 A, K K K4 K5 K Klasa abstrakcyjna nie może znaleźć się w liściu drzewa. Klasa konkretna może zająć każde położenie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 94

95 Metoda abstrakcyjna Metoda abstrakcyjna jest to metoda wyspecyfikowana w nadklasie, której implementacja musi znaleźć się w którejś z podklas. UML pozwala na oznaczenie bytu abstrakcyjnego za pomocą wartości etykietowanej {abstract = TRUE} (TRUE można opuścić) lub napisanie nazwy bytu abstrakcyjnego italikami (np. nazwy klasy czy metody abstrakcyjnej). Pracownik {abstract} już zarobił w tym roku oblicz wypłatę {abstract} Specyfikacja operacji oblicz wypłatę znajduje się w klasie abstrakcyjnej Pracownik. Każda z klas konkretnych zawiera właściwą dla siebie implementację tej operacji. 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ę Klasa abstrakcyjna może zawierać abstrakcyjne metody, ale nie musi. Klasa konkretna musi zawierać implementacje tych metod abstrakcyjnych, które nie zostały zaimplementowane w żadnej z nadklas danej klasy konkretnej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 95

96 Interfejs, zależność, realizacja Osoba {abstract} imię nazwisko data ur. policz wiek «interface» IPracownik + zmień pensję dependency Firma Pracownik realization pensja stanowisko zmień pensję Realizacja (realization) o notacji z premedytacją podobnej do dziedziczenia, oznacza zgodnie z nazwą, większy poziom szczegółowości. Stereotyp «interface» poprzedza nazwę klasy, która zawiera jedynie specyfikacje metod, bez implementacji. W UML interfejs nie zawiera atrybutów. Wszystkie metody są tu publiczne. Implementacje metod wyspecyfikowanych w interfejsie Ipracownik zawiera klasa Pracownik. Zależność (dependency) wskazuje na klasę (klienta), która korzysta z danego interfejsu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 96

97 Interfejs, zależność, uszczegółowienie Dla poprzedniego diagramu można zastosować inną, bardziej zwięzłą notację. IPracownik Firma Pracownik Osoba 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: klasa abstrakcyjna, w przeciwieństwie do interfejsu, może zawierać atrybuty i implementacje metod. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 97

98 Ekstensja klasy Ekstensja klasy (class extent) = aktualny (zmienny w czasie) zestaw wszystkich wystąpień tej klasy. Ekstensja klasy w implementacji oznacza specjalną strukturę danych, konkretny byt programistyczny dołączony do klasy. Ta struktura przechowuje wszystkie obiekty będące członkami danej 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 98

99 Ekstensja klasy Istnieje kilka definicji ekstensji klasy: 1. Jest to zbiór jedynie bezpośrednich wystąpień danej klasy, 2. Jest to zbiór wszystkich wystąpień danej klasy (bezpośrednich i pośrednich), ale obcięty do atrybutów wyspecyfikowanych w tej klasie, 3. Jest to, jak poprzednio, zbiór wszystkich wystąpień danej klasy, ale bez obcinania atrybutów, które zostały wyspecyfikowane w podklasach tej klasy. K1 {abstract} I E 1 = {}, E 2 = {O2}, E 3 = {O3}, E 4 = {O4} II E 1 = {O2, O3, O4}, E 2 = {O2}, E 3 = {O3} E 4 = {O4} K2 K3 K4 III E 1 = {O2, O3, O4}, E 2 = {O2}, E 3 = {O3} E 4 = {O4} O2 O3 O4 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 99

100 Ekstensja klasy; przykład Ekstensja klasy OSOBA : OSOBA NAZWISKO = Kowalska ROK_UR = 1975 NAZWISKO = Nowak ROK_UR = 1951 NAZWISKO = Abacki ROK_UR = 1948 NAZWISKO = Nowacki ROK_UR = 1940 OSOBA NAZWISKO ROK_UR Wiek() PRACOWNIK PENSJA DZIAŁ ZarobekNetto() ZmieńZarobek(...) : PRACOWNIK : PRACOWNIK NAZWISKO = Nowak NAZWISKO = Abacki ROK_UR = 1951 ROK_UR = 1948 PENSJA = 2000 PENSJA = 2500 DZIAŁ = zabawki DZIAŁ = zabawki Ekstensja klasy PRACOWNIK : PRACOWNIK NAZWISKO = Nowacki ROK_UR = 1940 PENSJA = 3000 DZIAŁ = sprzedaż Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 100

101 Atrybuty Atrybut może być nazwaną wartością lub obiektem (podobiekt). Atrybut, będący wartością, nie posiada tożsamości. Wartości atrybutów są przechowywane przez obiekty, ponieważ nie należą do inwariantów klasy. Uwaga! Sformułowanie wartość atrybutu w przypadku, gdy atrybut jest podobiektem jest pewnym uproszczeniem. nazwisko wiek atrybuty obiektów klasy Osoba Osoba nazwisko : string wiek : integer :Osoba nazwisko = Nowak wiek = 53 :Osoba nazwisko = Stycz wiek = 24 Klasa z atrybutami Obiekty (wystąpienia klasy) z wartościami atrybutów Atrybut unikalnie identyfikujący obiekt (klucz) nie jest wymagany, ponieważ każdy obiekt posiada tożsamość, implementowaną poprzez wewnętrzny unikalny identyfikator obiektu, automatycznie generowany przez system w momencie powoływania obiektu do życia i niewidoczny dla użytkownika. Zaleca się, by identyfikator nie miał znaczenia w dziedzinie problemu. Osoba id_osoby Pesel : nr nazwisko : string wiek : integer Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 101

102 Atrybuty Atrybuty mogą być: - proste: imię, nazwisko, nazwisko panieńskie, wiek, płeć, stosunek do służby wojskowej - złożone: data ur., adresy, lista poprz. miejsc pracy, zdjęcie - opcjonalne: nazwisko panieńskie, stosunek do służby wojsk, lista poprz. miejsc pracy - powtarzalne: lista poprz. miejsc pracy - pochodne: wiek - klasy: adres firmy - atrybut będący obiektem: zdjęcie Atrybuty klasy należą do inwariantów danej klasy. Pracownik imię nazwisko nazwisko panieńskie [0..1] data ur. /wiek adres zamieszkania płeć stosunek do służby wojsk. [0..1] lista poprz. miejsc pracy [0..*] adres firmy zdjęcie Kiedy z atrybutu warto zrobić klasę? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 102

103 Specyfikacja metod Metoda może mieć argumenty (oprócz obiektu, który jest argumentem implicite). Sygnatura (specyfikacja) metody włącza liczbę i typ argumentów plus typ wyniku metody. Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę. Osoba Plik nazwa_pliku Obiekt geometryczny długość w bajtach kolor ostatnia_zmiana pozycja nazwisko wiek zmień pracę zmień_adres drukuj przesuń ( delta: Wektor ) wewnątrz ( p: Punkt ): Boolean obróć ( kąt ) Jeżeli argumenty nie są specyfikowane, to może ich być dowolnie dużo, również w ogóle. Brak specyfikacji argumentów na etapie analizy może oznaczać zarówno, że metoda ich nie posiada, jak i że w danym momencie nie interesujemy się jeszcze nimi. To samo dotyczy wartości zwracanej przez metodę. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 103

104 Rodzaje metod Metody mogą być: - abstrakcyjne - obiektu: policz wiek, czy pracował w (nazwa firmy) - klasy: policz wiek (imię, nazwisko), znajdź najstarszego Klasa Pracownik nie posiada metod abstrakcyjnych, gdyż jako jedyna klasa na diagramie musi być klasą konkretną. Metoda obiektu operuje na atrybutach jednego obiektu - tego dla którego została wywołana. Obiekt jest argumentem domyślnym metody obiektu. Metoda klasy operuje na ekstensji klasy, czyli posiada dostęp do atrybutów wszystkich obiektów członków danej klasy. Pracownik imię nazwisko data ur. /wiek adres zamieszkania płeć stosunek do służby wojsk. [0..1] lista poprz. miejsc pracy [0..*] adres firmy policz wiek (imię, nazwisko) policz wiek policz wiek (imię, nazwisko) czy pracował w (nazwa firmy) znajdź najstarszego Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 104

105 Przesłanianie metod Przesłanianie (overriding) - metoda z klasy bardziej wyspecjalizowanej może przesłonić metodę z klasy bardziej ogólnej. Wybierana jest metoda znajdująca się najbliżej obiektu, w sensie hierarchii dziedziczenia. Pracownik nazwisko... zwolnij()... Decyzja o zwolnieniu w gestii dyrekcji Samodzielny prac.naukowy zwolnij() Decyzja o zwolnieniu w gestii sekretariatu PAN Metody mają tu identyczną sygnaturę ale różne implementacje (ciała). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 105

106 Przesłanianie metod Bryła {abstract} pole podstawy wysokość Przesłanianie jest ściśle powiązane z polimorfizmem metod. Przesłanianie wymaga dynamicznego wiązania. Przesłanianie jest ważnym elementem wspomagającym ponowne użycie. policz objętość {objętość = pole podstawy * wysokość} {incomplete} Prostopadłościan Walec Stożek policz objętość {objętość = 1/3 pola podstawy * wysokość} Dwie metody implementujące operację policz objętość. Metoda policz objętość w klasie Bryła nie może być metodą abstrakcyjną. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 106

107 Dynamiczne (poźne) wiązanie Wiązanie (binding): zamiana identyfikatora symbolicznego (nazwy) występującego w programie na: wartość, adres lub wewnętrzny identyfikator bytu programistycznego (danej, zmiennej, procedury,...) Wczesne (statyczne) wiązanie: przed uruchomieniem programu, podczas kompilacji i konsolidacji. Zalety: większa szybkość działania programu, możliwość pełnej statycznej kontroli typów. Wady: brak możliwości rozbudowy aplikacji podczas jej działania. Późne (dynamiczne) wiązanie: w czasie wykonania programu. Zalety: możliwość przesłaniania w trakcie działania aplikacji, możliwość komponowania programu w trakcie jego działania, szybkie przechodzenie od pomysłu do realizacji. Wady: wolniejsze działanie programu, utrudniona kontrola typów Późne wiązanie jest nieodzownym warunkiem dla: - implementacji komunikatów (polimorfizmu) - dynamicznie tworzonych perspektyw - dynamicznie tworzonych procedur bazy danych - języków zapytań - migracji obiektów - ewolucji schematu BD Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 107

108 Przeciążanie metod Przeciążanie (overloading) oznacza, że jakiś symbol (np. operatora czy funkcji) ma znaczenie zależne od kontekstu jego użycia, np. od składni lub ilości/typu argumentów. Np. przesuń (x, y), przesuń (x, y, z) - mają różną ilość argumentów przesuń (int, int), przesuń (float, float) - mają różne typy argumentów Powszechne jest przeciążanie operatora równości = służy do porównania liczb całkowitych, liczb rzeczywistych, stringów, identyfikatorów, struktur, itd. Podobnie, operator + może oznaczać dodawanie lub konkatenację. Przeciążanie nie wymaga dynamicznego wiązania: znaczenie operatora można wydedukować na podstawie statycznej analizy tekstu programu. W odróżnieniu od przeciążania, przesłanianie jest własnością dynamiczną, nie zawsze da się wydedukować z tekstu programu. Niektórzy autorzy (np. Cardelli - propagator teorii typów polimorficznych) uważają, że przeciążanie nie jest polimorfizmem. Stwierdzenie Wszystkie metody implementujące daną operację muszą mieć tę samą sygnaturę, leżące u podstaw idei polimorfizmu, jest sprzeczne z definicją przeciążania. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 108

109 Typ Typ bytu programistycznego nakłada ograniczenia na jego budowę (lub argumenty i wynik) oraz ogranicza kontekst, w którym odwołanie do tego bytu może być użyte w programie. W wielu opracowaniach i językach (C++, Eiffel) typ jest utożsamiany z klasą. Wielu autorów uważa jednak te dwa pojęcia za różne. Klasa: przechowalnia inwariantów, implementacja metod. Typ: specyfikacja budowy obiektu, specyfikacja metod. Podstawowe zastosowanie klasy: modelowanie pojęciowe. Podstawowe zastosowanie typu: wspomaganie formalnej kontroli poprawności programów. Generalnie, na linii rozróżnień definicyjnych pomiędzy pojęciami: - klasa - typ - abstrakcyjny typ danych (ADT) - ekstensja panuje spore zamieszanie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 109

110 Mocna kontrola typów Mocna kontrola typów oznacza, że każdy byt programistyczny (obiekt, zmienna, procedura, funkcja, metoda, moduł, klasa,...) podlega obowiązkowej specyfikacji typu. Każde odwołanie do tego bytu w programie jest sprawdzane na zgodność ze specyfikacją jego typu. Statyczna kontrola typu: kontrola tekstu programu (podczas kompilacji). Dynamiczna kontrola typu: kontrola typów podczas czasu wykonania. Zwykle mocna kontrola typu oznacza kontrolę statyczną. Kontrola dynamiczna jest znacznie mniej skuteczna, z dwóch powodów: jest istotnym obciążeniem czasu wykonania, błąd typu podczas wykonania jest takim samym błędem jak każdy inny, a rakieta przecież jest już w locie... Z drugiej strony, mocna statyczna kontrola typu powoduje znaczne zmniejszenie mocy języka programowania i jego elastyczności. Np. jak napisać procedurę w Pascal u, która mnoży dwie macierze o dowolnych rozmiarach? Własności takie jak: późne wiązanie, wartości zerowe, warianty, perspektywy, procedury bazy danych, dynamiczne klasy, etc. wymagają kontroli dynamicznej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 110

111 Podtyp Dwie definicje: Ekstensja podtypu jest podzbiorem ekstensji typu Np. zbiór liczb naturalnych jest podtypem zbioru liczb całkowitych. Typ B jest podtypem typu A, jeżeli B posiada więcej własności (atrybutów, metod,...) niż A, innymi słowy B jest bardziej wyspecjalizowane niż A. struct Osoba {string Nazwisko; integer Rok_urodz;}; struct Pracownik {string Nazwisko; integer Rok_urodz; integer Zarobek; }; Pracownik jest podtypem Osoba Innym (równoważnym) punktem widzenia na kwestię podtypowania jest założenie, że każdy obiekt może mieć wiele typów: swojej klasy podstawowej i wszystkich jej nadklas. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 111

112 Własność zamienialności Definiowanie relacji podtypu między typami posiada konkretny cel, określany przez zasadę zamienialności (substitutability): Jeżeli w jakimś miejscu programu (zapytania,...) może być użyty byt typu A, to może tam być także użyty byt, którego typ jest podtypem typu A. Np., jeżeli w jakimś miejscu programu może być użyty obiekt Osoba, to w tym samym miejscu może być użyty obiekt Pracownik. Wszędzie tam, gdzie może być użyta liczba całkowita, można także użyć liczby naturalnej. Wszędzie, gdzie może być użyta Elipsa, można też użyć obiektu klasy Koło. Zamiana odwrotna nie jest możliwa. Zasada zamienialności ma duże znaczenie dla przyrostowego rozwoju oprogramowania: obiekty nowych, bardziej wyspecjalizowanych klas mogą być wykorzystywane w tym samym środowisku, co mniej wyspecjalizowane, bez potrzeby zmiany środowiska przy każdej zmianie związanej z rozszerzeniami wynikłymi ze specjalizacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 112

113 Typy masowe Typy masowe to typy,, dla których rozmiar bytu nie da się ani przewidzieć ani sensownie ograniczyć. Kolekcje (termin ODMG-93 przyjęty dla określenia typów masowych): Zbiory (sets): nie uporządkowane kolekcje elementów dowolnego ustalonego typu, bez powtórzeń. Wielozbiory (multisets, bags): nie uporządkowane kolekcje elementów dowolnego ustalonego typu, elementy mogą się powtarzać. Sekwencje (sequences): uporządkowane kolekcje elementów dowolnego ustalonego typu; porządek ma znaczenie informacyjne, elementy mogą się powtarzać. Tablice dynamiczne (dynamic arrays): sekwencje, ale z dostępem poprzez indeks. Ortogonalność konstruktorów typu: typy masowe mogą być dowolnie kombinowane, w tym również z typami indywidualnymi, np. zbiór sekwencji czy obiekt, którego atrybutami są wielozbiory. Popularne języki obiektowe nie mają typów masowych lub je ograniczają (Smalltalk, C++). Systemy przedobiektowe nie są zgodne z zasadą ortogonalności konstruktorów typu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 113

114 Rozszerzalność systemu typów Projektant ma do wyboru wiele konstruktorów typu. Nowy typ można zdefiniować na podstawie typu już istniejącego (ortogonalna kombinacja) Konstruktory typów: typy atomowe: character, integer, float, string, boolean, bitmap,... typy zapisów (records): struct {nazwa:string; waga:float;} kolekcje: - zbiory (sets): set of bitmap, set of struct {nazwa:string; waga:float;} - wielozbiory (bags): zbiory z powtórzeniami - sekwencje (sequences): wielozbiory uporządkowane - tablice (arrays): array of integer, array[5..30] of set of bitmap Definicja nowego typu na podstawie typu już zdefiniowanego: TypCzęści = struct {string nazwa; float waga;}; TypRelacjiCzęści = set of TypCzęści; Rozszerzalność systemu typów znacząco wspomaga ponowne użycie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 114

115 Zagadnienia Asocjacja binarna Agregacja a kompozycja Modelowanie generalizacji-specjalizacji Obejście dziedziczenia wielokrotnego Asocjacja kwalifikowana Asocjacja n-arna Ograniczenia Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 115

116 Powiązanie a asocjacja binarna Powiązanie Asocjacja Fizyczny lub pojęciowy związek między obiektami, odwzorowywujący związek istniejący między odpowiednimi bytami w analizowanej dziedzinie przedmiotowej. Grupa powiązań posiadających wspólną strukturę i semantykę. Powiązanie jest wystąpieniem asocjacji. Asocjacja, która łączy dwie klasy nazywana jest binarną. Osoba imię Firma rodzaj pracuje_w :Osoba Kasia pracuje_w :Firma Krawiecka :Osoba Ewa pracuje_w :Osoba Jasio :Firma Szewska pracuje_w Klasy i asocjacja na diagramie klas Obiekty i powiązania na diagramie obiektów Asocjacje mogą też łączyć więcej niż dwie klasy, tzw. asocjacje n-arne. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 116

117 Oznaczanie asocjacji 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 1 pracuje_dla 1..* Osoba 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. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 117

118 Liczność asocjacji Liczność asocjacji, to cecha o dużym znaczeniu informacyjnym w analizie i modelowaniu. Jeżeli asocjacja wiąże klasy A i B, to istotne jest: jaka jest minimalna liczba obiektów B powiązana z jednym obiektem A, A --> B jaka jest maksymalna liczba obiektów B powiązana z jednym obiektem A, A --> B jaka jest minimalna liczba obiektów A powiązana z jednym obiektem B, B --> A jaka jest maksymalna liczba obiektów A powiązana z jednym obiektem B, B --> A. Zwykle, minimalna liczba jest 0 lub 1, maksymalna zaś 1 lub * (dowolnie dużo). a) b) a) b) A A A A A A A A A A A A 1,2 2,3 B B A B: min = 0, max = 1 B A: min = 1, max = 2 B B B A B: min = 1, max = 3 B A: min = 2, max = 3 B 0..1 B B 1..3 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 118

119 Liczność asocjacji Liczność jest oznaczana na obu końcach asocjacji. Przykłady: UML 1 1..* 2..* 3-5 2,4, * * znaczenie 1 1, 2, 3,... 2, 3, 4,... 3, 4, 5 2, 4, 18 1,? 0, 1 0, 1, 2,... 0, 1, 2,... Państwo Stolica Firma Osoba 1 * 0..* 0..1 Pracownik Adres Oznaczać czy nie oznaczać liczność 1? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 119

120 Asocjacje skierowane Zamówienie datazłożenia czyzapłacone sumadozapłaty realizuj() zamknij() 1 * PozycjaZamówienia ilość cena czyzrealizowana * 1 * 1 Klient nazwisko adres wiarygodność() 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. Produkt Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 120

121 Role asocjacji Asocjacje mogą być wyposażone w nazwy ról (przy końcach), np. pracodawca i pracownik.. Rola określa kierunek nawigowania, specyfikując klasę cel, np. rola pracodawca wyznacza kierunek nawigowania od obiektu klasy Osoba do powiązanych z nim obiektów klasy Firma. W tym sensie liczność asocjacji oznacza liczność roli. Firma * pracuje_dla 1..* pracodawca pracownik * Osoba podwładny 0..1 szef Role asocjacji są niezbędne, gdy powiązania łączą obiekty tej samej klasy. Jak oznaczać asocjacje binarne? (1) Można opuszczać nazwę asocjacji, gdy jest oczywista (?) i jest jedyną asocjacją łączącą dwie klasy. Firma 1 1..* Pracownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 121

122 Role asocjacji Osoba jest_członkiem * * 1 jest_przewodniczącym * Komitet Na diagramie powyżej, dwie asocjacje łączą te same klasy; w wypadku, gdy dwie klasy są połączone więcej niż jedną asocjacją, wszystkie asocjacje muszą być oznaczone. (2) Do oznaczenia asocjacji można użyć nazwy lub dwóch ról lub jednej roli. * Pracownik 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. szef Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 122

123 Atrybuty asocjacji Plik * dostępny dla * Użytkownik Prawo dostępu dostęp { dostęp oznacza: czytanie lub czytanie-pisanie} kieruje szef 0..1 Osoba nazwisko pesel adres * pracownik 1..* zatrudnia 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Jeśli klasa asocjacji nie zawiera metod ani asocjacji do innych klas to jej nazwa może być opuszczona dla podkreślenia faktu, że chodzi tu wyłącznie o atrybuty asocjacji. Ocena wydajności ocena Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 123

124 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. Osoba nazwisko pesel adres 1..* pracuje_w 0..1 Zatrudnienie zarobek stanowisko Firma nazwa adres Forma nie zalecana, mniej elastyczna: np. po zmianie powiązania na wiele-do-wielu trzeba zmieniać położenie atrybutów. Osoba nazwisko pesel adres zarobek stanowisko 1..* pracuje_w 0..1 Firma nazwa adres Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 124

125 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} asocjacja pochodna: /pracuje_w Asocjacja pracuje_w jest asocjacją pochodną, którą można wyznaczyć poprzez asocjacje zatrudnia i zlokalizowana_w. Asocjację pochodną można oznaczyć poprzedzając ukośnikiem nazwę lub rolę asocjacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 125 zatrudnia * * Wydział Sekcja Pracownik zlokalizowana_w * Budynek /pracuje_w *

126 Przykładowy diagram klas Osoba poprzedza zapisany_na 1..* 0..1 Kurs * 1 zawiera następuje_po Student Pracownik Profesor prowadzi 1 1..* 1..* Wykład * Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 126

127 Agregacja Agregacja jest szczególnym przypadkiem asocjacji wyrażającym zależność częśćcałość. Np. silnik jest częścią samochodu. Nie istnieje jednak powszechnie akceptowana definicja agregacji. P. Coad podaje przykład agregacji jako związek pomiędzy organizacją i jej pracownikami; dla odmiany J. Rumbaugh twierdzi, że firma nie jest agregacją jej pracowników. W wielu przypadkach związki agregacji są oczywiste. Jednakże wątpliwości powstają nawet w przypadku samochodu i silnika. Np. silnik może być towarem w sklepie nie związanym z żadnym samochodem. Ponadto, czy chodzi o konkretny samochód i silnik, czy też o typ samochodu i typ silnika? Mętlik dookoła pojęcia agregacji wynika również z tego, że jest ona nadużywana w celu usprawiedliwienia pewnych ograniczeń modelu obiektowego. Np. popularne wyjaśnienie powodów braku (wielo) dziedziczenia podaje, że można je obejść przez agregację, co jest nonsensem z punktu widzenia celów modelowania pojęciowego, tak samo jak zdanie: asocjacje są zbędne, bo można je obejść przez atrybuty. Wszysto można obejść... w assemblerze! Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 127

128 Kompozycja jako mocna postać agregacji Pojęcie agregacji jest rozumiane na dwa sposoby: Jako związek część-całość pomiędzy obiektami świata rzeczywistego; np. silnik jest częścią samochodu. Jako pomocniczy środek do modelowania dowolnej innej sytuacji, kiedy trzeba wydzielić podobiekty w pewnych obiektach. np. informacja o ubezpieczeniach wewnątrz obiektów pracowników. W UML te dwie sytuacje zostały rozdzielone. Pierwszą formę nazwano kompozycją. Kompozycja oznacza, że cykl życiowy składowej zawiera się w cyklu życiowym całości, oraz że składowa nie może być współdzielona. * * K Ks K Ks 1 * agregacja kompozycja Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 128

129 Agregacja a kompozycja (przykład) {ordered} 3..* Punkt Wielobok Okrąg promień * * Styl kolor czywypełniony W przedstawionym rozwiązaniu, punkt na płaszczyźnie, w którym przecinają się okrąg i wielobok, jest odwzorowywany w dwa (?) obiekty klasy Punkt. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 129

130 Modelowanie generalizacji-specjalizacji zastosowano dziedziczenie Osoba zastosowano kompozycję Osoba Student Pracownik {xor} Student Pracownik Osoba {overlapping} Osoba Student Pracownik Student Pracownik Dzięki kompozycji, podobiekty Student czy Pracownik są mocniej związane z obiektem Osoba, niż gdyby do użyto modelowania asocjacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 130

131 Obejście dziedziczenia wielokrotnego Osoba Osoba nie polecane Student Pracownik Student Pracownik 1 1 Student/Pracownik Osoba 0..1 Student/Pracownik Student Pracownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 131

132 Asocjacja kwalifikowana Bank Osoba Bank nr konta * 0..1 nr konta Osoba 1 kwalifikator asocjacji Bank * * Osoba Bank nr konta Bank/Osoba nr konta Osoba * 0..1 Kwalifikator jest atrybutem asocjacji (lub zestawem atrybutów), którego wartości służą do podziału zbioru obiektów definiowanych przez klasę znajdującą się na jednym z końców tej asocjacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 132

133 Asocjacja kwalifikowana Zamówienie 1 * pozycja WierszZamówienia nazwa produktu ilość Zamówienie nazwa produktu pozycja WierszZamówienia ilość Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 133

134 Asocjacja n-arna Asocjacja n-arna to asocjacja, której wystąpienia łączą n obiektów, będących instancjami co najwyżej n klas: 3-arna - 3 obiekty (inna nazwa dla tej asocjacji to ternarna), 4-arna - 4 obiekty, itd. Dana klasa może pojawić się na więcej niż jednej pozycji w asocjacji. Asocjacja binarna ze swoją uproszczoną notacją i pewnymi dodatkowymi własnościami (takimi jak możliwość ustalania kierunku nawigowania, kwalifikatorów, związków agregacji czy kompozycji) jest specjalnym rodzajem asocjacji n-arnej (dla n=2). Asocjacja binarna i 2- arna są równoważne, nie istnieje między nimi różnica semantyczna, inny jest tylko sposób reprezentowania. Wymienione wyżej dodatkowe własności asocjacji binarnych są zabronione dla asocjacji n-arnych, gdzie n > 2. Notacja asocjacja 3-arna asocjacja 4-arna K1 nazwa asocjacji K3 K1 K3 K2 K2 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 134

135 Asocjacja n-arna; liczności Liczności Specyfikowanie liczności dla asocjacji n-arnych nie jest tak oczywiste, jak dla asocjacji binarnych i różni autorzy wygłaszają na ten temat różne zdania. UML odrzuciła poglądy, że liczność danej roli powinna być ustalana w odniesieniu do liczności pozostałych ról, traktowanych oddzielnie. Przyjęto zasadę, że liczność n-tej roli jest opisana przez zbiór możliwych wartości liczności, gdy sytuacja na n-1 końcach asocjacji jest ustalona. Np. dla ternarnej asocjacji łączącej klasy A,B i C liczność roli C specyfikuje, ile obiektów klasy C jest powiązanych z każdą możliwą parą obiektów klas A i B. Taka reguła jest zgodna z regułą przyjętą dla specyfikowania liczności asocjacji binarnych. Atrybuty Rok * sezon Zespół * Mecz * bramkarz Gracz Zapis gole nasze gole ich Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 135

136 Obejście asocjacji n-arnej Asocjacje n-arne mają sens wtedy, gdy do identyfikacji powiązania (n-arnego) potrzebne są wszystkie obiekty, tzn. gdy liczność każdej z ról jest wiele. W pozostałych przypadkach asocjację n-arną warto jest zastępować asocjacjami binarnymi, które są łatwiejsze do implementacji i wyposażone w dodatkowe własności, o których była mowa poprzednio. Niestety traci się informację o związku, łączącym grupę obiektów w pewną całość. K2 K2 K1 A K3 K1 a1 a2 KA K3 KA m1 a1 a2 m1 Asocjacja n-arna zostaje zamieniona na klasę i n asocjacji binarnych. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 136

137 Ograniczenia (przykład) Pracownik dane osobowe stanowisko pensja {pensja <= 5000} {pensja nigdy nie maleje} ograniczenie statyczne Ograniczenia stanowią kolejny z mechanizmów rozszerzalności w UML (po stereotypach i wartościach etykietowanych). ograniczenie dynamiczne (ważny jest poprzedni stan) Konto 1 {xor} 0..1 Osoba Firma Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 137

138 Ograniczenia (przykład) Osoba jest_członkiem * * {podzbiór} Komitet jest_przewodniczącym * podwładny * 0..1 Osoba * pracownik zatrudnia 0..1 pracodawca Firma szef {Osoba.pracodawca = Osoba.szef.pracodawca} Ograniczenie lub adnotacja Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 138

139 Zagadnienia Faza analizy Faza projektowania Perspektywy: pojęciowa, projektowa i implementacyjna Proces tworzenia modelu obiektowego Identyfikacja obiektów i klas DDD a RDD Identyfikacja klas poprzez identyfikację rzeczowników Metoda CRC Identyfikacja związków między klasami Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 139

140 Faza analizy Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Czynności wykonywane w fazie analizy to: ustalenie kontekstu projektu, ustalenie wymagań użytkowników, rozpoznawanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości będącej przedmiotem projektu. W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie wszystkich tych aspektów dziedziny problemowej, które mogłyby być poddane procesowi informatyzacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 140

141 Faza projektowania Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja Celem fazy projektowania jest opracowanie szczegółowego planu implementacji systemu. W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji. Projektanci muszą posiadać dobrą znajomość języków, bibliotek i narzędzi stosowanych w trakcie implementacji. Dąży się, by struktura projektu zachowywała strukturę modelu stworzonego w poprzedniej fazie (analizie) - podejście bezszwowe (seamless). Niewielkie zmiany w dziedzinie problemowej powinny implikować niewielkie zmiany w projekcie. Może to być realizowane, np. poprzez wykorzystanie podejścia obiektowego. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 141

142 Zadania fazy projektowania Zadania stojace przed wykonawcami w fazie projektowania: Uszczegółowienie wyników analizy. Projekt musi być wystarczająco szczegółowy aby mógł być podstawą implementacji. Stopień szczegółowości zależy od poziomu zaawansowania programistów. Projektowanie tych składowych systemu, które nie są związane z dziedziną problemową. Optymalizacja systemu. Dostosowanie do ograniczeń i możliwości środowiska implementacji. Określenie fizycznej struktury systemu (projekt architektury systemu). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 142

143 Uszczegóławianie wyników analizy Uszczegóławianie wyników analizy - poprzez podanie reguł odwzorowania notacji dla danych (notacji stosowanej w modelu pojęciowym - wyniku fazy analizy) w struktury tego języka programowania, który będzie wykorzystany do implementacji systemu. Dane z analizy Adres Ulica Numer domu Numer mieszkania Miasto Kod Realizacja w C/C++ typedef struct { char Ulica[30]; int NumerDomu; int NumerMieszkania; char Miasto[30]; char Kod[5]; } TypAdres; Dane osobowe Imię Nazwisko Adres Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 143 typedef struct { char Imię[30]; char Nazwisko[30]; TypAdres Adres; } TypDaneOsobowe;

144 Uszczegóławianie wyników analizy Uszczegóławianie metod: Podanie pełnych sygnatur metod (wyspecyfikowanie typu argumentów oraz wartości zwracanej dla każdej metody). Zastąpienie niektórych prostych metod publicznym dostępem do atrybutów, np. metod PobierzNazwisko, UstawNazwisko, etc. Zastąpienie niektórych atrybutów redundantnych (pochodnych) przez odpowiednie metody, np. Wiek = BieżącaData - DataUrodzenia; KwotaDochodu = KwotaPrzychodu - KwotaKosztów; Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 144

145 Uszczegóławianie wyników analizy Określenie sposobów implementacji asocjacji Asocjacje można zaimplementować na wiele sposobów, z reguły poprzez wprowadzenie dodatkowych atrybutów. Mogą one być następujące: obiekt (lub kolekcja obiektów) 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, m:n) możliwe są bardzo różne deklaracje w przyjętym języku programowania. Symbol graficzny * * Słowo kluczowe Tablica obiektów: Lista wskaźników: Tablica wskaźników: TypSłowoKluczowe SłowaKluczowe[100]; list<typsłowokluczowe*> SłowaKluczowe; char *WskaźnikiSłówKluczowych[100]; Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 145

146 Raczej projektowanie niż analiza Asocjacje skierowane: oprócz oznaczenia asocjacji zaznacza się też kierunek przesyłania komunikatów (nawigację). Np. w systemie Systemie Informacji Graficznej nawigacja jest możliwa jedynie od obiektów klasy Symbol graficzny do obiektów Słowo kluczowe. Jest to jeden ze scenariuszy; w innym może być inaczej. Symbol graficzny * * Słowo kluczowe Oznaczenia dostępności dla atrybutów i metod: (+) publiczny - dla wszystkich (#) zabezpieczony (protected) - dostęp dla obiektów danej klasy oraz jej specjalizacji (-) prywatny - dostęp tylko dla obiektów danej klasy Symbol graficzny # Nazwa # Rysuj + Wyświetl + Wyświetl_opis * * Słowo kluczowe + Nazwa + Stan + Pobierz_stan + Zmień_stan Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 146

147 Raczej projektowanie niż analiza Szczegółowe specyfikacje atrybutów i metod Wzorce klas (szablony) Metaklasy, tj. klasy zawierające atrybuty i metody dotyczące klasy jako całości, a nie pojedynczych obiektów, np. atrybuty i metody statyczne (klasy). Wolne funkcje - funkcje nie będące metodami żadnej z klas. Stereotypy (np.: «persistent», «constructor», «query») wartości etykietowane? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 147

148 Składowe nie związane z dziedziną problemową Projekt skonstruowany drogą uszczegółowienia modelu obiektowego (wyniku fazy analizy) opisuje składowe systemu odpowiedzialne za realizację podstawowych zadań systemu. Gotowe oprogramowanie musi także zawierać składowe nie związane z dziedziną problemową: składową interfejsu użytkownika, składową zarządzania danymi (przechowywanie trwałych danych), składową zarządzania pamięcią operacyjną, składową zarządzania zadaniami (podział czasu procesora). Składowa zarządzania pamięcią (kompilator, system operac.) (kompilator, system operac.) Składowa zarządzania zadaniami Składowa dziedziny problemowej Składowa interfejsu użytkownika (do 90% nakładów; obecnie poprzez GUI) (SZBD) Składowa zarządzania danymi Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 148

149 Perspektywy Można wyróżnić trzy perspektywy, które powinny być brane pod uwagę w trakcie w konstruowania dowolnego modelu (diagramu): Perspektywa pojęciowa (koncepcyjna) - model przedstawia wyłącznie pojęcia funkcjonujące w dziedzinie problemu (w analizowanej rzeczywistości ): np. mówimy o operacjach wykonywanych na bytach, a nie o implementujących je metodach, a atrybuty to cechy opisujące byty. Asocjacje opisują związki semantyczne istniejące między bytami. Model pojęciowy w ogóle (lub w bardzo niewielkim stopniu) powinnien interesować się implementującym go softwarem. Perspektywa projektowa - tu uwzględniamy już software, ale interfejs a nie implementację, czyli myślimy tu raczej o typach niż o klasach. Typ reprezentuje interfejs, który może mieć wiele implementacji, np. uzależnionych od środowiska programowania (przyjętej platformy), żądanych charakterystyk wydajnościowych czy nawet sprzedawcy. Chociaż podejście obiektowe kładzie wielki nacisk na rozróżnienie między interfejsem a implementacją, w praktyce w wielu językach obiektowych nie oddziela się wyraźnie interfejsu od implementacji, co się zresztą zmienia na lepsze (przykład: Java, Corba). Perspektywa implementacyjna Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 149

150 Perspektywy Zrozumienie perspektywy, która była brana pod uwagę w trakcie konstruowania danego modelu, jest ważnym czynnikiem mającym wpływ na prawidłowe interpretowanie modelu. Prawidłowa interpretacja, dobre zrozumienie jest warunkiem koniecznym prawidłowego wykorzystania później. Niestety nie dość, że granice między perspektywami nie są wyraźnie zakreślone, to jeszcze wielu analityków i projektantów w ogóle lekceważy ten problem i konstruuje swoje modele od razu z perspektywy implementacyjnej, podczas gdy te inne mogłyby w danym momencie być znacznie bardziej użyteczne. Nadmiar informacji może też stanowić stanowić pewne ograniczenie. Zalecenia: jeśli konstruujesz model, konstruuj go z jednej, wyraźnie określonej perspektywy, perspektywę tę możesz opisać wykorzystując stereotypy lub wartości etykietowane, kiedy przeglądasz model musisz być świadom z jakiej perspektywy został skonstruowany, aby go poprawnie zinterpretować. Modele, tak jak i całość projektu, zawsze powstają (a przynajmniej powinny powstawać) w sposób iteracyjny i przyrostowy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 150

151 Tworzenie modelu obiektowego (dwie drogi) Zadania: Identyfikacja obiektów i klas Identyfikacja związków pomiędzy klasami (generalizacji-specjalizacji oraz asocjacji) Identyfikacja i definiowanie atrybutów Identyfikacja i definiowanie metod i komunikatów Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 151

152 Identyfikacja klas Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania. Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej dziś i to dla specyficznego być może zastosowania. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne. Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla technologii ponownego użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 152

153 Typowe klasy Typowe klasy: przedmioty namacalne (samochód, czujnik) grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części) role pełnione przez osoby (pracownik, wykładowca, student) zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa) interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (pożyczka, spotkanie, sesja) lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów organizacje (firma, wydział, związek) wydarzenia (posiedzenie sejmu, demonstracja uliczna) koncepcje i pojęcia (zadanie, miara jakości) dokumenty (faktura, prawo jazdy) Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 153

154 Obiekty, zbiory obiektów, metadane W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju bytem mamy do czynienia. Należy zwrócić uwagę na następujące aspekty: czy mamy do czynienia z konkretnym bytem w danej chwili czasowej? czy mamy do czynienia z konkretnym bytem w pewnym odcinku czasu? czy mamy do czynienia z opisem tego bytu (dokument, metadane)? czy mamy do czynienia z pewnym zbiorem konkretnych bytów? Np. klasa samochód. Może chodzić o: egzemplarz samochodu wyprodukowany przez pewną fabrykę historię stanów pewnego konkretnego samochodu pozycję w katalogu samochodów opisujący własności modelu model samochodu produkowany przez fabrykę Podobnie z klasą gazeta. Może chodzić o: konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) tytuł i wydawnictwo, niezależne od egzemplarzy i wydań partię egzemplarzy danej gazety dostarczaną codziennie do kiosku Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 154

155 DDD a RDD Eksperci od podejścia obiektowego do procesu tworzenia oprogramowania dzielą się na dwa obozy w zależności od proponowanego przez nich sposobu identyfikacji klas: w oparciu o dane (DDD - Data Driven Design), w oparciu o odpowiedzialności klas (RDD - Responsibility Driven Design). Odpowiedzialność klasy odpowiada zbiorowi zachowań obiektów tej klasy. DDD - polega na zidentyfikowaniu wszystkich danych w systemie i podziale ich na klasy bez specjalnego rozważania ich odpowiedzialności; przykładem tej techniki jest identyfikacja rzeczowników i fraz rzeczownikowych w tekście wymagań. RDD - tutaj rozpoznaje się wszystkie odpowiedzialności systemu (w oparciu o potrzeby przyszłych użytkowników) i bazując na nich wyróżnia się klasy; przykładem jest tu metoda CRC wykorzystywana w kilku metodykach. Najbardziej efektywne, jak to z reguły w praktyce bywa, są techniki mieszane, wykorzystujące każdą dostępną metodę. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 155

156 Metoda CRC Metoda CRC (Class, Responsibilities, Collaborations) została zaprezentowana przez K. Beck a i W. Cunningham a w 1989 r. w celu ułatwienia programistom nie-obiektowym naukę myślenia obiektowego. Okazała się być przydatna na wczesnych etapach rozwoju systemu do identyfikacji klas. Metoda CRC nie jest częścią UML. Na małej kartce papieru notuje się następujące elementy: u góry kartki - nazwę klasy, po lewej stronie - odpowiedzialności (responsibilities), czyli obowiązki danej klasy, po prawej stronie - współpracowników (collaborators), czyli klasy, które pomagają danej klasie w wypełnianiu jej obowiązków. Odpowiedzialności danej klasy opisywane są na wysokim poziomie abstrakcji - jako podstawa (główny powód, cel) zaistnienia danej klasy. Są powiązane z operacjami, które można wykonywać na obiektach tej klasy, ale są wyrażone w bardziej ogólny sposób. Np. akceptowalna jest odpowiedzialność, taka jak zarządzanie danymi dotyczącymi książki, co implikuje operacje, które czytają i zapisują dane. Klasa nie powinna mieć więcej niż trzy, cztery odpowiedzialności (wiele klas ma tylko jedną lub dwie). Jeśli klasa ma zbyt dużo odpowiedzialności (niska kohezja), należy zastanowić się czy zostały one dostatecznie zwięźle określone lub czy nie rozdzielić odpowiedzialności i mieć więcej klas. Zbyt wielu współpracowników sugeruje zbyt silne skojarzenie klas. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 156

157 Metoda CRC CRC wykorzystuje się wspólnie z przypadkami użycia - postępując w zgodzie ze scenariuszem identyfikuje klasy, których odpowiedzialności włączają potrzebną operację i znajduje ewentualnych współpracowników, zaangażowanych w realizację danego przypadku użycia. Upraszczając - odpowiedzialności każdej klasy mogą być postrzegane jako suma operacji, które można wykonywać na obiektach tej klasy. Kiedy brakuje klasy, która mogła by wykonać potrzebną operację, oznacza to błędy lub braki w modelu. Być może trzeba dodać nową klasę lub zmienić odpowiedzialności lub współpracowników klasy już istniejącej (być może jedno i drugie). Związek generalizacji-specjalizacji jest tu wyjaśniany w kategoriach współdzielenia odpowiedzialności i współpracowników. Klasa specjalizowana ma te własności odpowiednio większe. Sytuacja ta może też być postrzegana w drugą stronę - jeśli dwie klasy mają nakładające się odpowiedzialności i współpracowników, to może to być sugestia dla wydzielenia dla nich nadklasy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 157

158 DDD; identyfikacja klas poprzez rzeczowniki Identyfikacja klas poprzez identyfikację rzeczowników i fraz rzeczownikowych w tekście specyfikującym wymagania użytkownika jest jedną z podstawowych, powszechnie stosowanych technik. Proces ten przebiega w dwóch etapach: Identyfikacja potencjalnych klas poprzez podkreślenie wszystkich rzeczowników i fraz rzeczownikowych w tekście wymagań. Odrzucenie niektórych kandydatów i zmiana nazw, o ile wyniknie taka potrzeba. Nazwy przyszłych klas powinny być rozważane jako rzeczowniki w liczbie pojedynczej. Niektórzy analitycy konstruują dwie listy potencjalnych kandydatów: silnych i słabych. Kandydaci są przenoszeni w razie potrzeby z listy na listę. Taka technika chroni przed utratą informacji, być może przydatnej krok dalej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 158

159 Redukcja zbioru potencjalnych kandydatów Odrzucamy potencjalnego kandydata na klasę, gdy rzeczownik (fraza rzeczownikowa): jest redundantny - tzn. gdy istnieją różne rzeczowniki dla określenia tego samego bytu; trzeba tu brać pod uwagę następujący fakt: byty mogą być podobne, ale niekoniecznie dokładnie takie same, a to z kolei może wskazywać na związek generalizacji-specjalizacji istniejący między nimi; jest nieuchwytny - trudno jest określić, co właściwie oznacza i w jaką klasę miałby być odwzorowany - być może inne elementy notacji byłyby bardziej użyteczne do opisania go; oznacza wydarzenie lub operację - tutaj pomocnicze może być zadanie pytania, czy obiekty przyszłej klasy miałyby atrybuty, zachowanie i tożsamość; stanowi wyrażenie metajęzyka, tzn. służy do definiowania czegoś, np. rzeczowniki wymagania czy system używane są raczej w procesie modelowania niż do reprezentowania bytów istniejących w analizowanej dziedzinie problemowej; oznacza coś, co znajduje się na zewnątrz systemu, np. aktorzy - z reguły nie istnieje potrzeba do modelowania ich w postaci klasy; oznacza atrybut - coś prostszego niż klasa, bez interesującego zachowania. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 159

160 DDD - identyfikacja klas; przykład Przykład wymagań dla biblioteki: Biblioteka zawiera książki i czasopisma. Może być kilka egzemplarzy tej samej książki. Tylko personel może wypożyczać czasopisma. Członek biblioteki może mieć jednocześnie wypożyczonych sześć pozycji, podczas gdy osoba pracująca w bibliotece może mieć ich wypożyczonych dwanaście. System musi rejestrować wypożyczenia i zwroty oraz pilnować, by przestrzegano wymienionych powyżej reguł (ograniczeń). Zostawiamy: książka, czasopismo, egzemplarz książki, członek biblioteki, personel Odrzucamy: biblioteka (1 obiekt i to znajdujący się na zewnątrz systemu ), system (wyrażenie metajęzyka), osoba pracująca w bibliotece oznacza to samo co personel, reguła (nieuchwytne), ograniczenie (nieuchwytne) pozycja (?), wypożyczenie (?), zwrot (?), Każdy rzeczownik, kandydat na przyszłą klasę, jest tu rozważany w liczbie pojedynczej. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 160

161 CRC- identyfikacja klas; przykład Członek bibl. Odpowiedzialności Współpracownicy zarządzanie danymi dotyczącymi członka biblioteki kontrola wypełniania ograniczeń narzuconych na liczbę egzemplarzy egzemplarz Książka. Odpowiedzialności zarządzanie danymi dotyczącymi książki sprawdzanie, czy są egzemplarze możliwe do wypożyczenia Współpracownicy egzemplarz Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 161

162 Identyfikacja generalizacji-specjalizacji Identyfikacja związków generalizacji-specjalizacji Osoba Pozycja Personel Członek bibl. Książka Czasopismo Książka Egzemplarz książki Egzemplarz książki nie jest rodzajem pozycji wydawniczej, jaką oznacza tu każde wystąpienie klasy Książka. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 162

163 Identyfikacja asocjacji Identyfikacja asocjacji: podobnie, jak klasy można identyfikować poprzez wyszukiwanie rzeczowników (czy fraz rzeczownikowych) w tekście wymagań, tak asocjacje mogą być identyfikowane poprzez wyszukiwanie w tym tekście czasowników (fraz czasownikowych). Z przykładu z biblioteką moglibyśmy wydedukować następujące asocjacje: wypożyczył, zwrócił, jest egzemplarzem,. Nie wszystkie wystąpiły jawnie - w postaci czasowników (czy fraz czasownikowych). Asocjacja (o danej semantyce) musi połączyć Klasę A z klasą B jeżeli w czasie działania programu: obiekt klasy A wysyła komunikat do obiektu klasy B, obiekt klasy A tworzy obiekt klasy B (wywołuje konstruktor), obiekt klasy A posiada atrybut będący obiektem (lub kolekcją obiektów) klasy B, obiekt klasy A otrzymuje komunikat z argumentem będącym obiektem klasy B. W skrócie - jeśli obiekt klasy A musi mieć możliwość dostępu do danych pewnego obiektu klasy B, to klasy A i B musi połączyć asocjacja. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 163

164 Identyfikacja asocjacji Uwaga - nie archiwizujemy tu wypożyczeń; fakt zwrotu jest rejestrowany poprzez usunięcie powiązania wypożyczyła między obiektami klas Osoba i Egzemplarz Książki. Osoba wypożyczyła 0..1 * Egzemplarz Książki Osoba Wypożyczenie 1 * Egzemplarz Książki Preferowane jest rozwiązanie pierwsze - klasa Wypożyczenie nie posiada żadnych własności, ani atrybutów ani operacji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 164

165 Identyfikacja asocjacji Sytuacja ulegnie zmianie, gdy do poprzednich wymagań dołożymy sformułowanie: Książki mogą być wypożyczane na okres trzech tygodni, wypożyczanie książek jest archiwizowane, co implikuje konieczność pamiętania obu dat: wypożyczenia i zwrotu. Osoba wypożyczyła * * Egzemplarz Książki Wypożyczenie data wypożyczenia data zwrotu {data zwrotu - data wypożyczenia <= 3 tygod.} Osoba Wypożyczenie data wypożyczenia data zwrotu 1 * * 1 Egzemplarz Książki {data zwrotu - data wypożyczenia <= 3 tygod.} Oba rozwiązania są tu poprawne. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 165

166 Identyfikacja asocjacji asocjacja wypożyczył między klasami Personel i Czasopismo Personel wypożyczył 0..1 * Czasopismo nie archiwizuje się wypożyczeń dla czasopism, ani nie zostały nałożone żadne ograniczenia na długość okresu wypożyczenia asocjacja jest egzemplarzem między klasami Książka i Egzemplarz książki Książka 1 1..* Egzemplarz książki Książka 1..* Egzemplarz książki kompozycja silniej podkreśla tu związek istniejący między książką (byt wirtualny), a konkretnym egzemplarzem Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 166

167 Diagram klas dla przykładowych wymagań * Osoba /liczba wyp. akt. pozycji Pozycja Członek bibl. { liczba wyp. akt. pozycji <= 6 } Personel 0..1 { liczba wyp. akt. pozycji <= 12 } wypożyczył Czasopismo * * Książka 1..* Egzemplarz książki Wypożyczenie data wypożyczenia data zwrotu { data zwrotu - data wypożyczenia <= 3 tygodnie } Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 167

168 Model obiektowy - uwagi Konstruując system zawsze należy mieć na uwadze dwa główne cele, które powinny zostać osiągnięte: zbudowanie systemu (który spełni aktualne potrzeby klienta) tak szybko i tanio, jak tylko jest to możliwe, zbudowanie systemu, który będzie łatwy do utrzymania (konserwacji) i łatwo adaptowalny do przyszłych wymagań. Pierwszy cel można osiągnąć poprzez wyróżnienie obiektów, przypisanie im własności (atrybutów i zachowań), zgrupowanie ich w klasy, czyli skonstruowanie modelu obiektowego, a następnie zapewnienie sensownej realizacji wymagań klienta (wyspecyfikowanych w modelu przypadków użycia) - poprzez ustalenie dróg przesyłania komunikatów między obiektami w systemie - tu będą pomocne diagramy dynamiczne. Cel drugi można osiągnąć budując system modularny, złożony z komponentów oprogramowania (klas, modułów, ) o wysokiej kohezji (high cohesion) i słabych skojarzeniach wzajemnych (low coupling). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 168

169 Model obiektowy - uwagi Ważne: Identyfikując klasy, asocjacje np. poprzez wyszukiwanie rzeczowników, czasowników w tekście wymagań, nigdy nie należy tracić z oczu perspektywy pojęciowej - skonstruowany model obiektowy nie może zniekształcać relacji istniejących w analizowanej rzeczywistości, tzn. w tym fragmencie dziedziny problemowej, którym zajmuje się tworzony system. Osoby, znające daną dziedzinę nie mogą być nieprzyjemne niespodzianki! narażone na Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 169

170 Projektowanie systemów informacyjnych Zagadnienia: Dziedziczenie asocjacji Asocjacje pochodne Redukcja liczności Role wielowartościowe Trochę więcej o agregacji Agregacja rekursywna Trochę więcej o asocjacji kwalifikowanej Trochę więcej o mechanizmach rozszerzalności Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 170

171 Dziedziczenie asocjacji K1 {incomplete} K1 a K2 K3 K4 a K a K2 K3 K Aby asocjacje a (diagram po lewej stronie) mogły zostać zastąpione jedną asocjacją a poprowadzoną od nadklasy K1 do klasy K (diagram po prawej stronie) obie asocjacje a z diagramu po lewej stronie muszą spełniać następujące warunki: muszą mieć tą samą semantykę, muszą mieć tą samą strukturę, asocjacja a musi łączyć klasę K z wszystkimi podklasami klasy K1. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 171

172 Dziedziczenie asocjacji 0..1 Referat tytuł autorzy [1..*] Zaproszony 1..* Zwykły ocena Termin godz. wygłaszany wygłaszany 1..* Sesja nazwa data 1 Nazwa dla klasy asocjacji? wygłaszany Termin godz. Termin godz. Zastosowanie dziedziczenia asocjacji spowodowało, że część informacji nie została przeniesiona na nowy diagram (zmiany zostały oznaczone czerwonym kolorem). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 172

173 Asocjacje pochodne Osoba 1..* mieszka 1 Miasto 1..* 1 pracuje w? pracodawca znajduje się Firma 1..* Możliwe asocjacje pochodne: /mieszka lub /znajduje się 1) Jeśli Osoba mieszka w mieście w którym pracuje, to któraś z asocjacji: mieszka lub znajduje się powinna zostać oznaczona jako pochodna (albo usunięta z diagramu). 2) Jeśli liczność roli pracodawca wynosi 0..1 asocjacja mieszka nie będzie pochodna, ponieważ nie dla wszystkich obiektów powiązania będą mogły być wydedukowane. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 173

174 Redukcja liczności Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu K1 x K y K2 K1 K a1 a2 1 1 y x K2 a1 a2 gdzie: x, y oznaczają liczności wiele Przykład Osoba 1..* * Zatrudnienie stanowisko pensja Firma Osoba 1..* Zatrudnienie * * * stanowisko pensja Firma /pracodawca Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 174

175 Role wielowartościowe Rola wielowartościowa to taka rola, dla której górna granica liczności jest większa od 1. K1 1 r1 r2 K2 Rola r2 jest tu rolą wielowartościową. Uwaga: * W sensie dosłownym, liczności obu końców asocjacji oznaczają liczności obu ról. Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów opisującego daną rolę. K1 * a {ordered} 1..2 K2 Przyjmuje się domyślnie: zbiór obiektów, opisujący daną rolę, jest nieuporządkowany, dany obiekt pojawia się tylko jeden raz w w zbiorze obiektów opisującym rolę, powyższe reguły mogą zostać zmienione dzięki ograniczeniom {ordered}, {bag} i stereotypowi «history». :K1 :K1 a a a :K2 :K2 :K2 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 175

176 Role wielowartościowe Dwa powiązania między dwoma tymi samymi obiektami występują też w sytuacji, jak poniżej, ale nie są to powiązania o tej samej semantyce, jak w przykładzie poprzednim. * Osoba 1 pracuje {subset} jest dyrektorem 0..1 Firma 0..1 Nowak : Osoba pracuje jest dyrektorem IBM : Firma Ograniczenie: {bag} :Zatrudnienie Osoba 1..* {bag} * Firma X:Osoba programista 2000 Y:Firma Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja :Zatrudnienie NULL analityk 5000 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 176

177 Role wielowartościowe Stereotyp: «history» dla oznaczenia roli pracodawca Osoba 1..* «history» pracodawca * Firma Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja :Osoba Stereotyp «history», podobnie jak ograniczenie {bag}, pozwala na utworzenie więcej niż jednego powiązania o danej semantyce między dwoma obiektami, ale wykorzystywanie go jest raczej ukierunkowane na rejestrowanie zmian w czasie. :Zatrudnienie programista 2000 :Zatrudnienie NULL analityk 5000 :Firma Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 177

178 Role wielowartościowe Zatrudnienie Osoba * data zatrudnienia data zwolnienia stanowisko pensja 1..* Firma :Zatrudnienie :Osoba programista 2000 :Firma Zastosowanie klasy pośredniczącej Zatrudnienie wprawdzie pozwala na utworzenie wielu powiązań pracuje między dwoma tymi samymi obiektami, wystąpieniami klas Osoba i Firma, ale nie uwidacznia tego faktu. :Zatrudnienie NULL analityk 5000 Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 178

179 Agregacja Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowanie związku całość-część. agregacja jest asocjacją: dla obu jej końców są określane liczności, a także może mieć atrybuty, np. Grupa * Termin od do Student agregacja jest wykorzystywana do modelowania związku całość-część Grupa * całość część Student Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 179

180 Agregacja Inne nazwy dla ról agregacji: całość składa się z zawiera obejmuje, itp. część wchodzi w skład należy jest zawarta w, itp. Nazwa agregacji i nazwy jej ról, jako oczywiste, są pomijane! Własności agregacji: A B jest relacją niesymetryczną, tzn. jeśli B jest częścią A, to A nie jest częścią B A B C jest relacją przechodnią (tranzytywną), tzn. jeśli C jest częścią B i B jest częścią A, to C jest częścią A Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 180

181 Agregacja Kryteria służące analitykowi pomocą w podjęciu decyzji czy do modelowania pojęciowego wykorzystać agregację, czy też zwykłą asocjację. kryterium istnienia (część nie istnieje samodzielnie bez całości), kryterium wstawiania (nie ma sensu wstawianie części do systemu, jeśli nie wstawiono do niego całości), kryterium usuwania (usuwanie całości powinno skutkować usunięciem wszystkich powiązanych z tą całością części), kryterium fizycznej części. plan Grupa zmień plan zmień plan * Termin od do Student plan zmień plan Wszystkie kryteria zawiodły, a mimo to zdecydowano się zastosować agregację, ponieważ lepiej niż zwykła asocjacja modeluje związek część-całość - pewne operacje można wykonywać na całości, a nie na każdej z części oddzielnie. Operacja zmień plan została oznaczona jako ta, która będzie automatycznie wykonana dla wszystkich części, wtedy gdy zostanie wywołana dla całości (propagacja operacji). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 181

182 Agregacja rekursywna Agregacja rekursywna? K? Obiekt klasy K może zarówno wchodzić w skład innych obiektów klasy K, jak i zawierać obiekty klasy K K 0..1 :K :K :K Co by było, gdyby któryś z końców tej agregacji (lub oba końce) oznaczyć licznością dokładnie 1 zamiast liczności opcjonalnej 0..1? Jakie zmiany wprowadziłoby do powyższego diagramu zastosowanie zwykłej asocjacji zamiast agregacji? Czy można tu zastosować kompozycję? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 182

183 Agregacja rekursywna * K 0..1 :K :K :K :K :K :K :K Czy można tu zastosować liczność dokładnie 1 zamiast 0..1 i liczność 1..* zamiast liczności *? I Część nazwa materiał rozmiary * 0..1 II Firma 1 * Oddział * 0..1 Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji wydaje się być bezdyskusyjna? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 183

184 Agregacja rekursywna * K * :K :K :K :K :K :K :K Przykłady agregacji rekursywnych I Program II 1..* * 1 Blok 2-gi operand 1-szy operand 1 1 Człon Jak wyglądałby diagram obiektowy dla wyrażenia, np. (x + y/2) * (x/3 - y) 0..1 Instrukcja złożona Instrukcja prosta * Wyrażenie * operator binarny Zmienna nazwa Stała wartość Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 184

185 Asocjacja kwalifikowana Katalog 1 * Plik nazwa { nazwa pliku jest unikatowa w ramach katalogu } Katalog nazwa pliku Plik Perspektywa pojęciowa - plik jest w ramach katalogu jednoznacznie identyfikowany przez nazwę. Perspektywa projektowa - wskazanie na to, że katalog plików można zorganizować jako tablicę asocjacyjną lub słownik (przeszukiwanie za pomocą nazwy pliku). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 185

186 Asocjacja kwalifikowana Tablica Tablica rząd kolumna 1 1 Kwadrat rząd kolumna Kwadrat Kwalifikator asocjacji może stanowić więcej niż jeden atrybut. Warunek - wartości tych atrybutów muszą pozwolić na jednoznaczną identyfikację obiektu w ramach pewnego zbioru obiektów (tutaj - w ramach zbioru kwadratów należących do jednej konkretnej tablicy, czyli jednego obiektu klasy Tablica). Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty. Bank nazwa * * Osoba imię nazwisko Bank nazwa nr. konta * 0..1 Osoba imię nazwisko nr konta data założ. data założ. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 186

187 Mechanizmy rozszerzalności w UML W UML istnieją trzy rodzaje mechanizmów rozszerzalności: stereotypy, wartości etykietowane, ograniczenia. Stereotypy Stereotypy umożliwiają meta-klasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementów modelu (elementu metamodelu UML), np. relacji między przypadkami użycia, klas czy metod. Dany element modelu (np. jedna relacja między przypadkami użycia, klasa czy metoda) może mieć co najwyżej jeden stereotyp. Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne. Stereotypy rozszerzają semantykę metamodelu. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 187

188 Stereotypy - notacja Notacja: zwykle «nazwa stereotypu» lub ikona, ale można też używać koloru czy tekstury, choć z różnych względów nie jest to polecane (ograniczenia ludzkie lub sprzętu). «lub» guillemets - jeden znak - używany w charakterze cudzysłowia w jęz. francuskim (a) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) (b) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) ikona (c) PióroŚwietlne lokacja: Punkt uruchom (Tryb) (d) PióroŚwietlne Ikona może być używana na 2 sposoby: zamiast symbolu stereotypu (c, d) lub razem z nim (b). W przypadkach a, b, c zawartość elementu modelu opatrzonego stereotypem (tu: klasy Pióro Świetlne) jest widoczna. W przypadku d została opuszczona. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 188

189 Stereotypy; przykłady P1 «include» P2 P3 «extend» P4 rodzaj elementów modelu: relacje między przypadkami użycia lista stereotypów dla tego rodzaju: «include» i «extend» Każda relacja między przypadkami użycia (element modelu) jest opatrzona jednym z dwóch stereotypów z powyższej listy. «trwała» Prostokąt punkt1: Punkt punkt2: Punkt «konstruktory» Prostokąt (p1: Punkt, p2: Punkt) «zapytania» obszar () : Real aspekt() : Real... «aktualizacje» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) «trwała» Prostokąt punkt1: Punkt punkt2: Punkt «konstruktory» Prostokąt (p1: Punkt, p2: Punkt) «zapytania» obszar () : Real aspekt () : Real... przesuń (delta: Punkt) przeskaluj (współczynnik: Real) Jednym stereotypem można opatrzyć całą listę elementów modelu. Koniec listy może być oznaczany przez. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 189

190 Wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Dowolny łańcuch znaków może być użyty jako słowo kluczowe. Są słowa kluczowe predefiniowane, ale użytkownik może też definiować własne. Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. Dowolny element modelu może być skojarzony nie tylko z listą wartości etykietowanych, ale w bardziej ogólnym sensie z łańcuchem własności, w postaci: {dowolny łańcuch znaków}. Wartości etykietowane Wartości etykietowane są używane do skojarzenia arbitralnej informacji z pojedynczym elementem modelu. Przykład: {autor = Jan Nowak, termin zakończenia = 31 Maja 1999, status = analiza} Wartości etykietowane są szczególnie przydatne do przechowywania informacji związanych z zarządzaniem projektem (jak w przykładzie powyżej) czy szczegółów implementacyjnych. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 190

191 Ograniczenia Ograniczenia specyfikują restrykcje nakładane na elementy modelu. Mogą stanowić wyrażenia języka naturalnego czy języka formalnego (np. OCL w UML), mogą też przyjmować postać formuły matematycznej lub fragmentu kodu (czy też pseudokodu). Notacja: są zawarte wewnątrz {} i umieszczane za elementem w klasie, lub poza klasą. Mogą też być umieszczane w komentarzu (przykład na następnej folii). Pracownik imię nazwisko pensja {<=10 000} Pracownik imię nazwisko pensja {pensja <=10 000} zmień pensję (nowa) ograniczenie statyczne {pensja nie wzrasta o więcej niż 300} ograniczenie dynamiczne Ograniczenie dynamiczne - tu interesuje nas poprzedni stan elementu, na który jest nałożone ograniczenie. Czy powiedzie się próba zmiany pensji z 2500 na 5500? Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 191

192 Konto * należy * do Ograniczenia; przykłady Symbole, takie jak oraz > mogą być używane do wskazywania elementów, na które zostały nałożone ograniczenia. {xor} Firma Osoba podwładny * 0..1 szef Osoba 1..* pracownik 0..1 pracodawca Firma {Osoba.pracodawca = Osoba.szef.pracodawca} ograniczenie w komentarzu Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 192

193 Ograniczenia predefiniowane; przykłady j. angielski j. polski {complete} {incomplete} {disjoint} {overlapping} {or} {xor} {ordered} {subset} {bag} {history} {hierarchy} {dag} dag - directed acyclic graph {podział całkowity} {podział niecałkowity} {podział rozłączny} {podział nierozłączny} {lub} {albo} {uporządkowane} {podzbiór} {wielozbiór} {historia} {hierarchia} {graf acykliczny skierowany} Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 193

194 Design by Contract W idealnym przypadku ograniczenia powinny być implementowane jako asercje w docelowym języku programowania. Asercje są sercem metody projektowania Design by Contract zastosowanej przez Bertranda Meyer a w języku Eiffel. Design by Contract nie jest metodą specyficzną dla tego tylko języka - może i powinna być wykorzystana w każdym. Asercja - to wyrażenie typu Boolean (warunek), którego wartość = FALSE prowadzi do błędu. Zwykle asercje są testowane jedynie podczas debuggowania. Design by Contract używa 3 rodzajów asercji: warunek wstępny (precondition) - definiuje, co powinno być spełnione, aby dana operacja wykonała się poprawnie (jak powinien wyglądać świat sprzed ), warunek końcowy (postcondition) - określa, co będzie po poprawnym wykonaniu operacji ( świat po ), inwariant - asercja, definiowana dla klas posiadających dane, które nie powinny ulec zmianie po wykonaniu operacji; ten warunek musi być zawsze spełniony dla wszystkich wystąpień danej klasy. Na bazie definicji warunków wstępnego i końcowego można sformułować definicję wyjątku (exception) - zachodzi przy spełnionym warunku wstępnym i niemożliwości spełnienia warunku końcowego. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 194

195 Design by Contract Warunki, jak powyżej, mają kluczowe znaczenie dla wykonania się operacji i są zupełnie niezależne od kontekstu, w jakim operacja jest wywoływana. Bertrand Meyer stwierdza, że obecność tych warunków należy traktować jako kontrakt wiążący daną operację i operacji wywołujących ją. Operacja gwarantuje: jeśli wywołasz mnie ze spełnionym warunkiem wstępnym, to obiecuję doprowadzić do stanu, w którym będzie spełniony warunek końcowy [Meyer 1988,1992]. Warunki nie narzucają konkretnej implementacji w języku programowania. Przykład: dane pracownika są usuwane po 2 latach od daty warunek wstępny: minęło 2 lata, warunek końcowy: dane pracownika zostały usunięte z zasobów. Kto powinien być odpowiedzialny za poprawność warunków (aby uniknąć nadmiaru kontroli) - w idealnym przypadku: za warunek wstępny - operacja wywołująca, za warunek końcowy i inwarianty - operacja wywoływana. Warunki wstępne i końcowe powinny być dokumentowane łącznie z dokumentowaniem operacji. W idealnym przypadku powinny stanowić część kodu definiującego interfejs. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 195

196 Przykład asercji w języku Eiffel Class STACK[T] export nb_elements,empty, full, push, pop, top feature nb_elements : INTEGER;... push(x : T) is - Add on top require not full; do... ensure not empty; top=x; nb_elements=old nb_elements + 1 end; - push... Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 196

197 Przykład asercji w języku Eiffel (cd.) invariant 0 nb_elements; nb_elements max_size; empty = (nb_elements = 0) end; - class STACK Inwarianty mogą przybierać wartość = FALSE jedynie w trakcie wykonywania operacji. Przykład Tablica sortuj «postcondition» {po sortowaniu: nie zmienia się liczba elementów; każda wartość pojawia się tyle samo razy, co przed sortowaniem; dla kolejnych wartości x i y zachodzi x <= y } Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 197

198 OCL - Object Constraint Language OCL jest językiem o notacji tekstowej służącym do specyfikowania warunków, ograniczeń, asercji i zapytań (zapisu wyrażeń ścieżkowych). OCL zawiera pewien zestaw predefiniowanych operatorów do operowania na elementach kolekcji czy typach podstawowych, ale nie jest przeznaczony do zapisywania kodu wykonalnego. Podstawowe elementy składni OCL: element.selektor selektor może być nazwą atrybutu (opisującego element) - wtedy zwracana jest albo wartość albo zbiór wartości atrybutu selektor może być nazwą roli (celu) - wtedy zwracany jest zbiór powiązanych obiektów Przykład a A m A A 1 * r A r B a B m B B Niech O A oznacza pewien obiekt klasy A, wtedy: wyrażenie O A. a A zwróci wartość atrybutu a A wyrażenie O A. r B zwróci zbiór obiektów klasy B powiązanych z danym obiektem O A Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 198

199 OCL - Object Constraint Language element.selektor (lista arg) selektor jest nazwą operacji wywoływanej dla elementu, wartością wyrażenia jest tu wynik zwracany przez operację element.selektor (kwalifikator) selector specyfikuje asocjację kwalifikowaną; element plus wartość kwalifikatora jednoznacznie identyfikują zbiór powiązanych obiektów zbiór-> własność-zbioru własność-zbioru stanowi nazwę wbudowanej w OCL funkcji na zbiorze, np. select, reject, size zbiór->select (warunek) zwraca podzbiór elementów spełniających wyspecyfikowany warunek zbiór->reject (warunek) zbiór->size self operator zwraca podzbiór elementów nie spełniających wyspecyfikowanego warunku zwraca liczność zbioru specyfikuje aktualnie rozważany obiekt (może być opuszczony, gdy kontekst jest znany) np.=, <, >, <=, >=, <>, +, -, *, /, not, and, or, xor Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 199

200 OCL - Object Constraint Language Przykłady lot.pilot.godziny_treningowe >= lot.samolot.min_godz może być wykorzystane do zwrócenia zbioru pilotów, którzy wylatali odpowiednią dla danego samolotu liczbę godzin firma.pracownik->select (tytuł = szef and self.raport->size >10) zwróci zbiór pracowników będących szefami, którzy dostarczyli więcej niż 10 raportów Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 200

201 Zasada zamienialności a ograniczenia Zasada zamienialności (byt programistyczny typu B może zastąpić byt typu A, o ile B jest podtypem A) przenosi się na ograniczenia w sposób wyrażony poniższym potocznym stwierdzeniem: Nie żądaj więcej, nie obiecuj mniej ( demand no more, promise no less ). m A Obiekt klasy B może zastąpić obiekt klasy A, co oznacza, że jego zachowanie z punktu widzenia obiektu wysyłającego komunikat wywołujący metodę m, powinno być takie same, jak gdyby komunikat wysłano do obiektu klasy A. m B Warunek wstępny dla metody m w klasie B - powinien być nie silniejszy niż dla metody m w klasie A; warunek końcowy - nie słabszy niż w klasie A. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 201

202 Podsumowanie mechanizmów rozszerzalności UML dostarczyła kilku mechanizmów rozszerzalności, aby umożliwić projektantom wprowadzanie modyfikacji bez konieczności zmiany samego języka modelowania. Twórcy UML starali się w ten sposób (chociażby w pewnym stopniu) zaspokoić potrzeby specyficznych dziedzin problemowych czy środowisk programowych. Narzędzia mogą przechowywać wprowadzone modyfikacje oraz manipulować nimi bez konieczności wnikania w ich semantykę - modyfikacje z reguły są przechowywane w postaci łańcuchów znakowych. Narzędzia mogą ustanowić własną składnię i semantykę dla obsługi mechanizmów rozszerzalności. Należy pamiętać, że rozszerzenia stanowią z definicji odstępstwo od standardów UML, i że w naturalny sposób prowadzą do utworzenia pewnego dialektu UML, a to z kolei może prowadzić do problemów z przenaszalnością. Trzeba zawsze dobrze rozważyć zyski i straty możliwe do poniesienia dzięki korzystaniu z tych mechanizmów, szczególnie wtedy, gdy stare standardowe mechanizmy pracują wystarczająco dobrze. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 202

203 Projektowanie systemów informacyjnych Zagadnienia: ADT Delegacja Protytypy Role Transformacje diagramu klas: Podział poziomy klasy Podział pionowy klasy Obejście dziedziczenia typu: disjoint overlapping dynamic Obejście dziedziczenia wielokrotnego i wieloaspektowego Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 203

204 Abstrakcyjny typ danych Abstrakcyjny typ danych (ADT) - pojęcie udostępniane w niektórych językach programowania oparte na założeniu, że typ struktury danych jest skojarzony z operacjami działającymi na elementach tego typu. Nie istnieje potrzeba i możliwość używania operacji nie należących do oferowanego zestawu; operacje są kompletne i wyłączne. Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy. Abstrakcyjny typ danych jest bardzo bliski pojęciu klasy, której wystąpienia eksportują (niektóre) operacje, zaś ich struktura jest niedostępna dla operacji z zewnątrz. ADT ogranicza kontekst, w którym odwołanie do obiektu może być użyte w programie. ADT może odnosić się nie tylko do obiektów, ale również do wartości. Z drugiej strony, ADT może być uważane za pojęcie znacznie węższe lub ortogonalne w stosunku do pojęcia klasa. W czystej postaci, ADT nie uczestniczy w związkach dziedziczenia, wystąpienia ADT nie posiadają tożsamości, nie można ich wzajemnie łączyć (powiązaniami), ani wykonywać operacji na zbiorze wystąpień ADT (brak odpowiednika metody klasy). Przykłady ADT stos (z operacjami: pop, push, top, empty), pakiety obsługujące: mysz, CD ROM, grafikę, heap Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 204

205 Delegacja - alternatywa dla dziedziczenia Lista pierwszy następny ostatni dodaj usuń Stos push pop Stos zawartość push pop top Lista pierwszy następny ostatni dodaj usuń Obiekt Stos dziedziczy niepotrzebne mu operacje z klasy Lista Operacje na obiekcie są oddelegowane do innego obiektu. Obiekt klasy Stos składa się z podobiektu zawartość, członka klasy Lista. Anomalia dziedziczenia jest usunięta. Obsługa obiektu Stos jest (częściowo) oddelegowana do obiektu Lista. Delegacja to alternatywa dla dziedziczenia: w tym przypadku dziedziczenie, czyli importowanie inwariantów zachodzi dynamicznie (w czasie działania programu) w ramach wystąpień klas (obiektów). Część własności danego obiektu (np. metody) jest przechowywana w innej klasie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 205

206 Prototypy Pojęcie ściśle powiązane z delegacją. Dowolny obiekt może stać się prototypem. Pod pojęciem prototypu rozumie się zarówno obiekt jako wzorzec dla innego obiektu (przy tworzeniu nowego obiektu), jak i to, że informacje z obiektu-prototypu są dynamicznie (w czasie działania programu) dostępne dla innych obiektów. W ten sposób uzyskuje się jednorodność i zminimalizowanie środków: potrzebne są wyłącznie obiekty oraz wskaźniki (powiązania) od obiektów do ich prototypów. Te powiązania między obiektami są przechodnie; obiekty mogą być powiązane w hierarchię. Koncepcja prototypów jest dość uniwersalna i pozwala modelować klasy, dziedziczenie, dziedziczenie wielokrotne i role. Koncepcja wizjerów idzie dalej - wskaźnik prowadzący do obiektu prototypu może być dodatkowo zaopatrzony w filtry, ustalające, co ma być importowane. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 206

207 Prototypy Ulubieniec Łapy: 4 Ogon: 1 Uszy:2 Oczy:2 Szczepienie() Prototyp Języki prototypowe (np. Self) nie wprowadzają pojęcia klasy. Obiekt może dziedziczyć cokolwiek z jakiegokolwiek innego obiektu. Pies Wabi_się: Rex Rasa: jamnik Płeć: M Kot Wabi_się: Mrusia Rasa: nieznana Płeć: Ż Uszy:1 Podstawowym argumentem zwolenników prototypów jest zmniejszenie liczby pojęć. Koncepcja prototypów jest nieunikniona, jeżeli ktoś chciałby implementować dynamiczne role obiektów. Pojęcie klasy, jako przechowalni inwariantów, ma jednak ogromne znaczenie dla modelowania pojęciowego, stąd pojęcia prototypu i klasy uzupełniają się. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 207

208 Role Student jest Osobą Źle! Osoba staje się Studentem Każdy obiekt w czasie swojego życia może nabywać i tracić wiele ról, nie zmieniając swojej tożsamości. Role zmieniają się dynamicznie. Właściciel psa Osoba Kowalski Członek klubu golfowego Podatnik Pracownik Student Pacjent Kibic Legii Rola importuje wartości atrybutów obiektu oraz inwarianty jego klasy Rola może mieć własne (dodatkowe) atrybuty Rola może należeć do własnej klasy Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 208

209 Role - przykład OSOBA NAZWISKO ROK_UR Wiek() Kowalska: pracownik Nowak: pracownik+student Abacka: Nowacki: student :OSOBA :OSOBA :OSOBA :OSOBA NAZWISKO: Nowak NAZWISKO: Abacka ROK_UR: 1951 ROK_UR: 1948 NAZWISKO: Kowalska ROK_UR: 1975 NAZWISKO: Nowacki ROK_UR: 1940 PRACOWNIK ZAROBEK DZIAŁ ZarobekNetto() ZmieńZarobek(...) STUDENT NR_INDEKSU INDEKS WpiszOcenę(...) ObliczŚredniąOcen() rola :PRACOWNIK ZAROBEK: 2000 DZIAŁ: zabawki :PRACOWNIK ZAROBEK: 2500 DZIAŁ: zabawki :STUDENT NR_INDEKSU: INDEKS:... :STUDENT NR_INDEKSU: INDEKS:... Rola importuje nie tylko inwarianty swojej klasy, lecz także wartości atrybutów swojego obiektu oraz inwarianty jego klasy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 209

210 Podział poziomy klasy (podział ekstensji klasy) K1 a? a? K1 a K2 a1 a2 m1 m2 K21 a1? a2? m1? m2? K22 a1? a2? m1? m2? Firma nazwa 0..1 Osoba Przykład zatrudnia Osoba imię nazwisko podaj nazwisko Firma nazwa 1 zatrudnia imię nazwisko nazwa szkoły wysokość emerytury pensja podaj nazwisko podaj szkołę zmień emeryturę zmień pensję * Uczeń imię nazwisko nazwa szkoły podaj nazwisko podaj szkołę Emeryt imię nazwisko wysokość emerytury podaj nazwisko zmień emeryturę Pracownik imię nazwisko pensja podaj nazwisko zmień pensję * Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 210

211 Podział pionowy klasy (podział inwariantów klasy) K1 a K2 a1 a2 a3 m1 m2 m3 np. K21 a1 m2 m3 a K1 K22 a2 a3 m1 Klient * Firma zlecił Przykład Klient * zlecił nazwa adres firmy telefon firmy [1..*] imię dyrektora nazwisko dyrektora adres dyrektora telefon dyrektora zmień adres firmy podaj telefon dyrektora 1..* Osoba imię nazwisko adres telefon podaj telefon 1 dyrektor 0..1 Firma nazwa adres telefon [1..*] zmień adres 1..* Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 211

212 Obejście dziedziczenia typu disjoint Osoba Nowak Osoba Kowalski {xor} Student Pracownik Student perspektywa pojęciowa Pracownik perspektywa projektowa Nowak:Student Nowak:Osoba Kowalski:Osoba Kowalski:Pracownik Nowak:Student Kowalski:Pracownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 212

213 Obejście dziedziczenia typu overlapping Nowak Osoba {overlapping} Kowalski Zamiast kompozycji można tu użyć zarówno agregacji, jak i zwykłej asocjacji. Student Pracownik Osoba Abacki Student Pracownik Abacki:Osoba Nowak:Osoba Kowalski:Osoba Abacki:Student Abacki:Pracownik Nowak:Student Kowalski:Pracownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 213

214 Obejście dziedziczenia typu dynamic Osoba {abstract} Menażer {dynamic} Analityk Projektant Przy zmianie specjalizacji Osoby powstaje nowy obiekt z którejś z trzech podklas: Menażer, Analityk czy Projektant. Własności odziedziczone z klasy Osoba są każdorazowo przepisywane. Osoba {xor} Menażer Analityk Projektant W drugim przypadku, usuwany jest obiekt związany ze starą specjalizacją, tworzony jest obiekt przechowywujący własności związane z nową specjalizacją oraz tworzone jest powiązanie między nowym obiektem a obiektem klasy Osoba, przechowującym dane osobowe. W tym przypadku klasa Osoba nie może być klasą abstrakcyjną. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 214

215 Obejście dziedziczenia wielokrotnego Osoba Student Pracownik Student/Pracownik Osoba Student Pracownik Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 215

216 Dziedziczenie wielokrotne i wieloaspektowe Są konieczne, ale często komplikują pielęgnację oprogramowania. Obejście ich braku może odbyć się jeszcze na poziomie modelu obiektowego. Można też bezpośrednio zastosować metody zaproponowane dla obejścia braku dziedziczenia. Przykład: Pracownik status płacowy Osoba stosunek do emerytury Emeryt Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Pracownik godzinowy nie emerytowany Osoba specjalizacje wg płac specjalizacje wg emerytury Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 216

217 Delegacja z użyciem ról Pracownik Osoba Emeryt Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Osoba Pracownik Specjalizacje wg płac Emeryt Specjalizacje wg emerytury Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 217

218 Użycie dziedziczenia i delegacji Dziedziczenie Delegacja Pracownik Osoba Emeryt Pracownik godzinowy Pracownik etatowy Pracownik na zlecenie Osoba nie emerytowana Osoba emerytowana Osoba Emeryt Specjalizacje wg płac Specjalizacje wg emerytury Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 218

219 Zagnieżdżona generalizacja Permutacja klas Pracownik status płacowy Pracownik godzinowy stosunek do emerytury Pracownik etatowy stosunek do emerytury Pracownik na zlecenie stosunek do emerytury Pracownik godzinowy nie emerytowany Pracownik godzinowy emerytowany Pracownik etatowy nie emerytowany Pracownik etatowy emerytowany Pracownik na zlecenie nie emerytowany Pracownik na zlecenie emerytowany Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 219

220 Zalecenia Jeżeli klasa ma kilka nadklas, wszystkie jednakowo ważne, najlepiej użyć delegacji, która zachowuje symetrię modelu. Jeżeli jedna nadklasa wyraźnie dominuje, ma zdecydowanie więcej cech niż pozostałe lub może powodować wąskie gardło w wydajności, zaś inne wydają się być mniej ważne, tę jedną zaimplementować poprzez dziedziczenie, zaś pozostałe przez delegację. Jeżeli liczba kombinacji klas jest mała, można rozpatrywać zagnieżdżoną generalizację (permutację klas). Przy zagnieżdżonej generalizacji, najważniejszy czynnik powinien być pierwszym kryterium podziału; pozostałe dalej, w hierarchii ważności. Unikać zagnieżdżonych generalizacji, jeżeli duża ilość kodu musi być powtórzona. Te zalecenia mogą okazać się nieistotne o ile zdecydujemy się bezpośrednio obejść brak dziedziczenia wielokrotnego i wieloaspektowego metodami takimi samymi, jak dla obejścia dziedziczenia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 220

221 Projektowanie systemów informacyjnych Klasyfikatory i wystąpienia Diagramy interakcji: Diagramy współpracy Diagramy sekwencji Generyczne diagramy interakcji: Wyrażanie warunków Wyrażanie iteracji Współbieżność na diagramach interakcji Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 221

222 Klasyfikatory i wystąpienia W UML pojęcie klasyfikatora związane jest z bytem stanowiącym opis własności zbioru wystąpień (instancji). Poniższa tabela specyfikuje przykładowe pary: klasyfikator/wystąpienie. Klasyfikator klasa use case aktor komponent podsystem Wystąpienie obiekt scenariusz aktor komponent podsystem UML traktuje wszystkie pary klasyfikator/wystąpienie w jednolity sposób, np. zawsze taka sama ikona jest używana dla klasyfikatora i wystąpienia, np. prostokąt dla klasy i obiektu czy człowieczek dla aktora-klasyfikatora oraz aktora-wystąpienia. Ikona dla wystąpienia jest etykietowana przez NazwaWystąpienia:NazwaKlasyfikatora (nazwa wystąpienia może być opuszczana; dwukropek pozostaje). W przypadku, gdy ikona reprezentuje klasyfikator, to jest etykietowana wyłącznie jego nazwą (bez podkreślenia). Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 222

223 Diagramy interakcji Diagramy interakcji, stanowiące jeden z rodzajów diagramów dynamicznych, pozwalają na utworzenie opisu interakcji obiektów systemu podczas realizacji danego zadania: przypadku użycia czy jednego konkretnego scenariusza danego przypadku użycia. Nie dla wszystkich przypadków użycia może zachodzić potrzeba konstruowania diagramów interakcji, ale mogą okazać się szczególnie użyteczne np. do komunkacji wewnątrz zespołu projektowego (jak zresztą wszystkie rodzaje diagramów) czy też do rozważenia opcjonalnych realizacji w trudnych przypadkach. Ponadto, niektóre narzędzia CASE potrafią wykorzystać te diagramy do generacji kodu, co może stanowić ważny powód dla ich konstruowania. UML posiada dwa rodzaje diagramów interakcji: diagramy współpracy (kolaboracji) diagramy sekwencji. Oba rodzaje diagramów, bazując na danym diagramie klas, pokazują prawie tą samą informację, w nieco inny sposób. Niektóre narzędzia CASE potrafią generować jedne z tych diagramów z drugich. Decyzja, który rodzaj diagramów konstruować, zależy od pożądanego aspektu interakcji. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 223

224 Diagramy współpracy; przykład Diagramy współpracy pokazują w jaki sposób system realizuje dany przypadek użycia. Współpracujące obiekty, połączone liniami nazywanymi tu linkami, tworzą rodzaj kolektywu, zwanego tu kolaboracją. Linki odpowiadają powiązaniom, czyli wystąpieniom asocjacji z diagramu klas, a to oznacza, że odpowiednia asocjacja musi istnieć na diagramie klas. :Personel bibl. :Członek bibl. :Egzemplarz Książki :Książka Można tu pokazywać też informacje w rodzaju: kierunek nawigowania, nazwy linków, itp., jak w modelu klas pod warunkiem, że zwiększą, a nie zmniejszą czytelność diagramu. Prosty diagram współpracy, bez uwidaczniania interakcji między obiektami, stanowi coś w rodzaju wystąpienia fragmentu diagramu klas ; pokazuje aktora, relewantne obiekty i powiązania między nimi. Możliwe jest pokazanie więcej niż jednego obiektu danej klasy. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 224

225 Interakcja na diagramach współpracy Diagramy współpracy mogą dodatkowo pokazywać interakcje zachodzące między obiektami zaangażowanymi w realizację danego przypadku użycia. Sekwencja interakacji oznacza tu sekwencję komunikatów przesyłanych między współpracującymi obiektami. :Personel bibl. Pożycz (tytuł) komunikat wysyłany od aktora do obiektu klasy Członek bibl. :Egzemplarz Książki 3: ZaznaczWypożyczenie :Członek bibl. 1: CzyMożnaPożyczyć 2: CzyTytułDostępny :Książka Komunikaty przedstawiane są tu w postaci etykiet strzałek rysowanych wzdłuż linków między współpracującymi obiektami. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 225

226 Interakcja na diagramach współpracy Na diagramach współpracy nie pokazuje się odpowiedzi na wysyłane komunikaty. Komunikaty mogą być numerowane, albo kolejnymi liczbami naturalnymi (jak na poprzednim diagramie), albo stosując tzw. numerację zagnieżdżoną. W obu przypadkach, z reguły, nie bierze się pod uwagę komunikatu wysyłanego od aktora. :Personel bibl. Pożycz (tytuł) :Egzemplarz Książki 2.1: ZaznaczWypożyczenie :Członek bibl. 1: CzyMożnaPożyczyć 2: CzyTytułDostępny :Książka Numeracja zagnieżdżona oznacza, że jeśli obiekt O otrzyma komunikat o numerze np. 7.3 to ten numer będzie dołączany jako prefix do każdego komunikatu wysyłanego w trakcie realizacji komunikatu 7.3 przez O. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 226

227 Interakcja na diagramach współpracy Obiekt, adresat komunikatu, musi go rozumieć, co oznacza, że klasa której jest wystąpieniem musi dostarczyć (definiować) tę operację. Konstruowanie diagramów interakcji może pomóc w identyfikowaniu zarówno operacji w klasach, jak i asocjacji między klasami, a przez to może prowadzić do korekty diagramu klas, i temu celowi zresztą głównie służy. Jest oczywistym, że oba modele (obiektów i dynamiczny) muszą być spójne. Rodzaje interakcji: Sekwencyjna - tylko jeden aktor może zainicjować sekwencję komunikatów i w danym momencie tylko jeden obiekt może działać. Obiekt rozpoczyna tzw. aktywne życie (live activation) w momencie otrzymania komunikatu. Zanim wyśle odpowiedź do nadawcy komunikatu, może prowadzić obliczenia czy też wysyłać komunikaty do innych obiektów. Wysyłając komunikat do innego obiektu nadal pozostaje aktywny, ale jego własna działalność zostaje zawieszona do czasu otrzymania odpowiedzi na wysłany komunikat - wysyłanie komunikatu zwiazane jest tu z przekazywaniem sterowania do odbiorcy komunikatu. W każdym momencie istnieje w systemie stos aktywnych obiektów; na szczycie stosu znajduje się ten obiekt, który aktualnie działa. Wysłanie odpowiedzi na komunikat powoduje zdjęcie obiektu ze stosu. Współbieżna. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 227

228 Diagramy sekwencji Diagramy sekwencji nie pokazują linków między współpracującymi obiektami, ale można to wydedukować w oparciu o zaznaczone komunikaty. czas :Personel bibl. Pożycz (tytuł) :Członek bibl. :Książka linia życia obiektu :Egzemplarz Książki 1: CzyMożnaPożyczyć aktywne życie obiektu 2: CzyTytułDostępny 2.1: ZaznaczWypożyczenie Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 228 Kolejność obiektów nie ma tu znaczenia, ale warto zadbać o czytelność.

229 Ilustracja przekazywania sterowania Na diagramach sekwencji, wyraźniej niż na diagramach współpracy, można pokazać przekazywanie sterowania. :Personel bibl. :Członek bibl. :Książka :Egzemplarz Książki Pożycz (tytuł) 1: CzyMożnaPożyczyć 2: CzyTytułDostępny 2.1: ZaznaczWypożyczenie Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 229

230 Nakładanie ograniczeń na przepływ czasu Główna przewaga diagramów sekwencji nad diagramami kolaboracji przejawia się w ich zdolności do graficznego prezentowania przepływu czasu, a nawet do podawania ograniczeń czasowych, czy też - co może być kontrowersyjne - skali czasowej. Taka możliwość może mieć duże znaczenie dla opisu systemów czasu rzeczywistego. :Dzwoniący :Sterowanie :Odbierający {b - a < 1 sec.} {c - b < 10 sec.} Rozmowa jest łączona poprzez sieć {d - d < 5 sec.} a b c d d podniesienie słuchawki ton w słuchawce wybór cyfry... łączenie ton dzwonka uruchomienie dzwonka podniesienie słuchawki koniec tonu koniec dzwonienia Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 230

231 Nakładanie ograniczeń na przepływ czasu :Personel bibl. A Pożycz (tytuł) :Członek bibl. :Książka gdy interesuje nas czas wykonania komunikatu :Egzemplarz Książki 1: CzyMożnaPożyczyć {C-A < 5 sek.} { ZaznaczWypożyczenie - CzyDostępny < 1 sek.} 2: CzyTytułDostępny 2.1: ZaznaczWypożyczenie C Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 231

232 Wartości zwracane; tworzenie, usuwanie obiektów diagram sekwencji Czasami przydaje się uwidocznienie wartości zwracanej przez komunikat, poprzez instrukcję przypisania. Umożliwia to późniejsze wykorzystanie tej wartości, np. jako argumentu dla innego komunikatu. Może też być wykorzystana do specyfikowania warunku czy iteracji. :Sekretariat ds. nauczania :Wykładowca nowy obiekt pojawia się na diagramie w miejscu korespondującym z czasem jego utworzenia n := PobierzNazwisko UtwórzNowegoSzefaWykładowców (n) usuń X koniec życia obiektu :Szef wykładowców Wykładowca Szef wykładowców Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 232

233 Wartości zwracane; tworzenie, usuwanie obiektów diagram kolaboracji 1: n := PobierzNazwisko :Sekretariat ds. nauczania :Wykładowca {usuwany} 3: usuń 2: UtwórzNowegoSzefaWykładowców (n) własność (property) :Szef wykładowców {nowy} Komunikaty wysyłane od aktora są tu numerowane, aby można było ustalić ich kolejność. Projekt musi specyfikować, kto jest odpowiedzialny za usuwanie obiektów, aby zapobiec tzw. wyciekaniu pamięci. Niektóre języki, takie jak np.java czy SmallTalk, posiadają wbudowane mechanizmy zbierania nieużytków (garbage collectors). Z grubsza, polega to na usuwaniu (w jakimś czasie) wszystkich obiektów, do których nie ma żadnych referencji w systemie. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 233

234 Generyczne diagramy interakcji W UML, generyczny diagram interakcji ma specyfikować wszystkie sekwencje interakcji dla danego przypadku użycia, a nie tylko dla jednego z możliwych scenariuszy. Diagram dla pojedynczego scenariusza jest tu nazywany wystąpieniem generycznego diagramu interakcji. Ponieważ diagramy generyczne mogą w niektórych przypadkach okazać się zbyt złożone, dopuszcza się rozwiązania połowiczne. Przedstawianie zachowań warunkowych Wysłanie komunikatu może być uzależnione od spełnienia wyspecyfikowanego warunku. :K dwa różne punkty w czasie :K ten sam punkt w czasie [i = 0] x [i = 1] y [i = 0] x [i = 1] y {warunki muszą się wykluczać} Możliwe są tu wszystkie kombinacje. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 234 Może być wysłany albo komunikat x albo y. Może też nie być wysłany żaden z nich.

235 Generyczne diagramy interakcji Warunek, zapisany wewnątrz nawiasów [ ] stanowi wyrażenie typu Boolean i może być wyrażony w języku naturalnym, w języku ustrukturalizowanym (np. OCL), w języku programowania czy innej notacji. :K1 7.1: [i = 0] x 7.2: [i = 1] y :K2 Linia życia dla wystąpienia klasy K2 uległa rozgałęzieniu, aby podkreślić fakt, że stan obiektu może wyglądać inaczej w zależności od tego, który komunikat zostanie wysłany. Budzi wątpliwości numeracja komunikatów, może wykonać się tylko jedna z nich. Być może obie powinny być oznaczone przez 7.1. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 235

236 Generyczne diagramy interakcji Wyrażanie warunków na diagramach współpracy jest także możliwe. Nie da się tu jednak pokazać rozgałęzienia linii życia obiektu. Dlatego wydaje się, że poza najprostszymi sytuacjami, diagramy sekwencyjne lepiej modelują realizację bardziej złożonych (z opcjonalnymi scenariuszami) przypadków użycia. Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 236 Przedstawianie iteracji UML umożliwia oznaczenie komunikatu, który ma być wysłany wiele razy, poprzez poprzedzenie go symbolem *. Oczywiście musi być też wyspecyfikowany warunek, określający zakończenie iteracji. Przykłady iteracji: *[i := 1..10] - komunikat będzie wysłany 10 razy, *[x < 10] - komunikat będzie wysyłany dopóki x będzie < 10, *[pozycja znaleziona] - komunikat będzie wysyłany dopóty, dopóki pozycja nie zostanie znaleziona (do momentu, gdy warunek przyjmie wartość FALSE) Jeśli w trakcie wielokrotnego wysyłania komunikatu x, będzie wysyłany także komunikat y, to zostanie on wysłany tyle razy, ile razy wysyłane jest x. Zachowanie spójności diagramów nie wymaga powtarzania symbolu iteracji dla komunikatu y.

237 Generyczne diagramy interakcji :K1 :K2 :K3 xyxy 3.1: *[i := 1..2] x 3.1.1: y :K1 :K2 :K3 xyyyxyyy 3.1: *[i := 1..2] x 3.1.1: *[j := 1..3] y sekwencja komunikatów Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 237