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ę