Architektura zorientowana na mikroserwisy i sterowanie zdarzeniami

Recenzja książki Jest to jedna z ciekawszych pozycji na mojej półce a tym wpisem mam nadzieję zachęcę do jej nabycia projektantów systemów. Tym bardziej migracja z monolitycznej do bardziej otwartej i zwinnej architektury, odbywa się powoli, i na początek raczej w głowach projektantów, później dopiero w projektach i wdrożeniach. Kluczową wadą monolitów jest ich ociężałość, skutkująca tym, że ich rozwój i rozbudowa bardzo szybko zmienia się w walkę w ich wielkością. Powodem tego jest silna wewnętrzna "zależność wszystkiego od wszystkiego". Pewnym postępem jest wewnętrzne "upilnowanie" dziedzinowej separacji modułów, jednak separacja…

Czytaj dalejArchitektura zorientowana na mikroserwisy i sterowanie zdarzeniami

Ontologia c.d. czyli po co

Ontologia jako narzędzie tworzenia "modeli świata", jest bardzo dobrym narzędziem do projektowania danych, zorganizowanych w łatwe do zarządzania w bazach NoSQL, dokumenty. Wstęp Niedawno napisałem: Czy opra­co­wa­nie onto­lo­gii jest łatwe? Nie, nie jest. Czy zła onto­lo­gia szko­dzi? Tak, potra­fi dopro­wa­dzić do fia­ska pro­jek­tu infor­ma­tycz­ne­go.źr.;: Ontologia czyli jak się to robi Po co to wszystko? Obecnie często mówimy o Big Data, czyli o masowo gromadzonych danych. Ich gromadzenie wymaga opracowania struktury ich gromadzenia i zarządzania nimi, bez tego powstanie "stos nieskatalogowanych dokumentów". Proces gromadzenia danych jest stratny, więc dane te można…

Czytaj dalejOntologia c.d. czyli po co

Marsz ku klęsce – Poradnik dla projektanta systemów

Lektura na Nowy Rok... Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem.. Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę... i to trwało do tego momentu. To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów,…

Czytaj dalejMarsz ku klęsce – Poradnik dla projektanta systemów

Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

(wię­cej…)

Czytaj dalejOpis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

(wię­cej…)

Czytaj dalejDiagram aktywności UML – kiedy

Przyczyny nieplanowanych kosztów wdrożeń

Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy . Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a…

Czytaj dalejPrzyczyny nieplanowanych kosztów wdrożeń

Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Od cza­su do cza­su wpa­da­ją mi do skrzyn­ki ema­il niu­slet­te­ry”, któ­re gdzieś tam cza­sem zama­wiam, głów­nie z powo­dów poznaw­czych. Oto jeden z nich…

Nie jest tajem­ni­cą, że na ryn­ku mamy róż­ne meto­dy pra­cy i wszyst­kie mają swo­ich zwo­len­ni­ków i prze­ciw­ni­ków czy może raczej kry­ty­ków. Tym razem przed­mio­tem bada­nia” był spo­sób opi­sa­nia pro­ble­mu i wnio­ski jakie autor wyciągnął.

(wię­cej…)

Czytaj dalejMało który deweloper używa UMLa zgodnie ze specyfikacją…

Zwinne projektowanie interfejsu użytkownika

W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ:  ...analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1] Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są:  Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa…

Czytaj dalejZwinne projektowanie interfejsu użytkownika

Wymagania ? Zarządzanie wersjami

Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania. Stosowane są trzy metody (grupy metod) specyfikowania wymagań: Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody). Specyfikowanie tak zwanej "czarnej skrzynki" (przypadki użycia). Specyfikowanie tak zwanej "białe skrzynki" (przypadki użycia + model dziedziny systemu). Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i…

Czytaj dalejWymagania ? Zarządzanie wersjami

Granice kontekstu i mikroserwisy

Nie raz już pisałem tu o architekturze (Architektura systemu) tym razem kilka słów o tym. Często jestem pytany o kryterium podziału dużego systemu na komponenty. Jednym z nich jest praktyka dążenia do minimalizacji złożoności interfejsów między komponentami jako konsekwencja dziedzinowego kryterium podziału . Złą praktyką jest natomiast dążenie do usuwania redundancji. Stosuje takie - komponentowe dziedzinowe - podejście, w różnej formie,  z powodzeniem od lat. Można je spotkać w różnych formach w literaturze, pierwszy raz spotkałem się z nim w 1999 roku. Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal…

Czytaj dalejGranice kontekstu i mikroserwisy

Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów "mitycznym wodospadem" jak kiedyś dzieci straszone były Babą Jagą. [dzień po napisaniu: po dyskusji - patrz treść pod tym wpisem - a autorem cytowanego tu artykułu, doszliśmy do wniosku, że nie różnimy się zbytnio w poglądach, jednak zbytnie uproszczenie treści miało  prawo wprowadzić mnie w błąd, jednak mój artykuł pozostanie w pierwotnej treści bo polemizuje głównie z pewnym mitem a…

Czytaj dalejDlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Koniec treści

Nie ma więcej stron do załadowania