Część 2 – Analiza istniejącej aplikacji za pomocą narzędzia Altova UModel
W Część 1 W ramach cyklu "Analiza starszych aplikacji" zaprezentowaliśmy naszą aplikację do symulacji bankomatów, a kod źródłowy napisany w języku Java został zaimportowany do UModel projektu oraz dopracujemy diagram klas, aby uzyskać ogólny obraz klas aplikacji i ich relacji. W tym wpisie stworzymy diagramy przypadków użycia Celem tego dokumentu jest opisanie aktualnych funkcjonalności naszej aplikacji do bankomatów. Dodatkowo, dołączamy diagram przypadków użycia, który pomoże nam zaplanować przyszłe ulepszenia. Jak pokazano w części 1, gdy użytkownik uruchamia naszą symulację bankomatu, jest proszony o zalogowanie się za pomocą numeru konta i kodu PIN, a następnie wyświetlane jest menu transakcji, które podsumowuje wszystkie dostępne interakcje z aplikacją:
Korzystając z menu "Transakcje" jako punktu odniesienia, możemy stworzyć diagram przypadków użycia, który dokumentuje interakcje użytkownika z symulacją bankomatu:
Jeśli znają Państwo notację UML, być może zauważyli Państwo, że aktor w naszym diagramie nie przypomina typowej, schematycznej postaci używanej w UML. UModel umożliwia programistom tworzącym modele oprogramowania przypisywanie dowolnego pliku graficznego w formacie Windows .bmp jako reprezentację aktora w diagramie przypadków użycia. Użyliśmy okna pomocniczego "Właściwości", aby przypisać obraz z biblioteki dostarczonej wraz z programem UModel.
Diagram przypadków użycia nie jest odpowiednim miejscem do definiowania przepływu aplikacji ani klas obiektowych, ale służy jedynie do dokumentowania, w jaki sposób użytkownik (aktor w terminologii UML) wchodzi w interakcję z systemem. Możemy tworzyć dodatkowe diagramy przypadków użycia, aby przedstawić więcej szczegółów dotyczących każdej interakcji. Rozwijanie każdej interakcji w oddzielnym diagramie zwiększa czytelność, ponieważ każdy schemat jest prosty i przejrzysty, a jednocześnie pozostawia dużo miejsca na eksperymentowanie z różnymi opcjami.
Dodaliśmy weryfikację numeru konta i kodu PIN w formie notatki, a nie w formie diagramu przypadku użycia, ponieważ użytkownik bankomatu nie jest osobą, która wykonuje ten krok. Na podstawie doświadczeń z użytkowania bankomatów (ponieważ jeszcze nie analizowaliśmy kodu), możemy przypuszczać, że wypłata zostanie anulowana, jeśli żądana kwota jest większa niż saldo konta. Jednak porównanie kwoty wypłaty i salda konta nie jest wykonywane przez użytkownika, dlatego ta czynność również nie jest przedstawiona w diagramie przypadku użycia.
Strzałka znajdująca się wewnątrz przypadku użycia "Wypłata gotówki" wskazuje na hiperłącze. UModel umożliwia dodanie jednego lub więcej hiperłączy do dowolnego elementu w diagramach. Hiperłącze może odnosić się do adresu URL, zewnętrznego pliku lub innego diagramu. Okno dialogowe hiperłącza pozwala również na zdefiniowanie dodatkowego tekstu pomocniczego dla tych hiperłączy.
Jeśli zdefiniujesz więcej niż jeden hiperlink, tekst pomocniczy stanie się rozwijanym menu wyboru. Załóżmy, że naszym zadaniem jest zmodyfikowanie istniejącego symulatora bankomatu, aby pobierać opłatę za każdą wypłatę. Jeśli kwota wypłaty jest mniejsza niż 100 dolarów, opłata wyniesie 2 dolary. Jeśli kwota wypłaty wynosi 100 dolarów lub więcej, opłata wyniesie 4 dolary. Ponieważ bankomat nie jest zaopatrzony w banknoty o wartości jednego dolara, opłata musi być pobierana bezpośrednio z konta, a nie odejmowana od gotówki wypłacanej. Opłata zostanie wyświetlona przed wypłaceniem jakichkolwiek pieniędzy, a użytkownik będzie mógł anulować transakcję. Możemy dodać ten nowy wymóg do naszego diagramu przypadków użycia dla operacji wypłaty z bankomatu.
Zmieniliśmy kolor owalu reprezentującego przypadek użycia "Akceptacja opłaty", aby wskazać, że jest to planowana funkcja, która jeszcze nie została zaimplementowana. Niektórzy programiści mogliby twierdzić, że notatka dołączona do owalu "Akceptacja opłaty" jest zbędna, ponieważ sama notacja "include" (zawiera) wskazuje, że "Akceptacja opłaty" jest obowiązkowym elementem procesu "Wypłata gotówki". Jednak wiele osób jest zdezorientowanych różnicą między "include" a "extend", dlatego najlepiej jest być absolutnie precyzyjnym. Możemy również wykorzystać funkcję warstw w UModel, aby umieścić wszystkie elementy związane z nową funkcją na oddzielnej warstwie.
Teraz okno pomocnicze "Warstwy" umożliwia nam wyświetlanie lub ukrywanie planowanej funkcjonalności w widoku diagramu.
Analiza rzeczywistych transakcji w bankomatach pokazuje, że w obecnej symulacji bankomatów brakuje pewnych operacji. Menu transakcji nie oferuje możliwości przesyłania środków między kontami. Z analizy już stworzonych schematów wynika, że oryginalna konstrukcja aplikacji utrudnia implementację operacji transferu środków. Logowanie użytkownika opiera się na numerze konta, a wydaje się, że starsza wersja aplikacji nie uwzględnia koncepcji pojedynczego klienta banku, który posiada zarówno konto osobiste, jak i konto oszczędnościowe. Jeśli nasz menedżer zażąda funkcji przesyłania środków, będziemy musieli porozmawiać z architektem oprogramowania przedsiębiorstw w naszej firmie. Konieczne będzie wdrożenie identyfikatora użytkownika powiązanego z wieloma kontami nie tylko w naszej aplikacji symulującej bankomat, ale również w bazie danych banku.
Otrzymujący nagrodę Jolt pakiet Altova MissionKit dla architektów systemów to zestaw ośmiu narzędzi do pracy z XML, bazami danych i UML, przeznaczony dla architektów oprogramowania przedsiębiorstw, którzy mogą potrzebować narzędzi do modelowania UML i zarządzania bazami danych, oprócz zaawansowanych możliwości pracy z XML, usługami internetowymi i integracją danych.
Kliknij tutaj, aby pobrać w pełni funkcjonalną wersję próbną, dostępną przez 30 dni. W kolejnej części przyjrzymy się symulacji bankomatów z zupełnie innej perspektywy, przygotowując się do analizy kodu.