? 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:
Nie bardzo rozumiem, czemu ?Generator sygnału czasu? został tutaj przedstawiony jako aktor systemu. Wszak:
– aktor korzysta z usługi systemu w celi realizacji swojego celu,
– system oferuje usługę pozwalającą na realizację celu aktora.
Aktor ?Generator sygnału czasu? oraz przypadek użycia ?Odbierz sygnał czasu? przeczą obu powyższym punktom. Trudno mi sobie wyobrazić, żeby ?Generator sygnału czasu? miał jakiś interes w wykorzystaniu usługi naszego systemu ?Odbierz sygnał czasu?. Jak dla mnie zależność jest odwrotna – to ?Generator sygnału czasu? świadczy usługę na rzecz naszego systemu (czyli to nasz system jest dla niego aktorem). W związku z powyższym interfejs ?iSygnałCzasu? powinien być interfejsem wymaganym, a ?Programowana Syrena Alarmowa? powinna być od niego zależna.
Generator czasu jest czymś co stale emituje sygnał, jeżeli „system” na niego reaguje (i synchronizuje się) to znaczy, że po stronie systemu jest interfejs, który jest wywoływany (odbierz ode mnie informację). Aktor co do zasady to byt który inicjuje reakcję systemu. kto komu świadczy usługę to konsekwencja tego kto inicjuje działanie a inicjuje je generator czasu, system biernie czeka na sygnał czasu z generatora, a nie prosi go o sygnał.
To, kto inicjuje interakcję, nie ma żadnego wpływu na identyfikację aktora, najważniejszy jest fakt świadczenia usługi. W przypadku naszej syreny, to nasz system korzysta z usług generatora czasu.
Ponadto przypadek użycia 'Odbierz sygnał czasu’ to sztuczne wymaganie, które zostało dodane do diagramu po dokonaniu pewnej decyzji projektowej (dot. wyboru zewnętrznego zegarka). Realizacja zegarka własnymi siłami również pozwoliła by na osiągnięcie celu, ale przypadku 'Odbierz sygnał czasu’ by nie było. Mamy tu do czynienia z sytuacją, w której decyzja projektowa wpłynęła na zakres funkcjonalny systemu!
Generator sygnału czasu jest systemem zewnętrznym, ale nie aktorem (proszę wybaczyć odrobinę złośliwości, ale w tym momencie pozostaje mi tylko polecić Pański własny tekst 'Nie każdy współpracujący system to aktor…’) i to on (generator) posiada interfejs oferowany – to oferowany przez niego sposób komunikacji z aktorami (m.in. naszą syreną). Interfejs ten obsługuje jakiś format czasu i jakiś kanał przekazywania sygnału czasu. Dlatego też to my w ramach projektu musimy stworzyć interfejs, który się do tego formatu i kanału dostosuje (interfejs, który jest od naszego systemu wymagany)!
To, że aktorem systemu („aktor systemu” i „aktor” na diagramie UC to dwa odrębne pojęcia) jest ten, który inicjuje interakcje wynika z tego, że system reaguje na akcję aktora (komputer raczej nie zaczepia księgowej, to ona go zaczepia). Każdy przypadek użycia to określony stan początkowy 9dane wejściowe) i reakcja systemu na ten stan. Żaden system nie jest w stanie wyświadczyć usługi nie „proszony” o to… nie ma znaczenia, to że o budzenie mnie poprosiłem dzień wcześniej, podając jako stan wejściowy godzinę pobudki to ja zażądałem usługi.
PU „odbierz sygnał” nie jest niczym sztucznym, tak działa odbiornik sygnału czasu na falach długich. I w tym kontekście zewnętrzny generator czasu jest aktorem, bo System reaguje na niego. Nie ma znacznie kto buduje interfejs, znacznie ma to czy to interfejs oferowany czy wymagany, w przypadku generatora sygnału czasu i odbiornika sytuacja jest prosta: budzik ma interfejs oferowany, który pozwala zażądać odebrania sygnału czasu (nasz zmysł słuchu to interfejs oferowany, usta jako generator mowy to interfejs wymagany: żądamy zrozumienia naszej mowy – poleceń).