Wprowadzenie Pojęcie kontekstu projektu i diagram przypadków użycia jako narzędzie, nadal rodzi wiele pytań. Spowodowane jest to tym, że diagram przypadków użycia to najczęściej wykorzystywany diagram, najczęściej też "nielegalnie przeciążany" informacjami o architekturze wewnętrznej (związki 'include' i 'extend'). Jest to także najbardziej abstrakcyjny diagram w notacji UML. Postanowiłem odpowiedź "publicznie" na pytanie, które w różnych formach, często pada w projektach, na szkoleniach i w mailach do mnie kierowanych. Przykład jednego z nich: Mam pytanie, które dręczy mnie od jakiegoś czasu i teraz zmobilizowałam się by je zadać. W artykule Jarosław…
(źr. http://www.bptrendsassociates.com/)
Bez tej formalizacji (ścisłe stosowanie zdefiniowanych pojęć, także tych z użytej notacji) próby modelowania procesów prowadzą najczęściej do powstawania monstrualnych ilości nieczytelnych diagramów (widywałem dokumentacje, gdzie było dla jednej firmy powstałe blisko tysiąc stron! Masakra). To kompletnie nieprzydatne dokumenty.
Co jeszcze nam daje stosowanie powyższych definicji? Możliwość jednoznacznego "przejścia" (śladowanie) z modeli procesów biznesowych na modele przypadków użycia bo atomowy proces, zakwalifikowany do zakresu projektu jako wymagana usługa oprogramowania, to przypadek użycia, zaś procedura tego procesu to nic innego jak scenariusz tego przypadku użycia lub jak ktoś woli: user story. Z innej strony: jeżeli mamy wdrożona normę ISO9000, to modelując procesy biznesowe i "podpinając" do nich procedury z księgi jakości, szybko się przekonamy, czy nasze ISO to nie jest przypadkiem fikcja.
Dzisiaj co nieco o filozofii i przypadkach użycia. Dzielenie przypadków użycia na "rodzaje" zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: "przypadek użycia systemu", gdzie systemem jest coś (przedmiot opisu), czyli "analizowany/modelowany system" (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system (wymiennie "przedmiot zainteresowania", "przedmiot analizy"), zanim będzie rozpatrywany, musi być określony (granice systemu, który jest częścią "nad" (super) systemu, a składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek…
Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy... ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową.
Czyli np. "jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT", do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz "algorytm" wyliczenia podatków.
Jeżeli programista zaczyna "lepiej wiedzieć" od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie - jako developerowi - robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach "polegnie". Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być "pracownikiem" dostawcy? Jak sądzicie?
I tak mamy: 100% interfejsu użytkownika zamawia użytkownik (sam lub z pomocą specjalistów), 100% wymagań funkcjonalnych realizuje Model Dziedziny (projekt analityka-projektanta), 100% wymagań poza-funkcjonalnych realizuje developer (projekt i implementacja). Developer także implementuje model dziedziny z pomocą technologii jakiej używa.
A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba "wiedzieć co się chce".
Jak to zrobić? Tu kłania się analiza biznesowa: modelujemy procesy biznesowe, dla każdego z nich ustalamy wejście oraz efekt (produkt) czyli właśnie owe "wzory dokumentów". Po uporządkowaniu tego i upewnieniu się, że nie ma w tym bałaganu (powtórki, braki, niekonsekwencje, sprzeczności itp.) możemy pytać o gotowe oprogramowanie lub "zamawiać" jego wytworzenie. Produktem pracy analityka powinny być, poza modelami procesów bo one są narzędziem a nie celem, obiektowy model dziedziny czyli model tego jakimi informacjami i jak zorganizowanymi operuje organizacja, oraz to jak pracownicy tej organizacji chcą się komunikować z oprogramowaniem (źrodłem informacji jest jednak klient).
Mamy czysty podział odpowiedzialności i łatwość rozliczenia projektu. Na czym polega haczyk? Klient nie może unikać odpowiedzialności za skutki swoich decyzji i udzielanych informacji. Ale też, co jest kluczowe: Analityk musi zrozumieć problem i zaproponować rozwiązanie.
Jednak nie jest rolą analityka wykonanie oprogramowania! To "jak - technologia - ma to zostać zrealizowane" jest decyzją developera. Ma dużo pracy. Nie zapominajmy, że kod realizujący tak zwaną logikę biznesową to ledwie kilka procent całości kodu aplikacji, jednak nie zapominajmy także (programiści), że zła logika biznesowa dyskwalifikuje całe to oprogramowanie z prostego powodu: staje się nieprzydatne.
Tak więc radzę ostrożnie z Wikipedią. Wprowadzanie pojęć ukrywających istotę rzeczy to moim zdaniem, ukrywanie niewiedzy na etapie analizy i projektowania. To jedna z przyczyn złej jakości procesu tworzenia oprogramowania. Niezależnie od tego jak ładnie umotywujemy istnienie aktora Czas, programista i tak musi ten problem rozwiązać i nie będzie to na pewno interfejs "interakcji Systemu z Czasem"... A co z czasem? No cóż, albo człowiek klika co godzinę w coś, albo wewnątrz systemu jest moduł, który generuje zdarzenie wywołujące te samo operację co klikający użytkownik... Moduł wewnętrzny systemu nie jest jego aktorem.
Jak w takim razie w ogólności modelować cykliczność? Np. "prenumerata czasopisma na okres 12 m-cy", "codzienne generowanie raportu", "zbieranie wskazań licznika co N jednostek czasu" ? Po pierwsze usługa systemu to odpowiednio: zarządzanie prenumeratami, generowanie raportów, przetwarzanie pomiarów. Prenumerata to zapis mówiący, że mam otrzymać np. każde wydanie jakiegoś periodyka w ciągu danego roku. Generowanie raportów to czynność człowieka (raport na życzenie) albo automatu reagującego na zdarzenie "konkretny czas", zdarzenia takie generuje np. zegar systemowy. Zbieranie wskazań licznika to cykliczne zdarzenie inicjowane przez System. Implementacja tych wymagań to element projektowania logiki biznesowej i nie jest to już diagram przypadków użycia a model dziedziny systemu bo to tu jest logika biznesowa.
