Analiza starszego systemu aplikacji za pomocą Altova UModel – Część 1

W końcu prawie każdy programista zawodowy zostanie przydzielony do naprawiania błędów lub dodawania nowych funkcji do istniejącej aplikacji, której nie tworzył. W takich sytuacjach, nieprecyzyjna lub niekompletna dokumentacja oraz brak dostępu do oryginalnego zespołu programistów mogą stanowić poważne przeszkody. Na szczęście, program Altova UModel umożliwia inżynierię wsteczną istniejącego oprogramowania, tworząc model wizualny, który przyspiesza analizę i poprawia zrozumienie starszego systemu. To jest pierwszy artykuł z serii, w której będziemy wykorzystywać UModel, narzędzie firmy Altova Narzędzie UML do modelowania oprogramowania oraz rozwoju, w celu przeanalizowania symulacji bankomatu (ATM) napisanej w języku Java. Aplikacja została stworzona na podstawie kilku przykładów systemu bankomatów (ATM) pochodzących z popularnych tutoriali języka Java. Ponieważ urządzenie jest niewielkie, a zasada działania bankomatu jest dobrze znana, skupimy się bardziej na technikach, które można zastosować w własnych projektach Java, C# i Visual Basic, zamiast na przykładach kodu. Oto przykład działania starszej aplikacji uruchomionej w oknie wiersza poleceń:

Oryginalny twórca aplikacji udostępnił przykładowe dane konta, dzięki czemu możemy się zalogować. Następnie aplikacja wyświetla znany interfejs transakcji bankomatowych:

Jeśli zajrzymy do folderu zawierającego aplikację, zobaczymy pliki źródłowe w języku Java oraz skompilowane pliki .class, ale nie znajdziemy plików projektu.

To nie stanowi problemu. Menu projektu UModel umożliwia import projektu, katalogu źródłowego, a nawet plików binarnych skompilowanej aplikacji. Kod źródłowy bardzo dużych projektów jest prawdopodobnie zorganizowany w wielu folderach, więc nawet jeśli posiadacie plik projektu, warto przeglądać poszczególne foldery po kolei.

Zanim zaczniemy, upewnijmy się, że ustawiliśmy opcje UModel tak, aby automatycznie rysowały wszystkie relacje między klasami zdefiniowane w kodzie źródłowym

Podczas importu folderu, chcemy również uwzględnić wszelkie komentarze JavaDoc w kodzie źródłowym, aby wykorzystać je jako dokumentację dla naszego projektu UModel

Aby zapoznać się z tym starszym systemem, na początek chcemy uzyskać ogólny przegląd, dlatego nie będziemy otwierać wszystkich opcjonalnych sekcji:

UModel importuje projekt w ciągu kilku sekund, a okno komunikatów nie wyświetla żadnych błędów. Drzewo diagramów zawiera dwa diagramy:

Możemy kliknąć zakładkę "Drzewo modeli" i rozwinąć folder źródłowy, aby zobaczyć ikony reprezentujące wszystkie klasy Java zaimportowane przez UModel

Możemy wrócić do drzewa diagramów, aby otworzyć zawartość źródła Diagram klas UML. Po ustawieniu wszystkich stylów linii na proste oraz przemieszczeniu kilku linii i klas, aby uniknąć nakładania się, diagram wyraźnie ilustruje klasy aplikacji oraz relacje między nimi

Należy zwrócić uwagę, że nazwa klasy "Transaction" jest napisana kursywą, co wskazuje, że jest to klasa abstrakcyjna (lub klasa nadrzędna), a podklasy takie jak "BalanceInquiry", "Withdrawal" i "Deposit" dziedziczą jej właściwości. Jeśli kliknie się klasę "Transaction", aby ją wybrać, w oknie pomocniczym "Hierarchia" w programie UModel zostanie zobrazowane dziedziczenie, a wszelkie komentarze JavaDoc znajdujące się w kodzie źródłowym bezpośrednio przed definicją klasy zostaną wyświetlone w oknie "Dokumentacja"

Jeśli do analizy starszego systemu używalibyśmy tylko edytora tekstu, musielibyśmy przejrzeć każdy plik kodu źródłowego, aby zrozumieć strukturę hierarchiczną przedstawioną powyżej. Dzieje się tak, ponieważ klasa "Transaction" nie identyfikuje wewnętrznie swoich podklas. Kiedy już znajdziemy jedną podklasę, ta nie identyfikuje swoich "siostrzanych" klas. I nie możemy być pewni, czy inna klasa, o nielogicznej nazwie, nie jest podklasą klasy "Transaction", dopóki nie przeanalizujemy wszystkich klas. Można również wybrać każdą klasę indywidualnie, aby zapoznać się z jej dokumentacją w oknie dokumentacji. Alternatywnie, jeśli preferujesz bardziej przejrzysty schemat, możesz usunąć etykiety połączeń z samego schematu:

Teraz znak gwiazdki, oznaczający zakres "od zera do wielu" wystąpień kont w bazie danych banku, jest znacznie bardziej widoczny.

Kolejny członek naszego zespołu programistycznego znalazł fragment diagramu klas, który rzekomo przedstawiał starszy projekt, i przekazał go dalej. Od razu widać, że nie wygląda on jak diagram wygenerowany przez UModel:

Dokumentacja naszego starszego oprogramowania nie jest zgodna z kodem – niestety, ale jest to dość powszechne zjawisko! Istnieją pewne różnice między starym schematem a tym, który wygenerowaliśmy:

· The associations between ATM and the physical components are shown as composition associations

· The association between ATM and the BankDatabase is described by a text annotation

· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram

· Multiplicity is defined at each end of each association, but none were created by UModel

Rozważmy teraz każdy z tych punktów:

· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.

· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.

· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!

Dodamy adnotację, a następnie zaktualizujemy charakterystykę agregacji dla każdego powiązania z automatem (ATM) w oknie właściwości UModel. Użyjemy również paska narzędzi UModel Layout, aby wszystkie prostokąty reprezentujące klasy miały ten sam rozmiar. Nasz diagram klas wygląda teraz tak:

Ukończony diagram klas to dopiero początek naszej analizy. W kolejnych częściach zagłębimy się bardziej w kod aplikacji i automatycznie wygenerujemy więcej Diagramy UML, i tworzyć nowe schematy, w miarę jak nasze zrozumienie istniejącego kodu będzie się pogłębiać.

Jeśli chcesz od razu rozpocząć pracę i przeprowadzić analizę wsteczną własnej, starszej aplikacji napisanej w Javie, C# lub Visual Basic, kliknij tutaj, aby pobrać bezpłatną, w pełni funkcjonalną 30-dniową wersję próbną programu Altova UModel.