Myślenie systemowe

Najprostsze rze­czy bywa­ją naj­trud­niej­sze w mode­lo­wa­niu, powo­dem jest ich ​„pozor­na” pro­sto­ta. Na wie­lu uczel­niach na świe­cie zaczę­ły sie poja­wiać stu­dia pody­plo­mo­we i szko­le­nia o wdzięcz­nym tytu­le ​„Myślenie sys­te­mo­we” (System Thinking, np. to na MIT), ich celem jest kształ­to­wa­nie myśle­nia zorien­to­wa­ne­go na postrze­ga­nie świa­ta jako sys­te­mu czy­li mecha­ni­zmu zło­żo­ne­go z współ­pra­cu­ją­cych obiektów. 

Tu poja­wia się sto­so­wa­ne w nauce poję­cie ​„mecha­nizm” . Po co i kie­dy uży­wa­my tego poję­cia? ​„Mechanizmów poszu­ku­je się w celu wyja­śnie­nia, jak powsta­je jakieś zja­wi­sko lub jak dzia­ła jakiś istot­ny pro­ces.” . Innymi sło­wy ana­li­zu­jąc lub pro­jek­tu­jąc sys­te­my, odpo­wied­nio odkry­wa­my lub pro­jek­tu­je­my mecha­ni­zmy ich dzia­ła­nia. Ważna uwa­ga: sys­tem to nie tyl­ko ​„sys­tem infor­ma­tycz­ny”, sys­te­mem jest każ­de urzą­dze­nie, każ­da orga­ni­za­cja, każ­de pań­stwo. To co nazy­wa­my ​„sys­te­mem infor­ma­tycz­nym”, bar­dzo rzad­ko jest samo­dziel­nym sys­te­mem. Z regu­ły jest to część nad­rzęd­ne­go sys­te­mu jakim jest urzą­dze­nie, orga­ni­za­cja, państwo. 

Kluczowym eta­pem ana­li­zo­wa­nia lub pro­jek­to­wa­nia sys­te­mu jest zro­zu­mie­nie i usta­le­nie, czym ten sys­tem jest oraz na co i jak reaguje.

Na dwóch przy­kła­dach poka­żę czym jest Przypadek Użycia, któ­ry w nota­cji UML i SysML jest abs­trak­cją reak­cji sys­te­mu na bodź­ce. Pokaże też czym jest pro­jek­to­wa­nie w duchu myśle­nia systemowego.

W spe­cy­fi­ka­cji UML czytamy: 

Kluczowe ele­men­ty to:

1. przy­pa­dek uży­cia może być przy­po­rząd­ko­wa­ny do wie­lu mode­lo­wa­nych sys­te­mów (sub­ject: mode­lo­wa­ny przed­miot), mode­lu­je obser­wo­wal­ny efekt wywo­ła­nej usłu­gi (zacho­wa­nie się sys­te­mu w odpo­wie­dzi na okre­ślo­ny bodziec),
2. przy­pa­dek uży­cia to okre­ślo­ny zestaw zacho­wań systemu,
3. przy­pa­dek uży­cia repre­zen­tu­je okre­ślo­ne zacho­wa­nia bez odwo­ły­wa­nia się do wewnętrz­nej struk­tu­ry systemu.

Dlatego te dia­gra­my są (powin­ny być) pro­ste (patrz art. Diagram Przypadków Użycia), w zasa­dzie jako nazwy, mode­lu­ją przy­szłe menu głów­ne sys­te­mu. Diagram przy­pad­ków uży­cia to umo­wa na zakres. Diagram ten w nota­cji SysML peł­ni rolę mode­lu kon­tek­stu projektu. 

Coś małego i prostego czyli email

Od jed­ne­go z czy­tel­ni­ków dosta­łem pytanie:

Mam jesz­cze jed­no pyta­nie do UC. Czy przy­pad­ka­mi uży­cia apli­ka­cji pocz­ty e‑mail są wysy­ła­nie wia­do­mo­ści i odbie­ra­nie wiadomości?

odpi­sa­łem

Wysyłanie i odbie­ra­nie to sku­tek dzia­ła­nia sys­te­mu ema­il, UC to wyłącz­nie to co widzi użyt­kow­nik czy­li for­mat­ka ema­il, to to jaki adres jest w polu ​„Do:” skut­ku­je tym, gdzie ema­il jest wysła­ny czy ode­bra­ny. Decyduje o tym ​„regu­ła biz­ne­so­wa” (logi­ka sys­te­mu):
- moż­na wysłać mail gdzie­kol­wiek (nawet do sie­bie)
- cudzy mail jest tyl­ko do odczy­tu
odpo­wiedź lub prze­ka­za­nie dalej to tyl­ko logi­ka dane­go kro­ku pole­ga­ją­ca na ewen­tu­al­nym sko­pio­wa­niu treści.

Półtora roku temu (maj 2021) w arty­ku­le Krótka histo­ria pew­ne­go wyma­ga­nia opi­sy­wa­łem pew­ną spe­cy­fi­ka­cję wyma­gań wyko­na­ną tra­dy­cyj­ną opi­so­wą meto­dą, przez pra­cow­ni­ków pew­ne­go dzia­łu IT pew­nej insty­tu­cji (tu suge­stia by prze­czy­tać ten arty­kuł). Problem pole­gał na tym, że ten opis był zbyt deta­licz­ny i mimo to nie­jed­no­znacz­ny i nie­kom­plet­ny, a doty­czył jedy­nie pocz­ty elek­tro­nicz­nej. Niestety oka­zu­je się, że gene­ral­nie wyma­ga­nia opi­sa­ne w języ­ku natu­ral­nym, są nie­spój­ne i nie­jed­no­znacz­ne i nie jest to dobra meto­da wyko­na­nia ich opi­su .

Jako ludzie komu­ni­ku­je­my się, tak­że pisem­nie, narzę­dzia są wtór­ne. Narzędzia powsta­ją w odpo­wie­dzi na potrze­by a nie odwrot­nie. Jak wyglą­da komu­ni­ka­cja, elek­tro­nicz­na tak­że? Poniższy sche­mat poka­zu­je pro­sty pro­ces opra­co­wa­nia i wysła­nia treści:

Jak już nie raz tu wspo­mi­na­no, słow­nik pojęć jest fun­da­men­tem każ­de­go pro­jek­tu, a w pro­jek­cie z obsza­ru sys­te­mów infor­ma­cyj­nych szcze­gól­nie. Poniżej klu­czo­we poję­cia dla mode­lo­wa­ne­go obszaru:

doku­ment: mate­riał w posta­ci tek­stu, foto­gra­fii lub jaki­kol­wiek przed­miot, mają­cy war­tość dowo­do­wą lub infor­ma­cyj­ną, lub plik kom­pu­te­ro­wy zawie­ra­ją­cy infor­ma­cje zapi­sa­ne w odpo­wied­nim for­ma­cie
for­mu­larz: blan­kiet doku­men­tu z miej­sca­mi do wypeł­nie­nia
komu­ni­kat: infor­ma­cja prze­ka­zy­wa­na w pro­ce­sie bez­po­śred­niej komu­ni­ka­cji z dru­gą oso­bą
tekst: ciąg zapi­sa­nych słów i zdań skła­da­ją­cych się na pew­ną całość wyra­ża­ją­cą okre­ślo­ne treści

(źr.: https://​sjp​.pwn​.pl)

Z powyż­sze­go wnio­sku­je­my, że

• doku­ment jako tekst, wyra­ża okre­ślo­ne tre­ści, może być wypeł­nio­nym formularzem
• prze­sła­ny (prze­ka­za­ny) doku­ment to komunikat

Technologie infor­ma­cyj­ne to auto­ma­tycz­ne prze­twa­rza­nie tre­ści. Jednak aby było to moż­li­we, tre­ści te muszą być zwar­te i ustruk­tu­ry­zo­wa­ne, a robi­my to nada­jąc doku­men­tom struk­tu­rę z pomo­cą for­mu­la­rzy (podział na sek­cje, pola itp.). Prowadzone dość regu­lar­nie bada­nia i stu­dia lite­ra­tu­ro­we wska­zu­ją, że świat sys­te­mów infor­ma­cyj­nych od lat zmie­rza w stro­nę danych orga­ni­zo­wa­nych w for­mu­la­rze (doku­men­ty) opi­sy­wa­ne z pomo­cą onto­lo­gii (meta­da­ne) i odcho­dzi od ich roz­kła­da­nia na sztyw­ne i zło­żo­ne tabe­la­rycz­ne struk­tu­ry pozba­wio­ne redun­dan­cji, czy­ta­ne i zapi­sy­wa­ne języ­kiem SQL .

Dlatego na powyż­szym dia­gra­mie poja­wi­ły się Szablon doku­men­tu i Formularz doku­men­tu. Szablon to wzór for­ma­tu (struk­tu­ra) doce­lo­we­go doku­men­tu, Dokument to okre­ślo­na treść o narzu­co­nej przez ten sza­blon struk­tu­rze. Poniżej typo­wy sza­blon tre­ści pocz­ty elektronicznej:

Jest to pro­sta struk­tu­ra, narzu­ca­ją­ca wydzie­le­nie (jaw­ne wska­za­nie rodza­ju tre­ści): nadaw­cy, adre­sa­ta, tema­tu, nie­struk­tu­ral­ne­go tek­stu, pozwa­la­ją­ca opcjo­nal­nie dodać innych adre­sa­tów i załą­czyć do prze­sła­nia inne doku­men­ty (pli­ki jako załączniki). 

Tu bar­dzo istot­na rzecz: zde­fi­nio­wa­ny sza­blon to z zasa­dy nazwa wła­sna w słow­ni­ku, ozna­cza­ją­ca określ­nąa treść i jej struk­tu­rę. W efek­cie pro­ce­du­ra wysła­nia komu­ni­ka­tu ma postać:

1. utwórz nowy Email wg. szablonu
2. zre­da­guj treść
3. wyślij naci­ska­jąc OK

gdzie Email to nazwa sza­blo­nu. Z sza­blo­nem są powią­za­ne regu­ły jego popraw­ne­go wypeł­nie­nia, dla­te­go on sam zawsze sta­no­wi sobą część pro­ce­du­ry. Nie pisze­my w sce­na­riu­szu: 1. wstaw adre­sa­ta, 2. wstaw temat, 3. wpisz treść, 4. opcjo­nal­nie dodaj załącz­nik.…… Punkt sce­na­riu­sza: ​„Zredaguj treść”, co do zasa­dy ozna­cza wyko­na­nie tego zgod­nie z sza­blo­nem (i jest to – jako jeden for­mu­larz – z zasa­dy zawsze jeden krok sce­na­riu­sza). To dla­te­go defi­nio­wa­nie doku­men­tów (ich struk­tur i reguł popraw­no­ści) jest tak wygod­ne: sza­blon to nazwa wła­sna struk­tu­ry i tre­ści danych i zara­zem defi­ni­cja kro­ku w sce­na­riu­szu (pro­ce­du­rze).

Diagram przy­pad­ków uży­cia dla takie­go sys­te­mu komunikacji:

Dokumentując ten przy­pa­dek uży­cia two­rzy­my sza­blon for­mu­la­rza Email (oraz pomoc­ni­czy: Lista):

Przypadki uży­cia doku­men­tu­je­my mię­dzy inny­mi z pomo­cą sce­na­riu­szy. Często sta­wia­na jest teza, że przy­pa­dek uży­cia ma tyl­ko jeden sce­na­riusz, co nie jest praw­dą. Tych sce­na­riu­szy może być kil­ka (w UML: Use Case jest rodza­jem, któ­ry repre­zen­tu­je dekla­ra­cję zesta­wu ofe­ro­wa­nych zacho­wań ), wyra­ża­ne są jako jeden sce­na­riusz zawie­ra­ją­cy alter­na­tyw­ne kro­ki lub jako alter­na­tyw­ne pro­ste sce­na­riu­sze, wspól­ną cechą tych sce­na­riu­szy jest ope­ro­wa­nie na tych samych danych wg. tych samych reguł, róż­nią sie jedy­nie kon­tek­stem .

Scenariusz: Nowa wiadomość:

1. Użytkownik ini­cju­je usłu­gę Wymiana treści
2. SYSTEM wyświe­tla Lista wiadomości
3. Użytkownik wska­zu­je opcje ​„nowa”
4. SYSTEM wyświe­tla for­mu­larz Email
5. Użytkownik wpro­wa­dza dane i OK
6. SYSTEM potwier­dza zacho­wa­nie i wysła­nie treści

Scenariusz: Czytaj wiadomość:

1. Użytkownik ini­cju­je usłu­gę Wymiana treści
2. SYSTEM wyświe­tla Lista wiadomości
3. Użytkownik wska­zu­je okre­ślo­ną wiadomość
4. SYSTEM wyświe­tla for­mu­larz Email z tre­ścią wiadomości

Wysłanie odpo­wie­dzi lub prze­ka­za­nie wia­do­mo­ści, to przej­ście do Nowej wia­do­mo­ści, tu sys­tem sko­piu­je treść. Nie są to osob­ne sce­na­riu­sze a raczej instruk­cja użyt­kow­ni­ka, wyra­żo­na np. jako mapa ​„co ma klikać”:

Z per­spek­ty­wy repo­zy­to­rium wia­do­mo­ści nie ma zna­cze­nia któ­ra była wysła­na, a któ­ra otrzy­ma­na, bo mają one iden­tycz­ną struk­tu­rę, to co nazy­wa­my ​„wysła­ne” i ​„otrzy­ma­ne” zale­ży wyłącz­nie od tego czy nasz adres ema­il jest w polu Do czy Od więc maile są ​„takie same”. W tym przy­pad­ku (tech­no­lo­gicz­nie) repo­zy­to­rium pocz­ty (dokumentów/plików) to ser­wer IMAP (uży­wa­jąc sys­te­mu z POP3 musi­my mieć swo­ja lokal­ną kopię).

Tak więc bez wzglę­du na to czy wysy­ła­my ema­il czy czy­ta­my, jest to ta sama usłu­ga. Sposób pre­zen­ta­cji (wąt­ki, podział na fol­de­ry itp.) to jedy­nie deta­licz­ny pro­jekt inter­fej­su użyt­kow­ni­ka. A spam? A wła­sne lokal­ne archi­wum? Nasze potrze­by reali­zu­je magicz­ne sło­wo ​„archi­tek­tu­ra”:

Powyższy dia­gram to model archi­tek­tu­ry HLD (High Level Design, archi­tek­tu­ra wyso­kie­go pozio­mu, wię­cej w arty­ku­le Analiza Biznesowa i Opis Techniczny). Portal to stan­dar­do­we śro­do­wi­sko (widże­ty) dostę­po­we do usług apli­ka­cji. Wymiana tre­ści to kom­po­nent reali­zu­ją­cy sce­na­riu­sze pobie­ra­nia i wysła­nia maili, orga­ni­zu­ją­cy logi­kę wido­ków: sor­to­wa­nie, gru­po­wa­nie w wąt­ki, archi­wi­za­cja, itp.. Filtr antySPAM to z regu­ły wyko­rzy­sta­ny goto­wy kom­po­nent lub usłu­ga. Email Adapter to kom­po­nent sepa­ru­ją­cy naszą apli­ka­cje od ​„świa­ta”, unie­za­leż­nia apli­ka­cję (her­me­ty­zu­je ją) od deta­li kon­fi­gu­ra­cji zewnętrz­nych usług (IMAP i SMTP). 

Szafa grająca czyli myślenie systemowe

Tak zwa­na Szafa Grająca to (pier­wot­nie) urzą­dze­nie odtwa­rza­ją­ce muzy­kę z płyt winy­lo­wych zgro­ma­dzo­nych w spe­cjal­nym maga­zyn­ku. Każda pły­ta (z regu­ły sin­giel) ma numer oraz poda­ne dane dwóch utwo­rów (dwie stro­ny pły­ty). Wybór utwo­ru pole­gał na wybra­niu jego nume­ru, a odpo­wied­ni mecha­nizm pobie­rał z maga­zyn­ka pły­tę i zakła­dał ją na talerz gra­mo­fo­nu. Po jej odtwo­rze­niu pły­ta wra­ca­ła na swo­je miej­sce w magazynku. 

Jeżeli sza­fa gra­ją­ca była ele­men­tem wypo­sa­że­nia np. pubu, sys­tem udo­stęp­niał wybór utwo­ru dopie­ro po uisz­cze­niu opła­ty: wrzu­ce­niu odpo­wied­niej monety. 

Po pra­wej stro­nie widok typo­wej sza­fy gra­ją­cej, poni­żej jej mecha­tro­nicz­ny model:

Powyższy dia­gram to model sza­fy gra­ją­cej, dia­gram blo­ków wewnętrz­nych, wyko­na­ny w nota­cji SysML (roz­sze­rze­nie UML). Pełny model tej sza­fy zawie­rał by tak­że dia­gram aktyw­no­ści, dia­gram maszy­ny sta­no­wej i dia­gram para­me­trycz­ny (nie będę ich tu przy­ta­czał). Celem jest tu poka­za­nie jej mecha­nicz­nej kon­struk­cji na pozio­mie głów­nych blo­ków. Tu cho­dzi­ło o ele­men­ty wyko­naw­cze, peł­ny model zawie­rał by jesz­cze blok zasilania.

Jak już nie raz tu pisa­łem, w lite­ra­tu­rze na temat inży­nie­rii pro­gra­mo­wa­nia auto­rzy czę­sto piszą, że ​„kom­pu­ter to uni­wer­sal­ny mecha­nizm” . Szafa gra­ją­ca to kon­struk­cja elek­tro­me­cha­nicz­na, któ­rą moż­na w cało­ści zastą­pić kom­pu­te­rem (kom­pu­ter to pro­ce­sor, pamięć i pro­gram). Na jej przy­kła­dzie opra­cu­je­my jej kom­pu­te­ro­wy odpowiednik.

Generalnie sza­fa gra­ją­ca reali­zu­je dwie usługi:

Powyższe to ​„umo­wa na zakres sys­te­mu”. Kolejny etap to opis pla­no­wa­nej inte­rak­cji aktor-sys­tem. Usługę wybo­ru utwo­ru moż­na opi­sać scenariuszem:

1. Użytkownik ini­cju­je usłu­gę Wybór utworu
2. SYSTEM udo­stęp­nia «Panel wybo­ru utworu»
3. Użytkownik wpro­wa­dza numer wybra­ne­go utwo­ru i OK
4. SYSTEM potwier­dza wybór
5. SYSTEM odtwa­rza wybra­ny utwór
6. SYSTEM wra­ca do sta­nu początkowego

Zakładam, że usłu­ga przyj­mo­wa­nia opła­ty ​„z góry” nie wyma­ga opi­su. Stanowi ona osob­ną i nie­za­leż­ną usłu­gę bo nie przy­pad­kiem efekt wrzu­ce­nia mone­ty nazy­wa się kre­dy­tem (z któ­re­go korzy­sta­my wybie­ra­jąc utwo­ry do odtwo­rze­nia) i nie ma obo­wiąz­ku jego wyko­rzy­sta­nia. Po pro­stu sta­tus sza­fy zmie­nia się: przyj­mu­je zamó­wie­nia na odtwo­rze­nia muzy­ki, wyczer­pa­nie kre­dy­tu (któ­ry jako sal­do żyje sobie w tej maszy­nie ​„wła­snym życiem”) spo­wo­du­je zmia­ną sta­tu­su na ​„nie przyj­mu­je zle­ceń odtwo­rze­nia muzyki”. 

Jak już wie­my, mecha­nizm dzia­ła­nia sza­fy gra­ją­cej to wska­zy­wa­nie utwo­ru w okre­ślo­nej ich kolek­cji i odtwo­rze­nie go z posia­da­ne­go nośni­ka. Do skon­stru­owa­nia sza­fy gra­ją­cej potrzeb­ne jest: zgro­ma­dze­nie pew­nej ilo­ści płyt z muzy­ką, zbu­do­wa­nie kon­struk­cji zawie­ra­ją­cej stojak/magazynek na pły­ty, urzą­dze­nie auto­ma­ty­zu­ją­ce wybór pły­ty, jej odtwo­rze­nie i odło­że­nie na stojak. 

Do napi­sa­nia pro­gra­mu na kom­pu­ter, któ­ry zastą­pi mecha­nicz­ną kon­struk­cję, potrzeb­ne jest jego zapro­jek­to­wa­nie. Albo, nie tyle potrzeb­ne co zale­ca­ne. Dlaczego? Bo two­rze­nie (pisa­nie kodu) opro­gra­mo­wa­nia jest naj­droż­szą pra­cą w inży­nie­rii opro­gra­mo­wa­nia, podob­nie jak wytwa­rza­nie pro­duk­tów na hali pro­duk­cyj­nej. Po dru­gie cykl życia (ser­wis i roz­wój, wpro­wa­dza­nie zmian) sys­te­mu zale­ży od jego wewnętrz­nej archi­tek­tu­ry: sza­fa gra­ją­ca mogła by być mono­li­tycz­nym blo­kiem kon­struk­cyj­nym, ale nie jest, i war­to wie­dzieć dla­cze­go. Nie jest bo urzą­dze­nie zbu­do­wa­ne z nie­za­leż­nych i wymien­nych blo­ków, mimo że ma bar­dziej skom­pli­ko­wa­ną budo­wę, jest znacz­nie tań­sze w utrzy­ma­niu i rozwoju.

Pojawiło się poję­cie sys­tem, defi­niu­je­my jak poniżej:

System (z grec­kie­go sys­te­ma), jest to zestaw wza­jem­nie powią­za­nych ze sobą ele­men­tów, funk­cjo­nu­ją­cych jako jed­na całość (nakła­dy, pro­ce­sy trans­for­ma­cji, wyni­ki i sprzę­że­nie zwrot­ne). Systemem jest wszel­ki sko­or­dy­no­wa­ny wewnętrz­nie i wyka­zu­ją­cy okre­ślo­ną struk­tu­rę układ elementów.

żr,: https://​mfi​les​.pl/​p​l​/​i​n​d​e​x​.​p​h​p​/​S​y​s​tem

(Dlatego sys­te­mem jest zarów­no sza­fa gra­ją­ca jak i publicz­ny lokal, któ­re­go jest ona elementem.)

Skoro więc nie chce­my mono­li­tu, wie­my jak i dla­cze­go zbu­do­wa­na jest mecha­nicz­na sza­fa gra­ją­ca, zapro­jek­tuj­my jej kom­pu­te­ro­wy odpowiednik:

Kluczowe cechy tej architektury:

1. odse­pa­ro­wa­no od sie­bie i zaher­me­ty­zo­wa­no odpo­wie­dzial­no­ści: za przy­ję­cie nume­ru utwo­ru, za spraw­dze­nie pra­wa do jego odtwo­rze­nia, za repo­zy­to­rium utwo­rów, za kon­tro­le wno­szo­nej opła­ty, kolej­ko­wa­nie itp. 
2. roz­wój apli­ka­cji wyma­ga co naj­wy­żej doda­wa­nia kolej­nych operacji/metod do już zbu­do­wa­nych kom­po­nen­tów, moż­na zawsze dodać ope­ra­cję lub nawet nowy kom­po­nent nie mody­fi­ku­jąc istniejących. 

Np. począt­ko­wo sza­fa będzie po pro­stu powięk­sza­ła sal­do w mia­rę wrzu­ca­nych monet bez wzglę­dy na to kto je wrzu­ca. Wybór utwo­ru pomniej­szy sal­do. Gdyby zaszła taka potrze­ba doda­je­my moż­li­wość doda­wa­nia kolej­nych np. nume­ro­wa­nych, obiek­tów kla­sy Saldo: mody­fi­ku­je­my tyl­ko logi­kę kla­sy Logika przyj­mo­wa­nia wpłat.

Logika wybo­ru utwo­ru, korzy­sta­jąc z dostę­pu do aktu­al­ne­go sal­da, kon­tro­lu­je doda­wa­nie utwo­rów do kolej­ki. Dlaczego dublu­je­my utwo­ry (np. pli­ki mp3) w kolej­ce do odtwa­rza­nia, zamiast budo­wać tyl­ko link do Utworów? Bo każ­dy z pozio­mych cią­gów klas to osob­ny mikro-ser­wis i sepa­ru­je­my je, dzię­ki cze­mu są od sie­bie cał­ko­wi­cie nie­za­leż­ne. Wtedy np. w przy­szło­ści, może­my zamie­nić parę Kontrola dostę­pu do Utworów i Utwory, na inter­fejs do zewnętrz­ne­go ser­wi­su ofe­ru­ją­ce­go utwo­ry, bez inge­ro­wa­nia w pozo­sta­łe komponenty.

Nie było tu moim celem deta­licz­ne opi­sy­wa­nie powyż­szej kon­struk­cji a jedy­nie poka­za­nie jej. Jednak w razie jakich­kol­wiek pytań, pro­szę je zada­wać w uwa­gach pod artykułem. 

Podsumowanie

To co nazy­wa­my myśle­niem sys­te­mo­wym to tak zwa­ne kom­plek­so­we patrze­nie na świat, któ­ry trak­tu­je­my jak sys­tem (patrz defi­ni­cja wcze­śniej) oraz pro­jek­tu­je­my roz­wią­za­nia (apli­ka­cje) tak­że jako sys­te­my, wie­dząc że one są czę­ścią więk­sze­go, nad­rzęd­ne­go sys­te­mu. Pozwala to zapa­no­wać nad dowol­nej wiel­ko­ści pro­jek­tem oraz zapew­nić sobie, że jaka­kol­wiek jego zmia­na nie będzie pra­cą porów­ny­wal­ną, lub więk­szą, niż jego pier­wot­ne opra­co­wa­nie i wyko­na­nie .

Projektowanie w para­dyg­ma­cie myśle­nia sys­te­mo­we­go nie jest tym samym, czym pro­jek­to­wa­nie w para­dyg­ma­cie myśle­nia pro­jek­to­we­go. Wiele roz­bież­nych poglą­dów doty­czy pro­jek­to­wa­nia, ist­nie­je jed­nak zgo­da co do kil­ku pod­sta­wo­wych zasad, któ­ry­mi kie­ru­ją się ludzie myślą­cy sys­te­mo­wo, pla­nu­jąc przy­szłość. […] ludzie myślą­cy sys­te­mo­wo gene­ral­nie dążą do tego, by dziś zro­bić coś, co pozwo­li im jutro stwo­rzyć system.

To co popu­lar­nie ostat­nio nazy­wa­my holi­stycz­nym podej­ściem do orga­ni­za­cji, to wła­śnie trak­to­wa­nie ich jak sys­te­mów. Pozwala to two­rzyć i roz­wi­jać sys­te­my w spo­sób płyn­ny, ewo­lu­cyj­ny, bez potrze­by per­ma­nent­ne­go ​„zamie­nia­nia sta­re­go na nowe”. Nawet pozor­nie pro­sty sys­tem wymia­ny komu­ni­ka­tów, war­to prze­my­śleć i zapro­jek­to­wać, a póź­niej dopie­ro two­rzyć, bo to daje więk­sze zro­zu­mie­nie tego jak funk­cjo­nu­je i jaką role speł­nia dla swo­je­go oto­cze­nia. Warto tak­że naśla­do­wać ​„natu­rę”, któ­ra przez milio­ny lat ukształ­to­wa­ła na świat jako system… 

Źródła