Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Wprowadzenie

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

(wię­cej…)

Czytaj dalejArchitektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Obiektowy model systemu

Wprowadzenie Na temat tak zwanych metod obiektowych często można spotkać teksty takie jak ten z wikipedii: Programowanie obiektowe (ang. object-oriented programming, OOP) ? paradygmat programowania, w którym programy definiuje się za pomocą obiektów ? elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i…

Czytaj dalejObiektowy model systemu

Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Regularnie obserwuję pewną trudność jaką sprawia wielu ludziom, z jednej strony stosowanie systemów notacyjnych a z drugiej samo modelowanie. Wspólną częścią obu tych obszarów jest abstrahowanie od szczegółów. Praktycznie każdy mój klient i bardzo często, analitycy i projektanci developerów realizujących projekty które nadzoruję, zadają mi pytania: a gdzie zobaczę to, że zamówienie może być dla innego produktu i innego segmentu..... itp.  Innymi słowy: na dowolnym etapie pracy padają pytania o bardzo detaliczne szczegóły konkretnych operacji. Co prawda, jak to mawiają "diabeł tkwi w szczegółach", z czym wypada się zgodzić, ale…

Czytaj dalejAnaliza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Kolejna wpadka IT: obiektowość

obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).

Czytaj dalejKolejna wpadka IT: obiektowość

Demo System Szachownica

Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści. Kliknij i pobierz aktualny plik projektu Wszelkie pytania i sugestie na temat treści projektu…

Czytaj dalejDemo System Szachownica
Read more about the article System Analysis And Design with UML 2.0
System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

System Analysis And Design with UML 2.0

Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.

Czytaj dalejSystem Analysis And Design with UML 2.0

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

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...

Czytaj dalejWzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Kim więc jest dobry analityk?

Skoro logikę biznesową "programuje się" (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem było by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich "klocki", na które należy, na etapie analizy biznesowej, rozłożyć problem. To się np. nazywa DDD czyli siedem wzorców spośród wielu. Korzyści są ogromne, bo "wycinamy" etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem, który ma zrobić obiektowy model czegoś czego tak na prawdę nie rozumie, a opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Czytaj dalejKim więc jest dobry analityk?

Business Model vs. System Model

Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest "w systemie" a co w "rzeczywistości" (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika). Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules): To make a long story short, business models talk directly about real-world things (as business people do);…

Czytaj dalejBusiness Model vs. System Model

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty "na żywioł". Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany "maintenance") niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.

Czytaj dalejZnaczenie ma nie wielkość projektu, a cykl jego życia…

Ach ten wstrętny, wścibski analityk

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat. Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy... tak jak to napisano na początku. Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

Czytaj dalejAch ten wstrętny, wścibski analityk

Czego moglibyśmy się nauczyć od naukowców?

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu... Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta...

Czytaj dalejCzego moglibyśmy się nauczyć od naukowców?

Koniec treści

Nie ma więcej stron do załadowania