Język UML. Budowa modelu obiektowego i behawioralnego Wykorzystane materiały: prezentacje Bartosza Waltera (UW) UML Tutorial(part1) by Robert C. Martin
Historia projektowania obiektowego Początki projektowania obiektowego: lata 70-te XX wieku Najważniejsze metodologie obiektowe: OOADA(Object-OrientedAnalysisandDesignwithApplications) Grady Booch nacisk na projektowanie OOSE(Object Oriented Software Engineering) Ivar Jacobson nacisk na inżynierię wymagań OMT(ObjectModelingTechnique) JamesRumbaugh nacisk na analizę
Historia UML Język UML(UnifiedModelingLangauge ujednolicony język modelowania) unifikacja metod Boocha, Jacobsona i Rumbaugh (1994 r.), z poszczególnych notacji przejęto najlepsze rozwiązania Początkowo wspierany przez firmę Rational Software(program Rational Rose) Najbardziej rozpowszechnione wersje UML: 1.1 (1997) oraz 1.4 (2002 r.), jednak są powoli wypierane przez nowsze, bardziej spójne i dopracowane wersje (2.x) 2005 r. wersja 1.4.2 oficjalnym, międzynarodowym standardem projektowania aplikacji (Information technology: ISO/IEC 19501:2005) 07/2005 r. wersja: 2.0 (duży krok naprzód) 08/2011 r. wersja: 2.4.1 (http://www.omg.org/spec/uml/2.4.1/) uznana standardem w kwietniu 2012 r. (ISO/IEC 19505-1, 19505-2) Obecnie język UML nie posiada praktycznie konkurencji w dziedzinie obiektowego projektowania aplikacji
OMG Object Management Group Niekomercyjna organizacja powstała w 1989 r. Jej celem jest promowanie teorii oraz praktyki technologii obiektowych Założycielami OMG było 13 liczących się przedsiębiorstw z branży software'owej Obecnie do organizacji należy 321 firm producenci oprogramowania oraz sprzętu komputerowego (stan na dzień 11/04/2013) Organizacja zajmuje się opracowywaniem standardów pomagających w tworzeniu aplikacji obiektowych W 1997 r. OMG włączyła się do prac nad UML 2005 r. OMG doprowadziła do uznania UML 1.4 jako oficjalnego standardu
Czym jest UML? Jest językiemdo specyfikacji, wizualizacji, konstrukcji, dokumentowania projektów związanych z systemami informacyjnymi intensywnie wykorzystującymi oprogramowanie, a także do modelowania biznesowego wszelkich innych systemów Oferuje standaryzowany sposób zapisu projektu, obejmującego zarówno jego konceptualne aspekty, takie jak procesy biznesowe czy funkcje systemu, jak też i elementy fizyczne (np. schematy bazy danych, warstwę sprzętową systemu) Standaryzuje notację graficzną określa sposób zapisu modeli
Czym nie jest UML? UML nie jest metodyką UML nie określa metody modelowania, zaleca jedynie stosowanie podejścia przyrostowego UML nie jest narzędziem UML to specyfikacja dla narzędzi UML nie jest językiem programowania generowanie kodu z modelu stosowane jest obecnie na niewielką, choć stale zwiększającą się skalę (przyczyna: dopiero teraz powstają narzędzia CASE lepiej wspomagające ten proces)
Perspektywy UML Perspektywa przypadków użycia opisuje funkcjonalność, jaką powinien dostarczać system, widzianą przez jego użytkowników. Perspektywa logiczna zawiera sposób realizacji funkcjonalności, strukturę systemu widziana przez projektanta. Perspektywa implementacyjna opisuje poszczególne moduły i ich interfejsy wraz z zależnościami; perspektywa ta jest przeznaczona dla programisty. Perspektywa procesowa zawiera podział systemu na procesy (czynności) i procesory (jednostki wykonawcze); opisuje właściwości niefunkcjonalne systemu i służy zarówno programistom jak i integratorom. Perspektywa wdrożenia definiuje fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze; perspektywa taka służy integratorom i instalatorom systemu.
Diagramy UML 2.x diagram klas (class) diagram obiektów (object) diagram struktur złożonych (composite structure) diagram pakietów (package) diagram komponentów (component) diagram wdrożenia (deployment) diagram przypadków użycia (use cases) diagram maszyny stanowej (state machine) diagram czynności (activity) diagram sekwencji (sequence) diagram komunikacji (communication) diagram przeglądu interakcji (interaction overview) diagram uwarunkowań czasowych (timing) diagramy strukturalne diagramy zachowania (behawioralne) diagramy interakcji
Projektowanie i programowanie obiektowe Projektowanie obiektoweto strategia, w ramach której projektanci systemu myślą w kategoriach bytów, a nie operacji albo funkcji. Działający system składa się z oddziałujących na siebie obiektów, które przechowują swój lokalny stan i oferują operacje testujące lub zmieniające ten stan. Obiekty ukrywają informację o reprezentacji stanu i w ten sposób ograniczają do niego dostęp. Proces projektowania obiektowego obejmuje zaprojektowanie klas obiektów i związków (relacji) między tymi klasami. W działającym programie, potrzebne obiekty są tworzone na podstawie definicji klas. Programowanie obiektowepolega na realizacji projektu oprogramowania za pomocą obiektowego języka programowania. Języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów.
Definicje obiekt, klasa, atrybuty, operacje Obiekt(ang. object) jest bytem, który posiada swój stan i zbiór zdefiniowanych operacji działających na tym stanie. Stan jest reprezentowany jako zbiór atrybutów(ang. attributes) obiektu. Operacje(ang. operations) skojarzone z obiektem służą do oferowania usług innym obiektom (klientom), które mogą żądać tych usług, gdy potrzebują wyników ich działania. W obiektowych językach programowania operacje nazywa się metodami. Grupa obiektów może mieć wspólną definicję danych lub usług wykorzystywanych do definicji interfejsu, stanowiąc wcielenie (instancje) wspólnej definicji zwanej klasą obiektów. Pojęcie klasyumożliwia więc wyróżnienie podobnej grupy obiektów według pewnego kryterium (pewnych cech, którymi są atrybuty i operacje). Jeżeli mamy zdefiniowaną klasę, to mówimy, że obiekt należący doniej jest instancją tej klasy (ang. instance). Obiekty są tworzone zgodnie z definicja klasy obiektów. Definicja klasy obiektów służy jako szablon do tworzenia obiektów. Zawiera deklaracje wszystkich atrybutów i operacji, które należy skojarzyć z obiektem tej klasy.
Reprezentacja graficzna klasy w UML Nazwa klasy (- + #) nazwa atrybutu : typ danych = wartość domyślna (...) (- + #) nazwa operacji (lista argumentów) : typ wyników (...) Widoczność atrybutu / operacji: -: prywatny (ang. private) +: publiczny (ang. public) #: chroniony (ang. protected) podkreślenie: statyczny (ang. static) Nazwa klasy pisana kursywą klasa abstrakcyjna (ang. abstract class)
Przykład klasa Pracownik Pracownik + nazwisko : string + adres : string + dataurodzenia : Date + licznikpracowników : integer + PESEL : string + dział : Dział + przełożony : Pracownik + wynagrodzenie : integer = 0 + stan : {zatrudniony, tatus: zwolniony, {current, emerytowany} left, retired} taxcode: integer + NIP : integer... - numerpracownika : integer + zatrudnij() join () + zwolnij() leave () + przejdźnaemeryturę() retire + dajpodwyzke(kwota) changedetails ( # sprawdzpoprawnoscnumerupesel() Klasa Pracownik w mniejszym stopniu uszczegółowienia: Pracownik Symbol obiektu (instancji) klasy Pracownik: Jan Kowalski : Pracownik
Przykład klasa Circle i jej reprezentacja w C++ class Circle { public: void SetCenter(const Point&); void SetRadius(double); double Area() const; double Circumference() const; private: double itsradius; Point itscenter; };
Komunikacja pomiędzy obiektami Obiekty porozumiewają się przez żądania usług od innych obiektów (wywołania operacji), i jeśli trzeba, wymianę informacji niezbędnych do realizacji usługi. Kopie informacji potrzebnych do wykonania usługi i wyniki jej wykonania są przekazywane jako parametry. Obiekt odbiorca analizuje składniowo komunikat, rozpoznaje usługę i przekazane dane a następnie realizuje żądaną usługę. Typowe przykłady komunikacji w obiektowych językach programowania: // Wywołaj operację dla obiektu buforcykliczny, która pobiera kolejną // wartość z bufora i zapisuje ją do zmiennej. w = buforcykliczny.pobierz(); // Wywołaj metodę termostatu, ustawiającą temperaturę termostat.ustawtemperaturę(20);
Związki między obiektami W modelu zwykle istnieją różne zależności (wiązania( wiązania, ang. links) pomiędzy obiektami należącymi do różnych klas obiektów. o1 : K1 stan o1 o3 : K3 stan o3 o4 : K4 stan o4 o2 : K2 stan o2 o6 : K6 stan o6 o5 : K5 stan o5 Zależności te reprezentuje się przez związek(inaczej relację, ang. association) między klasami.
Związki między klasami. Powiązanie Najprostszym, ogólnym związkiem jest powiązanie(ang. binary association; generalassociation). Używa się go do wskazania, że atrybut obiektu jest powiązany z innym obiektem, albo że implementacja metody korzysta z powiązanego obiektu. Powiązanie modelowane jest linią łączącą klasy obiektów, która może mieć dodatkowe adnotacje (opis związku). Istnieją również powiązania n-arne, łączące ze sobą więcej niż 2 klasy. Pracownik Dział jest-członkiem jest-zarządzany-przez zarządza Kierownik
Związki między klasami. Uogólnienie Klasy obiektów można ułożyć w hierarchię uogólnienia (ang. generalization), w której widać związek między ogólnymi i bardziej szczegółowymi klasami obiektów. Szczegółowa klasa obiektów jest w pełni zgodna z ogólną klasą obiektów, ale zawiera więcej informacji. W UML uogólnienie obrazuje się za pomocą linii zakończonej strzałką wskazującą klasę macierzystą. W obiektowych językach programowania uogólnienie zwykle implementuje się za pomocą mechanizmu dziedziczenia(ang. inheritance). Klasa potomna dziedziczy atrybuty i operacje po klasie macierzystej. Zalety: Oszczędność czasu, przejrzystość i wygoda: klasy niższe w hierarchii mają te same atrybuty i operacje co ich klasy macierzyste, mogą jednak dodawać nowe atrybuty i operacje lub modyfikować niektóre z tych odziedziczonych. Bezpieczeństwo: zasada uogólniania działa jedynie w jednym kierunku.
Hierarchia uogólnienień Pracownik Kierownik zarządzanebudżety dataprzyjęcia Programista przedsięwzięcie językiprogr Kierownik Przedsięwzięcia przedsięwzięcie Kierownik Działu dział Kierownik Strategiczny obowiązki
Związki między klasami. Agregacja i kompozycja Agregacja(ang. ang. aggregation): tworzenie nowej klasy, przy użyciu klas już istniejących. Nowa klasa może być zbudowana z dowolnej liczby obiektów (obiekty te mogą być dowolnych typów) i w dowolnej kombinacji, by uzyskać żądany efekt. Jest to relacja typu zawiera np: samochód zawiera koła i silnik gdzie samochód, koło i silnik są klasami. Symbol linia zakończona rombem. Kompozycja(ang. ang. composition): składanie się obiektu z obiektów składowych, które nie mogą istnieć bez obiektu głównego. Kompozycja jest relacją typu posiada. Dana część może należeć tylko do jednej całości. Część nie może istnieć bez całości, a usunięcie całości powoduje automatyczne usunięcie wszystkich części związanych z nią związkiem kompozycji. Symbol linia zakończona zaczernionym rombem.
Związki między klasami. Zależność Zależność(ang. ang. dependency) ) między klasami zachodzi, jeżeli zmiany dokonane w stanie jednego z obiektów danej klasy mogą mieć wpływ na obiekt należący do innej klasy.
Związki między klasami. Implementacja Klasa może implementować(realizować) zachowanie wyspecyfikowane w innej klasie (ang. implementation). public interface KlasaA{ public void operacja(); } public class KlasaB implements KlasaA{ } public void operacja(){ // implementacja operacji } <<Interface>> symbol tzw. stereotypu, wyjaśniony będzie za chwilę
Krotność związku Krotność związku(ang. multiplicity) ) określa, ile obiektów danej klasy jest równocześnie związana z obiektami innej klasy 0..1 Zero lub jeden 1 Tylko jeden n Tylko n (gdzie n > 1) 0..* Zero lub więcej (skrót: *) 1..* Jeden lub więcej 0..n Od zera do n (gdzie n > 1) 1..n Od jednego do n (gdzie n > 1)
Atrybuty związku Związek, tak jak i obiekt, też może posiadać atrybuty (jest to tzw. związek kwalifikowany). Użytkownik prawa dostępu Plik
Stereotypy Idea stereotypów(ang. stereotypes) ) polega na ustaleniu pewnej meta- klasyfikacji obiektów (i innych bytów) i wprowadzeniu oznaczeń graficznych klas zgodnych z tą meta-klasyfikacją. Przykład: obiekty interfejsu, obiekty sterujące i obiekty rzeczywiste. Oznaczenie: ciągi znaków wewnątrz nawiasów ; np..«interface«interface»
Budowa modelu obiektowego (1) Identyfikacja klas obiektów Podejście praktyczne polega na wyselekcjonowaniu rzeczowników z Specyfikacji Wymagań Systemowych i potraktowaniu ich jako identyfikatorów klas obiektów. Innym źródłem identyfikacji obiektów mogą być: specyfikacja przypadków użycia dodatkowe klasy obiektów wynikające z ogólnej wiedzy na temat problemu Identyfikacja związków między klasami Wstępna identyfikacja przez rozpatrzenie ze specyfikacji wymagań fraz zawierających czasowniki
Budowa modelu obiektowego (2) Identyfikacja atrybutów i operacji Wstępna identyfikacja atrybutów polega na rozważeniu przymiotników, wyrażeń dzierżawczych odnoszących się do już zidentyfikowanych klas i związków Wstępna identyfikacja operacji m.in. na podstawie modelu przypadków użycia Optymalizacja modelu Identyfikacja związków uogólnienia Grupowanie klas w moduły (pakiety) Weryfikacja, walidacja i uszczegóławianie modelu DIAGRAM KLAS
Diagram klas Diagram klas statyczny statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych, przez ilustrację struktury tury klas i zależności między nimi.
Diagram klas kolejny przykład
Diagram obiektów Diagram obiektówprezentuje możliwą konfigurację obiektów w określonym momencie. Jest pewnego rodzaju instancją diagramu klas, w której zamiast klas przedstawiono ich obiekty. Diagram posługuje się identycznymi symbolami co diagram klas, zamiast symboli klas występują symbole obiektów. Diagramy obiektów przydają się w przypadku szczególnie skomplikowanych zależności, których nie można przedstawić na diagramie klas. Wówczas przykładowe konfiguracje obiektów pomagają w zrozumieniu modelu.
Diagram struktur złożonych Diagram struktur złożonychprzedstawia hierarchicznie wewnętrzną strukturę złożonego obiektu z uwzględnieniem punktów interakcji z innymi częściami systemu. Obiekt składa się z części, które reprezentują poszczególne składowe obiektu realizujące poszczególne funkcje obiektu. Komunikacja pomiędzy obiektem, a jego środowiskiem przebiega poprzez port (oznaczany jako mały prostokąt umieszczony na krawędzi obiektu).porty są połączone z częściami obiektu, które są odpowiedzialne za realizacje tych funkcji. Diagramy struktur złożonych mogą zawierać interfejsy wewnętrzne i interfejsy udostępnione, widoczne na zewnątrz obiektu
Diagram komponentów Komponentto wymienny, wykonywalny fragment systemu o hermetyzowanych szczegółach implementacyjnych. Komponenty z natury służą do ponownego wykorzystania poprzez połączenie ich z innymi komponentami, zwykle poprzez ich skonfigurowanie, bez potrzeby rekompilacji. Funkcjonalność oferowana przez komponent jest dostępna przez interfejsy, które ten implementuje. Z drugiej strony, komponent może wymagać pewnych interfejsów, które muszą być dostarczone przez inne komponenty. Diagram komponentów przedstawia komponenty, ich interfejsy oraz zależności pomiędzy nimi. komponent interfejs oferowany interfejs wymagany
Diagram pakietów Diagram pakietówsłuży do modelowania fizycznego i logicznego podziału systemu. Pakiety są elementem strukturalizującym elementy UML i służą do grupowania ich według dowolnego kryterium. W pakiecie można umieścić praktycznie dowolne elementy: klasy, komponenty, przypadki użycia, pojemniki danych a także inne pakiety.
Diagram wdrożenia Diagram wdrożeniaodzwierciedla fizyczną strukturę całego systemu, z uwzględnieniem oprogramowania i sprzętu. Jednostki oprogramowania są reprezentowane przez artefakty (skompilowane wersje komponentu, dane i biblioteki). Stronę sprzętową reprezentują węzły, czyli poszczególne urządzenia obliczeniowe, komunikacyjne i przechowujące, powiązane ścieżkami komunikacyjnymi (np. połączeniem TCP/IP). Diagram ten istotną rolę odgrywa przy wdrażaniu dużych, rozproszonych systemów.
Diagram przypadków użycia Modelowanie użytkowników systemu (aktorów) i ich potrzeb w stosunku do tworzonego systemu. Omówiony na poprzednich wykładach
Diagram maszyny stanowej Diagram maszyny stanowejreprezentuje zachowanie systemu lub jego elementu (zwykle obiektów danej klasy), a w szczególności zmiany tego zachowania. Podstawowymi elementami diagramu są stany obiektu połączone strzałkami przejść. Obiekt, reagując na nadchodzące zdarzenia, jeżeli j spełnione są określone warunki, zmienia swój stan i położenie na diagramie stanu. Do wersji UML 1.4 nosił nazwę diagramu stanów (state( statediagram)
Stan Stan jest etapem cyklu życia obiektu. Obiekt przebywający w danym stanie spełnia określony warunek. Stany są reprezentowane przez prostokąty z zaokrąglonymi narożnikami. Każdy stan ma swoją nazwę. Ze stanem mogą być związane pewne akcje, wykonywane w określonym momencie: entry: : jest akcją wykonywaną w momencie gdy obiekt przyjmuje dany stan; akcja ta jest wykonywana jeden raz i niepodzielnie do: : jest akcją wykonywaną nieprzerwanie w czasie, gdy obiekt przebywa w tym stanie exit: : oznacza (analogicznie do entry) ) moment opuszczenia stanu; podobnie, akcja taka jest wykonywana tylko raz. event: : reprezentuje akcję wykonywaną w momencie nadejścia zdarzenia określonego o typu. Wykonanie każdej z tych akcji może również generować zdarzenie.
Przejścia pomiędzy stanami Stany są powiązane ze sobą przejściami. Przejścia definiują warunki, jakie muszą zaistnieć, aby obiekt zmienił swój stan ze źródłowego na docelowy. Formalnie opis przejścia składa się z czterech elementów: wyzwalacza(ang. ang. trigger) zdarzenia, które może spowodować przejście i zmianę stanu dozoru(ang. guard condition) warunku, jaki musi być spełniony, aby przejście zostało wykonane; warunek ten jest ewaluowany w momencie pojawienia się wyzwalacza akcji(ang. action) operacji wykonywanej w momencie przejścia ze stanu do stanu; nawet jeżeli akcja przejścia jest złożona z wielu akcji elementarnych,jest ona wykonywana niepodzielnie zdarzenia(ang. ang. event) wysyłanego w momencie wykonania przejścia.
Pseudostany Stany pomocnicze (pseudostany( pseudostany): początkowy,, który reprezentuje obiekt w momencie jego utworzenia. końcowy,, który reprezentuje usunięcie obiektu z systemu. decyzja,, przedstawiająca wybór pomiędzy dwiema wartościami logicznymi pewnego p wyrażenia. złączenie/rozwidlenie powoduje synchronizację stanów (wszystkie dochodzące do niego przejścia muszą być wykonane) historia(literka H w okręgu wewnątrz stanu) zapewnia możliwość zapamiętania poprzedniego stanu obiektu i przywrócenie go.
Stany złożone Stany złożone posiadają wewnętrzną maszynę stanów. Wejście do stanu jest jej stanem początkowym, a wyjście końcowym.
Pełny diagram maszyny stanowej Diagram dla obiektów klasy Książka Dla przejrzystości nie uwzględnia akcji wewnątrz stanów
Diagram czynności Diagram czynnościprezentuje przepływ sterowania w systemie związany z wykonaniem pewnej funkcji. Przepływ łączy czynności wykonywane przez poszczególne obiekty i stany obiektów, w których znajdują się po wykonaniu czynności. W odróżnieniu od diagramu maszyny stanowej, diagram czynności może obejmować wiele obiektów na raz, zwykle umieszczanych w odpowiednich torach.
Diagram sekwencji Diagram sekwencjiprezentuje kolejność wywołań operacji, przepływ sterowania pomiędzy obiektami oraz szablon realizowanego algorytmu. Składa się z pionowych linii życia (ang.( lifelines) ) poszczególnych obiektów uczestniczących w interakcji oraz wymienianych między nimi n komunikatów (wywołań operacji). Czas jest reprezentowany w postaci pionowej osi diagramu. Białe prostokąty umieszczone na linii życia obiektu oznaczają, że obiekt jest zajęty wykonywaniem pewnej czynności. Fizycznie usunięcie obiektu można wprost oznaczyć jako znak X na linii życia
Diagram sekwencji kolejny przykład
Blok Często zachodzi konieczność wskazania specjalnej własności pewnej j części interakcji, np.. pętli. Taką grupę operacji obejmuje się prostokątem, w któregolewym górnym narożniku, w pięciokącie umieszcza się słowo kluczowe lub opis określający o znaczenie danego bloku (tzw. operator interakcji), np.: alt(od alternative) określający warunek wykonania bloku operacji, odpowiadający instrukcji if-else else; ; warunek umieszcza się wówczas wewnątrz bloku w nawiasach kwadratowych opt(od optional) reprezentujący instrukcję if(bez else) par(od parallel) nakazujący wykonać operacje równolegle critical oznaczający obszar krytyczny loop definiujący pętlę typu for (o określonej z góry liczbie iteracji) lub while(wykonywanej dopóki pewien warunek jest prawdziwy)
Diagram komunikacji Diagram komunikacjiskupia się na obiektach wchodzących w skład interakcji i wymienianymi przez nie komunikatach, natomiast w mniejszym stopniu niż diagram sekwencji wskazuje na aspekt czasowy. Komunikacje są przedstawiane za pomocą linii łączących obiekty, natomiast przesyłane między obiektami komunikaty i dane są umieszczane obok tych linii. Każdy komunikat jest opatrzony etykietą liczbową, wskazującą na kolejność wysłania. Etykieta ma postać liczb oddzielonych kropkami.
Diagram przeglądu interakcji Diagram przeglądu interakcjisłuży do przedstawiania ogólnego przepływu sterowania w interakcjach pomiędzy obiektami, korzystając z uproszczonej notacji diagramu czynności. Na jednym diagramie pokazany jest przepływ sterowania pomiędzy interakcjami pokazanymi w postaci innych diagramów, np.. sekwencji. Diagram ten może korzystać z większości elementów obecnych na diagramach czynności: punktu decyzyjnego, pętli, rozwidlenia i synchronizacji, itp.
Diagram uwarunkowań czasowych Diagram uwarunkowań czasowychprzeznaczony jest do prezentowania zależności związanych z czasem wykonywania operacji przez obiekt lub grupę obiektów. Linia czasu jest reprezentowana przez poziomą oś diagramu, natomiast oś pionowa przedstawia kolejne obiekty uczestniczące w interakcji i oraz ich zmieniające się stany wewnętrzne. Odległości pomiędzy momentami zmian stanów wyznaczają uwarunkowania czasowe. Diagram ten odgrywa duże znaczenie w modelowaniu systemów czasu rzeczywistego.
Budowa modelu behawioralnego (1) Identyfikacja scenariuszy Należy utworzyć zbiór scenariuszy, które opisują typowe interakcje systemu ze światem zewnętrznym. Punktem wyjścia jest tu specyfikacja przypadków użycia systemu, o ile została ona sprecyzowana w Specyfikacji Wymagań Systemowych. Jeśli nie została, należy je jawnie zidentyfikować i rozpatrzyć różne przypadki użycia systemu. Identyfikacja zdarzeń Dla danego scenariusza powstaje odpowiadający mu ślad zdarzeń przedstawiający drogi przepływu zdarzeń pomiędzy obiektami systemu. Budowa diagramów interakcji Dla każdego scenariusza budowane są diagramy sekwencji oraz (rzadziej) diagramy komunikacji, przeglądu interakcji oraz przebiegów czasowych.
Budowa modelu behawioralnego (2) Budowa diagramów maszyny stanowej Dla każdej klasy modelu obiektowegotworzony tworzony jest diagram opisujący jej zachowanie. Jeśli zachowanie obiektu klasy jest trywialne można pominąć jawną specyfikację diagramu. Identyfikacja wejść i wyjść Budowa diagramu czynności Definiowanie podstawowych (nie podlegających dalszej dekompozycji) transformacji danych opisywanych jako zależności funkcyjne między danymi wejściowymi i wyjściowymi. Tworzenie diagramu czynności, który uwidacznia obliczenia mające na celu wywiedzenie danych wyjściowych na podstawie odpowiednich wejść. Identyfikacja ograniczeń Identyfikacja zależności, których nie da się wyrazić w terminach relacji wejście wyjście wyjście i naniesienie ich na diagramy.
Rozszerzanie UML Mechanizm rozszerzania języka UML obejmuje trzy elementy: stereotypy(ang. stereotypes), zmieniające lub doprecyzowujące semantykę elementów modelu. Zapisywane są w danym elemencie w postaci <<nazwa stereotypu>> metki(ang. tagged values), dołączające do elementu dodatkowe właściwości w postaci par {klucz = wartość}.. Metki są dołączane do elementów w postaci notatek profile(ang. profiles), zawierające predefiniowane zestawy stereotypów i metek dla danej dziedziny zastosowań
Język OCL Język OCL(ang. Object Constraint Language) język formalnego wyrażania ograniczeń w UML wyraża dowolną regułę logiczną: warunki wstępne, końcowe, niezmienniki, wyniki metod etc. w postaci warunku zapisanego w nawiasach klamrowych nie może modyfikować modelu, jedynie go sprawdzać można go związać z dowolnym elementem modelu (klasą, operacją, atrybutem, asocjacją itp.) contextklient inv: self.nazwisko<> '' and self.wiek >= 18 self.uprawniony() context Konto::punkty: Integer init: if klient.wiek> > 60 then100 else0 endif
Uwagi końcowe Metodologia obiektowa także nie jest idealna Wiele celów łatwiej jest czasem osiągnąć stosując tradycyjne metody projektowania i programowania. Jednak ze względu na konieczność zapewnienia bezpiecznejpracy pracy przy tworzeniu dużych systemów informatycznych przez duże zespoły projektantów właśnie ta metodologia będzie zapewne dominująca w przyszłości. Krytycyzm UML: przeładowanie nie zawsze precyzyjny trudności w nauce (wynik powyższych dwóch wad) język do wszystkiego narzędzia CASE często implementują UML po swojemu brak narzędzi walidujących