Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy
aplikacji zgodnych z J2EE
Jacek Panachida
promotor: dr Dariusz Król
Przypomnienie
●
●
●
Celem pracy jest porównanie wybranych
szkieletów programistycznych o otwartym
kodzie źródłowym
Do analizy zostały wybrane Spring MVC oraz
JavaServer Faces
Analiza obejmuje teoretyczne aspekty ich
funkcjonowania oraz badania empiryczne
przeprowadzone w formie eksperymentów
Stan zaawansowania – rozdziały (1)
1.Wprowadzenie
2.Wstęp
1. Ewolucja szkieletów programistycznych
1. Historia i rozwój
2. Wzorce projektowe
3. Rozwiązania alternatywne
2. Architektura
1. Model 1 – strona JSP
2. Model 2 – centralny kontroler
3. Model komponentowy
3. Zadania szkieletów programistycznych
Stan zaawansowania – rozdziały (2)
2. Nowoczesne środowisko pracy programisty
1. Tworzenie aplikacji
1. Subversion
2. Maven
3. Eclipse
4. Hibernate
5. Spring Framework
2. Przeprowadzanie testów
1. Spring Mock
2. EasyMock
3. JUnit 4
4. Selenium
Stan zaawansowania – rozdziały (3)
3. Przegląd internetowych szkieletów
programistycznych
1. Struts 2
1. Architektura
2. Znaczniki
3. Interceptory
4. Implementacja wzorca MVC
2. Spring MVC
1. Obiekt nadzorujący
2. Znaczniki
3. Zasada konwencji
Stan zaawansowania – rozdziały (4)
3. Tapestry 5
1. Zasady
2. Moduły
4. JavaServer Faces
1. Specyfikacja
2. Architektura
3. Części składowe
4. Implementacja wzorca MVC
4. Porównanie Spring MVC z JavaServer Faces
Stan zaawansowania – rozdziały (5)
1. Architektura
1. Spring MVC
2. JavaServer Faces
3. Podsumowanie
2. Model programistyczny
1. Spring MVC
2. JavaServer Faces
3. Podsumowanie
3. Cykl życia żądania
1. Spring MVC
2. JavaServer Faces
3. Podsumowanie
Stan zaawansowania – rozdziały (6)
4. Walidacja i konwersja typów
1. Spring MVC
2. JavaServer Faces
3. Podsumowanie
2. Internacjonalizacja
1. Spring MVC
2. JavaServer Faces
3. Podsumowanie
5. Aplikacja Petclinic
1. Opis aplikacji
1. Wykorzystane technologie
2. Encje bazy danych
Stan zaawansowania – rozdziały (7)
2. Moduły aplikacji
1. Petclinic-data
2. Petclinic-core
3. Petclinic-web
3. Zaimplementowana funkcjonalność
6. Eksperymenty z wykorzystaniem aplikacji
Petclinic
1. Przebieg badania
1. Fazy implementacji aplikacji
2. Petclinic Badanie wydajności
3. Pomiar metryk kodu
4. Badanie łatwości wprowadzania zmian
Stan zaawansowania – rozdziały (8)
5. Badanie dostępności komponentów Triniad
2. Analiza wyników
1. Wydajność
2. Metryki kodu
3. Dostępność komponentów Trinidad
4. Łatwość wprowadzania zmian
7. Podsumowanie
Bibliografia
100%
Eksperymenty
●
●
Eksperymenty zostały przeprowadzone na
dwóch zaimplementowanych aplikacjach
–
opartej o Spring MVC
–
opartej o JavaServer Faces
Pomiary metryk kodu dotyczyły trzech faz
implementacji aplikacji
–
aplikacji umożliwiającej przeglądanie danych
–
aplikacji umożliwiającej zarządzanie danymi
–
aplikacji po lokalizacji
Przeprowadzane eksperymenty
●
Badania wydajności
●
Pomiar metryk kodu
●
●
Pomiar łatwości wprowadzania zmian (ang.
changeability)
Badanie dostępności (ang. accessibility)
komponentów Trinidad
Badania wydajnościowe (1)
●
●
Do badania wydajności posłużyło narzędzie
JMeter
Eksperymenty badające wydajność aplikacji
symulowały pracę trzech grup osób:
–
przeglądających dane
–
modyfikujących stan aplikacji
–
grupy mieszanej w proporcjach 4/1 przeglądających
i modyfikujących dane
Badania wydajnościowe (2)
●
Dla każdych z badanych grup zostały
zmierzone następujące wartości:
–
maksymalna liczba użytkowników mogących
korzystać z systemu, przy zapewnieniu jego
stabilnej pracy
–
maksymalna liczba użytkowników mogących naraz
korzystać z aplikacji przy zapewnieniu stabilnej
pracy systemu (próg czasu reakcji – 3 sekundy)
Metryki kodu (1)
●
Metryki proste
–
liczba dzieci (całkowita liczba bezpośrednich
podklas interfejsów danej klasy)
–
głębokość drzewa dziedziczenia
–
liczba pól, metod, przeciążonych metod
–
liczba klas i interfejsów
–
liczba linii kodu
Metryki kodu (2)
●
Metryki złożone
–
indeks specjalizacji
–
skojarzenia dośrodkowe
–
skojarzenia odśrodkowe
–
abstrakcyjność
–
niestabilność
–
znormalizowana odległość kategorii od ideału
Łatwość wprowadzania zmian
●
●
●
Metryka zdefiniowana w normie ISO 9126
Pomiaru dokonano na każdym z trzech etapów
budowy aplikacji
W pomiarze uwzględniono:
–
liczba nowo dodanych plików
–
uzupełnienia (liczba plików zmodyfikowanych bez
zmiany dotychczasowej zawartości)
–
modyfikacje (liczba plików zmodyfikowanych
których zmiana miała wpływ na dotychczasową
treść)
Łatwość wprowadzania zmian (2)
●
Pomiaru dokonano podczas czynności
związanych z:
–
dodawaniem listy stronicowanej
–
dodawaniem formularza
–
lokalizacją aplikacji
Dostępność (1)
●
Dostępność komponentów Trinidad zmierzono
poprzez:
–
sprawdzenie poprawności składniowej kodu HTML
komponentów
–
weryfikacji poprawności pracy w popularnych
przeglądarkach internetowych
Wyniki badania
wydajności
Liczba żądań w zależności od
badanej grupy użytkowników
Średni czas odpowiedzi aplikacji w
zależności od badanej grupy
użytkowników
Wyniki pomiaru metryk
kodu
Metryki kodu modułów aplikacji
Metryki kodu pakietów według
pełnionych funkcji
Metryki złożone aplikacji opartej o
Spring MVC oraz JavaServer Faces
Zmiana wartości metryk podczas
kolejnych etapów implementacji
aplikacji
Wyniki pomiaru metryk
kodu szablonów
Liczba znaczników wg rodzaju
widoków
Wielkość wygenerowanej strony
HTML
Wyniki badań
dostępności
komponentów Trinidad
Poprawność działania
komponentów Triniadad
Poprawność działania
komponentów wg przeglądarek
Udział błędów określonego typu w
komponentach Trinidad
Wyniki łatwości
wprowadzania zmian
Łatwość wprowadzania zmian a
liczba zmienionych plików
Wyniki analizy teoretycznej (1)
●
●
Model aplikacji. JSF jest szkieletem
zorientowanym na strony (ang. page-oriented),
Spring MVC na obsługę żądań przez
kontrolery.
Model programistyczny. Spring MVC zaczyna
od mapowania żądań użytkownika a
JavaServer Faces od definicji używanych w
aplikacji komponentów z uwzględnieniem ich
integracji z użytkownikiem.
Wyniki analizy teoretycznej (2)
●
●
Cykl życia żądania. W Spring MVC stosowane
jest pojęcie żądania, Aplikacje oparte o
JavaServer Faces używają pojęcia zdarzenia
odbieranego przez komponenty umieszczone
na stronie internetowej
Walidacja. Obie biblioteki są podobne pod tym
względem. JavaServer Faces poprzez
bibliotekę Trinidad posiada dodatkowo
znaczniki walidacyjne umieszczane
bezpośrednio na stronie JSP
Wyniki analizy teoretycznej (3)
●
Lokalizacja. Spring MVC posiada lepsze
wsparcie w tym zakresie. Oferuje wbudowane
przełączanie się między wersjami językowymi.
JavaServer Faces poprzez bibliotekę Trinidad
posiada gotowe komunikaty o błędach
walidacyjnych w języku polskim.
Wnioski z eksperymentów (1)
●
●
●
Oba szkielety programistyczne spełniły swoją
rolę w stopniu umożliwiającym w pełni
poprawną implementację wcześniejszych
założeń.
Spring MVC – tradycyjne podejście. JSF –
tworzenie aplikacji podobne do aplikacji
tworzonych w technologii ASP.NET
Aplikacje Spring MVC domyślnie są
bezstanowe. Aplikacje JSF zarządzają
wewnętrznym stanem aplikacji poprzez
ciasteczka.
Wnioski z eksperymentów (2)
●
●
Projekt oparty o Spring MVC posiada większą
liczbę linii kodu oraz artefaktów
programistycznych. Klasy projektu opartego o
JavaServer Faces posiadały większą liczbę pól
i metod.
Pomiar metryk złożonych wykazał większą
zgodność z zasadami dotyczącymi
obiektywności projektu wykorzystującego
Spring MVC
Wnioski z eksperymentów (3)
●
●
●
Strony generowane przez szkielet JavaServer
Faces są średnio nawet czterokrotnie większe
niż analogiczne strony aplikacji Spring MVC.
Badanie łatwości wprowadzania zmian
wykazało, iż JavaServer Faces lepiej sprawuje
się w przypadku tworzenia formularzy a gorzej
w aspekcie kompleksowej lokalizacji aplikacji.
Badanie dostępności komponentów Trinidad
pozwoliło stwierdzić wysoką kompatybilność
elementów interfejsu użytkownika.
Dalszy kierunek prac
●
●
Proponowany jest dalszy rozwój aplikacji w celu
zwiększenia jej złożoności dążąc do
implementacji rzeczywistych wymogów
biznesowych stawianych przed tego typu
systemami. Raportowanie, uwierzytelnienie
W porównaniu możliwe jest uwzględnienie
aspektów związanych z samymi szkieletami.
Badanie popularności, jakości dokumentacji,
liczby dostępnych narzędzi.
Dziękuję za uwagę