W dobie dążenia do budowania wysokiej jakości systemów informatycznych istotne jest badanie dynamicznych własności kodu. W Rational Software Architect ten obszar wspomaga mechanizm Runtime Analysis.
Czym tak naprawdę jest Runtime Analysis? Runtime Analysis to nic innego jak praktyka nakierowana na zrozumienie zachowania komponentów oprogramowania na podstawie danych zgromadzonych w czasie wykonywania komponentu. Nad definicją Runtime Analysis należy się zastanowić w aspekcie znaczenia dwóch tworzących ją słów:
-
?Runtime? ? oznacza, że analiza nie obejmuje statycznych sposobów analizowania kodu źródłowego rozwijanego oprogramowania i relacji pomiędzy blokami budującymi oprogramowanie. Umożliwia ona raczej pozyskanie cennych informacji o tym jak dany komponent zachowuje się w czasie jego uruchomienia, zarówno w środowisku testowym, jak i w docelowym środowisku wdrożeniowym.
-
?Analysis? ? oznacza, że czynność jest zaprojektowana w celu uzyskania wyjaśnień dla różnych, występujących lub potencjalnych złych zachowań.
Runtime Analysis jest często mylone z debugowaniem, które jest dobrze znaną czynnością wykonywaną przez wszystkich developerów oprogramowania.
Często zakładamy, że aplikacja będzie działała tak długo, jak długo kod źródłowy posiada prawidłową składnię, a komponent kompiluje się i linkuje bez żadnych błędów lub ostrzeżeń. To założenie jest jak najbardziej błędne. Nawet jeśli kompilator nie zgłosi żadnych błędów, to i tak aplikacja może nie być gotowa aby przedstawić ją klientowi. Przeważnie pisząc kod najpierw testujemy bazową funkcjonalność komponentu i upewniamy się czy wszystkie wymagania są spełnione. Później w cyklu rozwoju oprogramowania zespół przeważnie testuje oprogramowanie. Takie testy często skupiają się na funkcjonalności głównych scenariuszy przypadków użycia. Wnioskując zadajmy sobie pytanie. Czy jeżeli funkcjonalność głównych scenariuszy przypadków użycia jest potwierdzona, to czy aplikacja jest gotowa aby zaprezentować ją klientowi? Odpowiedz nadal brzmi nie. Aplikacja może bowiem zwracać błędy na niektórych maszynach, w niektórych kombinacjach scenariuszy lub w niektórych nie przetestowanych scenariuszach. Co więcej możliwe jest, że wydajność może nie być satysfakcjonująca. Zadaniem wszystkich ról biorących udział w rozwoju oprogramowania powinno być zminimalizowanie prawdopodobieństwa ze klient otrzyma wadliwy kod i w rezultacie nieprawidłowo działające oprogramowanie. Najlepszym sposobem aby to osiągnąć jest wykonywanie testów oprogramowania tak wcześnie jak to tylko możliwe. Bardzo rozsądnie jest uważać Runtime Analysis za rozszerzenie standardowego narzędzia debugującego i metodę, która pomaga zespołom ujawniać szczególne i bardzo często trudno do rozwiązania problemy.
Celem wykonania testów dynamicznych należy stworzyć profi dla projektu testu komponentu. Całe oprzyrządowanie analizy runtime jest dostępne właśnie poprzez tenże profil. Efekty realizacji danego punktu ćwiczeń laboratoryjnych przedstawione są poniżej:
Rys.1 Tworzenie profilu dla projektu testu komponentu
Rys.2 Tworzenie profilu dla projektu testu komponentu
Rys.3 Widok Profiling Monitor otworzony po stworzeniu profilu
Kolejnym etapem realizacji analizy dynamicznej jest uruchomienie aplikacji rezultatów analizy profilu i uruchomienie badanej aplikacji. Przeglądu analizy profilu dokonujemy z widoku Profiling Monitor. Przykładowe efekty realizacji przeglądu wyników analizy przestawione są poniżej:
Rys.4 Przegląd wyników analizy ? Basic Memory Analysis (Memory Statistics)
Rys.5 Przegląd wyników analizy ? Basic Memory Analysis (Object References)
Rys.6 Przegląd wyników analizy ? Execution Time Analysis (Execution Statistics)
Rys.7 Przegląd wyników analizy ? Method Code Coverage (Coverage Statistics)
Podsumowując, Runtime Analysis rozszerza standardowe czynności związane z rozwojem oprogramowania o jeden kluczowy wymiar, a mianowicie o dbałość o jakość. Wyznacza ona drogę w kierunku osiągnięcia wyższej jakości oprogramowania poprzez lepsze zrozumienie wewnętrznych procesów w rozwijanej aplikacji. Należy zapamiętać, że kompilacja kodu źródłowego nie jest żadnym dowodem jakości.
