Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona43/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   39   40   41   42   43   44   45   46   ...   113

Modelowanie aplikacji JSP w UML


Strona JSP zawiera kod JAVA, który jest implementowany do dokumentu HTML. Tegi HTML odwzorowują statyczną część dokumentu oraz tegi specjalne JSP odwzorowują go dynamiczną część. Wywołanie strony JSP na serwerze powoduje uruchomienie kodu części dynamicznej tej strony, oraz rezultat obrabiania tegów specjalnych razem z częścią statycznej musi być przesyłany do klienta. W technologii JSP Strony JSP są wykorzystywane dla realizacji funkcji prezentacyjnej, to znaczy dla odwzorowania rezultatów obrabiania informacji (stereotyp klasy VIEW w modelu MVC). Dla realizacji funkcji logiki biznesowej (stereotyp klasy CONTROLLER w modelu MVC) w technologii JSP mogą być wykorzystywane serwlety, komponenty JavaBean, komponenty J2EE.

Serwlety realizują się w kontenerach serwletów (WEB-kontenerach), które są w serwerach WWW. Aby realizować żądania klienta za pomocą serwletów, serwer WWW musi obsługiwać interfejs Javy Servlet API. Serwer WWW musi zatem posiadać wbudowaną obsługę serwletów. Serwlety reprezentują klasy Java, oraz rozszerzają jedną z dwóch klas realizacji: HttpServlet (serwlet HTTP) lub GenericServlet (serwlet uniwersalny) . Życiowy cykl serwleta(rys.113) klasy GenericServlet zawiera trzy główne metody:




Rys. 113

Metoda Service () to jest główna metoda serwleta, która realizuje logikę. W tej metodzie muszą być zrealizowane następne czynności:



  • Otrzymanie poleceń od klienta

  • Czytanie danych polecenia

  • Stworzenie i zapisywanie obiektów dla odpowiedzi.

Serwlety są sterowane przez polecenia od stron JSP lub innych serwletów. Do serwleta może być przesłany uzupełniony formularz zawierający różne pola. Kiedy serwer WWW (kontener serwleta) otrzyma polecenia do serwleta, on inkapsuluje otrzymane dani w obiekt ServletRequest (obiekt polecenia) i przesyła ten obiekt jako pierwszy parametr do metody service(). Po tym serwlet może realizować obrabianie obiektu polecenia za dopomogą następnych metod interfejsu ServletRequest:

  • getCharacterEncoding – otrzymać format kodowania w obiekcie polecenia

  • isSecure – czy był wykorzystywany bezpieczny kanał

  • getParameterNames – otrzymać listę parametrów polecenia

  • getRemoteAddr – otrzymać IP klienta

  • getParameter – otrzymać wartość parametru

Polecenie zawsze potrzebuje odpowiedzi. Odpowiedź może być realizowana przez obiekt ServletResponse, który jest przesyłany przez drugi parametr do metody service(). Obiekt ServletResponse zawiera metody dla generacji kodu na stronie JSP:

  • getOutputStream – deskryptor obiektu ServletOutputStream dla binarnych danych

  • getWriter - deskryptor obiektu PrintWriter dla znakowych danych – pozwoli generować tegi dla stron JSP

  • oraz inne.

Klasa HttpServlet rozszerza klasę GenericServlet oraz dlatego dziedziczy wszystkie metody GenericServlet. Klasa HttpServlet oprócz bazowych metod zawiera metody dla obrabiania poleceń HTTP (Rys 113a):

  • doGet() – obrabia polecenia HTTP GET

  • doPost() - obrabia polecenia HTTP Post

  • doPut() - obrabia polecenia HTTP Put

  • doDelete() - obrabia polecenia HTTP Delete

  • doOptions() - obrabia polecenia HTTP OPTIONS

  • doTrace() - obrabia polecenia HTTP Trace.


rys.113a


Jest docelowym stworzenie każdego serwleta realizować oddzielnie dla wyznaczonego zadania lub funkcji. Komplikowane zadania w ten sposób będą realizowane za dopomogą wielu serwletów. Sterowanie tymi serwletami może być realizowane przez wykorzystanie interfejsu RequestDispatcher. Ten interfejs zawiera następne metody:

  • Forward. Za dopomogą tej metody serwlet przekazuje polecenie innemu WEB komponentu (stronie WWW lub serwletu). Ta metoda pozwoli formować ciągi serwletów, każdy z których formuje swoje dane i przekazuje ich do kolejnego serwletu.

  • Include. Ta metoda pozwoli włączyć treść jednego WEB komponenta do innego serwleta.

Technologia wykorzystywania stron JSP jest bardzo podobna do serwletów. W rzeczywistości, skrypty JSP są kompilowane do postaci serwletów. Strona JSP jest plikiem, który w czasie pracy serwera WWW jest przekształcany w serwlet. Poważną różnicą pomiędzy skryptami JSP a serwletami jest sposób kodowania: strony JSP nie są czystym kodem Javy, koncentruje się na interfejsu użytkownika. Skrypty JSP nie wymagają kompilatora Javy.

Komponenty JavaBeans odróżniają się od standardów Enterprise JavaBeans. JavaBeans to są klasy Javy zawierające standardowy zestaw metod get() i set(). Są komponentami Javy wielokrotnego użytku zawierającymi własności, zdarzenia i metody (podobne do kontrolek ActiveX firmy Microsoft), które można łatwo wykorzystać w celu stworzenia (często wizualnych) aplikacji Javy. JavaBeans są znacznie mniejsze od Enterprise JavaBeans , mogą być wykorzystywane dla do budowy większych komponentów lub całych aplikacji. JavaBeans nie są komponentami przeznaczonymi do natychmiastowego stosowania, wymagają pewnej obróbki. Ponieważ komponenty te nie mogą funkcjonować samodzielnie, nie wymagają specjalnego środowiska uruchamiania ( jako komponenty Enterprise JavaBeans). Ponieważ JavaBeans są zwykłymi klasami Javy, nie potrzebują serwera aplikacji do instalacji, niszczenia czy łączenia z innymi usługami.



