Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona46/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   42   43   44   45   46   47   48   49   ...   113

Komponenty sesyjne


Komponenty sesyjne są związane z logiką aplikacji, z obiektami procesu biznesowego, implementują logikę biznesową, oraz różne algorytmy i czynności dla klienta. Przykładowo, komponent sesyjny może notować ceny, realizować zamówienie, dokonywać transakcji bankowych, operacji z koszykiem klienta w sklepie, operować na bazie danych, wykonywać skomplikowane obliczenia itp. Komponenty sesyjne mogą być dwóch podtypów:

Stan sesji to są dani, które odwzorowują połączenie oddzielnego (konwersację) klienta z obiektem sesji. Stanowe komponenty zapamiętują swój stan reprezentujący sesję z oddzielnym klientem. Te komponenty pozwalają klientom przerywać sesję oraz potem przedłużać ją z tym samym obiektem sesji. Decyzję pro przerywanie sesji oraz pro zapamiętywanie stany komponentu musi być realizowana tylko przez kontener - Klient nie może bezpośrednio oddziaływać na zachowanie komponentu. Bezstanowe komponenty nie mogą przechowywać swoich stanów. Bezstanowy komponent sesyjny utrzymuje konwersację obejmującą tylko pojedyncze wywołanie metody. Po zakończeniu każdego wywołania metody kontener może wybrać, czy usuwać bezstanowy komponent sesyjny z pamięci czy tworzyć go ponownie. Przykład diagramu klas bezstanowego komponentu sesyjnego jest pokazany na rys. 127. Ten komponent jest przeznaczony dla realizacji procesów biznesowych przypadku użycia „Koszyk” w sklepie Internetowym.

Rys.127


Na tym rys. są pokazane klasy oraz interfejsy:

      • koszykBean (stereotyp „EJBSession”) - klasa realizacji komponentu. Klasa realizacji zawiera kody realizacji wszystkich metod, zdefiniowanych oraz wywołanych w domowym, zdalnym i innych interfejsach, oraz metod, które są potrzebne dla realizacji życiowego cyklu komponentu. Metody życiowego cyklu są wywołane przez kontener.

      • koszyk (stereotyp „EJBRemote”) – interfejs zdalny. To jest główny interfejs reprezentujący komponent dla aplikacji użytkownika. Klient zawsze komunikuje z tym interfejsem dla wywołania metod biznesowych.

      • koszykHome (stereotyp „EJBRemoteHome”) – interfejs domowy. Przez ten interfejs realizuje się wygenerowanie obiektów EJB w kontenerze.

      • koszykLocal (stereotyp „EJBLocal”) – interfejs lokalny, jest bardziej wydajną wersją zdalnego interfejsu. Ten interfejs trzeba używać w przypadkach, gdy komponent EJB działa w tym samym procesie. Wywołanie metod biznesowych nie będzie przechodziło przez namiastki, szkielety, wywołania sieciowe.

      • koszykLocalHome (stereotyp „EJBLocalHome”) – lokalny interfejs domowy, jest bardziej wydajną wersją interfejsu domowego. Ten interfejs jest interfejsem domowym dla interfejsu koszykLocal.

Klasa realizacji rys.127 zawiera metody:

  • ejbCreate(). Dla każdej metody typu create() w interfejsie domowym musi być odpowiednia metoda ejbCreate() w klasie realizacji. Np. dla metody typu create() z nazwą create2() w interfejsie domowym musi być odpowiednia metoda ejbCreate2() w klasie realizacji. Uruchomienie metod ejbCreate() realizuje się przez kontener.

  • ejbRemove(). Ta metoda powoduje usunięcie obiektu EJB oraz może być wywołana przez metodę remove() interfejsów lub przez kontener.

  • setSessionContext(). Kontener tworzy obiekt kontekstu dla inkapsulacji danych w sesji komponentu. Obiekt kontekstu to jest brama do kontenera, zawiera dani o aktualnym stanie kontenera, metody dla obrabiania tej informacji oraz metody dla sterowania transakcjami. Obiekt EJB może wykorzystać te metody oraz informację. Metoda setSessionContext() udostępni obiekt kontekstu dla EJB.

  • Metody biznesowe – addItem(), removeAll(), showCartContens(), checkout(), confirmCheckout(), removeItem(). Te metody potrzebne dla realizacji przypadku użycia.

  • ejbPassivate(), ejbActivate(). Te metody są potrzebne tylko dla stanowych komponentów sesyjnych.

Znak tego komponentu na diagramu komponentów jest pokazany na rys. 128.

Rys.128


Cyklem życia komponentów steruje kontener. Diagram stanów bezstanowego komponentu sesyjnego jest pokazany na rys. 129.

Ten diagram zawiera dwa stany:



  1. Nie istnieje egzemplarz komponentu

  2. Gotowy.

Wszystkie metody, które powodują przejścia pomiędzy stanami nie są inicjowane przez klienta. Kontener samodzielnie decyduje pro wywołanie tych metod.

Przejście od stanu 1 do stanu 2 może być powodowane wywołaniem metody create(...) interfejsu domowego. Kontener w tym przypadku tworzy obiekt EJB wywołując następne metody klasy realizacji:



  1. Class.newinstance() – to jest konstruktor klasy EJB.

  2. setSessionContext() – to jest kontekst w obiekcie EJB.

  3. ejbCreate(...) – to jest odpowiednia metody create(...) w klasie realizacji.

Diagram przebiegu, który realizuje przypadek użycia „koszyk” przez komponent sesyjny „Koszyk” jest pokazany na rys. 130.

Rys. 129


Rys. 130






1   ...   42   43   44   45   46   47   48   49   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna