Jedenasta Górska Szkoła PTI Szczyrk’99 Kazimierz Subieta

Prezentacja na temat: "Jedenasta Górska Szkoła PTI Szczyrk’99 Kazimierz Subieta"— Zapis prezentacji:

1 Wprowadzenie do obiektowych metodyk projektowania i notacji UML (Unified Modeling Language)
Jedenasta Górska Szkoła PTI Szczyrk’99 Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych,

2 Plan wykładu Trochę o obiektowych Trochę o inżynierii
metodykach analizy i projektowania Trochę o inżynierii oprogramowania Trochę o obiektowości Trochę o UML Podziękowanie dla Artura Kasprzyka za okazaną pomoc w przygotowaniu materiału.

3 Część 1: Inżynieria oprogramowania
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 1: Inżynieria oprogramowania

4 Przedmiot inżynierii oprogramowania
Inżynieria oprogramowania jest to wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt. Dobre oprogramowanie powinno być: zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, ergonomiczne. Produkcja oprogramowania jest procesem składającym się z wielu faz. Kodowanie (pisanie programów) jest tylko jedną z nich, niekoniecznie najważniejszą. Inżynieria oprogramowania jest wiedzą empiryczną, a nie pochodną “teorii”.

5 Zagadnienia inżynierii oprogramowania
Sposoby prowadzenia przedsięwzięć informatycznych. Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przesięwzięć informatycznych. Metody analizy i projektowania systemów. Techniki zwiększania niezawodności oprogramowania. Sposoby testowania systemów i szacowania niezawodności. Sposoby przygotowania dokumentacji technicznej i użytkowej. Procedury kontroli jakości. Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń) Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

6 Tworzenie niezawodnego oprogramowania
Znaczenie niezawodności: Troska o zadowolenie klientów oprogramowania. Niezawodność oprogramowania ustępuje niezawodności sprzętu. Jest to prawdopodobnie nieuchronne ze względu na znacznie mniejszą powtarzalność oprogramowania i większy stopień jego złożoności. Potencjalnie wysokie straty finansowe wynikające z błędnego działania oprogramowania, zagrożenie dla bezpieczeństwa ludzi i ludzkich własności. Nieprzewidywalność skutków oraz trudność usunięcia błędów w oprogramowaniu. Kompromis pomiędzy efektywnością i niezawodnością. Łatwiej jednak pokonać problemy zbyt małej efektywności niż zbyt małej niezawodności.

7 Kryzys oprogramowania (1)
Sprzeczność pomiędzy odpowiedzialnością, jaka spoczywa na współczesnych SI, a ich zawodnością wynikającą ze złożoności i ciągle niedojrzałych metod tworzenia i weryfikacji oprogramowania. Ogromne koszty utrzymania oprogramowania. Niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania; niski stopień powtarzalności poszczególnych przedsięwzięć. Długi i kosztowny cykl tworzenia oprogramowania, wysokie prawdopodobieństwo niepowodzenia projektu programistycznego. Długi i kosztowny cykl życia SI, wymagający stałych (często globalnych) zmian. Eklektyczne, niesystematyczne narzędzia i języki programowania.

8 Kryzys oprogramowania (2)
Frustracje projektantów oprogramowania i programistów wynikające ze zbyt szybkiego postępu w zakresie języków, narzędzi i metod oraz uciążliwości i długotrwałości procesów produkcji, utrzymania i pielęgnacji oprogramowania. Uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym. Problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych. Problemy przystosowania istniejących i działających systemów do nowych wymagań, tendencji i platform sprzętowo-programowych. Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania.

9 Ź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: decyzje strategiczne, analiza, projektowanie, konstrukcja, dokumentacja, wdrożenie, szkolenie, eksploatacja, pielęgnacja, modyfikacja. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

10 Jak walczyć ze złożonością ?
Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata.

11 Walka z kryzysem oprogramowania
Stosowanie technik i narzędzi ułatwiających pracę nad złożonymi systemami; Korzystanie z 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.

12 Modelowanie pojęciowe
Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzacych w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

13 Perspektywy w modelowaniu pojęciowym
odwzorowanie odwzorowanie ... Percepcja rzeczywistego świata Analityczny model rzeczywistości Model struktur danych i procesów SI Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych.

14 Niezgodność modelu pojęciowego i relacyjnego
Pojęciowy schemat obiektowy: FZ PZ Firma Zatrudnienie Pracownik Osoba 1 0..* 0..* 1 Nazwa Wyp ł ata * Zawód * Nazwisko Miejsce * Ocena * Imi ę * Adres * Schemat relacyjny: Firma(NrF, Nazwa) Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód(NrDochodu, Wypłata, NrF, NrP) Osoba(NrOs, Nazwisko) Wyszkolenie(Zawód, NrP) Imiona(NrOs, Imię) Adresy(NrOs, Adres)

15 Jakie są skutki niezgodności modelu pojęciowego i relacyjnego?
Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programistę. Efektem jest zwiększona skłonność do błędów (mylnych interpretacji). Programy manipulacyjne odwołujące się do schematu relacyjnego są dłuższe od programów odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Ma to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości, pielęgnacyjności, itd. Programy te są też zwykle znacznie wolniejsze. Mini przykład: Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu SBQL: (Firma where ”Radom” in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = “Radom” and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs Zapytanie w SQL jest znacznie dłuższe od zapytania w SBQL wskutek tego, że w SQL konieczne są „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne) kojarzące informację semantyczną, która jest dana implicite w relacyjnej strukturze danych.

16 Część 2. Pojęcie metodyki analizy i projektowania
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 2. Pojęcie metodyki analizy i projektowania

17 Co to jest metodyka (metodologia)?
Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Metodyka jest powiązana z notacją służącą do zapisywania wyników faz projektu (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem. fazy projektu, role uczestników projektu, modele tworzone w każdej z faz, scenariusze postępowania w każdej z faz, reguły przechodzenia od fazy do następnej fazy, notacje, których należy używać, dokumentację powstającą w każdej z faz. Metodyka ustala:

18 Metodyki obiektowe i strukturalne
Metodyki strukturalne - metody tradycyjne rozwijane od lat 60-tych. Łącza składowe pasywne (opis danych) oraz aktywne (wykonywanie operacji). Metodyki obiektowe - rozwijane od lat 80-tych, oparte na wyróżnianiu obiektów łącznie z operacjami. Analiza strukturalna (structured analysis) rozpoczyna się od budowy dwóch różnych modeli systemu: modelu danych oraz modelu funkcji. Te dwa modele są integrowane.Wynikiem jest model przepływu danych (data flow model). Wadą podejścia są trudności w zintegrowaniu modeli. Ostatnio coraz bardziej popularne są metodyki obiektowe. Metodyki posługują się notacją, z reguły graficzną, którą dość często utożsamia się z samą metodyką (niesłusznie).

19 Różnice pomiędzy metodykami
Podejścia proponowane przez różnych autorów róznią się częściowo, nie sa jednak ze sobą sprzeczne. Poszczególne metodyki zawieraja elementy rzadko wykorzystywane w praktyce (np. model przepływu danych w OMT). Notacje proponowane przez różnych autorów nie są koniecznie nierozerwalne z samą metodyką. Np. notacji UML można użyć dla metodyki Coad/Yourdon. Nie ma metodyk uniwersalnych. Analitycy i projektanci wybierają kombinację technik i notacji, która jest w danym momencie najbardziej przydatna. Wybór może być jednak utrudniony istniejącą rutyną w danej firmie. Narzędzia CASE nie narzucają metodyki; raczej, określają one tylko notację. Twierdzenia, że jakieś narzedzie CASE “jest oparte” na konkretnej metodyce jest najczęściej wyłącznie hasłem reklamowym.

20 Czy wierzyć metodykom? Nie istnieją wiarygodne testy wskazujące na to, że przyjęcie pewnej konkretnej metodyki lub notacji usprawniło proces projektowania, lub że dana metodyka lub notacja jest lepsza od innej. Zalety/wady metodyk i notacji są subiektywne i sprowadzają się często do zręczności w sztuce retoryki. Wielu specjalistów uważa twórczość w zakresie metodyk za arbitralny zestaw reguł i zaleceń, czy też spekulacje, za którymi nie kryją się ani głębokie uzasadnienia ani obiektywne prawdy. Dość często doświadczenie praktyczne twórców metodyk jest ograniczone lub dotyczy poprzedniej epoki informatycznej, której problemy i paradygmaty uległy dezaktualizacji. Nawet najlepsze metodyki i narzędzia CASE nie są w stanie zapewnić jakości projektów. Kluczem do dobrego projektu jest zespół doświadczonych, zaangażowanych i kompetentnych osób, dla których metodyka i notacja taka jak UML oraz wykorzystujące ją narzędzia CASE mogą wyłącznie służyć jako istotne, lecz drugorzędne wspomaganie.

21 Co to jest “metodyka obiektowa”?
Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych. Podstawowym składnikiem jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek. Diagram obiektów zawiera: klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające stany i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące zwykle pewną mutacją diagramów przepływu danych), itd. Popularność zdobyła koncepcja przypadków użycia (use cases), której podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu widzenia jego użytkownika.

22 Metodyki obiektowe : Eksplozja metodyk i notacji obiektowych. Powstało ich ponad 20. Obecnie obserwuje się ich zredukowanie, koncentrację: UML, OPEN, BON,... Express MainstreamObjects, Yourdon Martin/Odell OOA/OOD, Coad/Yourdon OODA, Booch Catalysis, D’Souza & Wills OMT, Rumbaugh Fusion, HP Laboratories OOSA, Shlaer-Mellor DOOS, Wirfs-Brock Objectory, Jacobson Goldberg/Rubin BON (Business Object Notation), Nerson & Walden OORAM EROOS (Entity-Relationship Object-Oriented Specification) Sintropy MOSES/OPEN (Methodology for OO Software Engineering of Systems) OSA

23 Notacje w analizie i projektowaniu
Język naturalny Notacje graficzne Specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny Rodzaje notacji Szczególne znaczenie maja notacje graficzne. Inżynieria oprogramowania wzoruje się na innych dziedzinach techniki, takich jak elektronika i mechanika. Zalety notacji graficznych potwierdzają badania psychologiczne. Funkcje notacji Narzędzie pracy analityka i projektanta, zapis i analiza pomysłów Współpraca z użytkownikiem Komunikacja z innymi członkami zespołu Podstawa implementacji oprogramowania Zapis dokumentacji technicznej Notacje powinny być przejrzyste, proste, precyzyjne, łatwo zrozumiałe, umożliwiające modelowanie złożonych zależności.

24 Cykl życiowy oprogramowania
Określenie strategicznych celów wprowadzenia informatyki Planowanie i definicja projektu Analiza Analiza dziedziny przedsiębiorczości Analiza wymagań systemowych Projektowanie Projektowanie pojęciowe Projektowanie logiczne Projektowanie fizyczne Konstrukcja Rozwijanie Testowanie Dokumentacja Przygotowanie użytkowników, akceptacja, szkolenie Działanie, włączając wspomaganie tworzenia aplikacji Utrzymanie, konserwacja, pielęgnacja

25 Analiza Analiza włącza następujące czynności: Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu; Ustalenie kontekstu projektu; Ustalenie wymagań użytkowników; Ustalenie wymagań organizacyjnych Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd. Analiza nie zajmuje się zmianą rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci SI. Jej celem jest dokładne rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

26 Projektowanie systemowe
Etap w którym projektant systemu podejmuje decyzje wysokiego poziomu dotyczące całościowej architektury systemu. Wynikowy system jest organizowany w podsystemy na podstawie wyników analizy jak i założeń co do ogólnej architektury. Projektant musi podjąć decyzje dotyczące optymalizacji charakterystyk wydajnościowych, wybrać strategię rozwiązania tego problemu oraz podjąć decyzje odnośnie alokacji zasobów. Np. projektant musi określić charakterystyki monitorów (rozdzielczość, rozmiar ekranu, kolory), musi wybrać konfigurację sprzętu, strategię buforowania pamięci, właściwe protokóły komunikacyjne, itd.

27 Projektowanie Projekt bazuje na wyniku analizy oraz wyniku projektowania systemowego. Zawiera wiele elementów implementacyjnych odnoszących się do struktury danych oraz algorytmów (metod) przetwarzania. Klasy obiektów rzeczywistych wyodrębnione podczas analizy są również istotne na etapie projektowania obiektowego, z następującymi różnicami: Niektóre klasy wyodrębnione podczas analizy nie kwalifikują się do implementacji; Zwykle konieczne jest wprowadzenie nowych klas odnoszących się do struktur danych i algorytmów niezbędnych dla implementacji (ekranów, plików, itd). Zzwyczaj pojęcia odnoszące się do analizy i projektowania są opisywane w sposób jednorodny przy pomocy tej samej notacji.

28 Konstrukcja (implementacja)
Obiekty i klasy wyodrębnione podczas projektowania obiektowego są ostatecznie odwzorowane w postaci konstrukcji języka programowania, systemu zarządzania bazą danych, udogodnień sieciowych, oraz konfiguracji sprzętowej. Zakłada się, że etap programowania powinien być mniej ważną, w zasadzie pół-mechaniczną czynnością, która nie wypacza elementów projektu. Wskazane byłoby, aby trudne decyzje dotyczące implementacji były podjęte i udokumentowane na etapie projetu. To założenie jest szczególnie ważne dla dużych projektów, gdzie pojedynczy programista nie ma możliwości ogarnięcia całościowej logiki. Odwzorowanie projektu w implementację powinno być bezszwowe, bezpośrednie, tak, aby każdy fragment oprogramowania mógł być jednoznacznie przyporządkowany odpowiedniemu fragmentowi projektu.

29 Tematyka analizy i projektowania obiektowego
Analiza i modelowanie struktur obiektów Analiza i modelowanie procesów i sekwencji transakcji Analiza i modelowanie interakcji pomiędzy obiektami Analiza i modelowanie cyklu życiowego obiektów Kompleksowe modelowanie systemów Planowanie projektu Zarządzanie projektami dotyczącymi obiektowości Analiza wymagań dotyczących systemu Projektowanie pojęciowe, logiczne i fizyczne bazy danych Rozwijanie obiektowych aplikacji Testowanie, akceptacja, wdrażanie, działanie

30 Klasyczna i obiektowa struktura aplikacji
Pasywne dane (relacje) Powiązane obiekty Schemat bazy danych ... ... ... ... ... ... Schemat bazy danych ... ... ... Klasy i typy ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Biblioteki procedur i funkcji Moduły aplikacyjne Typy Biblioteki procedur i funkcji Moduły aplikacyjne Słowniki, katalogi Procedury bazy danych, perspektywy, reguły Słowniki, katalogi Procedury bazy danych, perspektywy, reguły

31 Część 3: Wprowadzenie do obiektowości
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 3: Wprowadzenie do obiektowości

32 Ź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 czynnik ludzki w tworzeniu oprogramowania, zmniejszenie dystansu pomiędzy modelem pojęciowym a modelem realizacyjnym Współczesne pojęcia obiektowości Metodyki projektowania oprogramowania, od swojego początku bazujące na wyróżnianiu obiektów i ich klas w otaczającej nas rzeczywistości Bazy danych, od początku bazujące na obiektach (IMS, CODASYL). Wady modelu relacyjnego baz danych; odrzucenie jego powierzchownej prostoty.

33 Obszary oddziaływania obiektowości
Metodyki analizy i projektowania SI, narzędzia CASE. Pojęcia obiektowości jako podstawa ideologiczna i koncepcyjna. Języki programowania (Smalltalk, C++, Java, Eiffel,...). Obiekty, klasy, metody, dziedziczenie, hermetyzacja, polimorfizm. Bazy danych i składy trwałych obiektów (standard ODMG, Gemstone, Versant, ObjectStore, Objectivity/DB, O2, Poet, ...). Przeniesienie obiektowych technologii programowania na grunt baz danych. Obiektowość w systemach relacyjnych, systemy obiektowo-relacyjne. Współdziałanie systemów heterogenicznych (OMG CORBA, COM/DCOM,...). Obiekty i klasy jako abstrakcyjny poziom przykrywający szczegóły implementacji. Wizyjne środki programistyczne (Smalltalk, IBM VisualAge,...). Przeniesienie technik obiektowych do programowania wizyjnego. Inne: biblioteki oprogramowania, grafika, miary i oceny oprogramowania, re-inżynieria procesów biznesowych (BPR).

34 Przeszkody dla obiektowości
Zastany świat interfejsów programistycznych (C, COBOL, Fortran, SQL, ...) Zastane poglądy, mity, steoretypy i przekręty konkurencji. Typowe, często powtarzane półprawdy, nieprawdy i bzdury: Ogromne inwestycje w przedrelacyjne i relacyjne bazy danych. Konkurencja technologicznie dojrzałych systemów relacyjnych (obiektowo-relacyjnych). Własna słabość: niedopracowane zasady, formalizmy, języki, standardy; kompromisy w zakresie celów. Relacyjna baza danych zapewnia prostotę struktur danych. Relacyjne bazy danych mają solidne podstawy matematyczne. Wskaźniki/hermetyzacja/... w bazie danych są niekorzystne. Tylko relacyjne bazy danych umożliwiają realizację języków zapytań. Tylko relacyjna baza danych zapewnia przetwarzanie transakcji/rozproszenie/... Relacyjne bazy danych mają nieosiągalną dla innych wydajność/skalowalność/...

35 Podstawowe pojęcia obiektowości (1)
Obiekty, tożsamość. Złożone struktury danych z przypisanymi do nich operacjami, czyli obiekty. Unikalny identyfikator obiektu. Powiązania, asocjacje. Obiekty mogą być powiązane związkami o charakterze wskaźników. Hermetyzacja (encapsulation). Informacja o obiekcie jest zamknięta w jednej bryle. Niepotrzebna informacja jest ukryta. Klasy, typy, interfejsy. Cechy niezmienne dla grup obiektów, np. definicje ich atrybutów i operacji, są zbierane wewnątrz klas. Typy umożliwiają kontrolę budowy obiektów i poprawności ich użycia. Specyfikacja klasy (interfejs) jest oddzielona od jej implementacji. Abstrakcyjne typy danych. Dostęp do struktur danych odbywa się wyłącznie poprzez zdefiniowy dla tych struktur zestaw operacji.

36 Podstawowe pojęcia obiektowości (2)
Operacje, metody, komunikaty. Operacja na obiekcie jest wykonywana przy pomocy jednej z jego metod, po wysłaniu komunikatu do obiektu. Hierarchia klas i dziedziczenie. Klasy są organizowane w hierarchię. Klasy bardziej szczegółowe dziedziczą cechy klas bardziej ogólnych (definicje atrybutów, metody, itd.). Przesłanianie, późne wiązanie, polimorfizm. Ten sam komunikat wysłany do różnych obiektów może wywoływać różne operacje. Wiązanie nazw operacji następuje na etapie wykonania. Metoda z klasy bardziej ogólnej może być przesłonięta przez inna metodę z klasy wyspecjalizowanej. Trwałość. Niektóre obiekty zachowują swój stan dłużej niż czas pojedynczego uruchomienia programu.

37 Obiekty (1) Obiektem jest rzecz lub pojęcie obserwowane w świecie rzeczywistym którego dotyczy SI. Obiekt jest odróżnialny od innych obiektów, ma dobrze określone granice i nazwę. Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jako zwartą bryłą (wyszukiwać, wiązać, kopiować, blokować, usuwać, indeksować, ...). Obiekt posiada swoją tożsamość, która wyróżnia go spośród innych obiektów. Tożsamość obiektu jest niezależna od wartości jakichkolwiek jego atrybutów i od jego lokacji w świecie rzeczywistym lub w przestrzeni adresowej komputera. Obiekt posiada stan, który może zmieniać się w czasie (bez zmiany tożsamości obiektu).

38 Obiekty (2) Obiekt może być złożony, tj. może składać się z mniejszych obiektów. Obiekt złożony odnoszący się do modelowanej rzeczywistości zawiera w sobie wszystkie cechy modelowanego obiektu. Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi. Obiekt ma przypisane zachowanie, tj. zestaw operacji które wolno do niego stosować. Implementacja operacji jest zwana metodą. Obiekt ma przypisany typ, tj. wyrażenie językowe, które ogranicza budowę obiektu, ustala operacje, które wolno wykonać na obiekcie, oraz ogranicza kontekst, w którym dany obiekt moze być użyty w programie.

39 Przykład obiektu KONTO Wypłać Wpłać Porównaj Sprawdź podpis stan
Numer Właściciel Jan Kowalski Upoważniony Ewa Kowalska Nalicz procent SaldoZł 34567 Zlikwiduj konto .... Zmień upoważnienie Upoważnij

40 Obiekt złożony 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 obiektów. Nie powinno istnieć ograniczenie rozmiaru obiektu, liczby komponentów składających się na obiekt lub liczby poziomów hierarchii 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.

41 Obiekty złożone (kompozytowe)
Pracownicy Pracownik Zatrudnienia ..... Zatrudnienie Stanowisko Nazwisko Dzieci ... Dziecko Pracownik Zatrudnienia ..... Zatrudnienie Stanowisko Nazwisko Dzieci ... Dziecko .....

42 Powiązania pomiędzy obiektami
Na poziomie realizacyjnym powiązania pomiędzy obiektami można sobie wyobrazić jako wskaźniki prowadzące od obiektu do obiektu. FIRMA NrFirmy Nazwa Syntex Prezes Zatrudnia PRACOWNIK Nazwisko Nowak Zarobek 1500 PracujeW Nazwisko Babel Zarobek 2000 Nazwisko Kowal Zarobek 2500 Diagram klas: PRACOWNIK Nazwisko Zarobek 0..* PracujeW Prezes Zatrudnia 0..1 FIRMA NrFirmy Nazwa Na poziomie pojęciowym powiązania nie mają charakteru wskaźników, lecz pewnych abstrakcyjnych “nitek” łączących obiekty. Asocjacje: abstrakcyjne oznaczenia powiazań na diagramach klas.

43 Powiązania jako “nitki” łączące obiekty
OSOBA Bober OSOBA Kowalska Sprzedający Pośrednik Diagram klas: Kupujący Transakcja Transakcja Sprzedający OSOBA Nazwisko Kupujący Pośrednik Sprzedający OSOBA Nowak Kupujący OSOBA Wilczek Pośrednik Pośrednik Transakcja Kupujący Transakcja OSOBA Maciąg OSOBA Bielicka Sprzedający

44 Atrybuty powiązań Diagram klas: Sprzedający Kupujący Pośrednik
OSOBA Bober OSOBA Kowalska Diagram klas: Sprzedający Sprzedający OSOBA Nazwisko Kupujący Kupujący Pośrednik Transakcja Plac 40000 Transakcja Dom 300000 Pośrednik Pośrednik OSOBA Nowak OSOBA Wilczek Kupujący Sprzedający Transakcja Pośrednik Transakcja Samochód 20000 DaneTransakcji PrzedmiotTransakcji DataTransakcji WartośćTransakcji Kupujący OSOBA Maciąg OSOBA Bielicka Sprzedający

45 Modelowanie powiązań jako obiektów
OSOBA Bober OSOBA Kowalska Sprzedający Kupujący Pośrednik TRANSAKCJA Plac 40000 TRANSAKCJA Dom 300000 Diagram klas: Sprzedający OSOBA Nazwisko Kupujący Pośrednik OSOBA Nowak Kupujący Sprzedający OSOBA Wilczek Pośrednik Pośrednik 0..* TRANSAKCJA Samochód 20000 Transakcja PrzedmiotTransakcji DataTransakcji WartośćTransakcji 0..* 0..* Kupujący Sprzedający OSOBA Maciąg OSOBA Bielicka

46 Liczność asocjacji A A A B B B B B B B B B A B: min = 1, max = 1
B: min = 1, max = n A B: min = 0, max = 1 A B A: min = 1, max = n A: min = 0, max = n B A: min = 0, max = n B A A A Oznaczenia liczności na diagramie klas: 1..* 0..* 0..* 1..* 0..1 B B B

47 Hermetyzacja i ukrywanie informacji
Hermetyzacja: zamykanie szczegółów w bryłę, którą można manipulować tak jak jednostką (D. Parnas, 1972). Ukrywanie informacji: programista ma tyle wiedzieć o tworze programistycznym (procedurze, module, obiekcie, klasie), ile mu trzeba, aby go efektywnie używać. Wszystko, co może być przed nim ukryte, powinno być ukryte. Wewnętrzna struktura obiektu Zewnętrzna struktura obiektu PRACOWNIK NAZWISKO Nowak ROK_UR 1951 ZAROBEK 2500 ZmieńZarobek(...) {...}; Podatek(){...}; ZarobekNetto() {...}; Wiek() { return RokBież - ROK_UR }; DZIAŁ Zabawki PRACOWNIK NAZWISKO Nowak DZIAŁ Zabawki ZarobekNetto() ZmieńZarobek(...) Wiek()

48 Komunikaty Komunikat jest wyrażeniem językowym skierowanym do obiektu. Nazwa użyta w komunikacie jest nazwą metody skojarzonej z obiektem. Źródłem komunikatu jest pewien obiekt lub aktualnie działający program. Komunikat może mieć parametry. Obiekt otrzymujący komunikat wykonuje odpowiednią metodę, która może zmienić jego stan. Wypłać ( 1000 ) Wypłać Wpłać KONTO OK, wypłaciłem Sprawdź stan Porównaj podpis Numer SaldoZł 34567 Właściciel Jan Kowalski Upoważniony ... .... Graj Nalicz procent Zlikwiduj konto Zmień upoważnienie ??? błąd! Upoważnij Po wykonaniu metody obiekt, który otrzymał komunikat, może zwrócić odpowiedź do obiektu lub programu, który go wysłał. Odpowiedź nie jest komunikatem.

49 Komunikat a wołanie procedury
Pojęcia są bardzo podobne: Wołanie procedury: obiekt jest komunikowany jako parametr: procedura( obiekt, par1, par2,...) Komunikat: obiekt-adresat poprzedza wywołanie metody: obiekt.metoda(par1, par2,...) Zasadnicza różnica: Komunikat nie określa która konkretnie metoda ma być wywołana; komunikat jest kierowany do obiektu, i w zależności od niego może być wywołana zupełnie inna metoda. Musi być przełączenie explicite wewnątrz procedury dochody; procedurę musi pisać jeden programista, na wszystkie okazje. X = dochody( emeryt ) Y = dochody( pracownik ) Nie ma przełączenia; wywoływana jest zupełnie inna metoda dochody w zależności od obiektu - adresata komunikatu. Te metody (i ich programiści) nie muszą nic o sobie wiedzieć. X = emeryt.dochody() Y = pracownik.dochody()

50 Przesyłanie komunikatów a równoległość
Często termin „przesyłanie komunikatów” (message passing) jest mylnie interpretowany. Zgodnie z wypowiedziami niektórych autorów, obiekty komunikują się ze sobą asynchronicznie i równolegle poprzez mechanizm komunikatów, zaś obiektowość postuluje taką równoległość (lub wręcz rozwiązuje problem równoległości). Są to poglądy nieuzasadnione i naiwne. Są one oparte na budowaniu pochopnej analogii ze światem rzeczywistym, gdzie obiekty posiadają własną autonomię i funkcjonują niezależnie od siebie, komunikując się między sobą w ramach swoich potrzeb. Obiektowość nic takiego nie zakłada. Przetwarzanie równoległe jest ważnym i trudnym problemem, całkowicie niezależnym w stosunku do obiektowości, a w szczególności do mechanizmu przesyłania komunikatów. Komunikat należy rozumieć jako obiektowy odpowiednik wołania procedury.

51 Klasy Klasa jest nazwanym zbiorem obiektów o podobnych własnościach. Własności te (zestaw atrybutów, metody) są określone w definicji klasy. Stosunek klasa/podklasa oznacza zawieranie się zakresów znaczeniowych. Np. zbiór obiektów Student zawiera się w zbiorze obiektów Osoba. Zła definicja: Klasa jest miejscem przechowywania cech obiektów, które są niezmienne (inwariantów). Klasa nie jest zbiorem obiektów i nie jest definicją zbioru obiektów. Stosunek klasa/podklasa oznacza, że obiekty podklasy posiadają wszystkie inwarianty nadklasy, plus swoje inwarianty. Np. klasa Student ma wszystkie inwarianty klasy Osoba, plus niektóre własne. Dobra definicja: Nazwa, czyli językowy identyfikator obiektu Typ, czyli statyczna budowa obiektu (atrybuty) Metody, czyli operacje, które można wykonać na obiekcie Najważniejsze inwarianty to: Zdarzenia lub wyjątki, które mogą zajść w operacjach na obiekcie Obsługa zdarzeń lub wyjątków Lista eksportowa, określająca, które atrybuty dostępne są z zewnątrz Ograniczenia, którym musi podlegać każdy obiekt ...... Możliwe są inne inwarianty:

52 Wyodrębnienie klasy KONTO KONTO 123-4321 34567 Jan Kowalski ....
Klasa KONTO Wypłać Wpłać KONTO Obiekty KONTO (punkt widzenia użytkownika) Sprawdź stan Porównaj podpis Numer: char[8] SaldoZł: integer Właściciel: string Upoważniony: string .... Wpłać Porównaj podpis Zlikwiduj konto Wpłać Porównaj podpis Zlikwiduj konto Nalicz procent Zlikwiduj konto Wypłać Wpłać Zmień upoważnienie Upoważnij KONTO Sprawdź stan Porównaj podpis Numer SaldoZł 34567 Właściciel Jan Kowalski Upoważniony ... .... Związki “jest wystąpieniem klasy” Nalicz procent Zlikwiduj konto Zmień upoważnienie 34567 Jan Kowalski .... Upoważnij Obiekty KONTO (reprezentacja wewnątrz pamięci)

53 Wyodrębnienie hierarchii dziedziczenia
Hierarchia dziedziczenia Klasa ogólna Klasa wyspecjalizowana OSOBA Nazwisko Imię RokUrodz Wiek() OSOBA Nazwisko Imię RokUrodz Wiek() PRACOWNIK Nazwisko Imię RokUrodz Zarobek Firma Zdjęcie Wiek() ZarobekNetto() ZmieńZarobek(...) PRACOWNIK Zarobek Firma Zdjęcie ZarobekNetto() ZmieńZarobek(...)

54 Generalizacja/specjalizacja
budowa pojęć bardziej ogólnych jeżeli mamy pojęcia bardziej szczegółowe. Specjalizacja: budowa pojęć bardziej szczegółowych jeżeli mamy pojęcia bardziej ogólne. Sklep nazwa adres Rodzaj towaru Firma usługowa nazwa adres Rodzaj usługi Firma nazwa adres ...Rodzaj towaru? ...Rodzaj usługi? Firma nazwa adres Generalizacja Sklep Rodzaj towaru Firma usługowa Rodzaj usługi Specjalizacja

55 Polimorfizm Każda klasa ma własną metodę dochody.
Są one niezależne i są niezależnie programowane OSOBA nazwisko kategoria .... PRACOWNIK .... dochody() STUDENT .... dochody() EMERYT .... dochody() obiekt obiekt obiekt

56 Ekstensja klasy Ekstensja klasy OSOBA Ekstensja klasy PRACOWNIK OSOBA
Nazwisko Kowalska RokUr 1975 OSOBA Nazwisko RokUr Wiek() Ekstensja klasy OSOBA OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko Abacki RokUr 1948 OSOBA Nazwisko Nowacki RokUr 1940 PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(...) PRACOWNIK Nazwisko Nowak RokUr 1951 Zarobek 2000 Dział zabawki PRACOWNIK Nazwisko Abacki RokUr 1948 Zarobek 2500 Dział zabawki PRACOWNIK Nazwisko Nowacki RokUr 1940 Zarobek 3000 Dział sprzedaż Ekstensja klasy PRACOWNIK

57 Delegacja Określenie sytuacji w modelu obiektowym, gdy komunikat wysyłany do danego obiektu powoduje wykonanie operacji na innym obiekcie (jest „oddelegowany” do innego obiektu). W UML delegacją jest nazywana sytuacja, kiedy obiekt po otrzymaniu komunikatu wysyła komunikat do innego obiektu. Często określenie „delegacja” dotyczy sytuacji, kiedy jakiś złożony atrybut obiektu jest także obiektem i jest wystąpieniem innej klasy. Jest ona także określana jako dziedziczenie w ramach wystąpień obiektów, co kojarzy ją z pojęciem prototypu. W tym znaczeniu pojęcie to jest wykorzystywane dla pewnych technicznych celów, np. „obejścia” braku dziedziczenia lub wielodziedziczenia. Pojęcie delegacji nie zawsze jest jasne, ponieważ opiera się na powierzchownych cechach specyficznych dla modelu obiektowego przyjętego w danym języku, co powoduje dość różne jego rozumienie. Np. w języku Smalltalk (gdzie „wszystko jest obiektem”) trudno wyróżnić istotną merytorycznie podstawę definicji tego pojęcia.

58 Klasa, interfejs, typ Mnóstwo nieporozumień na tle rozróżnień pomiędzy tymi pojęciami. Klasa. Zestaw cech wspólnych dla obiektów zarówno w planie ich populacji, jak i zmian zachodzących w czasie. Klasa jest jednostką ponownego użycia i obrotu handlowego. Zawiera wszystko to, co jest potrzebne do tego, aby ją umieścić wewnątrz pewnej aplikacji, w szczególności, implementację metod, implementację bloków reakcji na zdarzenia, itd. Interfejs. Komplet informacji o tych własnościach obiektów klasy, które są niezbędne do ich poprawnego użycia. Interfejs posiada znaczenie pojęciowe dla użytkownika lub programisty, pozwalając na manipulowanie zewnętrznymi cechami obiektów i przewidywanie skutków tych manipulacji. Interfejs może być (nieodpłatnie) opublikowany w podręczniku. Pojedynczy interfejs może cechować wiele implementacji, jak również jedna klasa może być wyposażona w wiele interfejsów. Typ. Specyfikacja ograniczająca kontekst, w którym obiekty danej klasy mogą być użyte w wyrażeniach, zapytaniach lub programach. Typ określa również reprezentację wartości przechowywanych wewnątrz obiektu. Niekiedy typ określa również wewnętrzną budowę obiektów. Typ jest pojęciem różnym zarówno od klasy jak i od interfejsu.

