Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona14/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   10   11   12   13   14   15   16   17   ...   113

Elementy czynnościowe.


Elementy czynnościowe (Behavioral things) to dynamiczna część modelu w UML. Są wyrażone czasownikami w czasie i w przestrzeni. Wyróżniają się dwa rodzaje takich elementów.

1. Interakcja (Interaction) to zachowanie polegające na wymianie komunikatów między objektami w pewnym otoczeniu, w pewnym celu. Za dopomogą interakcji można zdefiniować zarówno zachowanie zespołu obiektów, jak i pojedynczą operacje. Składa się z wielu innych bytów, w tym komunikatów, ciągów akcji (w odpowiedzi na komunikat) i połączeń (między obiektami).

Komunikat jest przedstawiony na diagramie jako strzałka, zawsze z nazwą operacji.



Rys.35


2 Maszyna stanowa (State machine) określa algorytm zachowania obiektu w formie ciągu stanów, jakie obiekt lub interakcja przyjmuje w odpowiedzi na zdarzenia zachodzące w czasie ich życia. Określa też ich odpowiedzi na te zdarzenia. Za jej pomocą może być zdefiniowane zachowanie pojedynczej klasy lub kooperacji. Maszyna stanowa składa się z innych elementów, takich jak stany, przejścia (między stanami), zdarzenia (które powodują przejścia) i czynności (odpowiedzi na zdarzenia). Stan jest przedstawiany na diagramie jako prostokąt z zaokrąglonymi rogami, zazwyczaj z nazwą i podstanami (jeśli istnieją) w środku (Rys.36)

Rys.36


Owe dwa elementy (interakcja i maszyna stanowa) to podstawowe składniki modelu zachowania zapisanego w UML. Zgodnie z semantyką są zwykle powiązane z różnymi elementami strukturalnymi – głównie z klasami, kooperacjami i obiektami.

Elementy Grupujące.


Elementy Grupujące Odgrywają w UML rolę organizacyjną. Są to bloki, na które dany model może być rozłożony. Podstawowym rodzajem tego typu elementu jest pakiet.

Pakiet służy do grupowania elementów. Może zawierać elementy strukturalne, czynnościowe, a nawet inne elementy grupujące. W odróżnieniu od komponentu (który istnieje w czasie wykonania programu) jest bytem pojęciowym, to znaczy istnieje jedynie w czasie tworzenia oprogramowania. Na diagramie jest przedstawiony jako skoroszyt z fiszką, zazwyczaj tylko z nazwą w środku, ale czasami też z zawartością (rys.37). Pakiety są podstawowymi elementami grupującymi, za pomocą których można usystematyzować model zapisany w UML.

Rys.37


Elementy komentujące.

Elementy komentujące odgrywają w UML rolę objaśniającą. Są to adnotacje, których można używać w celu opisania, uwypuklenia lub zaznaczenia dowolnych składników modelu. Podstawowym rodzajem tego typu elementu jest notatka. Jest to symbol umożliwiający skojarzenie dodatkowych ograniczeń i objaśnień z pojedynczym bytem lub grupą bytów. Na diagramie jest przedstawiana jako prostokąt z zagiętym rogiem, z komentarzem tekstowym lub graficznym w środku. (rys.38)



Rys.38


Notatka to podstawowy element komentujący, który może się pojawić w modelu zapisanym w UML. Zwykle używa się jej w celu wzbogacenia diagramu o ograniczenia i objaśnienia, które najłatwiej wyrazić za pomocą formalnego lub nieformalnego tekstu.

Związki w UML

W UML są uwzględnione cztery rodzaje związków:



  1. Zależność,

  2. Asocjacja (powiązanie),

  3. Uogólnienie,

  4. Realizacja.

Zależność (Dependency) to związek semantyczny (znaczeniowy) między dwoma elementami. Zmiany dokonane w definicji jednego z tych elementów(niezależnego) mogą mieć wpływ na znaczenie drugiego (zależnego). Na diagramie związek ten jest przedstawiany jako linia przerywana, zazwyczaj z grotem i nazwą (rys. 39)


Rys.39


Na tym rysunku jest pokazana klasa „Perpheral tester” która wykorzystuje interfejs „Peripheral”. To znaczy, że realizacji klasy„Perpheral tester” będą wykorzystali metody tego interfejsu przy odwołaniu do klas, które implementują interfejs„Peripheral”(na rys.40 te klasy nie są pokazane).

Asocjacja (association) ( lub inny termin –„powiązanie”) to związek strukturalny, który określa zbiór wiązań między obiektami. Szczególnym przypadkiem powiązania jest agregacja (składanie), które wyznacza więź między całością a częściami. Asocjacja jest przedstawiana na diagramie jako linia ciągłą, z nazwą asocjacji, z nazwami oddzielnych ról i oznaczeniami liczebności (rys.)

Rys.40


Uogólnienie (Generalization) to związek między dwoma bytami: ogólnym (przodek) i szczegółowym (potomek), czyli związek uogólnienie – uszczegółowienie. Obiekt bytu szczegółowego może być używany w zastępstwie obiektu bytu ogólnego. W takim związku potomek ma strukturę i zachowanie przodka. Uogólnienie jest przedstawiane na diagramie jako linia ciągła zakończona zamkniętym, niewypełnionym grotem wskazującym przodka związku (rys.41 )