W technologii JSP strona klienta może być stworzona następnymi sposobami:

  • bibliotek plików HTML

  • Za dopomogą serwletów

  • Za dopomogą komponentów JavaBeans.

Modelowanie technologii JSP w UML zawiera trudności które polegają w tym, że każdy komponent JSP(skrypt) istnieje w dwóch postaci :

        1. W postaci strony WWW na stronie klienta;

        2. W postaci skryptu części kodu, który musi być realizowany na stronie serwera.

To nie pozwoli wykorzystać standardowe konstrukcji UML dla diagramów klas, systemów informatycznych w technologii JSP. Jednak UML zawiera mechanizmy rozszerzenia, które można wykorzystać dla modelowania WEB procesów. Dla modelowania technologii JSP w standardzie UML trzeba rozdzielić każdy komponent JSP na dwa klasy:

  1. Strona klienta <>. Ta klasa modeluje zachowanie elementu JSP na stronie klienta oraz wszystkie zewnętrzne go prezentacje. Strony klienta mogą mieć asocjacji z resursami na stronie klienta, np. z innymi stronami klienta, apletami, formularzy, komponentami JavaBeans itp.

  2. Strona serwera <>. Ta klasa odwzorowuje zachowanie komponentu JSP na stronie serwera. Strony serwera mogą mieć relacji z resursami na stronie serwera., np. zewnętrzne systemy, bazy danych, serwletami, z innymi stronami na stronie serwera.

Relacja pomiędzy stroną klienta a stroną serwera ma charakter „ jest pobudowany” , typ tej relacji jest pokazany na rys.114 .

Rys. 114


Strona klienta oprócz związków ze własną stroną serwera może mieć także relacje z następnymi obiektami:

  • Innymi stronami aplikacji. Relacje mogą być wejściowymi lub wyjściowymi ze stereotypem <>.

  • Apletami. Aplety modelują się w wyglądzie klas ze stereotypem <>. Relacji pomiędzy stroną klienta oraz apletem występują jako agregacji. Aplet to jest specjalna klasa Java, kontenerem której jest przeglądarka klienta. Aplet działa na stacji klienta oraz jest wywołany przez specjalne tegi przeglądarki.

  • Formularzami. Formularz pozwoli otrzymać dani klienta przez przeglądarkę. Formularz modeluje się w postaci klasy ze stereotypem <
    >. Pola formularza muszą być atrybutami tej klasy.

Przykład różnych relacji strony klienta jest pokazany na rys 115.

Rys.115


Związki elementu JSP na stronie serwera mogą występować w następnych kategoriach:

  1. Z innymi stronami serwera za dopomogą relacji <> oraz <>.

  2. Z Serwletami za dopomogą relacji <>. Serwlet to jest specjalna klasa Java, która jest analogiczna apletu, ale działa tylko na serwerze WWW. Serwlety są przeznaczone dla obrabiania poleceń protokołu HTTP od WWW-klienta. Serwlet nie ma swego interfejsu graficznego. Kontenerem dla serwletu jest serwer WWW.

  3. Z obiektami niejawnymi za dopomogą asocjacji. Do obiektów niejawnych mogą być odniesione obiekty następnych typów:

    • Request – identyfikuje polecenie, które inicjuje aktywację strony Serwera

    • Response – odpowiedź na polecenie

    • PageContext - dostęp do atrybutów strony

    • Session - obiekt sesji

    • Application – obiekt aplikacji

    • Out – obiekt dla zapisywania do W/W

    • Config – obiekt konfiguracji serwletu

    • Page – bezpośrednio sam element JSP

    • Exception – wątek, który formuje komunikat pro błędy.

  4. Z komponentami JavaBeans za dopomogą asocjacji ze stereotypem <>. Ta relacja odwzorowuje obecność tegu JSP:USEBEAN, który pozwoli wywołać JavaBeans ze stron JSP (patrz poprzedni rysunek)

  5. Z innymi klasami za dopomogą asocjacji UML

  6. Z bibliotekami tegów. Strony JSP mogą mieć tegi, które wyznaczają klasy do wywołania z bibliotek. Taki relacji modelują się jako zależności pomiędzy stroną JSP oraz klasy bibliotek tegów.

  7. Z komponentami J2EE. Strona serwera może wywołać metody komponentu J2EE. Taka relacja jest odwzorowana przez związek asocjacji pomiędzy stroną serwera oraz interfejsami komponentu J2EE.

Przykład diagramu klas z związkami stron serwera JSP jest pokazany na rys 116.

Rys 116


Rozpatrzymy model obiektowy systemu informatycznego banku rys. 117.

Rys. 117.

Scenariusz przypadku użycia „Wejście do systemu” zawiera następnie kroki:

Scenariusz główny:

1. Klient uruchomi stronę logowania

2. System wyświetli się formularz

3. Klient uzupełni się formularz

4.Klient przesyła się swoje dani do systemu

5. System sprawdzi się dani klienta

6. System uruchomi przypadek użycia „Lista operacji”

Scenariusz alternatywny

6.a



1   ...   39   40   41   42   43   44   45   46   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna