Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona41/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   37   38   39   40   41   42   43   44   ...   113

Wzorzec High Cohesion


Decyzja: Wyznaczyć odpowiedzialność w sposób pozwalający otrzymać wysoki stopień zaczepienia wewnątrz każdego obiektu.

Problem. W jaki sposób można sterować poziomem komplikacji klas?

Stopień zaczepienia to jest miara powiązania zobowiązań wewnątrz obiektów klasy. Obiekt klasy ma wysoki stopień zaczepienia w przypadkach, kiedy wszystkie go zobowiązania są skojarzone pomiędzy sobą . Obiekty z niskim stopniem zaczepienia realizują zachowania nie skojarzone pomiędzy sobą. Wadami niskiego stopnia zaczepienia są:



  • Trudność porozumienia zachowań klasy przez projektanta.

  • Komplikacji przy powtórnym wykorzystaniu kodu klasy.

  • Trudności na etapie konserwacji

  • Słaba niezawodność , częste zmiany.

Przykład. Trzeba stworzyć egzemplarz obiektu Payment oraz powiązać go z obiektem realizującym sprzedaż – Sale.

Realizacja z niskim stopniem zaczepienia ( rys 5). W tym przykładzie klasa Register realizuje następne funkcje:

  1. Tworzy się egzemplarz P klasy Payment - operacja createPayment() w klasie Payment.

  2. Tworzy komunikat do klasy Sale dla przekazania obiektu P- operacja addPayment (P) w klasie Sale.

Realizacja z wysokim stopniem zaczepienia ( rys 6).

W tym przykładzie klasa Register realizuje następną funkcję:



  1. Tworzy się egzemplarz klasy Sale.

Oprócz tego te rozwiązanie ma mały stopień powiązania pomiędzy klasami.

Wzorzec High Cohesion ma analogię w świecie rzeczywistym. Pracownik w firmie działa nie efektywne, kiedy pełni dużo różnych funkcji, którzy mogą być rozproszone wśród innych pracowników.

Z pojęciem zaczepienie jest skojarzona modułowość oprogramowania. Moduł programowy zawiera metody i klasy z dużym stopniem zaczepienia.

Powiązanie oraz zaczepienie są skojarzony pomiędzy sobą. Złe powiązanie powoduje słabe zaczepienie.


Wzorzec Controller


Decyzja: Delegowanie zobowiązań dla obrabiania zdarzeń systemowych do klasy, która może pełnić jeden s następnych warunków:

  • Klasa prezentuje cały system, lub podsystem (kontroler zewnętrzny)

  • Klasa prezentuje scenariusz pewnego przypadku Użycia który może mieć stereotypy Handler, Coordinator lub Session.

W drugim przypadku dla wszystkich zdarzeń systemowych w ramach tego samego scenariusza musi być wykorzystana ta sama klasa-kontroler. Klasy realizujące interfejsy z użytkownikom nie mogą pełnić funkcje kontrolerów. Klasy interfejsów otrzymują komunikaty od użytkowników i przekazują ją do kontrolerów.

Problem. Jaka klasa musi odpowiadać za obrabianie zdarzeń systemowych?

Zdarzenie systemowe to jest zdarzenie na wyższym poziomie które jest inicjowane przez aktora. Zdarzenia systemowe są skojarzone z operacjami systemowymi, zwłaszcza z operacjami, którzy realizują się przez system( w odpowiedź na zdarzenia systemowe). Np. , przy kliknięciu przycisku „wypłata” zostanie wygenerowane zdarzenie systemowe pro zakończenie transakcji handlowej.

Kontroler to jest obiekt odpowiadający za realizację operacji systemowych. Kontroler nie może być jednocześnie interfejsem użytkownika.

Przykład. Zdarzeniami – operacjami systemowymi są:


  • endSale()

  • enterItem()

  • makeNewSale()

  • makePayment()

Na rys. 1 dla realizacji funkcji kontrolera została wybrana klasa Register, która prezentuje cały system.

W przypadkach, kiedy kontroler jest stworzony dla scenariusza przypadku Użycia każdy przypadek użycia musi mieć swój kontroler. Kontrolery przypadków użycia należy wykorzystać kiedy kontroler prezentujący cały system ma mały stopień zaczepienia oraz jest obciążony odpowiedzialności.



Wzorce architektury aplikacji WWW


Każda aplikacja WWW może zawierać następne komponenty architektury :

  • HTML/XML browser na komputerach klienta

  • Serwer WWW

  • Serwer aplikacji

  • Protokół HTTP (lub inny)

  • Strony na poziomie serwera WWW

  • Strony na poziomie browsera.

Wzorce projektowe aplikacji WWW odwzorowują strukturę jednostek programowych realizujących zadania aplikacji. Wzorzec zawiera zbiór podsystemów z wyznaczeniem ich zobowiązań. Istnieją trzy ogólnych wzorce WWW:

    1. Wzorzec na bazie „chudego klienta” (Thin Web Client). Klient wykorzysta przeglądarkę z formularzami do uzupełniania. Wszystkie operacji z logiką biznesową realizują się na serwerze. Komunikacja z klientem realizuje się przez protokół HTML.

    2. Wzorzec na bazie „tłustego klienta” (Thick Web Client). Klient może wykorzystać dynamiczny HTML, aplety Java, kontrolki ActiveX. Komunikacja z klientem realizuje się przez protokół HTML.

    3. Wzorzec na bazie mechanizmów dostarczania WWW (Web Delivery). Dla komunikacji pomiędzy klientem a serwerem oprócz protokołu HTTP mogą wykorzystać się IOOP, DCOM, CORBA oraz inne które są wykorzystane dla połączenia z obiektami rozproszonymi. Browser jest wykorzystany jako kontener systemu rozproszonych obiektów.

Wzorzec architektury Thin Web Client.


Główne komponenty architektury wzorca architektury Thin Web Client są pokazane w „Pattern_WEB”. Na tym schemacie są pokazane:

Browser - Przeglądarka (Client browser) - zawiera formularzy HTML, wykorzysta się jako interfejs z klientem. Zawiera możliwości przechowywania i wywołania danych cookie.

Serwer WWW – to jest punkt główny dla dostępu wszystkich browserów do aplikacji WWW. W zależności od żądania serwer WWW może inicjować odpowiednie procesy. Rezultatem jest strona HTML.

Protokół HTTP - to jest element architektury opisujący ustalenia związku pomiędzy klientem a serwerem. Protokół HTTP nie popiera pamięć łącza. Za każdym razem przy wymianie informacji pomiędzy klientem a serwerem trzeba ustalić nowe łącze. Protokół HTTP może mieć rozszerzenie w postaci protokołu SSL (Secure Cockets Layer). W takim przypadku dani są zaszyfrowane.

Strony HTML (HTML page) – to są strony WWW z interfejsem użytkownika, którzy nie potrzebują procesów obrabiania skryptów, bo nie zawierają żadnych kodów oprócz znaczników HTML.

Strony serwerowe (Server page) - to są strony WWW, którzy muszą wywołać procesy do obrabiania swoich scenariuszy(ASP,JSP). Te strony mają dostęp do wszystkich resursów logiki biznesowej, baz danych oraz do systemów zewnętrznych.

Serwer aplikacji - to jest główne narzędzie do realizacji procesów biznesowych. Serwer aplikacji może być realizowany w tej samej przestrzeni procesu, że serwer WWW. Głównym zadaniem serwera aplikacji jest realizacja kodów scenariuszy procesów biznesowych. Serwer aplikacji został wydzielony do oddzielnego elementu architektury.

Główne zasady zachowania wzorca Thin Web Client :



  1. Logika biznesowa aplikacji jest uruchomiana tylko jako odpowiedź na polecenie odpowiedniej strony WWW przez klienta.

  2. Klient współdziała z systemem przez protokół HTTP dla otrzymania stron z serwera WWW. Kiedy polecana strona jest plikiem HTML, to serwer WWW bezpośrednio przesyła je do klienta.

  3. Kiedy strona serwera zawiera scenariusz, to ten scenariusz musi być opracowany przez serwer aplikacji. Serwer aplikacji interpretuje scenariusz i w razie potrzeby zwraca się do resursów serwera , np. do Serwera baz danych, Serwera poczty elektronicznej, innych systemów itp.

  4. Dla uruchomienia logiki biznesowej musi być ustalone łącze pomiędzy klientem a serwerem. Po obrabianiu scenariusza z logiką biznesową łącze pomiędzy klientem a serwerem będzie rozerwane.

Wzorzec architektury Thick Web Client


W tym wzorcu dla realizacji logiki biznesowej w części klienskiej aplikacji wykorzystają się komponenty JavaBean, ActiveX lub aplety Java. Mogą być także wykorzystane scenatiusze klienckie.

Główne zasady zachowania wzorca Thick Web Client :



  1. Logika biznesowa aplikacji jest uruchomiana tylko jako odpowiedź na polecenie odpowiedniej strony WWW przez klienta oraz część logiki biznesowej może być zrealizowane na poziomie klienta.

  2. Strona klienta może zawierać scenariusze, komponenty ActiveX, aplety Java. Scenariusze mogą być wykorzystane dla sprawdzenia danych. Scenariusze zawierają zdarzenia, którzy są częścią modelu obiektowego DOM (Document Object Model).

  3. Interfejs DOM pozwoli scenariuszom klienckim mieć dostęp do dokumentów XML.


Rozszerzenie języka UML dla modelowania aplikacji WWW


Rozszerzenie języka UML musi wykorzystać mechanizmy którzy pozwalają stworzyć nowe typy „elementów budowlanych” w modelu. Rozszerzenie zawiera następne właściwości tych elementów:

  • Stereotypy (stereotype)

  • Wartości tegowane (tagged value)

  • Ograniczenia (constraint).

Stereotyp to jest rozszerzenia słownika UML. Stereotyp pozwala skojarzyć z nowym elementem modelu nowy sens semantyczny. Stereotyp może być zastosowany do dowolnego elementu. Na diagramie stereotyp jest odwzorowany w znacznikach <> klasy.

Wartość tegowana to jest rozszerzenie właściwości elementu modelu. Większość elementów modelu już mają skojarzone z nimi właściwości. Na przykład wszystkie klasy mają nazwiska, atrybuty itp. Wartość tegowana pozwoli ustalić nową właściwość, która będzie skojarzona z każdym elementem. Na diagramie wartość tegowana jest odwzorowana za dopomogą wierszy w nawiasach().

Ograniczenia to są rozszerzenia semantyki języka. To są reguły definiujące w jaki sposób elementy modelu mogą współpracować z innymi elementami. Ograniczenia wyznaczają warunki, którzy są niezbędne dla stworzenia całego modelu. Dani ograniczenia na diagramie mogą być odwzorowane za dopomogą wierszy w nawiasach{}.

Stereotypy do modelowania klas:


1. Strona serwera.

Stereotyp

Server Page

Klas metamodeli

Klasa

Opis

To jest model strony WWW która zawiera skrypty scenariuszy. Scenariusze współdziałają z bazami danych, logiką biznesową, systemy zewnętrzne oraz innymi resursami serwera. Operacji tej klasy - to są funkcji scenariusza. Atrybuty – to są zmienne to są zmienne widoczne w zasięgu całej strony.

Ograniczenia

Strony serwerowe mogą mieć związki asocjacyjne tylko z obiektami serwera

Wartości tegowane

Zasób dla stworzenia scenariusza (JavaScript, Vbscript, Perl itd)

2.Strona klienta



Stereotyp

Client Page

Klas metamodeli

Klasa

Opis

Egzemplarzem strony klienckiej jest strona WWW w formacie HTML, elementy interfejsu oraz część logiki biznesowej która jest uruchomiana w scenariuszy na poziomie klienta. Te scenariusze są interpretowane przez przeglądarkę.

Operacji tej klasy (funkcji) - to są funkcji scenariusza którzy zostali zdefiniowane w deskryptorach strony. Atrybuty – to są zmienne którzy widoczne oraz dostępne każdej funkcji strony. Strony klienckie mogą mieć asocjacji z innymi stronami klienta oraz serwera.



Ograniczenia

-

Wartości tegowane

TitleTag – Tytuł strony, który odwzorowuje przeglądarka.

BaseTag - Adres bazowy URL

BodyTag – Zbiór atrybutów dla deskryptora , którzy wyznaczają odpowiednie właściwości, np. tekst, kolor itp.

3.Formularz



Stereotyp

Form

Klas metamodeli

Klasa

Opis

Ta klasa jest zbiorem pól typu Input oraz jest częścią strony klienckiej. Ta klasa może być przekształcona bezpośrednio w deskryptor HTML
. Atrybuty tej klasy to są pola tekstowe, typu Input, Password, Radio i inne. Klasa nie zawiera żadnych operacji. Wszystkie operacji na formularzu to są funkcji strony klienckiej, zawierającą ten formularz.

Ograniczenia

-

Wartości tegowane

Metoda Get lub POST

4.Układ ramek



Stereotyp

Frameset

Klas metamodeli

Klasa

Opis

Ta klasa jest układ ramek (frameset) który może być kontenerem kilka stron WWW. Zawartością każdej ramki może być strona WWW lub inna ramka. Klasa ze stereotypem <> musi być przekształcona w układ ramek strony WWW oraz znacznik HTML ...

Ograniczenia

-

Wartości tegowane

Rows, Cols - to są wartości właściwości „rows” oraz „cols” znacznika HTML

5.Ramka


Stereotyp

Target

Klas metamodeli

Klasa

Opis

Ta klasa jest oddzielnej ramką docelowej (target) w której mogą być odwzorowane strony WWW.

Ograniczenia

-

Wartości tegowane

-

Stereotypy modelowania asocjacji

1.Link


Stereotyp

Links

Klas metamodeli

Asocjacja

Opis

To jest link ze strony klienckiej (Client Page) do innej strony klientckiej lub do strony serwerowej (Server Page). Asocjacja <> przekształcona jest do znacznika HTML

Ograniczenia

-

Wartości tegowane

Parameters - Lista parametrów, którzy są przekazane razem z poleceniem do strony

2.Targeted Link

Stereotyp

Targeted links

Klas metamodeli

Asocjacja

Opis

To jest link do innej strony klienckiej która musi być odwzorowana w innej ramce. Asocjacja <> przekształcona jest do atrybutu „target” znacznika HTML .

Ograniczenia

-

Wartości tegowane

Parameters - Lista parametrów, którzy są przekazane razem z poleceniem do strony

Target - imię ramki docelowej gdzie będzie odwzorowana strona.



3.Frame Content

Stereotyp

Frame Content

Klas metamodeli

Asocjacja

Opis

To jest agregacja innych ramek lub stron klienckich

Ograniczenia

-

Wartości tegowane

Row

Col


4.Submit



Stereotyp

Submit

Klas metamodeli

Asocjacja

Opis

Asocjacja Submit łączy się klasy oraz . Formularzy przekazują wartości swoich pól dla obrabiania na poziomie serwera. Serwer WWW obrabia stronę , która otrzyma dani z formularza.

Ograniczenia

-

Wartości tegowane

Parameters – Lista parametrów , którzy muszą być przekazane do strony.

5.Buid


Stereotyp

Build

Klas metamodeli

Asocjacja

Opis

to jest typ asocjacji pomiędzy stronami oraz . Strony istnieją tylko na serwerze oraz są przeznaczone dla stworzenia stron klienta. Ta asocjacja wyznaczy, jaka strona ma zobowiązanie stworzyć odpowiednią stronę . Ta asociacja jest skierowana od do , strona kliencka nie wie , przez którą stronę została stworzona.

Ograniczenia

-

Wartości tegowane

-

6.Redirect

Stereotyp

Redirect

Klas metamodeli

Asocjacja

Opis

To jest asocjacja która wyznaczy przejście pomiędzy stronami lub < Frameset>

Ograniczenia

-

Wartości tegowane

-

7.Protokół IIOP (Internet Inter –ORB Protocol)

Stereotyp

IIOP

Klas metamodeli

Asocjacja

Opis

Asocjacja odwzorowuje mechanizm współpracy pomiędzy obiektami klienta a serwera przez protokół IIOP. Ta asocjacja łączy się komponenty JavaBeans z EJB na serwerze.

Ograniczenia

-

Wartości tegowane

-

8.Mechanizm RMI



Stereotyp

RMI

Klas metamodeli

Asocjacja

Opis

To jest mechanizm przekazania parametrów pomiędzy apletami Java i komponentami Java Beans do innych komponentów Java Beans na innych komputerach.

Ograniczenia

-

Wartości tegowane

-





1   ...   37   38   39   40   41   42   43   44   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna