Ostatnio natknąłem się na publikację pod tytułem System Analysis and Design for Advanced Modeling Methods: Best Practices opracowaną w 2009 roku pod redakcją Akhilesh Bajaj oraz Stanisława Wrycza (ISBN 9781605663449). Książka ta stanowi zbiór wyników badań naukowych w obszarze analizy i projektowania systemów oraz metodologii.
Szczególnie zainteresował mnie rozdział X (dziesiąty), w którym prof. dr hab. Stanisław Wrycza napisał o potrzebie stworzenia lekkiej wersji języka UML (zwanej Light UML). Otóż, programiści proponują opracowanie ograniczonej i minimalistycznej wersji UML z uwagi na jego skomplikowanie i zastosowanie różnorodnych zestawów technik do budowania diagramów. Taki odchudzony UML byłby w pełni kompatybilny z pełną wersją języka, zawierałby tylko zestaw diagramów, które są najczęściej wykorzystywane. Ale również składnia tych diagramów byłaby pozbawiona niektórych elementów, na przykład brakowałoby na diagramach klas relacji: Dependency czy Generalization, a na diagramach przypadków użycia: <<include>> Dependency oraz <<extend>> Dependency. Poza tym "lekki UML" byłby zgodny z podstawowymi zasadami RUP, na przykład w zakresie specyfikacji wymagań, analizy i projektowania.
Na bazie badań na Uniwersytecie Gdańskim, obejmujących 180 studentów przedstawiono w książce wyniki w tym zakresie. Z mojego punktu widzenia najciekawszy jest aspekt przystępności poszczególnych typów diagramów UML. Wybrałem to zagadnienie, gdyż autor wskazuje, że wpływa na interpretację między innymi przez kadrę kierowniczą i przyszłych użytkowników. A to oni zwykle są najważniejszymi adresatami modeli.
This aspect of the system model should be as precise as possible, remaining easy to interpret by all system stakeholders, in particular system owners, managers and future users.
 |
| Assessment of UML diagrams user-friendliness Źródło: A. Bajaj, S. Wyrcza, "Systems Analysis and Design for Advanced Modeling Methods: Best Practices" 2009 |
Zastanawiam się, co wpływa na łatwość zrozumienia diagramów przypadków użycia. Czy jest to zastosowanie formy graficznej dla aktorów, która przypomina ludziki rysowane przez dzieci? Dla mnie osobiście najbardziej zrozumiałe są chyba diagramy aktywności, które w intuicyjny sposób prezentują ciąg czynności oraz punkty decyzyjne. Diagramy przypadków użycia nie prezentują takiego ciągu. Czytając taki diagram można ustalić jedynie, jakie czynności są wykonywane przez danego aktora, ale nie ma znaczenia, czy dany aktor na przykład najpierw usunie z rejestru książek daną pozycję, a dopiero później spróbuje ją wyszukać w celu modyfikacji.
Duże zrozumienie diagramów klas i obiektów można złożyć na karb specyfiki badanej grupy. Jak podano w opracowaniu - w wielu przypadkach byli to studenci z doświadczeniem w programowaniu i projektowaniu.
Ale niezrozumiały jest dla mnie niski poziom zrozumienia diagramów typu Component oraz Deployment.
Według mnie pojęcie komponentu, który może zawierać jakieś inne elementy oraz rozmieszczenie komponentów w fizycznych węzłach jest dość intuicyjne.
Ale abstrahując od pomysłu odchudzenia UML i zaprezentowanych wyników badań - myślę, że najważniejszym problemem jest zapewnienie odpowiedniego poziomu zrozumienia diagramów przez odbiorców.
Język UML może być trudny w obiorze, ale jest bardziej precyzyjny niż język naturalny. Tylko jak sprawić, aby wszyscy rozmawiali w tym samym języku?
Wyniki tych badań mówią przede wszystkim o słabej znajomości UML w ogóle. Z moich doświadczeń wynika, że bardzo trudno wytłumaczyć komuś różnicę pomiędzy funkcjonalnością(Przypadek Użycia, najmniejsza niepodzielna "korzyść", jaką otrzymuje Użytkownik Systemu, Czy Klient biznesu), a funkcją(algorytm, jak osiągnąć założony efekt). Trudno też wytłumaczyć, że budowanie modelu UML to jest tworzenie wielowymiarowej konstrukcji, w której diagramy stanowią jedynie pewne przekroje, by pokazać specyficzne cechy budowanego systemu, takie jak np. jego zachowanie(diagramy aktywności), strukturę(diagramy klas, komponentów), czy też właściwości(diagramy wymagań), funkcjonalności(diagramy przypadków użycia). Dla wielu ludzi te diagramy to jedynie rysunki, nie zauważają podstawowej korzyści modelowania, jaką jest wzajemne powiązanie elementów modelowanego systemu i możliwość prześledzenia ich współzależności, weryfikacji kryteriów jakości: czy model jest spójny, minimalny, kompletny, jednoznaczny, wystarczający... Słaba jest też umiejętność posługiwania się narzędziami, takimi jak EA. Pracuję w projekcie, gdzie mamy CASE, natomiast dokumentację sklejamy z fragmentów generowanych w EA... Słaba znajomość notacji, plus słaba znajomość narzędzi CASE powoduje, że często modelowanie widziane jest jako utrudnienie, rysowanie obrazków, nie jako proces wytwarzania wizji rozwiązania.
OdpowiedzUsuń