Co prawda formalna publikacja wersji 2.5 UML  to 1 marzec 2015 r. ale co ma wisieć nie utonie (spokojne przebrnięcie tych 794 stron wymaga czasu i cierpliwości), czyli wzmianka i kilka słów z pierwszych wrażeń. Specyfikacja  do pobrania tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5) 

Zdaję sobie sprawę z tego, że poniższe nie wszystkim z Was wszystko wyjaśni ale ten akurat wpis adresuję dla tych z Was, którzy korzystają już z UML, nawet w bardzo prosty sposób.

Wersja 2.5 UML to wersja chyba przełomowa, bo:

• zrezygnowano w końcu z podziału na dwie części Infrastructure i Superstructure,
• uporządkowano cały system pojęciowy notacji: jest to w końcu jedna w pełni spójna notacja (system klasyfikatorów, kiedyś Infrastructure) oraz zestaw predefiniowanych grup stereotypów z ich dedykowaną semantyką i syntaktyką (kiedyś Superstructure).
• diagram jako pojęcie, obecnie stanowi jedynie kontekst a nie, jak kiedyś zamkniętą “subnotację” (UML zaczynał w latach 90-tych jako zlepek kilku notacji  trzech autorów).

Obecnie mamy osiem typów diagramów (kopia z oryginału):

UML diagrams may have the following kinds of frame names as part of the heading:
? activity
? class
? component
? deployment
? interaction
? package
? state machine
? use case
In addition to the long form names for diagram heading types, the following abbreviated forms can also be used:
? act (for activity frames)
? cmp (for component frames)
? dep (for deployment frames)
? sd (for interaction frames)
? pkg (for package frames)
? stm (for state machine frames)
? uc (for use case frames)

Jak widać, trzylitrowych skrótów oznaczających diagramy jest o jeden mniej  (siedem). To wynika z tego, że wszystkie diagramy w UML to tak na prawdę diagramy klas (ten typ diagramu nie ma swojego dedykowanego skrótu), z tym że stanowią one kontekstowe profile. Struktura pojęciowa tych diagramów (ich [[taksonomia]]):

W stosunku do UML 2.4 diagram profilu jest teraz równoprawnym typem diagramu (czternasty). Wszystkie pojęcia UML (constructs) zostały przydzielone kontekstowo to typów diagramów:

The constructs contained in each of the UML diagrams are described in the clauses indicated below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment diagram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozumieć w ten sposób: diagram aktywności daje kontekst dla pojęć z grupy “activities” (aktywności i czynności oraz ich syntaktyczne asocjacje), diagram klas daje kontekst  dla “klasyfikatorów strukturalnych”, itd.

Warto przypatrzeć się swoim narzędziom  CASE, gdyż niestety nie wszystkie mają wbudowany powyższy “klasowy” paradygmat (w UML wszystko jest klasą). Wiele z nich nadal hołduje zasadzie diagramy jako odrębne notacje, obecnie w UML w każdym typie diagramu można użyć każdego elementu notacji, diagram jako pojęcie to wyłącznie kontener niosący główny kontekst danego modelu, bo przypominam, że diagram w UML to wyłącznie widok całości lub części modelu z określonej perspektywy i na określonym poziomie abstrakcji.

[uzupełnienie 2015-11-21] Z pewną satysfakcją “odkryłem” (pierwotnie, pisząc ten artykuł miesiąc temu, nie zwróciłem na to uwagi), że zrezygnowano w końcu z pojęcia agregacji, zwanej w części literatury “słabą kompozycją”. Ta kuriozalna konstrukcja pojęciowa kłóciła się z pojęciem i asocjacji jako takiej i kompozycji jako związku “całość część”. Nie ja jeden, jak śledzę dyskusje członków OMG na listach LinkedIn, deklarowałem, że “nie rozumiem” czym jest agregacja (chyba pierwszym, który to głośno mówił był Martin Fowler). Na szczęście widać, że definicja tego pojęcia nie wytrzymała boju z logiką. Co prawda symbol asocjacji z “pustym rombem” jest (tylko) na liście symboli w dodatku B.6 (str. 718) jednak widać, że to relikt kompatybilności wstecz, w treści całej specyfikacji to pojęcie nie jest w ogóle używane. Generalnie mamy związek kompozycji (pełny romb), a element skomponowany może być rzeczywisty (part) lub abstrakcyjny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dziedziczeniem: nie ma dziedziczenia (korekta grudzień 2017, UML 2.5.1.).