Rys.41


Realizacja (Realization) to jest związek semantyczny (znaczeniowy) między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego. Takie związki występują najczęściej między interfejsami a klasami i komponentami oraz między przypadkami użycia a kooperacjami. Na diagramie realizacja jest przedstawiona jako kombinacja symboli uogólniania i zależności (rys.42)

Rys.42


Diagramy w UML

Diagram to jest schemat przedstawiający zbiór bytów.



Najczęściej jest grafem, w którym wierzchołkami są elementy (encji), a krawędziami związki. Różne diagramy pozwalają przedstawić system z różnych punktów widzenia. Każdy diagram to swego rodzaju rzut systemu. Z wyjątkiem najbardziej banalnych sytuacji daje jednak niepełny obraz bytów składających się na system. Ten samy byt może się pojawić na wszystkich diagramach, lub tylko na niektórych(co się zdarza najczęściej) lub na żadnym (przypadek wyjątkowy). Istnieją dziewięć rodzajów diagramów:

  1. Diagram klas,

  2. Diagram obiektów,

  3. Diagram przypadków użycia,

  4. Diagram przebiegu,

  5. Diagram kooperacji,

  6. Diagram stanów,

  7. Diagram czynności,

  8. Diagram komponentów,

  9. Diagram wdrożenia.

Przykład diagramów UML oraz ich związki jest pokazany na rys. 42a

Rys. 42a

Na diagramie klas (Class diagram) mogą się znaleźć klasy, interfejsy, kooperacje i związki między nimi. Jest to najczęściej spotykany diagram w modelach obiektowych. Odnosi się do statycznych aspektów perspektywy projektowej. Diagram klas uwzględniający klasy aktywne dotyczy aspektów perspektywy procesowej.

Na diagramie obiektów (Object diagram) przedstawia się obiekty i związki między nimi. Diagram ten wyobraża statyczny zrzut pewnych egzemplarzy elementów występujących na diagramie klas. Podobnie jak diagram klas, odnosi się do statycznych aspektów perspektywy projektowej lub procesowej.

Na diagramie przypadków użycia (Use case diagram) przedstawia się przypadki użycia, aktorów (to jest specyficzny rozdaj klas) i związki między nimi. Diagram ten odnosi się do statycznych aspektów perspektywy przypadków użycia. Przydaje się zwłaszcza do wyznaczenia i modelowania zachowania systemu.



Diagram przebiegu (Sequence diagram) i diagram kooperacji (Collaboration diagram) to są rodzaje diagramu interakcji (Interaction diagram), na którym przedstawia się interakcję jako zbiór obiektów i związków między nimi, w tym też komunikaty, jakie obiekty przekazują między sobą. Diagram przebiegu obrazuje kolejność przesyłania komunikatów w czasie. Na diagramie kooperacji kładzie się nacisk na organizację strukturalną obiektów wymieniających komunikaty. Oba te diagramy są izomorficzne, to znaczy można je przekształcać jeden w drugi.

Diagram stanów (Statechart diagram) przedstawia maszynę stanową składającą się ze stanów, przejść zdarzeń i czynności. Odnosi się do modelowania dynamicznych aspektów systemu. Jest szczególnie przydatny w modelowaniu zachowania interfejsów, klas i kooperacji. Przedstawia reakcje obiektów na ciągi zdarzeń i dlatego nadaje się do projektowania systemów interakcyjnych.

Diagram czynności (Activity diagram) to jest szczególny przypadek diagramu stanów, który obrazuje strumień kolejno wykonywanych czynności wewnątrz systemu. Odnosi się do modelowania dynamicznych aspektów systemu. Jest bardzo przydatny w modelowaniu funkcji systemu. Kładzie się na nim nacisk na przepływ sterowania między obiektami.

Diagram komponentów (Component diagram) obrazuje uporządkowanie komponentów i zależności między nimi. Odnosi się do statycznych aspektów perspektywy implementacyjnej. Ściśle wiąże się z diagramem klas, ponieważ zwykle każdemu komponentowi są przyporządkowane pewne klasy, interfejsy i kooperacje.

Diagram wdrożenia (Deployment diagram) obrazuje konfigurację poszczególnych węzłów działających w czasie wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera co najmniej jeden komponent.

Diagram przypadków użycia to jeden z pięciu rodzajów diagramów UML, które służą do modelowania dynamiki systemu (pozostałe cztery to diagramy czynności, diagramy stanów, diagramy przebiegu i diagramy kooperacji). Diagramy przypadków użycia są głównym narzędziem do modelowania zachowania systemu, podsystemu lub klasy. Każdy z nich przedstawia zbiór przypadków użycia i aktorów oraz związki między nimi.

Diagramy przypadków użycia służą do modelowania perspektywy przypad­ków użycia systemu, a w tym do opisywania otoczenia systemu, podsystemu lub klasy lub określania wymagań dotyczących zachowania tych bytów.

Diagramy przypadków użycia są szczególnie przydatne w obrazowaniu, specyfikowaniu i dokumentowaniu zachowania bytu. Dzięki nim systemy, podsystemy i klasy stają się bardziej przystępne i zrozumiałe. Diagramy te bowiem przedstawiają byt od zewnątrz.




1   ...   10   11   12   13   14   15   16   17   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna