Wstęp

Po dziesięciu latach UML stał się jednym z narzędzi w przyborniku twórcy oprogramowania. Sposobów na jego wykorzystanie jest bez liku i tylko od użytkownika zależy co opisze w UML. Większość osób piszących o UML koncentruje się na tym jak tworzyć system opisując go w UML. Ja chciałbym przyjrzeć się UMLowi od innej strony i pokazać jak go wykorzystać jako wsparcie w zdobywaniu wiedzy na temat istniejącej aplikacji, której nie pisaliśmy. Używając UMLa do tworzenia systemów możemy diagramy rysować na kartkach i skorzystać z notacji, do prezentowanego podejścia niezbędne będzie wykorzystanie narzędzia. W moim artykule używam jednego z najpopularniejszych narzędzi na naszym rynku Enterprise Architect firmy Sparx Systems, ale pokazane tu techniki mogą być również zastosowane w innych narzędziach, które posiadają funkcje zbliżone do prezentowanych.

Problem

Zacznijmy od opisu sytuacji w której się znajdujemy. Trafiliśmy do pewnego projektu związanego z utrzymaniem istniejącego systemu. Musimy się z nim zapoznać się, zacząć poprawiać błędy i rozwijać system. Wielu programistów w takiej sytuacji stwierdza, że oni zrobiliby to lepiej, ale nie ma wyjścia i musi działać z istniejącym kodem. Im dłużej kod był rozwijany i im więcej osób go poprawiało tym gorsza może być jakość takiego kodu. Nikt nie lubi wielokrotnie poprawianego kodu tak jak niechętnie ubralibyśmy się w ubranie w którym na łaty naszywa się kolejne łaty. Taki kod będzie wymagał działań na kilku frontach jednocześnie. Jednym z frontów będą bieżące działania naprawcze, a drugim refaktoring struktury tego kodu.

Właśnie trafił do nas jeden taki błąd i zabieramy się do pracy. Na początek wiemy, że system jest napisany w .NET, służy do pilnowania obsługi błędów i nie został udokumentowany przez swego twórcę bo jak zwykle nie było na to czasu.

Próby rozwiązania

Mając błąd do poprawienia najpierw sprawdzimy na czym on polega, potem spróbujemy przyjrzeć się kodowi, który dostaliśmy w spadku. Najprościej się mu przyglądać z debuggerem w dłoni i wykonywaniem krokowym pod palcem. Tak znajdziemy najbardziej prawdopodobne miejsce wystąpienia błędu i rozpoczniemy jego poprawianie. I znów jeden błąd poprawiony. Niestety to podejście ma pewną wadę – leczymy objawy a nie przyczyny. Poprawianie następnego błędu znów zaczniemy tak samo, nasza wiedza na temat systemu i sposobu jego działania będzie rosła bardzo powoli. Najgorsze w tym wszystkim, że architektura będzie coraz bardziej połatana. Bynajmniej nie jest moim zamiarem sugerowanie, że dzięki UML obejdziecie się bez debuggera. Użycie UML pozwoli uzyskać dodatkową wiedzę na temat architektury i udokumentować tą wiedzę na później lub dla innych, jeżeli nasz zespół rozrośnie się.