Tym razem książki czyli co się dzieje na świecie. Książki z "całego świata" na mojej półce mają dwa zadania. Pierwsze to dowiedzieć się co i jak robią inni. Drugie to:…
Taksonomia diagramów UML Ten artykuł to kontynuacja wątku rozpoczętego wpisem o modelu dziedziny i diagramie klas, jednak inna jest intencja. Wśród wielu listów i pytań od studentów i pracujących już analityków,…
Do napisania tego artykułu “zmusiła” mnie kolejna przygoda z korepetycjami, w której tym razem dostałem od studenta pełną treść zadania wraz ze wskazówkami. Nie będę pisał o jaką uczelnię chodzi i kim jest tenże wykładowca bo nie jest moim celem krytyka osoby czy uczelni. To co pisze, wydaje mi się, jest zjawiskiem powszechnym (w miarę czasu jakim dysponuje, udzielam często korepetycji studentom różnych uczelni). […] to tylko przykład “zadania dla studenta”, takich “zadań” i ich zaliczeń znam multum. Ktoś tak “wykształcony” pojawia się na rynku pracy i ma pretensje, że ma kłopoty ze znalezieniem pracy albo na podstawie dyplomu prestiżowej uczelni zostaje zatrudniony, i sieje spustoszenie w projektach nie raz ogromnej wartości. Jest nie raz gorzej, bo buduje stereotyp “nieprzydatnej i kosztownej pracy analityka”. Powyższy przykład to praca wykładowcy na prestiżowej w naszym kraju uczelni na kierunku Analiza Biznesowa.
Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w “oryginale” Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na “polecenia”. Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia.
Generalnie diagram PU jest bardzo dobrym “korzeniem” do analizy i tworzenia pozostałych modeli, ale bez powstającego “natychmiast” modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów.
Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na “strawne” kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje.
Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek….
Niedawno mój serdeczny kolega napisał: Samo zebranie wymagań to ważny etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? [...] Nie mamy w Polsce…
Tym razem krótki wpis po pewnym spotkaniu projektowym, dla tworzących i czytających diagramy: Semiotyka, ogólna teoria znaku związana z logiką i lingwistyką. Jej współczesna postać pochodzi od Ch. Morrisa, który…
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.
Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy. Faktycznie, czytelnicy mają wiele racji, jest on dość “bliski implementacji”. Niejednokrotnie “lepszym pomysłem” jest opis logiki systemu na nieco wyższym poziomie abstrakcji pozostawiając tym samym więcej swobody developerowi. […] Nieco inne podejście, to które stosuję obecnie, opisuję poniżej. Zachowując podstawowe znaczenia tych trzech klas, dostosowałem je do wzorca MVVC. Jest to o tyle wygodne i ważne, że stosowanie wzorca BCE wyłącznie do modelowania logiki biznesowej wymaga zachowania hermetyzacji komponentu Model. W takim układzie boundary nie będzie elementem komponentu View a Modelu. Jego rola to stworzenie dedykowanego interfejsu do model np. pomiędzy komponentem View lub Controlerem. Dzięki temu możliwe jest stworzenie odrębnego interfejsu dla View na duży ekran i odrębnego dla View na np. małych ekranach smartfonów. Tak więc jest moim zdaniem droga do modelowania wymagań metodą “tak to ma działać” a nie tylko “tak to ma wyglądać”, bo to drugie jest przyczyną wielu problemów…
