
Czas nie jest aktorem dla Systemu c.d. czyli projekt
? i udało się. Ciąg dalszy tekstu Czas nie jest aktorem dla Systemu, zapraszam do lektury.
Prosty przykład (na opisanie bomby w sieci internet się nie odważyłem ;)). Produkt jaki ma powstać to syrena sygnałowa. Wymaganie funkcjonalne: system powinien pozwalać na zaprogramowanie godziny i czasu trwania sygnału. Wymaganie poza-funkcjonalne: dokładność zegara programatora ma być nie gorsza niż błąd rzędu sekundy w skali roku (:)).
Wersja pierwsza
Diagram prosty (wprost modelowane wymagania zamawiającego) za to implementacja już nie. Diagram przypadków użycia, jego celem jest opisanie wymagań funkcjonalnych, czyli tego jakie system ma oferować usługi albo jak kto woli serwisy:

Diagram enigmatyczny ale do tego służy ten typ diagramu: aktorzy i usługi dla nich (tak zwany korzeń projektu). W tej postaci (pierwsza iteracja analizy i projektowania) otrzymamy np. taki projekt architektury (logiki) systemu:

Jak widać system składa się z dwóch podstawowych komponentów: Sterownika i Generatora Dźwięku czyli syreny właściwej ;). Sterownik jest implementowany (znak Realizacji) z pomocą generatora sygnału czasu i programatora. Programator ma interfejs użytkownika (GUI), zaprogramowany wysyła do Syreny sygnały Start i Stop zgodnie z ustawionym (zaprogramowanym) czasem (harmonogramem).
Generator sygnału czasu ma wyśrubowane wymagania, więc jego wykonanie będzie raczej kosztowne.
Wersja druga
Jak widać programowania dużo, koszt całości potencjalnie wysoki, więc kombinujemy dalej. Czy aby na pewno wszystko trzeba robić samemu? Pierwsza rzecz po wstępnym projekcie to upewnienie się, czy nie ma czegoś gotowego na rynku. Jak nie trudno (chyba) się domyśleć, zegarków na rynku dostatek, więc chyba nie trzeba go na nowo odkrywać. Mamy coś takiego jak COTS ([[Commercial off the shelf]]) czyli ogólnie dostępne na rynku komponenty lub usługi. No to zmiana projektu:

Zegarek mam gotowy, kupujemy Zegar lub, tu, użyjemy wzorcowego sygnału czasu, np. takiego jakiego używa typowa domowa pogodynka z radiowo sterowanym zegarem (to darmowa usługa). Teraz nasz diagram UC wygląda tak:

Tu aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my „zrozumieliśmy istotę rzeczy”. Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).
Wprowadziłem dwa stereotypy: człowiek i system, cel chyba jest oczywisty (człowiek ma ekrany GUI, system „jakiś interfejs” wymiany danych).
Rolą analityka biznesowego jest zrozumienie celu zamawiającego ale też opracowanie najkorzystniejszego rozwiązania. Nie jest to wyręczanie programistów, a analiza i projektowanie. Programiści (dostawca oprogramowania) implementują, rozwiązują problemy techniczne.
Tak więc jedynym tak na prawdę elementem (komponentem) wymagającym szczegółowego opracowania i implementacji jest Programator, warto było pochylić się nad analizą i projektowaniem, testy pomysłu wykonać na modelach… bo taniej.
Pokazałem przy okazji tak zwane zstępujące podejście do analizy i projektowania: od ogółu do szczegółu. Zanim zaczniemy projektować model dziedziny systemu warto ograniczyć zakres projektu do niezbędnego minimum (narobić to się każdy potrafi .)). W stylu opartym na [[Domain Driven Design]] (DDD) nazywa się „[[core domain]]” i „[[bounded context]]” (o DDD innym razem).
Zapytany zostałem także o testy akcentacyjne. Proste: nastawiam jakąś godzinę i czas „wycia” i czekam :), żeby długo nie czekać nastawiam taką by czekać kilka minut a nie godzin … upływu czasu się nie testuje (ten płynie i bez nas) , testujemy programator… Owszem można się umówić, że testujemy sygnały Start Stop interfejsu a nie syrenę (będzie ciszej).
Podsumowanie
Jak widać troszkę się, mam nadzieję, uporządkowało i mamy następujące wnioski:
- czas nie jest żadnym aktorem, aktorem jest beneficjent systemu, ktoś kto z niego korzysta lub z nim współpracuje, parametry takie jak godzina alarmu i czas jego trwania, to nie aktor czas, a treść danych wprowadzanych do systemu (np. formularz konfiguracji alarmu),
- opracowanie samej specyfikacji wymagań funkcjonalnych absolutnie nie determinuje projektu, czyli tego co nam programiści dostarczą (a może to być kosztowne lub nie, ale to wynika z projektu a nie diagramu UC),
- jedynym sposobem dokładnego postawienia zadania programistom (developerowi) jest opracowanie projektu tego co ma powstać (jego logiki), jest to już nie specyfikacja wymagań funkcjonalnych a specyfikacja systemu (albo jak kto woli, wymaganie jest projektem),
- nie liczcie na to, że dostawca zawsze zrobi wszystko by to kosztowało jak najmniej… (patrz druga wersja projektu, jest tańszy w wykonaniu – ryzyko),
- jeżeli ktoś umieszcza na diagramie UC aktora Czas, to najprawdopodobniej nie rozumie implementacji albo ukrywa ją, lub odkłada implementację, to znaczy, że odsuwa jedną z najważniejszych decyzji projektowych (koszty!) na później,
- zaletą takiego projektowania (obiektowe ukierunkowane na komponenty) jest możliwość szybkiego osiągania celu relatywnie niskim kosztem, w tym projekcie tak na prawdę do napisania jest sam programator, resztę jako COTS kupujemy: gotową syrenę, sygnał czasu wykorzystujemy „cudzy” (w tym przypadku to przy okazji klasyczny cloud computing).
Tak więc warto na etapie analizy biznesowej wykonać nie stenogram z życzeń zamawiającego (potrafi sobie nawet sam zrobić krzywdę) i naginać zasady (czas to nie aktor!), ale wykonać projekt logiki systemu by zrozumieć problem do rozwiązania i sprawdzić jak go rozwiązać najefektywniej. Wybór wykonawcy powinien być ostatnim krokiem.
Poniżej analiza (diagram pokazujący powyższe niuanse analizy i modelowania czyli zrozumienia co tak na prawdę jest istota problemu):
Wyobraźmy się, że wielu potencjalnych developerów dostało wymaganie: dostarczyć programowana syrenę (lub pierwszy diagram UC) jako zapytanie ofertowe, jaki będzie rozrzut ofert?
Do zamawiających oprogramowanie: oddzielajcie analizę i projektowanie od wykonania :), to ma same zalety. Zastanów się teraz Czytelniku, jakie rozwiązanie zaproponuje większość firm programistycznych…
Na koniec pytanie z gatunku ironii: jak na tym tle wyglądają zwinne metodyki wytwarzania oprogramowania?
P.S.
Polecam diagram przypadków użycia z innej strony: Udziałowcy projektu czyli który diagram UML …,
oraz ten sam problem, opisany z innej perspektywy na stronach IBM.

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.