Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona26/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   22   23   24   25   26   27   28   29   ...   113
Po pierwsze, występują na nich linie życia obiektów – pionowe przerywane kreski reprezentujące czas istnienie obiektów. Większość obiektów z diagramu interakcji żyje przez czas trwania interakcji. Znajdują się one w górnej części diagramu, a ich linie życia biegną od góry do dołu. Podczas interakcji mogą powstawać nowe obiekty. Ich linie życia rozpoczynają się w chwili odebrania przez nie komunikatu stereotypowanego jako <>. Pewne obiekty są niszczone. Ich linie życia kończą się w chwili odebrania przez nie komunikatu stereotypowanego jako <> (ich śmierć jest dodatkowo oznakowana wielką literą X).

Po drugie, na diagramach przebiegu jest uwzględniony ośrodek sterowania – podłużny , cienki prostokąt reprezentujący okres wykonywania przez obiekt jakiejś akcji osobiście albo z użyciem procedury podrzędnej. Górna krawędź tego prostokąta znajduje się na tej samej wysokości co początek akcji, a dolna – na wysokości zakończenia akcji (może być dodatkowo oznaczona komunikatem przekazania).

Na rys.68 jest pokazany diagram przebiegu. Obiekt „Client” tworzy obiekt „Transaction”, który żyje w ciągu wprowadzenia zmian do bazy danych przez obiekt „ODBCProxy”. Transakcja zawiera dwa procesy modyfikacji danych. Te procesy są realizowane przez obiekt „ODBCProxy”. Po wprowadzeniu zmian w bazie danych obiekt „Transaction” formuje komunikat „Commited”. Po zakończeniu transakcji obiekt „Transaction” jest usunięty przez komunikat „Destroy”.



rys.68


Przy projektowaniu diagramów przebiegu może być wykorzystany następny sposób, zawierający dwa etapy:

Etap 1. Na diagramu trzeba odwzorować informację górnego poziomu, która jest potrzebna końcowym użytkownikom systemu oraz nie zawiera szczegółów realizacji. Komunikaty w tym diagramu nie są skojarzone z operacjami, oraz obiekty także nie są skojarzone z konkretnymi klasami. Diagramy na tym etapie są potrzebne analitykom, użytkownikom oraz osobom, które są specjalistami w procesach biznesowych. Tak diagram, który opisuje kooperację wpisywania danych użytkownika do bazy danych może mieć ewentualne następny wygląd (rys. 68a).

Rys. 68a


Etap 2. Diagram, otrzymany na poprzednim etapie jest zadaniem do projektowania więcej szczególnego diagramu. Analizując pierwszy diagram, użytkownicy muszą go uzgodnić. Diagram po uzgodnieniu trzeba rozszerzyć szczegółami konkretnych klas programowych. W tym celu trzeba stworzyć obiekt (lub obiekty) które odpowiadają za konsekwentność zdarzeń scenariusza głównego. Ten obiekt-menedżer jest pokazany na rys. 68b. Każdy przypadek użycia może mieć wiele diagramów przebiegu, oraz w tych diagramach musi być ten samy obiekt menedżer. Zadaniem tego obiektu jest kontrola wszystkich przepływów informacji w wyznaczonym przypadku użycia.

Rys. 68b


Obiekt-menedżer jest obiektem dla sterowania, to znaczy on nie realizuje procesów biznesowych. Obiekt-menedżer formuje komunikaty do innych obiektów oraz jest odpowiedzialnym za czynności tych obiektów. Zaletą wykorzystania obiektu-menedżera jest oddzielenie logiki biznesowej od logiki wyznaczającą konsekwencję zdarzeń w systemu. Kiedy będzie została konieczność zmiany istniejącej konsekwencji zdarzeń, to zmiany te potrzebują modyfikacji tylko jednego obiektu-menedżera.

Na diagramu mogą być stworzone inne obiekty z różnymi odpowiedzialności , np. : ubezpieczenie, diagnostyka, związek z bazą danych.



Przy zachowaniu informacji w bazie danych lub przy otrzymaniu informacji z bazy można wykorzystać dwa następne rozwiązania:

  1. Logika biznesowa jest połączona z logiką bazy danych. Ten przypadek jest pokazany na rys. 68c. Oprócz zachowania metod biznesowych (np. zatrudnienie pracownika) ten obiekt realizuje aktualizację informacji w bazie danych. Obiekt „John Doe” może wiedzieć wszystko o bazie danych i dla tego zachowuje siebie sam. W tym przypadku, przy zmianach bazy danych trzeba dokonać zmian w każdym obiekcie.

  2. Logika biznesowa jest oddzielona od logiki bazy danych. Ten przypadek jest pokazany na rys. 68d. W tym przypadku trzeba stworzyć obiekt – menedżer transakcji, którego zadaniem jest komunikacja z bazą danych.




Rys. 68c

Rys.68d



1   ...   22   23   24   25   26   27   28   29   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna