Ten arty­kuł jest adre­so­wa­ny do wszyst­kich. Biznes (praw­ni­cy tak­że) może prze­ko­nać się, że opro­gra­mo­wa­nie moż­na nary­so­wać i zro­zu­mieć. Analitycy i pro­gra­mi­ści, że to moż­li­we, a dewe­lo­pe­rzy, że nikt im nie odbie­ra pra­cy a raczej pomaga. 

Wprowadzenie

W dzi­siej­szym świe­cie inży­nie­rii naj­więk­szą war­tość mają czas i zaso­by. Czas to jak naj­szyb­sze odda­nie roz­wią­za­nia (pro­duk­tu) do użyt­ku (szyb­ka komer­cja­li­za­cja), zaso­by to koszt jakim się to odbę­dzie. Kluczem są kosz­ty: ​„time to mar­ket”, tu kosz­tem jest opóź­nie­nie komer­cja­li­za­cji (nie­zre­ali­zo­wa­ne przy­cho­dy), kosz­tem jest tak­że samo powsta­wa­nia opro­gra­mo­wa­nia. Praktycznie od począt­ku inży­nie­rii opro­gra­mo­wa­nia zależ­ność kosz­tów od dys­cy­pli­ny i eta­pu pra­cy się nie zmie­nia, wyglą­da to jak poniżej:

Od same­go począt­ku prac nad opro­gra­mo­wa­niem tak napraw­dę roz­wią­zu­je­my pro­ble­my: począw­szy od pro­ble­mów z odkry­ciem co tak napraw­dę jest roz­wią­za­niem pro­ble­mu (a pro­blem trze­ba naj­pierw ziden­ty­fi­ko­wać), przez pro­ble­my zwią­za­ne z wła­ści­wym zapro­jek­to­wa­niem roz­wią­za­nia (algo­ryt­my, archi­tek­tu­ra kodu), do pro­ble­mów wybo­ru tech­no­lo­gii i imple­men­ta­cji. Patrząc od koń­ca: pomył­ki są bar­dzo kosz­tow­ne dla orga­ni­za­cji (spon­sor pro­jek­tu). Development (kodo­wa­nie i testy) to pra­ca zespo­łów ludzi, są bar­dzo kosz­tow­ne. Najtańsza jest tu pra­ca (etap) ana­li­ty­ka-pro­jek­tan­ta, to jed­nak tak­że czas (pamię­ta­my ​„time to market”). 

Tak więc ​„water­fall” nie wcho­dzi w grę. Praktyka jed­nak poka­zu­je, że roz­po­czę­cie od razu od kodo­wa­nia nie roz­wią­zu­je żad­ne­go pro­ble­mu bo złe pomy­sły są i będą, kory­go­wa­ne dopie­ro na eta­pie kodo­wa­nia gene­ru­ją bar­dzo duże kosz­ty. Lekarstwem jest odej­ście o mono­li­tycz­nej archi­tek­tu­ry na rzecz samo­dziel­nych kom­po­nen­tów, czy wręcz mikro­ser­wi­sów (jed­nost­ki imple­men­ta­cji to poje­dyn­cze przy­pad­ki uży­cia UML, tu rozu­mia­ne jako nie­za­leż­ne mikro-apli­ka­cje ). Dlatego opty­mal­ne wyda­je sie podej­ście: 1. ana­li­za, 2. pro­jek­to­wa­nie HLD: kom­po­nen­ty, 3. ite­ra­cyj­ne pro­jek­to­wa­nie LLD kom­po­nen­tów i ich deve­lop­ment. Osiągamy waż­ną rzecz: naj­droż­sze zaso­by: deve­lop­ment, dosta­ją do imple­men­ta­cji prze­my­śla­ne roz­wią­za­nie, nie tra­ci­my cza­su i środ­ków na kolej­ne pro­to­ty­py w kodzie. 

MDA czyli cykl życia aplikacji

Ponad 10 lat temu orga­ni­za­cja Object Management Group opu­bli­ko­wa­nia spe­cy­fi­ka­cje MDA (Model Driven Architecture, archi­tek­tu­ra zorien­to­wa­na na mode­le ). Opisuje ona pro­ces od ana­li­zy, przez mode­le roz­wią­za­nia, aż do jego imple­men­ta­cji. Proces ten wyglą­da tak:

Czy to jest water­fall (tech­ni­ka wodo­spa­do­wa)? To zale­ży od zapro­jek­to­wa­nej archi­tek­tu­ry opro­gra­mo­wa­nia. Jeżeli będzie to funk­cyj­ny mono­lit budo­wa­ny na cen­tral­nej rela­cyj­nej, bazie danych (RDBMS) to będzie to water­fall. Jeżeli jed­nak będzie to kom­po­nen­to­wa archi­tek­tu­ra zorien­to­wa­na na micro apli­ka­cje (micro ser­wi­sy), będzie to zwin­na, ite­ra­cyj­no-przy­ro­sto­wa, imple­men­ta­cja i roz­wój, gdyż na pod­sta­wie mode­lu PIM (tak­że poli­ty­ka podzia­łu na kom­po­nen­ty i usłu­gi) wyko­ny­wa­ne są przy­ro­sto­wo i nie­za­leż­nie od sie­bie, kolej­ne imple­men­ta­cje usług apli­ka­cji (PSM->Code). Tak więc wszyst­ko roz­strzy­ga się na pozio­mie mode­li PIM. PIM (Platform Independent Model) to pro­jekt opro­gra­mo­wa­nia nie­za­leż­ny od tech­no­lo­gii (czy­li tak­że od uży­te­go języ­ka programowania). 

Mikro-serwisy

O mikro-apli­ka­cjach pisa­łem nie raz, tu tyl­ko przypomnienie:

Tak więc wszyst­ko zale­ży od archi­tek­tu­ry, zwin­ność tak­że. Po pra­wej stro­nie (dia­gram powy­żej) poka­za­no ideę podzia­łu apli­ka­cji na nie­za­leż­ne kom­po­nen­ty, każ­dy z wła­snym repo­zy­to­rium (bazą danych). Komponenty te moż­na deve­lo­po­wać i odda­wać do użyt­ku w dowol­nej kolej­no­ści .

Program to abstrakcja rozwiązania, określony kod to jedna z wielu możliwych implementacji

Złożoność sys­te­mów rośnie z każ­dym rokiem. Oprogramowanie (kom­pu­te­ry) jest czę­ścią coraz więk­szej ich licz­by. Development jest naj­kosz­tow­niej­szą fazą wytwa­rza­nia opro­gra­mow­nia, dla­te­go coraz zno­wu czę­ściej poprze­dza się go pro­jek­to­wa­niem czy­li ​„two­rze­niem pro­gra­mu jako logi­ki” . Nie da się ​„z mar­szu” napi­sać tysię­cy linii kodu, nie popeł­nia­jąc błę­dów w kodzie czy na pozio­mie samej archi­tek­tu­ry i logi­ki działania.

Tworzenie sys­te­mów zawie­ra­ją­cych opro­gra­mo­wa­nie obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­ra nie może być wypeł­nio­na przez zwy­kłe meto­dy pro­gra­mo­wa­nia, ale któ­ra może być wypeł­nio­na, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy modelowania.

Program kom­pu­te­ro­wy może zostać wyra­żo­ny z pomo­cą kodu, ale tak­że, w spo­sób rów­no­praw­ny, ​„z pomo­cą sche­ma­tów blo­ko­wych, algo­ryt­mów i wzo­rów mate­ma­tycz­nych” (http://​www​.ipblog​.pl/​2​0​1​7​/​0​3​/​p​r​o​g​r​a​m​y​-​k​o​m​p​u​t​e​r​o​w​e​-​c​o​-​p​o​d​l​e​g​a​-​o​c​h​r​o​n​ie/). Zgodnie z powyż­szym i z MDA mamy:

Przykład czyli programujemy obrazkowo

Zakres projektu

Opracujemy pro­gram wspie­ra­ją­cy pro­ces obsłu­gi klien­tów przy­chod­ni wete­ry­na­ryj­nej. Wygląda on tak:

Jak widać nie jest spe­cjal­nie wyra­fi­no­wa­ny: Jeżeli potrzeb­na jest wizy­ta ze swo­im pupi­lem u wete­ry­na­rza, uma­wia­my ter­min, przy­cho­dzi­my na wizy­tę, opusz­cza­my przy­chod­nie z recep­tą i zale­ce­nia­mi. Faza ana­li­zy i opra­co­wa­nia archi­tek­tu­ry zosta­ła opi­sa­na w arty­ku­le Projekt apli­ka­cji. Tu sku­pi­my się na ​„pro­gra­mo­wa­niu”.

Od kil­ku już dekad w pod­ręcz­ni­kach inży­nie­rii opro­gra­mo­wa­nia nadal moż­na spo­tkać sentencję: 

algo­ryt­my + struk­tu­ry danych = programy 

Poza tech­no­lo­gią i para­dyg­ma­ta­mi, nic sie nie zmie­ni­ło. To zna­czy, że bez wzglę­du na archi­tek­tu­rę, para­dyg­mat i język pro­gra­mo­wa­nia, «pro­gra­my» to «algo­ryt­my + struk­tu­ry danych». Innymi sło­wy: pro­gra­mo­wa­nie to pro­jek­to­wa­nie algo­ryt­mów i struk­tur danych, dalej jest już tyl­ko imple­men­ta­cja (kodo­wa­nie) tych programów. 

Każdy ​„pro­gram” to dekla­ra­cja zmien­nych + dzia­ła­nia na nich. Może to być poprze­dzo­ne pobra­niem tych danych i zakoń­czo­ne zwró­ce­niem danych (para­me­trów). Można to (frag­ment pro­gra­mu pre­zen­to­wa­na jako ​„czyn­ność” w UML) wyra­zić pseudokodem:

Lub w for­mie bar­dziej przy­stęp­nej dla laika, ​„obraz­ko­wej”:

Od począt­ków ​„czło­wie­czej biu­ro­kra­cji” stan­dar­do­wą for­mą prze­cho­wy­wa­nia danych są for­mu­la­rze, czy sze­rzej rzecz ujmu­jąc, doku­men­ty. W roku 1972 Codd opu­bli­ko­wał swo­ja pra­cę, w któ­rej opi­sał rela­cyj­ny model danych, jed­nak celem było zarzą­dza­nie zbio­ra­mi danych a nie ​„infor­ma­cją” . Powstało wie­le imple­men­ta­cji tego mode­lu i nie­ste­ty model ten zdo­mi­no­wał bran­że. W cza­sie gdy powsta­wał liczy­ła się opty­ma­li­za­cja tych zbio­rów od stro­ny obję­to­ści (to był głów­ny czyn­nik kosz­to­wy). Jednak po latach oka­za­ło się, że:

Relacyjny model danych jest nie­ela­stycz­ny. Cechuje się pre­cy­zyj­nie zde­fi­nio­wa­ną struk­tu­rą danych, któ­ra jed­nak bar­dzo ją ogra­ni­cza. Musimy zde­fi­nio­wać sta­łą struk­tu­rę jak kolum­ny i wier­sze tabel oraz okre­ślić ich rela­cje, co jest póź­niej trud­ne do zmia­ny. Ponadto, jeśli dzie­dzi­na poję­cio­wa jest głę­bo­ko zagnież­dżo­na, uży­cie mode­lu rela­cyj­ne­go dla niej będzie wyma­ga­ło wie­lu tabel i złą­czeń. Relacyjne bazy danych mają sła­bą ska­lo­wal­ność pozio­mą. Mogą być ska­lo­wa­ne w pio­nie poprzez doda­nie więk­szej ilo­ści zaso­bów, takich jak pro­ce­sor i pamięć RAM. Ale nie mogą być ska­lo­wa­ne pozio­mo, tzn. łączyć wie­lu maszyn i two­rzyć kla­strów. Wynika to z wyma­gań doty­czą­cych spój­no­ści. Baza danych zorien­to­wa­na na doku­men­ty roz­wią­zu­je nie­któ­re z tych pro­ble­mów, z któ­ry­mi bory­ka się baza danych w mode­lu relacyjnym.

Główną wadą rela­cyj­ne­go mode­lu danych w sys­te­mach biz­ne­so­wych jest zapi­sy­wa­nie danych w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, co powo­du­je, że dane są pozba­wio­ne kon­tek­stu , a w kon­se­kwen­cji model ten nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi i ich treścią. 

Dokumenty biz­ne­so­we (dowo­dy księ­go­we ale tak­że umo­wy, ofer­ty i wie­le innych) to zło­żo­ne agre­ga­ty danych, więc zapy­ta­nia SQL do tabel rela­cyj­nych (do ich zapi­su i odczy­tu) to bar­dzo zło­żo­ne struk­tu­ry kodu, powo­du­ją­ce że tak zor­ga­ni­zo­wa­ne bazy szyb­ko sta­ją się nie­wy­daj­ne (zaso­by takie jak pro­ce­sor i RAM są ogra­ni­czo­ne a ska­lo­wa­nie pozio­mie RDBMS jest nie­moż­li­we). Dodatkowo doku­ment, w sen­sie fizycz­nym nie może być gene­ro­wa­ną dyna­micz­nie struk­tu­rą (zapy­ta­nia SQL do bazy rela­cyj­nej), bo jest wte­dy tyl­ko wir­tu­al­nym chwi­lo­wym bytem, nie sta­no­wi tak­że doku­men­tu w sen­sie praw­nym (Kodeks Cywilny), nie da się też zarzą­dzać jego cyklem życia. 

To powo­du­je, że od 20 lat mamy moż­li­wość korzy­sta­nia z baz zorien­to­wa­nych na doku­men­ty (bazy NoSQL). Struktury danych bar­dzo łatwo i efek­tyw­nie moż­na pro­jek­to­wać od razu jako szkie­le­ty doku­men­tów: agre­ga­ty :

Powyższy dia­gram to kla­sycz­ny agre­gat, któ­ry z innej per­spek­ty­wy wyglą­da tak:

Powyższe łatwo zapi­sać jako jed­na struk­tu­rę XML (lub JSON) i zacho­wać jako war­tość jed­ne­go atry­bu­tu obiek­tu . Każdy ele­ment tego agre­ga­tu (atry­but) ma adre­so­wal­ną uni­kal­ną postać, np. data pla­no­wa­nej wizyty: 

Karta Wizyty.data := 22-10-02
Karta Wizyty.Rezerwacja.data := 22-10-16

Gdzie nazwa doku­men­tu jest począt­kiem ścież­ki (nazwy doku­men­tów-agre­ga­tów muszą być uni­kal­ne). Dzięki temu atry­bu­ty, jako typy danych, defi­nio­wa­ne są raz (np. tu data), zaś kon­tekst nada­je im poło­że­nie w struk­tu­rze doku­men­tu. Powyższy przy­kład to dwie róż­ne daty: data doko­na­nia rezer­wa­cji (data zało­że­nia Karty wizy­ty) i data samej wizy­ty. Tu 2 paź­dzier­ni­ka umó­wio­no sie na wizy­tę w dniu 16 paź­dzier­ni­ka. Ale typ «data» defi­niu­je­my raz, nie musi­my defi­nio­wać tylu dat ile jest ich rodza­jów (data_rezerwacji, data_wizyty, itp…)

Tą meto­dą jed­nym pro­stym kro­kiem pobie­ra­my dane z takie­go agre­ga­tu , następ­nie opi­su­je­my jakie ope­ra­cje mają zostać na nich wyko­na­ne, wynik zwra­ca­my jako ten sam agre­gat (wyli­czo­no war­to­ści pustych atry­bu­tów, zwra­ca­my wypeł­nio­ne) lub inny agre­gat (wynik wyli­czeń to nowy formularz/agregat) i może­my go np. prze­ka­zać inne­mu kom­po­nen­to­wy do utrwa­le­nia, lub zwró­cić jako wynik do poka­za­nie na ekra­nie (patrz tak­że star­szą for­mę wzor­ca enve­lo­pe: DTO).

Przykładowy opis two­rze­nia nowej kar­ty wizyty:

Tak więc zapro­jek­to­wa­nie apli­ka­cji, prze­te­sto­wa­nie spój­no­ści i kom­plet­no­ści logi­ki jej dzia­ła­nia, przed kodo­wa­niem jest nie tyl­ko moż­li­we ale i pożą­da­ne, pomi­jam, że odby­wa sie znacz­nie mniej­szym kosz­tem i szyb­ciej (prak­ty­ka poka­zu­je, że powyż­sze na dia­gra­mach jest o ponad rząd wiel­ko­ści szyb­sze i tań­sze niż pra­ca od razu na kodzie).

Podsumowanie

Od począt­ku inży­nie­rii opro­gra­mo­wa­nia wia­do­mo, że pro­gra­mo­wa­nie to nie koniecz­nie kodo­wa­nie. Już na stu­diach naj­pierw ​„ryso­wa­łem” opro­gra­mo­wa­nie a potem dopie­ro kodo­wa­łem to np. w Fortranie. Powód zawsze był ten sam: pra­ce kon­cep­cyj­ne są wie­lo­krot­nie tań­sze na sche­ma­tach blo­ko­wych niż na żywej maszy­nie. Ten sam pro­gram moż­na było zawsze uru­cho­mić na róż­nych kom­pu­te­rach, koniecz­ny był jedy­nie wybór wła­ści­we­go języ­ka dla danej maszy­ny. Owszem, moż­na ​„od razu w kodzie”, jest to jed­nak naj­bar­dziej nie­efek­tyw­na meto­da two­rze­nia opro­gra­mo­wa­nia. Wbrew potocz­ne­mu postrze­ga­niu mani­fe­stu agi­le, opi­sa­ne tu sche­ma­ty blo­ko­we to nie jest ​„nad­mia­ro­wa doku­men­ta­cja” a ​„isto­ta dzia­ła­nia sys­te­mu”. Po dru­gie ani urząd paten­to­wy w USA, ani euro­pej­ski sąd w spra­wie ochro­ny know-how, nie będzie ana­li­zo­wał kodu źró­dło­we­go tyl­ko jego sfor­ma­li­zo­wa­ny opis. 

Jak defi­niu­je­my role? 

CZYM ZAJMUJE SIĘ INŻYNIER OPROGRAMOWANIA?
Inżynierowie opro­gra­mo­wa­nia oce­nia­ją potrze­by klien­ta lub fir­my w połą­cze­niu z potrze­ba­mi użyt­kow­ni­ka i meto­dycz­nie kon­cep­tu­ali­zu­ją i wyra­ża­ją rozwiązanie.

https://​buil​tin​.com/​r​e​c​r​u​i​t​i​n​g​/​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​-​v​s​-​p​r​o​g​r​a​m​mer

CZYM ZAJMUJE SIĘ PROGRAMISTA?
Programiści piszą kod i debu­gu­ją błę­dy w pro­gra­mach i opro­gra­mo­wa­niu na pod­sta­wie instruk­cji od inży­nie­rów opro­gra­mo­wa­nia. Są zaan­ga­żo­wa­ni w poje­dyn­czy etap cyklu roz­wo­ju i kon­cen­tru­ją się na jed­nym kom­po­nen­cie naraz.

https://​buil​tin​.com/​r​e​c​r​u​i​t​i​n​g​/​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​-​v​s​-​p​r​o​g​r​a​m​mer

Źródła