59 Wielokrotne dziedziczenie
Przy wielodziedziczeniu klasa może dziedziczyć z dwóch lub więcej klas. POJAZD ciężar ..... prędkość_eksploat() POJAZD_LĄDOWY ilość_kół max_prędkość ..... POJAZD_WODNY wyporność max_prędkość ..... SAMOCHÓD TRAKTOR ŻAGLÓWKA JACHT AMFIBIA Wielodziedziczenie prowadzi do anomalii i wad koncepcji. Z tego względu niektóre języki (m.in. Java) rezygnują z wielodziedziczenia. W wiekszości anomalie są konsekwencją faktu, że przy pomocy wielodziedziczenia próbuje się opanować koncepcję dynamicznych ról obiektu.

60 Dynamiczne role obiektów
OSOBA Nazwisko RokUr Wiek() PRACOWNIK Zarobek Dział ZarobekNetto() ZmieńZarobek(..) STUDENT Semestr NrIndeksu WpiszOcenę(...) ObliczŚredniąOcen() Klasy OSOBA Nazwisko Abacka RokUr 1948 OSOBA Nazwisko Kowalska RokUr 1975 OSOBA Nazwisko Nowak RokUr 1951 OSOBA Nazwisko Nowacki RokUr 1940 PRACOWNIK Zarobek 2500 Dział Kredyty PRACOWNIK Zarobek 1500 Dział Obsługa Obiekty STUDENT Semestr 7 NrIndeksu STUDENT Semestr 4 NrIndeksu jest_klientem pracuje_w pracuje_w studiuje_na studiuje_na FIRMA Nazwa BankSA UCZELNIA Nazwa PW UCZELNIA Nazwa UW

61 Podsumowanie obiektowości
Obiektowość jest informatyczną ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka. Obiektowość jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością, i trudną do opanowania złożonością. Obiektowość przenika wszystkie fazy projektowania, oraz narzędzia i interfejsy. Obiektowość dopracowała się własnej kolekcji pojęć i narzędzi. W dziedzinie baz danych obiektowość jest na początku drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii i technologii.

62 Część 4. Wprowadzenie do UML
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 4. Wprowadzenie do UML

63 Unified Modeling Language (UML)
RATIONAL SOFTWARE CORPORATION (dokumentacja on line) UML , 1995-wrzesień 1996. UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMG UML 1.3, kwiecień 1999 (mówi się o wersji 1.4, ale brak danych) Połączone siły trzech znanych metodologów oprogramowania: Grady BOOCH, Ivar JACOBSON, James RUMBAUGH Wykorzystano doświadczenia poprzednich metodyk: OOAD (Booch), OMT (Rumbaugh, et al.), Fusion (Coleman et al.), OOSE (Jacobson)

64 Czym jest a czym nie jest UML?
UML nie jest metodyką analizy i projektowania. UML (jak dotąd) nie definiuje procesu rozwoju oprogramowania UML nie jest wyłącznie notacją (tzn. składnią diagramów). Definicja podana przez Rational [ : "The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system." “UML jest językiem do specyfikacji, konstruowania, wizualizaji i dokumentowania wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie.”

65 Notacja a metodyka UML nie ogranicza się do notacji. Dowolny język, w tym UML, oprócz składni posiada dwa znacznie od niej ważniejsze aspekty: semantykę i pragmatykę. Składnia określa, jak wolno kombinować ze sobą przyjęte oznaczenia. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Pragmatyka określa, w jaki sposób i do czego należy używać przyjętych oznaczeń. Pragmatyka określa, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny. Pragmatyka UML wyznacza więc procesy prowadzące do wytworzenia zapisów wyników analizy i projektowania, które są zgodne z intencją autorów tej notacji. Jakakolwiek notacja nie ma większego sensu bez wiedzy o tym, w jaki sposób może być ona użyta w ramach pewnego procesu analizy i projektowania. Autorzy UML pracują nad metodyką, noszącą obecnie nazwę Rational Objectory Process lub Rational Unified Development Process. (Na razie nazwy zmieniają się zbyt szybko, aby można było mieć pewność...)

66 Zalety i wady poprzedników UML
Każdy model lub notacja ma swoje zalety i wady. 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 analizy i rozpoznania wymagań użytkowników. Istnieje wiele aspektów systemów, które nie są właściwie przykryte przez żadne z wyżej wymienionych podejść, 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.

67 Cele UML (1) Podstawowym celem UML jest modelowanie systemów (nie tylko oprogramowania) z użyciem pojęć obiektowych. Utworzenie języka do modelowania użytecznego zarówno dla ludzi jak i dla maszyn. UML jest notacją pośrednią, pomostem pomiędzy ludzkim rozumieniem struktury i działania programów, a kodem programów. Taka notacja pośrednia jest niezbędna do specyfikacji, konstrukcji, wizualizacji i dokumentacji wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie.

68 Cele UML (2) Diagramy UML ustanawiają bezpośrednie powiązanie elementów modelu pojęciowego z wykonywalnymi programami. Jednocześnie umożliwiają one objęcie zagadnień związanych ze skalą problemu, towarzyszących bardzo złożonym systemom o krytycznej misji. Zdaniem autorów UML, tworzenie takiego języka nie jest istotnie różne od zaprojektowania nowego języka programowania. Z tym pogladem można polemizować. Zasadnicza różnica polega na tym, że język do modelowania nie musi mieć (i z reguły nie ma) precyzyjnej składni i semantyki umożliwiających tworzenie wykonywalnych specyfikacji struktur danych i akcji komputera (programów).

69 Zakres UML Specyfikacja, konstrukcja, wizualizacja i dokumentacja wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie. UML łączy pojęcia metodyk Boocha, OMT i OOSE. Rezultatem jest pojedynczy, wspólny, szeroko stosowalny język dla użytkowników tych i innych metodyk. UML przykrywa to, co może być zrobione przy pomocy istniejących metodyk. W szczególności, autorzy UML mieli na względzie systemy współbieżne i rozproszone. UML skupia się na standardzie języka do modelowania, a nie na standardzie procesów tworzenia oprogramowania. (Różne organizacje i problemy wymagają różnych procesów, które mogą być opisane przy pomocy tego samego języka.) Wysiłek autorów jest skoncentrowany na stworzeniu wspólnego metamodelu (unifikacji semantyki) i wspólnej notacji (odbioru tej semantyki przez ludzi). Promowany jest proces, który jest napędzany przez przypadki użycia, skoncentrowany na architekturze, iteracyjny i przyrostowy.

70 Diagramy definiowane w UML
Autorzy UML wychodzą z założenia, że żadna pojedyncza perspektywa spojrzenia na projektowany system nie jest wystarczająca. Stąd wiele środków: Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy zachowania się (behavior) Diagramy implementacyjne Diagramy stanów Diagramy aktywności Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.

71 UML - krótka charakterystyka diagramów
Diagramy przypadków użycia (use cases): z OOSE (Objectory). Diagramy klas: z OMT i Booch’a. Rozszerzenia specyficzne dla procesów rozwoju (np. stereotypy i odpowiadające im ikony). Diagramy stanów (machine-state): wykresy stanów D. Harela z modyfikacjami. Diagram aktywności, podobny do diagramów przepływu prac znanych z wcześniejszych metodyk. Diagramy sekwencji znane pod innymi nazwami (interakcji, tropów zdarzeń, tropów komunikatów). Diagramy współpracy znane z Booch’a (object diagram) i Fusion (object interaction diagram). Są one nową formą ustalającą podstawę dla wzorców. Diagramy implementacyjne (komponentów i wdrożeniowe) pochodzą od diagramów modułów i procesów wg Booch’a, ale są bardziej zorientowane na komponenty niż na moduły i są znacznie lepiej ze sobą związane. Stereotypy są jednym z mechanizmów rozszerzalności UML. Dają możliwość zdefiniowania nowych ikon dla przystosowania UML do specyficznego procesu oraz uszczegółowienia semantyki modelu.

72 Nowe pojęcia wprowadzone w UML
Stereotypy Odpowiedzialności (responsibilities) Mechanizmy rozszerzalności: stereotypy, etykietowane wartości (tagged values), ograniczenia Wątki i procesy Rozproszenie i współbieżność (np. dla modelowania ActiveX/DCOM i CORBA) Wzorce / współpraca Diagramy aktywności (dla reinżynierii procesów biznesowych) Jasne odróżnienie klasy, typu i wystąpienia Uszczegóławianie (refinement) dla objęcia związków pomiędzy poziomami abstrakcji Interfejsy i komponenty.

73 Metamodel i semantyka UML
Autorzy UML sporo uwagi poświęcają semantyce wprowadzanych notacji. Jest to spowodowane zarzutami w stosunku do metodyk OMT, Booch’a, i innych, podnoszącymi fakt, że sprowadzają się one do radosnego rysowania prostokacików, kółeczek i strzałeczek bez precyzyjnych reguł pragmatycznych i semantycznych. Ta wada modeli analitycznych i projektowych jest prawdopodobnie nie do uniknięcia i bezpośrednio wiąże się z własnościami ludzkiego umysłu, który posługuje się bardziej wyobrażeniem niż formalną konstrukcją. Modele odwołują się do tego wyobrażenia i przez to nie są i nie mogą być matematycznie precyzyjne. Taka precyzja jest sprzeczna z niezbędnym wysokim poziomem abstrakcji, wieloaspektowością rozpatrywanych problemów oraz z charakterem twórczych procesów zachodzących w umysłach analityków i projektantów. Niemniej, to nieprecyzyjne wyobrażenie można uszczegółowić. Opis semantyki proponowany przez autorów UML jest w gruncie rzeczy opisem składni + ograniczenia typologiczne + klasyfikacja pojęć + związki pomiędzy pojęciami. Opisowi temu daleko do formalnej, “algorytmicznej” precyzji wymaganej przez maszynę. I bardzo dobrze...

74 <<aktor>>
UML: stereotypy stereotypes Stereotypy są nazwami umożliwiającymi meta-klasyfikację elementów modelu. Są wspólnymi, nazwanymi własnościami klas. Stereotyp deklaruje meta-klasę wewnątrz modelu zapisanego w UML Element modelu może mieć co najwyżej jeden stereotyp Istnieje lista stereotypów dla każdego rodzaju elementu UML Niektóre stereotypy są predefiniowane, ale użytkownicy mogą dodawać własne Stereotypy mogą mieć implikacje semantyczne (ograniczenia). Rodzaje stereo- typów: Stereotypy klas i obiektów: zdarzenie, wyjątek, interfejs, metaklasa, udogodnienie Sterotypy typu obiektów: obiekt istniejący, sterujący, interfejs Stereotypy zadań: proces, wątek Stereotypy węzłów i stereotypy pakietów <<aktor>> Klient Klient Równoważne oznaczenia

75 Różne notacje stereotypów
«sterowanie» PióroŚwietlne lokacja: Punkt uruchom( Tryb ) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom( Tryb ) PióroŚwietlne lokacja: Punkt uruchom( Tryb ) PióroŚwietlne «woła» ZarządcaZadań Planista

76 Etykietowane wartości
tagged values Dowolny element modelu zbudowanego w UML może być skojarzony z etykietowanymi wartościami. Jest to ciąg znaków o postaci: słowo kluczowe = wartość Etykietowane wartości umieszcza się w nawiasach { }. Podobnie do stereotypów, etykietowane wartości są uważane za cechę wspomagającą rozszerzalność UML. W ten sposób można na diagramach umieścić dowolną dodatkową infiormację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości. Przykłady: {autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza} {abstrakcyjna = TRUE} można skrócić do {abstrakcyjna}

77 Część 5. UML: diagramy klas
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 5. UML: diagramy klas

78 Diagramy klas Są one odmianą dość klasycznych diagramów encja-związek (entity-relationship). Podstawowymi oznaczeniami są oznaczenia klas (prostokąty), oznaczenia hierarchii dziedziczenia (strzałki z białym grotem), oznaczenia związków asocjacji (linie) oraz oznaczenia związków agregacji (białe i czarne romby). Te podstawowe oznaczenia są uzupełnione o dużą liczbę pomocniczych oznaczeń. Oznaczenia praktycznie bez większych zmian są przejęte z OMT. Wprowadzone są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do konkretnej dziedziny zastosowań (np. stereotypy i odpowiadające im ikony).

79 Zastosowania diagramu klas
Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań. Model pojęciowy nie musi być związany z oprogramowaniem; jest on wyłącznie sformalizowaną wizją wyobrażeń powstających w trakcie twórczych procesów myślowych związanych z danym problemem. Sformalizowana specyfikacja danych i metod. Jest ona związana z oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne (hermetyzacja). Dla wielu celów zależy nam wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów, metod, itd.), bez wchodzenia w szczegóły. Rozróżnienie pomiędzy specyfikacją i implementacją jest charakterystyczne dla nowo powstających języków i standardów (CORBA, Java, ODMG). Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++.

80 Oznaczenia klas Trzy pola identycznie jak w OMT. Różny poziom szczegółowości. Stereotypy moga być użyte dla oznaczenia grupy elementów. Okno Okno rozmiar czy_widoczne Okno rozmiar czy_widoczne wyświetl() schowaj() Okno rozmiar: Obszar czy_widoczne: Boolean wyświetl() schowaj() 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*) 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)

81 Oznaczenia dziedziczenia
Oznaczenia dziedziczenia zachowują konwencję OMT (z minimalną zmianą syntaktyczną). Strzałka (z białym trójkątnym grotem) prowadzi od pod-klasy do jej bezpośredniej nadklasy. Zakłada się, że obiekt pod-klasy automatycznie dziedziczy wszystkie atrybuty, metody, asocjacje i agregacje z wszystkich jej nadklas. Osoba Osoba Pracownik Pracownik Asystent Adiunkt Docent Profesor Asystent Adiunkt Docent Profesor

82 Asocjacje Oznaczenia klas są połączone liniami oznaczającymi asocjacje, czyli powiązania pomiędzy obiektami tych klas, np. asocjację Pracuje_dla pomiędzy obiektami klasy Osoba i obiektami klasy Firma. Czarny trójkącik określa kierunek wyznaczony przez nazwę powiązania. W danym przypadku określa on, że osoba pracuje dla firmy, a nie firma pracuje dla osoby. Nazwy asocjacji, takie jak Pracuje_dla, wyznaczają znaczenie tej asocjacji w modelu pojęciowym. Pracuje_dla 1..* Firma Osoba Asocjacje mogą być wyposażone w oznaczenia liczności. Jak zwykle, 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. Asocjacje mogą być także wyposażone w dodatkowe nazwy ról (przy odpowiednich końcach), np. pracodawca i pracownik.

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

84 Notacja stosowana w diagramach klas - przykład
Pracuje-dla * 1..* Firma Osoba pracodawca pracownik Stanowisko zarobek szef 0..1 podwładny * Kieruje Firma Osoba Konto {or}

85 Przykładowy diagram klas w UML
Osoba zapisany_na poprzedza Student Pracownik 1..* 0..* Kurs 0..* Student_asystent Profesor zawiera następuje_po asystuje_w 0..1 prowadzi prowadzony_dla jest_składową 1..* 1..* ma_asystenta Wykład 0..* prowadzony_przez

86 Ograniczenia - przykład
constraints * Jest_członkiem * Osoba Komitet {podzbiór} 1 Jest_przewodniczącym * podwładny Osoba * * Pracuje_dla 0..1 Firma 0..1 pracownik pracodawca szef Ograniczenie lub adnotacja {Osoba.pracodawca = Osoba.szef.pracodawca}

87 Asocjacje kwalifikowane
Bank nrKonta * 0..1 Osoba Zamówienie WierszZamówienia ilość: Liczba 0..1 produkt pozycja zamów Kwalifikator jest atrybutem asocjacji (lub zestawem atrybutów asocjacji), 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.

88 Wieloaspektowe generalizacje/specjalizacje
Pojazd napęd napęd teren teren {overlapping} {overlapping} Pojazd wiatrowy Pojazd silnikowy Pojazd lądowy Pojazd wodny Ciężarówka Żaglówka Drzewo «powertype» GatunkiDrzew {disjoint, incomplete} species: GatunkiDrzew Dąb Brzoza Sosna stereotyp

89 Agregacje 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!

90 Kompozycja jako mocna forma 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 modelowania dowolnej innej sytuacji, kiedy trzeba wydzielić pod-obiekty 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.

91 Agregacja i kompozycja
{ordered} Punkt Kompozycja 3..* 1 Wielobok Okrąg promień * * Styl kolor czyWypełniony 1 1 Agregacja

92 Różna postać zapisu kompozycji
Okno pasekPrzesuwny[2]: Suwak tytuł: Nagłówek ciało: Panel Okno 1 1 1 pasekPrzesuwny 2 tytuł 1 ciało 1 Suwak Nagłówek Panel Okno pasekPrzesuwny: Suwak tytuł: Nagłówek ciało: Panel Okno 2 2 Suwak pasekPrzesuwny 1 1 Nagłówek tytuł 1 1 Panel ciało

93 Konstruowanie diagramu klas
Konstruowanie diagramu klas wymaga następujących kroków: Identyfikacja obiektów i klas Przygotowanie słownika danych Zidentyfikowanie związków między obiektami Zidentyfikowanie atrybutów obiektów Zorganizowanie i uproszczenie klas obiektów z użyciem dziedziczenia Analiza ścieżek dostępu dla prawdopodobnych zapytań Iteracje i precyzowanie modelu Grupowanie klas w moduły

94 Budowa modelu obiektowego: ćwiczenie
Założenia systemu transportu lotniczego: Mają być rejestrowane są informacje o wszystkich lotach konkretnych, odbytych i planowanych (data, numer lotu, samolot, pilot, itd ). Powinna istnieć możliwość zmiany danych o locie. Mają być rejestrowane dane o dostępnej flocie powietrznej (typ samolotu, nr_seryjny, rok produkcji, przeleciane godziny), z możliwością określenia, czy samolot spełnia warunki techniczne niezbędne do eksploatacji. Mają być rejestrowane informacje o pilotach, ich przypisaniu do poszczególnych lotów, miejsce ich zatrudnienia. Mają być rejestrowane informacje o liniach lotniczych, zatrudnianych przez nich pilotów i posiadanych przez nich maszynach Mają być rejestrowane informacje o przylotach i odlotach, portach i miastach Mają być rejestrowane informacje o pasażerach, rezerwacjach i wykupionych biletach an poszczególne loty

95 Przykładowe rozwiązanie: pierwsza przymiarka
Osoba nazwisko Pilot kwalifikacje Sprzęt latający ... prowadzi zatrudniony Linia lotnicza nazwa posiada obsługuje Samolot model nr seryjny rok_produkcji godziny_przeleciane czy_posiada_atest odlot Lot data nr lotu zmień_lot Port lotniczy nazwa przypisany przylot Miasto nazwa Pasażer rezerwacja bilet Fotel lokalizacja

96 Klasy parametryzowane
Niektóre języki obiektowe, wśród nich C++, wprowadzają użyteczne pojęcie klasy parametryzowanej (zwane też szablonem, template). UML wprowadza specjalne oznaczenie dla klas parametryzowanych, które może być użyte w diagramie klas. class Zbiór <T> { void wstaw ( T nowyElement ); void usuń ( T pewienElement ); } T Zbiór wstaw( T ) usuń( T ) Klasa parametryzowana Parametr (typ)

97 Diagramy pakietów Pakiety są zestawami elementów modelu wraz z zachodzącymi pomiędzy nimi zależnościami. Diagramy pakietów odwzorowują przekazywanie (import) informacji z pakietu do pakietu. Diagramy pakietów mogą być istotne dla dużych projektów, składających się z wielu modułów funkcjonalnych ze złożonymi zależnościami pomiędzy modułami. Pakiety mogą być zagnieżdżane. Zależności pomiędzy pakietami są przedstawiane w postaci strzałki z przerywaną linią. Strzałki zaznaczają przepływ (import) informacji pomiędzy pakietami. Pakiety są traktowane jako obiekty należące do swoich klas, które mogą podlegać związkom dziedziczenia.

98 Przykład diagramu pakietów
Pakiety są rysowane jako duże prostokąty z małym prostokątem u góry (“etykietą”). Jeżeli zawartość pakietu nie jest pokazana, wówczas nazwa pakietu jest wpisana do większego prostokąta. Jeżeli jest pokazana, to nazwę pakietu wpisuje się do “etykiety”. Edytor Sterownik Elementy diagramów graficznych Elementy dziedziny zastosowań System okienkowy Rdzeń grafiki Rdzeń grafiki Motif Motif Rdzeń grafiki Windows MS Windows

99 Wprowadzenie do obiektowych metodyk projektowania
Jedenasta Górska Szkoła PTI Szczyrk’99 Wprowadzenie do obiektowych metodyk projektowania i notacji UML Część 6. UML: przypadki użycia, modele dynamiczne, diagramy implementacyjne

100 Przypadki użycia Przypadki użycia odwzorowują strukturę systemu tak,
use case Podstawowym problemem jest określenie wymagań na projektowany system. Celem metody opartej na przypadkach użycia jest: zrozumienie użycia systemu bedącego przedmiotem procesu projektowania zwiekszenie stopnia świadomości analityków i projektantów co do celów tego systemu umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami weryfikacja poprawności i kompletności projektu odzyskanie wszystkich strukturalnych i funkcjonalnych własności systemu ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu dostarczenie podstawy do sporządzenia planu testów systemu Przypadki użycia odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy.

101 Przykład modelu przypadków użycia
wpłata pieniedzy kasjer wypłata pieniedzy «uses» klient banku sprawdź bilans weź pożyczkę zarząd banku Model przypadków użycia można rozbudowywać poprzez dodanie nowych aktorów, nowych przypadków użycia oraz nowych powiązań pomiędzy przypadkami użycia.

102 Diagram przypadków użycia
Ustalenie limitów Aktualizacja rozliczeń System rozliczeniowy Dyrektor handlowy Analiza ryzyka «uses» Wyliczenie ocen Sprawy cenowe «uses» Handlowiec Ocena zysków «extends» Sprzedawca Przekroczenie limitów Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie.

103 Opis przypadku użycia Opis przypadku użycia może być dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: 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, lub jak i kiedy zapamiętuje dane w systemie? Wyjątki przy przepływie zdarzeń. Jak i kiedy używane są pojęcia dziedziny problemowej?

104 Powiązania w modelu przypadków użycia
Generalizacja pomiędzy aktorami Analityk Uczestnik projektu Programista «extends» Modeluje sytuację kiedy rozszerzający przypadek użycia definiuje wspólne lub dobrze wyodrębnione akcje. Rozszerzony przypadek użycia wykonuje wszystkie zdefiniowane w nim akcje plus niekiedy dodatkowo akcje określane przez przypadek rozszerząjący. Jest on zwykle niekompletny. «uses» Modeluje sytuację kiedy przypadek (przypadki) użycia wykorzystuje (wykorzystują) wspólny przypadek użycia (np. blok ponownego użycia) na zasadzie podobnej do wywołania procedury. Zmiany: «uses» «import» «extends» «extend» Dziedziczenie w ramach przypadków użycia, liczność związków aktor - przypadek użycia

105 Dokumentacja przypadków użycia
Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy: Krótki opis przypadku użycia. Przepływ zdarzeń opisany nieformalnie. Związki pomiędzy przypadkami użycia. Uczestniczące obiekty. Specjalne wymagania (np. czas odpowiedzi, wydajność). Obrazy interfejsu użytkownika. Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów). Diagramy interakcji dla każdego aktora.

106 Przypadki użycia - analiza aktorów
Przy wyszukiwaniu aktorów ze sformułowanych wymagań istotne są odpowiedzi na następujące pytania: Jaka grupa użytkowników potrzebuje wspomagania ze strony systemu? Jacy użytkownicy są konieczni do tego, aby system działał i wykonywał swoje funkcje? Należy te funkcje rozbić na funkcje odnoszące się do dziedziny przedmiotowej (np. osoba rejestrująca korespondencję) i do wspomagania systemu (np. administrator systemu). Z jakiego sprzętu zewnętrznego (komputerów, czujników, sieci, itp.) musi korzystać system aby realizować swoje funkcje?

107 Modele i diagramy dynamiczne
Są to modele i diagramy, które uwzględniają: czas, zdarzenia, następstwo czynności, synchronizację czynności, transakcje, stany procesów, spontaniczne akcje, interakcję z otoczeniem systemu, dialogi. Zwykle są notacjami opartymi na diagramach przepływu sterowania, diagramach automatów skończonych, sieciach Petri’ego, sieciach PERT, Modele dynamiczne są zwykle powiązane z innymi modelami wspólnymi oznaczeniami (obiektów, procesów). Modele dynamiczne są często istotnym uzupełnieniem diagramów klas, ale w wielu przypadkach ich znaczenie jest pomocnicze, drugorzedne. Warto je sporzadzać tylko wtedy, jeżeli odwzorowują one istotną informację. Często modele dynamiczne są trudne do sporządzenia, ze względu na nieprzewidywalność, wielowariantowość scenariuszy działania systemu.

108 Diagramy sekwencji Idea bardzo podobna do diagramów tropów zdarzeń lub diagramów tropów komunikatów, ale rozudowana o możliwość podawania ograniczeń czasowych, a nawet (co jest kontrowersyjne) skali czasowej. dzwoniący sterowanie odbierający podniesienie słuchawki a {b - a < 1 sec.} ton w słuchawce b {c - b < 10 sec.} wybór cyfry c . . . Rozmowa jest łączona poprzez sieć {d’ - d < 5 sec.} d łączenie d’ ton dzwonka uruchomienie dzwonka podniesienie słuchawki koniec tonu koniec dzwonienia W tym punkcie rozmówcy mogą rozmawiać