Polecam całą specyfikację, znacznie krótsza od poprzedniej :).

Całkiem niedawno cytowałem raport opisujący przyczyny niepowodzeń projektów, malutki fragment:

40% projektów korzysta z emaili do zbierania wymagań i komunikacji z klientem. (Sabotaż dokumentacyjny).

Dzisiaj czytam:

polecamy ściągnięcie GnupPG przy pomocy którego można szyfrować pocztę asymetrycznie samodzielnie, w dowolnym kliencie pocztowym. Jest to więc rozwiązanie jeszcze bezpieczniejsze niż Lavabit ? ale wymaga wtajemniczenia rozmówców w zasady korzystania z kryptografii asymetrycznej (Lavabit, serwis z którego ponoć korzystał Snowden zostaje zamknięty pod naciskami — Niebezpiecznik.pl —).

Nie będzie tu jednak nic o szpiegostwie ani terroryzmie, a o naszych projektach. Krótkie wyjaśnienie.

Z perspektywy każdego z nas, nasz klient poczty i to jak nasza poczta dociera do adresata wygląda tak:

 

Jako Nadawca każdy z nas, korzystają z funkcjonalności używanego klienta poczty, wysyła email’a do adresata. Treść w przemieszcza się mniej więcej tak:

W większości przypadków  treść umieszczana jest w treści email’a lub w załączniku (załączone dokumenty). Jeżeli treść emaila nie jest szyfrowana (a generalnie nie jest, o ile sami o to nie zadbamy, co jednak, jak pokazuje cytowany Niebezpicznik, nie jest trywialne) nasza korespondencja, przechodząc przez publiczne łącza sieci Internet, jest jawna i łatwa do podsłuchiwania.

Jak uczynić naszą korespondencję (bardziej) niejawną? Mój komentarz do wpisu na stronie Niebezpiecznik:

osobiście uważam, że najprościej i bez ?uczenia korespondentów? czegokolwiek, jest posiadanie ?strzeżonego? repozytorium i używanie maila tylko w celu wysyłania enigmatycznych ?nowy dokument??.. w moich oczach, traktowanie skrzynki email jako repozytorium treści jest co najmniej naiwne.

Jak to wygląda?

Idea  polega na tym, by dokumenty (treści chronione) nie były przesyłane mailem a składowane we współdzielonym repozytorium. Wtedy email służy wyłącznie do monitowania o pojawieniu się nowych dokumentów. Łącza pomiędzy repozytorium a jego użytkownikiem łatwo zabezpieczyć np. z użyciem SSL.

A teraz popatrzmy na nasze (Państwa) projekty. Wielu z nas podpisuje umowy o zachowaniu poufności, nie raz obłożone dużymi karami. Zgodnie z prawem informacje można uznać za poufne wyłącznie wtedy, gdy są strzeżone przez ich właściciela, wysłanie więc czegokolwiek w postaci zwykłego załącznika praktycznie wyłącza taką treść z klauzuli poufności.

Drugi problem to przetwarzanie danych, zwracam uwagę, że serwery pocztowe to rzadko kiedy własność administrowana przez strony projektu. Zwracam także uwagę, że serwery pocztowe przechowują treści jakie wymieniamy. Zastanówmy się, jak tu wyglądają nasze emaile z załącznikami np. na Google.com? Zastanówmy się czy tu cokolwiek jest poufne i kiedy?

Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go “podsłuchiwać”, i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej,  kompletnej wiedzy o projekcie.

Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem):

… byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).

Gdzie problem?

Regularnie na szkoleniach i w projektach miewam dyskusje inicjowane pytaniem: Dlaczego nie podoba się Panu klasa Pracownik? No właśnie: Dlaczego nie podoba mi się klasa Pracownik?

 

Najpierw kluczowy dla każdego projektu diagram przypadków użycia czyli wymagania i kontekst projektu:

Jest to hipotetyczny diagram opisujący prosty program do sprzedaży. Tu pierwsza uwaga, zanim coś nazwiemy ‘system’ należy pamiętać, że

System (stgr. ??????? systema ? rzecz złożona) ? obiekt fizyczny lub abstrakcyjny, w którym można wyodrębnić zespół lub zespoły elementów wzajemnie powiązanych w układy, realizujących jako całość funkcję nadrzędną lub zbiór takich funkcji (funkcjonalność). (System ? Wikipedia, wolna encyklopedia).

Systemem więc może być oprogramowanie i wtedy mamy tu System wspomagający sprzedaż towarów. Ale pracownicy firmy współdziałają z tym oprogramowaniem, (korzystają z niego), więc oni wraz z oprogramowaniem, jako cała firma (organizacja) także są systemem.  Zgodnie z ogólna teorią systemów “system to system systemów”, z perspektywy badanego Systemu mamy jeszcze podsystem (system składowy) i supersystem (system nadrzędny). Jeżeli więc nazywamy nasze oprogramowanie System to znaczy, że firma wraz z jej pracownikami i wyposażeniem to Supersystem, a ewentualne komponenty Systemu wspomagającego sprzedaż towarów to podsystemy. Innymi słowy mamy tu dwa systemy: jeden obwiedziony linia przerywaną czyli ludzie używający oprogramowania do pełnienia swoich obowiązków, drugi będący projektowanym oprogramowaniem.

Pierwsza uwaga: bardzo często obserwuję, że już na etapie analizy zapomina się, że analizowana organizacja to ów Supersystem, do którego należy stosować takie same zasady jak do Systemu. To znaczy, że chcąc opracować wymagania na System należy przeanalizować Supersystem. Powodem wielu porażek wdrożeń jest zignorowanie tego faktu, rzucamy się na wdrożenie np. Systemu ERP nie mając pojęcia o jego “roli” w Supersystemie (naszej organizacji), który tym wdrożeniem można nawet zniszczyć. Z moich obserwacji wynika, że jest to jedna z kluczowych przyczyn porażek wielu wdrożeń Systemów CRM, które na ich – tych CRM’ów – nieszczęście często dotyczą całej organizacji.

I teraz wyjaśnienie: Supersystem (zaznaczony jako Współdziałanie) ma Magazyniera i Sprzedawcę wiec System ich już nie ma (oni są Aktorami na zewnątrz). Magazynier (pamiętamy, że nie wolno w jednym systemie – przestrzeni nazw – używać twego samego pojęcia w więcej niż jednym znaczeniu) to “osoba przyjmująca i wydająca towary z magazynu” więc to słowo już zarezerwowaliśmy w projekcie, nie należy go więc używać powtórnie w innym znaczeniu. Tak więc nasz Supersystem to nasi pracownicy używający do pracy Systemu wspomagającego sprzedaż towarów.

Pora na model dziedziny systemu. Tu delikatnie przypomnę, wcześniejszy artykuł: Czym jest a czym nie jest tak zwany model dziedziny systemu. Jeżeli ktoś go nie czytał to to jest właściwy moment. Drugi scenariusz to przeczytanie go po tym, wtedy zapewne tezy tam prezentowane będą oczywiste.

Model dziedziny naszego Sytemu (to jakaś wstępna, zapewne wymagająca jeszcze pracy wersja ale chodzi o zasady :)):

Przypominam, że powyższe to model dziedziny systemu czyli nie model pojęciowy i na pewno nie model danych. Jest to diagram klas (zastosowałem ikony wzorca BCE) opisujący współpracę obiektów, bo zgodnie z definicją obiektowego paradygmatu:

Program obiektowy należy postrzegać jako kolekcję współdziałających obiektów, w przeciwieństwie do  konwencjonalnego modelu programowania, gdzie program to lista poleceń (zadań, podprogramów) [przyp. mój] operujących na określonym zestawie danych (baza danych). (Czym jest a czym nie jest tak zwany model dziedziny systemu).

Klasy nie mają więc na tym etapie analizy i projektowania atrybutów, bo do analizy i zrozumienia problemu są zupełnie zbędne. Mają zaś operacje, bo te są niezbędne dla zrozumienia problemu i opracowania jego modelu.

No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do  identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie (a nie w Systemie), system “ma w środku” Kartę Towaru (zastąpiła papierową) zawierającą opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.

Co uzyskujemy dzięki temu:

• Nie ma problemu z tym co oznacza w dokumentacji projektu np. słowo Pracownik (wiadomo, że to aktor a nie klasa dziedzinowa).
• System ten jest tym czym jest, czyli narzędziem pracy człowieka a nie np. człowiekiem.
• Model dziedziny, z niewielka pomocą, jest zrozumiały dla biznesu (tu ewentualna ewolucja modelu do wzorców DDD).
• Model ten nadaje się do bezpośredniej implementacji (no prawie ;))

Kilka słów komentarza do praktyk i użytych wzorców. Cały problem został rozłożony na trzy analityczne składniki: obiekty graniczne (Boundary, klasy z pozioma literką T) odpowiedzialne za to jak System świadczy usługi swoim aktorom (Aktor to Użytkownik Systemu).  Obiekty posiadające wiedzę o wybranych aspektach działania Systemu i świadczące wewnątrz systemu takie usługi, np. o tym  jak utworzyć Fakturę czy Kartotekę (strzałka zawinięta w kształt koła). Obiekty reprezentujące unikalne, zapamiętywane “istnienia” takie jak faktury, kartoteki itp. (Entity, klasy w postaci koła z poziomą linią u dołu).

Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali… ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i “normalizacji”. Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są ‘tymi samymi rzeczami” ale w innych kontekstach, prowadzi do bardzo wielu problemów  z implementacją. Ale po kolei.

Wymaganie: system ma pozwalać na wystawianie faktur VAT

Wyobraźmy sobie pozornie prosty problem: oprogramowanie CRM zawierające między innymi funkcjonalność fakturowania. Z reguły z wywiadów (analiza) dowiemy się, że w kilku miejscach różne osoby wystawiają faktury. Wzór faktury będzie załącznikiem, z kilku tak zwanych “user story” zostanie opracowany jeden (normalizacja user story) przypadek użycia “Wystawienie faktury VAT”, jego implementacja z reguły jest kompilacją treści kilku wywiadów (user story). Kilka różnych osób (role) dostanie prototyp do oceny, każdy zgłosi inne zmiany i oczekiwania, powoli powstaje bardzo złożony scenariusz przypadku użycia obłożony warunkowymi ścieżkami scenariusza realizacji tego przypadku użycia. Nie raz można spotkać bardzo skomplikowany “model procesu” wystawiania faktury z  wieloma warunkami… Diagram przypadków użycia jednak, po czymś w rodzaju normalizacji, najczęściej przedstawiał by jedno wymaganie – wystawianie faktur VAT – i wyglądał by tak:

 

Analiza biznesowa krok po kroku

Model procesów biznesowych

Pierwszym krokiem powinna być jednak analiza polegająca na opracowaniu modeli procesów biznesowych. Celem tego modelowania jest wykrycie, udokumentowanie i zrozumienie każdego kontekstu wystawienia faktury, weryfikacja treści wywiadów (ludzie mają naturalne tendencje do pomijania rzeczy oczywistych i uwypuklania swojej roli w procesie) oraz upewnienia się, że znamy wszystkie sytuacje, w których wystawiana jest faktura VAT. Dlatego niezależnie od zakresu projektu warto zawsze opracować model procesów biznesowych całej organizacji.

Tu mała uwaga, model procesu to nie algorytm pracy a model obrazujący czynności i ich cele.Samo wystawianie faktur może mieć różne konteksty, może to robić więcej niż jedna osoba, a sposób w jaki to robi zależy od kompetencji tej osoby. W opisywanym przypadku mamy dwa takie konteksty. Faktura VAT za usługę wystawiana przez osobę o wysokich kwalifikacjach:

oraz faktura VAT za towar z magazynu wystawiana przez osobę nie mającą wiedzy lub uprawnień pozwalających na samodzielne wystawienie Faktury VAT – dla takiej osoby powstała dokładna procedura:

Jak widać diagramy nie są jest zbyt skomplikowane i takie powinny być. Model procesów biznesowych nie powinien zawierać w sobie wiedzy z innych obszarów takich jak : procedury, uprawnienia, umiejętności. Proces biznesowy ma ścisłą definicję (czynność lub czynności przekształcające stan wejścia w produkt procesu).  Jak widać powyżej, czynności procesu są kojarzone z procedurami (tu komentarz) i rolami (tor ma modelu procesów). W powyższych przykładach procedury jawnie umieszczono na diagramie (to jedna z możliwych konwencji). W pierwszym przypadku procedura jest trywialna, wpisałem ją tylko dla zobrazowania jej prostoty co wynika z faktu, że kierownik projektu (PM) to osoba o wysokich kompetencjach, od której wymagamy (CV, rekrutacja) wiedzy o tym jak wystawiać faktury VAT. Informacja taka powinna być w dokumentacji skojarzona z rolą PM.

Na diagramach oznaczono czynności związane z fakturowaniem jako <<przypadek użycia>> (przyjęta tu konwencja, nie jest to element notacji BPMN, w której wykonano te diagramy).

Jak widać mamy więc dwa zupełnie różne konteksty wystawiania faktur w tej firmie. Oba są istotne i było by dużym błędem tworzenie dla nich jednego uniwersalnego scenariusza.

Model przypadków użycia

Jak poradzić sobie z fakturowaniem na dwa sposoby? Błędem było by proste uznanie, że mamy dwa przypadki użycia:

Powyższe sugeruje wykonanie dwóch implementacji, zapewne z powieleniem części kodu. Pojawienie się kolejnego nowego kontekstu, to tu kolejny przypadek użycia, będzie to wymagało dopisania kolejnego kodu. Powyższy diagram to nie najlepszy pomysł. Więc jak?

Tu pojawia się rola modelu dziedziny jako elementu dokumentacji wymagań. Nazywa się to czasem “wymagania dziedzinowe” w analizie biznesowej czyli zrozumienia i udokumentowanie biznesowych aspektów narzędzia (a nim jest zamawiane oprogramowanie), na które wymagania mają zostać wyspecyfikowanie.

Moim zdaniem model przypadków użycia, jako tak zwana czarna skrzynka, nie rozwiązuje żadnego problemu poza oczywiście wyspecyfikowaniem wymagań funkcjonalnych (co jest bardzo ważne!).

Dobry projekt będzie zawierał jednak, moim zdaniem, jeden przypadek użycia ale także konteksty ról. Nieco nadmiarowy diagram przypadków użycia z kontekstami:

Powyższy diagram modeluje “pomysł” z kontekstami. Oprogramowanie ma jeden przypadek użycia (system ma być prosty i łatwy w użyciu!). Diagram przedstawia dwóch aktorów (dwie role), jeden przypadek użycia (w projektach wole osobiście pojęcie “usługa systemu”, które jest łatwiejsze w komunikacji z użytkownikiem), oraz jego dwie specjalizacje po jednej dla każdego aktora (aktor jest połączony z właściwym przypadkiem użycia związkiem użycia). Powyższy diagram byłby trudny do zrozumienia przez Zamawiającego nie znającego dobrze notacji UML, różowe elementy umieściłem nadmiarowo dla zilustrowania tego artykułu). W dokumentacji dla klienta elementów oznaczonych na różowo nie umieszczam.

Nadal jest to jednak czarna skrzynka, która nie determinuje logiki biznesowej systemu. Czy powinna? Myślę, że tak, gdyż wyznaję zasadę, że rolą developera jest implementacja a nie modelowanie logiki organizacji , której nie zna. Zostawiając developera tylko z powyższym diagramem, bardzo ryzykujemy, że wykona co prawda oprogramowanie “w stanie na dzisiaj”, ale jego rozwój, wynikający z logiki biznesowej organizacji (np. planowanego jej rozwoju) może być trudny, kosztowny a nawet czasem niemożliwy.

Model dziedziny systemu

Dlatego jednak tworzymy model dziedziny systemu, nie narzucając (tu zgadzam się z programistami) metod rozwiązywania problemów implementacji (czyli na tym etapie nie praktyki DDD a raczej model analityczny BCE).

Nie umieszczamy więc na diagramie przypadków użycia kontekstów (powyżej przypadki użycia oznaczone kolorem różowym) a tworzymy model wewnętrznej logiki zawierającej informację o tych kontekstach. Model ten powinien być tak opracowany, by możliwe było łatwe dodawanie nowych kontekstów, bo to wynika ze specyfiki biznesu. Dodatkowo elementem biznesowym jest także to, że Zamawiający na dziś oczekuje możliwości pracy z pomocą komputera i tabletu, nie wyklucza w przyszłości innych urządzeń końcowych. Wymaganie to nie powinno prowadzić do powielenia przypadków użycia, nie powinno także komplikować   elementów typowo dziedzinowych np. zarządzania kontekstami przypadku użycia.

Proponowany tu model dziedziny to kompletna logika dziedzinowa (komponent Model wzorca MVC, diagram klas w konwencji BCE/ICONIX)):

Powyższy model zawiera dwa dedykowane elementy, każdy dla konkretnego urządzenia końcowego, bez ingerencji w sam mechanizm  fakturowania (klasa WystawienieFakturyVAT). To wzorzec architektoniczny MVVM. Klasa ta (jedna dla przypadku użycia!) zawiera odpowiednie scenariusze dla każdego kontekstu (klasy skomponowane o nazwach takich jak aktorzy, tu np. wzorzec projektowy strategia). Faktury VAT  są zarządzane przez repozytorium faktur.

Model sterowania interakcją

Uzupełnieniem powyższego, diagram przypadków użycia i model dziedziny, powinien być model scenariusza realizacji przypadku użycia – diagram sekwencji (którego już tu nie prezentuję, był nie raz opisywany) oraz diagram sterowania interakcją (nie jest to diagram aktywności!):

Powyższy diagram pokazuje, kolejne ekrany (ich makiety powinna zawierać dokumentacja wymagań). Mam nadzieję, że nie powyższego szczegółowo wyjaśniać.

Na zakończenie

Powyższe to kompletne wymagania dla developera, które nie narzucają implementacji a jedynie oczekiwaną logikę tworzonego oprogramowania. Jeżeli w wymaganiach dodamy, że elementy Entities (tu “kapelusik” FakturyVAT) mają być rozdzielne, a w wypadku wątpliwości (niestety) narzucamy [[wzorzec active records]] (czasem [[wzorzec active table]]), to zabezpieczamy się przed  bardzo częstą i szkodliwą praktyką wielu developerów, polegającą na projektowaniu repozytorium w postaci jednej dużej relacyjnej bazy danych dla całego systemu i stosowaniu bardzo złożonego mapowania ORM (mapowanie obiektowo-relacyjne), które w zasadzie zabije wszystkie korzyści z obiektowej ([[paradygmat OOAD]]) hermetyzacji (utrzymanie pełnej niezależności wszystkich elementów architektury). Drugim tego efektem jest z reguły drastyczny spadek wydajności z powodu bardzo wielu skomplikowanych zapytań do bazy danych.

Tak więc, warto prowadzić analizę rzetelnie, bez nadmiaru “zwinności” i z pełnym zrozumieniem problemu. Pochopne decyzje, rozpoczynanie implementacji bez posiadania projektu całości, to najczęstsze przyczyny nieudanych projektów, projektów trwających i kosztujących znacznie więcej niż planowano…

Bo najważniejsi w analizie, Panie, są Aktorzy…

Krótki wpis po pewnej nie długiej dyskusji na pewnym forum.  Jeden z dyskutantów przytoczył definicję zakresu projektu publikowaną w WIKI:

Zakres projektu jest to możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu.

Zakres nigdy nie określa konkretnych zadań mających na celu realizację projektu. Odpowiada na pytanie, co powinno być zrobione w projekcie. Wyznacza ramy do oszacowania kosztu projektu i czasu realizacji projektu. Zakres, koszt i czas tworzą parametry projektu, tzw. ?magiczny trójkąt?. (Zakres projektu ? Wikipedia, wolna encyklopedia).

Tak więc mamy pytanie: “co powinno być zrobione w projekcie”? Pytanie jakie ja postawiłem: “czyim projekcie”? Zakres projektu dla kogo?

Księgowa

Zacznijmy od początku, pewna Księgowa chcę nowe oprogramowanie, z jej perspektywy padną następujące oczekiwania:

1. wystawianie faktur sprzedaży (w załączeniu wzory faktur)
2. rejestracja zamówień klientów (w załączeniu przykłady zamówień)
3. oprogramowanie ma działać bezawaryjnie (dopuszczamy przerwy trwające do godziny czasu ale nie częściej niż raz w tygodniu)
4. wystawione faktury mają być eksportowane do biura księgowego.
5. z oprogramowania korzysta wyłącznie księgowa

Od księgowej więcej bym nie oczekiwał bo ta osoba ma za zadanie opisać tylko to czego potrzebuje do pracy. Tak zwany biznes zawsze opisze potrzebne mu narzędzie ze swojej perspektywy, podobnie jak moja mama, gdy poprosiła mnie o pomoc przy kupnie nowego telewizora: ma się nadawać do odbioru kablówki, mieć HD i mieścić w regale pod książkami. Więcej nie trzeba. To ja pilnowałem by ambitny sprzedawca nie wcisnął, nie znającej się na tej technologii emerytce, wypasionego TV na raty o przekątnej wymagającej osobnego salonu.

Wracamy do księgowej

Mamy zakres projektu, przypomnę definicję: możliwie jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu. Opis księgowej spełnia te kryteria. Ale mam problem z resztą definicji z WIKI:  zakres określa “co powinno być zrobione w projekcie”. I tu WIKI w moich oczach niestety przemilcza ważny fakt: o jaki projekt chodzi, co jest tym projektem, dla kogo jest to zakres projektu?

Na pytanie “co powinno być zrobione w projekcie” odpowie dopiero projektant.

Komu księgowa postawiła zadanie? Na pewno nie programistom bo tu nie ma nic do kodowania… Przedstawiony powyżej zakres, to zakres dla Analityka biznesowego projektanta. Ktoś musi zamienić opis funkcjonalności nowego narzędzia (oprogramowanie dla Księgowej) na jego projekt (pamiętamy poprzedni artykuł o młotku). Księgowa opisała wymagania swoje funkcjonalne i poza-funkcjonalne (ograniczenia jakościowe).

Pominąłem tu ich spójność i kompletność. Jeżeli zachodzi ryzyko, że są niekompletne warto je opracować skuteczniejszą metodą niż “lista z pamięci” czy efekt “burzy mózgów“, ale to inny temat ;). Ważne jest to, by te wymagania były jednoznaczne,  nie nadmiarowe, spójne. Jak to osiągnąć?

Model wymagań czyli schemat blokowy

Poniżej diagram obrazujący dokładnie to co opisała Księgowa:

Po co ten obrazek, skoro Księgowa to napisała, przecież to to samo tylko w postaci obrazka. Tak to to samo, problem w tym, że gdyby ten opis był tekstem np. na 100 stron, niemalże niemożliwe było by wychwycenie niespójności i powtórzeń. Powyższy diagram pozwala sprawdzić, czy mamy właściwie skojarzonych użytkowników z tym jakie czynności będą wykonywali, czy nie ma zdublowanych funkcjonalniej (jajeczka) i nakładających się ról (ludzik, tak zwany Aktor systemu). Najważniejszy jest tu prostokąt o nazwie Nowy Fajny System dla Księgowej, bo on pokazuje Zakres projektu. Teraz wiemy, że wykonawcę nie interesuje Biuro Księgowe, interesuje go tylko “jakie pytanie ma obsłużyć”.

Jeżeli padnie pytanie o szczegóły tych funkcjonalności, należy je jednoznacznie przyporządkować albo do Aktora albo do Systemu. Np. jak padnie pytanie o to, jak się nalicza podatek VAT, powinno paść dodatkowe pytanie: kto ten podatek ma naliczać, Aktor czy System (podział odpowiedzialności, zakres projektu). Uporządkowanie tego da nam jasny zakres projektu. Mając dobre narzędzie, można z takiego diagramu bez problemu wykonać oczekiwany tekstowy raport specyfikujący wymagania na system i wszelkie ograniczenia  jakimi są umiejętności aktorów i wymagania jakościowe (tak zwane poza-funkcjonalne).

Gdyby tych wymagań było nie kilka a kilkadziesiąt, bez takiego modelu bardzo trudne było opracowanie takiej specyfikacji bez ryzyka niespójności i braków oraz zagwarantowanie, że zakres projektu jest jednoznaczny i dobrze przemyślany. Po drugie jeden taki diagram zastępuje kilka, kilkanaście stron tekstu, a z czym łatwiej się nam będzie szybko zapoznać?

Duża liczbę wymagań, dla czytelności diagramów i uporządkowania wymagań, dzieli się na kilka takich diagramów np. kontekstowo, tak by na jednym diagramie nie było więcej niż kilkanaście obiektów.  Czy ten diagram, po powyższym komentarzu  jest niezrozumiały? Właśnie Państwo poznali Diagram Przypadków Użycia z notacji UML.

Można spotkać te diagramy poszerzone o mało zrozumiałe dla laika pojęcia <<extend>>, <<include>> i inne, jednak moim zdaniem to niepotrzebnie je komplikuje i czyni niezrozumiałymi dla Zamawiającego, a to Zamawiający określa wymagania i diagram ten nie powinien u Zamawiającego budzić żadnych wątpliwości (powinien się pod nim bez strachu podpisać). Jeżeli więc Państwu jako Zamawiającemu, ktoś da do podpisu dokumentację, której nie rozumiecie w 100%, to po prostu nie podpisujcie się pod nią, bo to zła dokumentacja skoro jej nie rozumiecie, a powstała dla Was bo macie ją podpisać.

Na tym byśmy poprzestali gdyby celem był zakup gotowego oprogramowania. A jak nie, jeżeli z jakiegoś powodu musimy mieć dedykowane?

Co dalej?

Diagram ten w 100% opisuje zakres projektu z perspektywy Zamawiającego, ale jest zupełnie bezwartościowy dla programisty (kodera). Bo zakres projektu, opis, musi mieć adresata. Zakres projektu owszem ale dla kogo?

Szybki przegląd od końca: zakres projektu dla programisty (przypomnę definicję) jak najdokładniejsze i całkowite określenie oczekiwanego wyniku projektu, to opis kodu jaki ma programista wytworzyć. Czy diagram Przypadków mu to powie? Absolutnie nie!

Zakres projektu dla programisty stworzy Architekt systemu, kluczowa rola w każdej dobrej firmie programistycznej. Co jest zakresem projektu dla Architekta systemu? Architekt oczekuje opisu tego jaką logikę ma realizować oprogramowanie, jakimi danymi i jak ma zarządzać System. Kto to ma zrobić?

Analityk biznesowy

Powyższy diagram przypadków użycia, to pierwszy etap pracy, ktoś – znowu Analityk biznesowy bo poznał i zrozumiał biznes Zamawiającego na etapie opisu wymagań biznesowych, musi teraz powyższe zamienić na, najlepiej obiektowy, model (dokumentację) całej logiki biznesowej (dane i metody ich przetwarzania) jaka ma być zaimplementowana: tak zwany model dziedziny systemu.

Zakładam, że użyte zostaną obiektowe metody i narzędzia implementacji. Obiektowe metody analizy zdobyły sobie uznanie bo dają jednoznaczne opisy, to teraz w zasadzie standard w oprogramowaniu dla biznesu.

Zakres projektu dla Architekta

Tu pojawią się więc: klasy, sekwencje, statusy klas, algorytmy metod. To jest zakres projektu dla architekta, który “wpakuje” to np. w strukturę  używanego frameworka i stworzy zakres projektu dla programistów.

Na zakończenie

W moich oczach nie ma nic bardziej ryzykownego niż przekazanie Opisu Księgowej od razu programistom do wykonania. Bo mamy tak na prawdę trzy zakresy projektu, każdy inny, każdy ma innego adresata i każdy należy udokumentować inaczej, ale zawsze jednoznacznie postawić zadanie.

Praca bez tego typu dokumentów, bez jasnego wydzielenia poszczególnych etapów analizy, tak często praktykowana przez wiele firm IT, to atak na twierdzę bez mapy terenu i strategii…

P.S.

Wpadł mi dziś ręce artykuł: Sygnity wykona system e Podatki. Powiem tylko tyle: system za 232 mln. wyceniono na podstawie opisu (OPZ) mającego 23 strony: http://www.mf.gov.pl/_files_/ministerstwo/przetargi/si…, jestem pod wrażeniem metod wyceny. Każdy inny projekt inżynierski wart 232 mln. miałby pewnie pół kontenera dokumentacji przetargowej, a tu proszę 23 strony…