Część 3 – Analiza istniejącej aplikacji za pomocą narzędzia Altova UModel

W Część 1 W tej serii zastosowaliśmy inżynieria odwrotna funkcjonalność Altova UModel aby zaimportować kod źródłowy z istniejącej aplikacji symulującej bankomat. Stworzyliśmy diagram UML diagrama klas w celu zilustrowania hierarchii klas i relacji między klasami w aplikacji Część 2 Narysowaliśmy diagram UML diagram przypadków użycia aby udokumentować interakcje użytkowników z systemem, przygotowaliśmy również kilka dodatkowych diagramów przypadków użycia, które szczegółowo opisują interakcje oraz planowane ulepszenia. W tej części przyjrzymy się bankomatowi z innej perspektywy.

W upalny letni dzień, zmęczony kierowca zauważa w oddali budkę z lodami z możliwością zamówienia przez okienko. Pojawia się jednak jeden problem – nie ma przy sobie gotówki! Dlatego skręca do parkingu przy centrum handlowym i parkuje obok bankomatu znajdującego się w szklanej budce. Zanim jeszcze wysiądzie z samochodu, nasz sfrustrowany klient zastanawia się, w jakim stanie jest bankomat. Czy inny klient, który załatwia skomplikowane sprawy bankowe, już z niego korzysta? Nawet jeśli nikt nie przebywa wewnątrz budki, czy bankomat może być poza służbą?

UML (Unified Modeling Language) - Ujednolicony Język Modelowania diagrama stanów (zwany również diagramem stanów) pozwoli nam zmapować stany naszego symulowanego bankomatu oraz czynniki wyzwalające, zdarzenia i przejścia między stanami, co pozwoli nam lepiej zrozumieć, jak działa nasze starsze oprogramowanie. Wróćmy do naszego doświadczenia z uruchomienia symulacji, aby zacząć:

Po uruchomieniu starszej wersji aplikacji, nasz symulator bankomatu przeszedł w tryb oczekiwania, gotowy na pierwszego klienta:

Następnie, może być pomocne zidentyfikowanie i narysowanie dodatkowych stanów w oddzielnych, eliptycznych kształtach. Będziemy mogli przesuwać te elipsy, jak elementy układanki, aby znaleźć logiczną sekwencję, nie martwiąc się o przejścia między kolejnymi stanami.

Ta wstępna lista stanów automatu stanów jest jedynie naszym pierwszym, roboczym szkicem. Opisy stanów zostały zaproponowane na podstawie elementów menu naszego istniejącego systemu, i jest oczywiste, że możemy je uprościć:

Nie ma różnicy między opcjami "Wybierz pierwszą transakcję" i "Wybierz następną transakcję", więc powinny zostać połączone.
"Wylogowanie" prawdopodobnie nie jest stanem, ale natychmiastowym przejściem, które następuje, gdy nasz użytkownik naciska klawisz 4 w menu transakcji.
Możemy przypisać wprowadzenie przez użytkownika kwoty wypłaty lub kwoty wpłaty jako podstany w ramach stanu "Wykonanie transakcji". Trzeci punkt upraszcza nasz schemat i byłby również zgodny z naszym podejściem do wprowadzania przez użytkownika numeru konta i kodu PIN jako części procesu "Uwierzytelnianie użytkownika". Po wprowadzeniu tych zmian i dodaniu przejść, nasz schemat wygląda następująco:

Dodane przez nas proste przejścia to mechanizmy, które powodują, że bankomat przechodzi z jednego stanu do następnego. Należy również zauważyć, że każdy stan ma co najmniej jedno wejście i jedno wyjście – w przeciwnym razie starsze oprogramowanie mogłoby doprowadzić użytkownika do sytuacji bez wyjścia. Diamentowy element pomiędzy "Wybieraniem transakcji" a "Wykonywaniem transakcji" to symbol UML oznaczający możliwość wyboru różnych ścieżek. Na pierwszy rzut oka może się wydawać nielogiczne, że aplikacja pozwala użytkownikowi wylogować się przed wykonaniem jakiejkolwiek transakcji, ale jest to opcja, którą oferuje nasze starsze oprogramowanie w menu transakcji. A użytkownicy w rzeczywistości często zmieniają zdanie w ostatniej chwili! Zwróciliśmy szczególną uwagę na używanie spójnego języka w nazwach i opisach naszych elementów. Stanom nadano nazwy zawierające czasowniki w czasie teraźniejszym zakończone na "-ing". Przejścia są oznaczone, aby wskazać zakończenie działania, które powoduje zmianę stanu. Spójne nazewnictwo elementów zwiększa czytelność diagramu.

Gdy mamy już działający diagram stanów, taki jak ten powyżej, warto zastanowić się, co się dzieje, gdy próba przejścia między stanami się nie powiedzie. Użytkownik bankomatu może wprowadzić nieprawidłowy numer konta/kod PIN, lub uwierzytelniony użytkownik może zażądać wypłaty kwoty, która przekracza saldo konta. Możemy rozbudować nasz diagram stanów, aby uwzględnić te możliwości:

Obecnie nasz diagram stanów pokazuje wiele alternatywnych ścieżek przebiegu działania aplikacji, a nie tylko jedną, idealną ścieżkę "scenariusza sukcesu". Wybraliśmy układ pionowy dla naszego diagramu, ale nie ma żadnej zasady, która by to narzucała. Niektóre aplikacje lepiej nadają się do układu poziomego, albo może to po prostu kwestia osobistych preferencji. Poniższa ilustracja przedstawia fragment naszego diagramu stanów w układzie poziomym:

Niezależnie od wybranego układu diagramu maszyny stanów, należy unikać rysowania linii przejść, które się przecinają lub nakładają. Tworzenie diagramu maszyny stanów UML może wydawać się przesadą w przypadku naszej symulacji bankomatu, ponieważ aplikacja jest niewielka, a wszyscy znamy sposób działania bankomatów. Jednakże, te techniki mogą być bardzo pomocne, gdy trzeba pracować nad znacznie większą aplikacją działającą w obszarze tematycznym, który jest nieznany lub złożony.

Jeśli jesteście gotowi do tworzenia diagramów maszyn stanów UML dla Waszych istniejących aplikacji Java, C# lub Visual Basic, kliknij tutaj, aby pobrać bezpłatną, w pełni funkcjonalną 30-dniową wersję próbną Altova UModel. W kolejnej części omówimy szczegółowo transakcję wypłaty oraz nową funkcję, którą zaplanowaliśmy w części drugiej.