109 Różne oznaczenia w diagramach sekwencji
op() ob3:C3 ob4:C4 ob1:C1 [x>0] foo(x) ob2:C2 [x<0] bar(x) doit(w) Diagram sekwencji z warunkami, rekurencją, tworzeniem i kasowaniem doit(w) more() Autorzy UML strają się doprowadzić te diagramy do precyzji języków programowania. Wydaje się, że jest to pseudo-koncepcja. Diagramy te, ze swojej natury, są raczej słabym środkiem specyfikacji programów. Wprowadzanie wielu opcji na tych diagramach mija się z ich celem.

110 Diagramy współpracy (kolaboracji)
Istotą diagramów współpracy jest przedstawienie przepływu komunikatów pomiędzy obiektami. Współpraca pomiędzy obiektami włącza dwa aspekty: strukturę uczestniczących obiektów oraz sekwencję komunikatów wymienianych pomiędzy obiektami. Czas nie jest odwzorowany, natomiast odwzorowane są powiązania pomiędzy obiektami (część powiązań z diagramu klas). :OknoWprowadzaniaZamówienia Obiekt 1: przygotuj() Komunikat :Zamówienie 2: *[dla wszystkich wierszy zamówienia] przygotuj() Numer kolejny komunikatu 3: maAkcje := sprawdź() 4:[maAkcje]:usuń() 5:czyNoweZamów := potrzebaNowegoZamów() LiniaMacallana: WierszZamówienia AkcjeMacallana: PozycjaAkcji 7: [maAkcje]: new 6:[czyNoweZamów]: new :PozycjaDostarczana :PozycjaPonownieZamówiona

111 Diagram stanów Diagram stanów nawiązuje do automatu skończonego. Opisuje on stany pewnego procesu, które są istotne z punktu widzenia modelu pojęciowego tego procesu, oraz przejścia pomiędzy stanami, wymuszane poprzez pewne „zdarzenia”. W UML ta pierwotna idea uległa istotnym modyfikacjom i rozszerzeniom. Stany są wzbogacone o akcje wykonywane „wewnątrz” stanów, zaś „zdarzenia” mogą być także pewnymi warunkami, w szczególności warunkiem który jest zawsze prawdziwy. W istocie, w „diagramach stanów” nie chodzi o „stany”. Nazwa “diagram stanów” (wprowadzona przez D. Harela jako “statecharts”) nie oddaje istoty. Diagramy stanów nie są tymi diagramami stanów, o których jest mowa w teorii automatów. Są to dość klasycznie diagramy przepływu sterowania (flowcharts), z szeregiem drugorzędnych opcji syntaktycznych i semantycznych. Nazwa „diagramy stanów” jest nieodpowiednia i myląca dla środowiska akademickiego, gdyż powoduje fałszywe asocjacje.

112 Przykład diagramu stanów
Stany (akcje) mogą być zagnieżdżane. Aktywny Nr telefonu Koniec czasu do/ odegraj komunikat wybierz cyfrę(n) [niekompletny] 15 sec. 15 sec. Ton w słuchawce do/ odegraj ton Wybieranie numeru podniesiona słuchawka /włącz ton wybierz cyfrę(n) [zły numer] wybierz cyfrę(n) [numer poprawny] /połącz Spoczynek Zły numer do/ odegraj komunikat Łączenie Zajęty Połączony Rozmowa zawieszona Zajęty do/ odegraj ton zajętości położona słuchawka /rozłącz rozmówca zawiesza rozmówca odpowiada rozmówca odpowiada /umożliwienie rozmowy Dzwonek u odbiorcy do/ odegraj ton dzwonka Rozmowa

113 Diagram dynamiczny - specyfikacja wymagań
Pracownik firmy zgłasza wniosek o zakup do kierownika zaopatrzenia. Kierownik uruchamia procedurę zakupu i wyznacza pracownika odpowiedzialnego. Pracownik odpowiedzialny przygotowuje informację o zakupie i swoje sugestie. Kierownik przegląda tę informację i zatwierdza wniosek lub nie. Jeżeli zatwierdza, to dalsze postępowanie zależy od szacunkowego kosztu zakupu. Jeżeli koszt jest poniżej 1000 zł, to wniosek musi zaakceptować dział finansowy. Dział finansowy może wniosek zaakceptować, odrzucić lub mieć wątpliwości i skierować do prezesa. Jeżeli zakup jest powyżej 1000 zł, to akceptacji musi dokonać prezes. Prezes może wniosek zaakceptować lub odrzucić. Po akceptacji prezesa wniosek musi jeszcze przejść procedurę w dziale finansowym, j.w. Jeżeli wniosek jest odrzucony w dowolnej fazie, to pracownik odpowiedzialny musi o tym pisemnie poinformować wnioskodawcę Jeżeli wniosek jest zakceptowany, to pracownik odpowiedzialny musi równocześnie pisemnie poinformować wnioskodawcę i uruchomić procedurę zakupu.

114 Przykład diagramu stanów: zakupy dla firmy
[Wpłynął wniosek] Przygotowanie informacji o zakupie (prac. odpow.) Start wystąpienia procesu Ustalenie pracownika odpowiedzialnego Przygotowanie informacji o odrzuceniu (prac. odpow.) Akceptacja przez kierownika zaopatrzenia [odrzucony] [odrzucony] [odrzucony] [zaakceptowany] Akceptacja przez prezesa Decyzja kierownika zaopatrzenia [koszt >= 1000zł] [wątpliwości] [zaakceptowany] Przygotowanie informacji o akceptacji (prac. odpow.) Akceptacja przez dział finansowy [koszt < 1000zł] [zaakceptowany] Procedura zakupu AND

115 Diagram aktywności Osoba::Przygotowanie Napoju [nie ma kawy]
[nie ma herbaty] Znajdź Napój [herbata znaleziona] [kawa znaleziona] Zrób herbatę Weź sobie wody Nasyp kawy do filtru Dolej wody do zbiornika Weź filiżankę Włóż filtr do maszynki 1..4 Nalej kawę 1..4 Wypij światełko zgasło Włącz maszynkę Gotowanie kawy MaszynkaDoKawy.włączona

116 Diagramy implementacyjne
Diagramy implementacyjne pokazują niektóre aspekty implementacji SI, włączając w to strukturę kodu źródłowego oraz strukturę kodu czasu wykonania (run-time). UML wprowadza dwa typy takich diagramów: Diagramy komponentów pokazujące strukturę samego kodu, Diagramy wdrożeniowe pokazujące strukturę systemu czasu wykonania.

117 Diagram implementacyjny: komponentów
Diagramy komponentów pokazują zależności pomiędzy komponentami oprogramowania, włączając komponenty kodu źródłowego, kodu binarnego oraz kodu wykonywalnego. Komponenty mogą istnieć w różnym czasie: niektóre z nich w czasie kompilacji, niektóre w czasie konsolidacji, zaś niektóre w czasie wykonania. Diagram komponentów jest przedstawiany jako graf, gdzie węzłami są komponenty, zaś strzałki (z przerywaną linią) prowadzą do klienta pewnej informacji do jej dostawcy. Program do harmonogramów rezerwacje Program planujący aktualizacje Interfejs graficzny

118 Diagram implementacyjny: wdrożeniowy
Diagram wdrożeniowy pokazują konfigurację elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, procesów , związanych z nimi obiektów. Diagram wdrożeniowy jest grafem, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne. AdminServer:KomputerHost «baza danych» spotkaniaBD KomputerJacka:PC Program planujący Program do harmonogramów rezerwacje

119 Diagram wdrożeniowy Specjalne symbole są zwykle znacznie lepsze. W UML są one w pełni legalne. Serwer oddziału terapii Szpitalna sieć Ethernet Internet Klient Web Serwer diabetyków Sieć Ethernet oddziału PC z Windows PC z Windows

120 UML: Podsumowanie UML powstał w rezultacie połączonych wysiłków trzech znanych metodologów: G. Booch’a, I. Jacobsona i J. Rumbaugh’a. UML stał się bardzo popularny, przez wiele lat będzie prawdopodobnie dominował w obszarze analizy i projektowania. UML nie ma ambicji być metodyką projektowania. Jest zestawem pojęć, diagramów i oznaczeń, który może być użyty w dowolnej metodyce. Notacja opiera się o podstawowe pojęcia obiektowości. UML wprowadza wiele pojęć, diagramów i oznaczeń, które w założeniu mają przykryć większość istotnych aspektów modelowanych systemów. Kwestia semantyki tej notacji pozostaje mglista, co jest nieuchronnym skutkiem sprzeczności pomiędzy naturą procesów twórczych i formalizacją. Pragmatyka użycia tej notacji (tj. dopasowanie jej do konkretnej sytuacji) pozostaje wielkim problemem, którego przyczyny są podobne do w/w. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór niestabilny, zbyt ciężki, przereklamowany, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, “design by contracts”, i innych.