Celem budo­wy i roz­wo­ju tego słow­ni­ka, jest zebra­nie klu­czo­wych pojęć, nazw i defi­ni­cji, oraz metod i narzę­dzi jakie sto­su­je w pro­jek­tach, oraz zapew­nie­nie jed­no­znacz­no­ści tre­ści moich opra­co­wań. Źródłem przy­to­czo­nych tu defi­ni­cji są lite­ra­tu­ra przed­mio­tu, spe­cy­fi­ka­cje nota­cji, ofi­cjal­ne słow­ni­ki, w szcze­gól­no­ści Słownik Języka Polskiego. Definicje spe­cja­li­stycz­ne mają poda­ne źró­dła (recen­zo­wa­ne publi­ka­cje nauko­we, ency­klo­pe­die, patrz Bibliografia). Wykorzystane zosta­ły defi­ni­cje spra­woz­daw­cze (opi­so­we), a tam gdzie to było to koniecz­ne lub moż­li­we, tak­że defi­ni­cje real­ne (atry­bu­to­we) [Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Red.). Wydawnictwo Naukowe PWN.]

Spis tre­ści

adapter

w inży­nie­rii opro­gra­mo­wa­nia wzo­rzec, któ­ry pozwa­la na wyko­rzy­sta­nie inter­fej­su ist­nie­ją­cej kla­sy jako inne­go inter­fej­su, jest czę­sto uży­wa­ny, aby ist­nie­ją­ce kla­sy współ­pra­co­wa­ły z inny­mi bez mody­fi­ko­wa­nia ich kodu źró­dło­we­go; przy­kła­dem jest adap­ter, któ­ry prze­kształ­ca inter­fejs SQL do rela­cyj­nej bazy danych w inter­fejs REST tak by nie udo­stęp­niać bazy danych na zewnątrz i nie kasto­mi­zo­wać kodu tej aplikacji:(opracowanie własne)Legacy System to posia­da­ne opro­gra­mo­wa­nie o struk­tu­ral­nej, mono­li­tycz­nej archi­tek­tu­rze. Aby bez­piecz­nie udo­stęp­nić dane, budo­wa­ny jest Adapter czy­li kom­po­nent udo­stęp­nia­ją­cy lokal­ne zapy­ta­nia SQL jako ope­ra­cje REST API zwra­ca­ją­ce dane w posta­ci doku­men­tów XML/JSON. Może on być wypo­sa­żo­ny w logi­kę reali­zu­ją­cą wewnętrz­ny sce­na­riusz (jeże­li jest taki konieczny). 

administrator

oso­ba lub insty­tu­cja zarzą­dza­ją­ca czymś (s.j.p.), tak­że usta­la­ją­ca i egze­kwu­ją­ca okre­ślo­ne zwią­za­ne z tym zasa­dy (nie jest to więc potocz­nie wyko­naw­ca czyn­no­ści kon­fi­gu­ra­cyj­nych opro­gra­mo­wa­nie, wyko­ny­wa­nych poza jego nor­mal­ny­mi, prze­zna­czo­ny­mi do tego, funk­cjo­nal­no­ścia­mi, patrz: usłu­ga apli­ka­cji), patrz tak­że admi­ni­stra­tor danych osobowych

administrator danych osobowych

zgod­nie z ogól­nym roz­po­rzą­dze­niem o ochro­nie danych (RODO) jest to oso­ba fizycz­na lub praw­na, organ publicz­ny, jed­nost­ka lub inny pod­miot, któ­ry samo­dziel­nie lub wspól­nie z inny­mi usta­la cele i spo­so­by prze­twa­rza­nia danych osobowych

agent

sys­tem kom­pu­te­ro­wy (pro­gram) umiesz­czo­ny w okre­ślo­nym śro­do­wi­sku, któ­ry jest zdol­ny do ela­stycz­ne­go, auto­no­micz­ne­go dzia­ła­nia, aby zre­ali­zo­wać cele dla któ­rych został stwo­rzo­ny (??An agent is a com­pu­ter sys­tem, situ­ated in some envi­ron­ment, that is capa­ble of fle­xi­ble auto­no­mo­us action in order to meet its design objec­ti­ves.?? (Jennings et al.,1998)

agent-based modeling

mode­lo­wa­nie zorien­to­wa­ne na budo­wa­nie sys­te­mów jako kolek­cji auto­no­micz­nych obiek­tów zwa­nych agen­ta­mi, każ­dy agent sam oce­nia oto­cze­nia i podej­mu­je decy­zje wg. swo­ich wewnętrz­nych reguł, meto­da bazu­je na ogól­nej teo­rii sys­te­mów, meto­da wyko­rzy­sty­wa­na jest w wie­lu róż­nych dzie­dzi­nach nauki do symu­lo­wa­nia sys­te­mów spo­łecz­nych, tak­że w socjo­lo­gii (Bonabeau, 2002) czy eko­no­mii (Fonseca-Statter, 2015)

agregat

zło­żo­na, zagnież­dżo­na struk­tu­ra, sta­no­wi sobą kla­sy­fi­ka­tor struk­tu­ral­ny, czy­li taki, któ­ry ma nie­try­wial­ną wewnętrz­ną struk­tu­rę (patrz UML, v.2.5.1, rozdz, 11, 2017-12-05); tak­że wzo­rzec archi­tek­to­nicz­ny, spo­pu­la­ry­zo­wa­ny wraz z wzor­ca­mi DDD E.Evansa [Evans, E. (2003). Domain-Driven Design. Pearson Education (US).], jest to struk­tu­ra drze­wia­sta połą­czo­na związ­ka­mi całość-część (lub zawie­ra­nia się); typo­wym przy­kła­dem agre­ga­tów są drze­wia­ste struk­tu­ry repre­zen­tu­ją­ce kon­struk­cje mecha­nicz­ne lub struk­tu­ry tre­ści zło­żo­nych dokumentów

aksjomat

pew­nik, log. takie twier­dze­nie danej teo­rii deduk­cyj­nej, któ­re zosta­ło przy­ję­te bez dowo­du i sta­no­wi pod­sta­wę dowo­dów innych twierdzeń;

analityk biznesowy

oso­ba potra­fią­ca zro­zu­mieć i udo­ku­men­to­wać dzia­ła­nia klien­ta oraz zasu­ge­ro­wać roz­wią­za­nia zgło­szo­nych pro­ble­mów lub spo­so­bów reali­za­cji celów; doku­men­ta­cja ana­li­zy biz­ne­so­wej opi­su­je: pro­ce­sy, struk­tu­ry orga­ni­za­cyj­ne, ogra­ni­cze­nia, dane i sys­te­my (źr. IIBA​.org)

analityk systemów

reali­za­tor pro­gra­mu ana­li­zy sys­te­mo­wej, oso­ba sto­su­ją­ca ana­li­zę sys­te­mo­wą do roz­wią­zy­wa­nia pro­ble­mów; cechy ana­li­ty­ka systemów: 

  • myśle­nie alter­na­tyw­ne, czy­li zdol­ność cią­głe­go dostrze­ga­nia alter­na­tyw­nych rozwiązań,
  • myśle­nie anty­cy­pa­cyj­ne, czy­li zdol­ność prze­wi­dy­wa­nia dal­szych skut­ków pro­po­no­wa­nych roz­wią­zań pro­ble­mow praktycznych,
  • myśle­nie pro­ba­bi­li­stycz­ne i posy­bi­li­stycz­ne, czy­li zdol­ność ana­li­zo­wa­nia obiek­tów w kate­go­riach nie­pew­no­ści i ryzy­ka oraz możliwości,

Celem ana­li­ty­ka sys­te­mów nie jest stwier­dze­nie jaka powin­na być decy­zja, lecz przed­sta­wie­nie okre­ślo­nych reko­men­da­cji opar­tych wca­le nie na jego war­to­ścio­wa­niu. Gdyby tak nie było, nie speł­niał by on roli ana­li­ty­ka, lecz dorad­cy. (Sienkiewicz, 1994).

analiza

roz­pa­try­wa­nie jakie­goś pro­ble­mu, zja­wi­ska z róż­nych stron w celu jego zro­zu­mie­nia lub wyja­śnie­nia; też: wyja­śnie­nie lub opis, będą­ce wyni­kiem takie­go roz­pa­try­wa­nia; meto­da badaw­cza pole­ga­ją­ca na wyod­ręb­nie­niu z danej cało­ści jej ele­men­tów i bada­niu każ­de­go z osob­na (źr. SJP); pro­ces izo­lo­wa­nia lub powro­tu do tego, co jest bar­dziej fun­da­men­tal­ne, za pomo­cą któ­re­go coś, począt­ko­wo trak­to­wa­ne jak fak­ty, moż­na wyja­śnić lub zre­kon­stru­ować, wyja­śnie­nie lub rekon­struk­cja czę­sto są następ­nie pre­zen­to­wa­ne jako pro­ces syn­te­zy. (źr. Encyklopedia filo­zo­fii)

analiza biznesowa

sfor­ma­li­zo­wa­na ana­li­za sys­te­mo­wa orga­ni­za­cji i powią­za­nych z nią pod­mio­tów biz­ne­so­wych, pro­wa­dzo­na w celu stwo­rze­nia mode­lu ich funk­cjo­no­wa­nia i zro­zu­mie­nia zasad dzia­ła­nia; bar­dzo czę­sto pro­wa­dzo­na w celu oce­ny wpły­wu pla­no­wa­nych zmian i wyspe­cy­fi­ko­wa­nia wyma­gań w sto­sun­ku do pla­no­wa­ne­go do wdro­że­nia roz­wią­za­nia, w szcze­gól­no­ści tech­no­lo­gii infor­ma­cyj­nych i infor­ma­tycz­nych (opr. wł. na pod­sta­wie www​.iiba​.org)

Proces Analizy Biznesowej wg. IIBA/MDA (opra­co­wa­nie własne)

analiza systemowa

sztu­ka pozna­wa­nia i okre­śla­nia sys­te­mów dro­gą budo­wa­nia ich mode­li” (Koźmiński, A. K. (1979). Decyzje: Analiza sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.)w nauce pro­ces gene­ra­li­za­cji pole­ga­ją­cy na wyod­ręb­nie­niu, z bada­nej rze­czy­wi­sto­ści, skoń­czo­nej licz­by jej ele­men­tów lub ich klas oraz ich cech, w celu opi­sa­nia mecha­ni­zmu jej zacho­wa­nia; w zarzą­dza­niu jest for­mal­nym i jaw­nym bada­niem wspo­ma­ga­ją­cym dzia­ła­nia osób odpo­wie­dzial­nych za decy­zje lub linie postę­po­wa­nia w okre­ślo­nej sytu­acji cha­rak­te­ry­zu­ją­cej się nie­pew­no­ścią; ma ona na celu okre­śle­nie pożą­da­ne­go dzia­ła­nia lub linii postę­po­wa­nia przez roz­po­zna­nie i roz­wa­że­nie dostęp­nych warian­tów i porów­na­nie ich prze­wi­dy­wa­nych następstw; skła­da się z czte­rech eta­pów: (1) zba­da­nie celów pla­no­wa­ne­go postę­po­wa­nia, (2) zba­da­nie moż­li­wych spo­so­bów osią­gnię­cia celu, (3) oce­na pozy­tyw­nych i nega­tyw­nych skut­ków każ­de­go z warian­tów, (4) porów­na­nie warian­tów w spo­sób umoż­li­wia­ją­cy wybór roz­wią­za­nia, (Edward S. Quade, Wydanie Praca zbio­ro­wa Findejsen 1985, patrz tak­że: https://​mfi​les​.pl/​p​l​/​i​n​d​e​x​.​p​h​p​/​A​n​a​l​i​z​a​_​s​y​s​t​e​m​owa)sto­so­wa­na tak­że w inżynierii:Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml

aplikacja

kom­pu­te­ro­wy pro­gram użyt­ko­wy (źr. sł. j. pol­skie­go PWN)

archetyp

for­mal­na i uni­wer­sal­na (re-usa­ble), dzie­dzi­no­wa defi­ni­cja poję­cia prze­zna­czo­na do wyko­rzy­sta­nia w dzie­dzi­no­wych mode­lach poję­cio­wych, two­rzo­na w celu stan­da­ry­za­cji pojęć i odse­pa­ro­wa­nia dzie­dzi­no­wych mode­li infor­ma­cyj­nych od mode­li sys­te­mów (źr. OMG​.org, w języ­ku pol­skim: pierwowzór).

architekt oprogramowania

eks­pert w dzie­dzi­nie opro­gra­mo­wa­nia, któ­ry doko­nu­je wyso­ko­po­zio­mo­wych wybo­rów doty­czą­cych projektu

architektura biznesowa

opis przed­sta­wia­ją­cy cało­ścio­wo struk­tu­rę dzia­ła­nia i zaso­by wewnętrz­ne orga­ni­za­cji z per­spek­ty­wy jej stra­te­gii i sto­so­wa­nych tak­tyk (źr. http://​bawg​.omg​.org, http://​www​.busi​nessar​chi​tec​tu​re​in​sti​tu​te​.org), tak­że McDavid, D. W. (1999). A stan­dard for busi­ness archi­tec­tu­re descrip­tion. IBM Systems Journal38(1), 12?31. doi: 10.1147/sj.381.0012

architektura informacji

prak­ty­ka decy­do­wa­nia o tym, jak upo­rząd­ko­wać infor­ma­cje aby były zro­zu­mia­łe; uzna­jąc, że infor­ma­cja do zro­zu­mia­łe (mają­ce zna­cze­nie) dla czło­wie­ka dane, archi­tek­tu­ra infor­ma­cji to spo­sób orga­ni­za­cji danych.

architektura korporacyjna

W zna­cze­niu rze­czo­wym archi­tek­tu­ra kor­po­ra­cyj­na to for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie. Przy czym kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne. (A.Sobczak).(opra­co­wa­nie wła­sne na pod­sta­wie Czym jest Architektura Korporacyjna (A.Sobczak, 2011)).Logika zor­ga­ni­zo­wa­nia pro­ce­sów biz­ne­so­wych i zaso­bów IT, odzwier­cie­dla­ją­ca wyma­ga­nia na inte­gra­cję i stan­da­ry­za­cję jakie sta­wia model ope­ra­cyj­ny orga­ni­za­cji (źr. Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, August 1, 2006, Jeanne W. Ross, Peter Weill, David Robertson).

architektura oprogramowania

zbiór fun­da­men­tal­nych decy­zji doty­czą­cych apli­ka­cji lub roz­wią­za­nia, zapro­jek­to­wa­nych by spro­stać ocze­ki­wa­nej jako­ści pro­duk­tu (wyma­ga­nia archi­tek­to­nicz­ne); archi­tek­tu­ra zawie­ra głów­ne kom­po­nen­ty, ich klu­czo­we para­me­try, opis współ­pra­cy (inte­rak­cje i zacho­wa­nie) pozwa­la­ją­ce osią­gnąć wyma­ga­ną jakość pro­duk­tu; archi­tek­tu­ra może opi­sy­wać, i czę­sto tak jest, wie­le róż­nych pozio­mów szcze­gó­ło­wo­ści zależ­nie od zło­żo­no­ści i wiel­ko­ści pro­jek­tu (źr. SOA Patterns, Arnon Rotem-Gal-Oz, wyd. Manning 2012r.)

architektura systemu

struk­tu­ra kom­po­nen­tów sys­te­mu i ich wza­jem­ne związ­ki w posta­ci mode­lu, wyra­żo­na w okre­ślo­nej nota­cji (J. Żeliński, Zastosowanie nota­cji UML i Ogólnej Teorii Systemów w mode­lo­wa­niu odpo­wie­dzi sys­te­mów, 2019)Dobrzy archi­tek­ci ostroż­nie oddzie­la­ją szcze­gó­ły od reguł biz­ne­so­wych, robiąc to tak dokład­nie, że regu­ły te nie mają żad­nej wie­dzy o szcze­gó­łach i w żaden spo­sób od nich nie zale­żą. Dobrzy archi­tek­ci tak pro­jek­tu­ją regu­ły sys­te­mu, żeby wszyst­kie decy­zje doty­czą­ce szcze­gó­łów moż­na było podej­mo­wać tak póź­no, jak to tyl­ko możliwe.(Martin, R. C. (2018). Czysta archi­tek­tu­ra Struktura i design opro­gra­mo­wa­nia Przewodnik dla pro­fe­sjo­na­li­stów (W. Moch, Tłum.). Helion SA.)

architektura zorientowana na interfejsy

(tak­że pro­jek­to­wa­nie lub pro­gra­mo­wa­nie zorien­to­wa­ne na inter­fej­sy) wzo­rzec archi­tek­to­nicz­ny i styl pro­jek­to­wa­nia, któ­ry na eta­pie pro­jek­to­wa­nia archi­tek­tu­ry, defi­niu­je apli­ka­cję jako zbiór kom­po­nen­tów repre­zen­to­wa­nych wyłącz­nie przez ich inter­fej­sy, wywo­ła­nia pomię­dzy kom­po­nen­ta­mi mogą być wyko­ny­wa­ne tyl­ko poprzez te inter­fej­sy (na eta­pie pro­jek­to­wa­nia abs­trak­cyj­ne), wewnętrz­na struk­tu­ra kom­po­nen­tów (reali­za­cja inter­fej­sów) powsta­je jako osob­ny pro­jekt każ­de­go z nich (Steimann & Mayer, 2005).Architektura ta, zasto­so­wa­na jako wzo­rzec, daje dużą modu­lar­ność apli­ka­cji, a tym samym łatwość jej utrzy­ma­nia i roz­wo­ju. Jednak samo podzie­le­nie apli­ka­cji na dowol­ne kom­po­nen­ty komu­ni­ku­ją­ce się za pomo­cą inter­fej­sów nie gwa­ran­tu­je małej zależ­no­ści kom­po­nen­tów i ich wyso­kiej spój­no­ści, czy­li dwóch klu­czo­wych cech archi­tek­tu­ry, któ­re powszech­nie uwa­ża się za klu­czo­we dla niskich kosz­tów utrzy­ma­nia. Konieczne jest tak­że ich dzie­dzi­no­we sepa­ro­wa­nie i spój­ność (patrz E.Ewans, Domanin-Driven Design, 2003).Np. model HLD sys­te­mu infor­ma­tycz­ne­go orga­ni­za­cji jest taką archi­tek­tu­rą. Architektura opar­ta na inter­fej­sach sprzy­ja zle­ca­niu ich wytwo­rze­nia odręb­nym zespo­łom, dostaw­com opro­gra­mo­wa­nia. Przypomina to tro­chę sytu­ację, w któ­rej pro­du­cent tele­fo­nu komór­ko­we­go okre­śla inter­fejs prze­no­śnej łado­war­ki (układ pinów, ocze­ki­wa­ne napię­cie prą­du sta­łe­go, itp.), a zarów­no pro­du­cent, jak i stro­ny trze­cie two­rzą wła­sne łado­war­ki do tele­fo­nów komór­ko­wych, któ­re są zgod­ne z tą stan­dar­do­wą spe­cy­fi­ka­cją interfejsu.Realizacja dużych sys­te­mów odby­wa się tu jako pro­jek­to­wa­nie zorien­to­wa­ne na kon­trakt”, tym kon­trak­tem jest spe­cy­fi­ka­cja inter­fej­su. Interfejs (jego spe­cy­fi­ka­cja) jest tu postrze­ga­ny jako umo­wa” – pomię­dzy dostaw­cą a użyt­kow­ni­kiem inter­fej­su. Jeśli ta umo­wa jest udo­ku­men­to­wa­na bar­dziej for­mal­nie jako spe­cy­fi­ka­cja opro­gra­mo­wa­nia, to jest to przy­kład pro­jek­to­wa­nia przez umowę.Wzorzec koja­rzo­ny czę­sto z języ­kiem Java z uwa­gi na spe­cy­fi­kę tego języ­ka, jed­nak jest sto­so­wa­nie na eta­pie pro­jek­to­wa­nia opro­gra­mo­wa­nia (model PIM, Platform Independent Model) nie narzu­ca uży­cia tego języka. 

artefakt biznesowy

abs­trak­cja (nazwa) repre­zen­tu­ją­ca kate­go­rię lub pod­ka­te­go­rię (kla­sę) biz­ne­so­wą uży­wa­na jako poję­cie do budo­wy bazy wie­dzy o orga­ni­za­cji np. pro­ces, zdol­ność do, poten­cjał biz­ne­so­wy, komór­ka orga­ni­za­cyj­na (źr. http://​www​.omgwi​ki​.org/​b​a​w​g​/​d​o​k​u​.​p​h​p​?​i​d​=​g​l​o​s​s​ary)

artifact-centric paradigm

para­dyg­mat zakła­da­ją­cy, że każ­da fir­ma, nie­za­leż­nie od tego, jakie fizycz­ne towa­ry lub usłu­gi wytwa­rza, opie­ra się na doku­men­ta­cji han­dlo­wej; musi ona zapi­sy­wać szcze­gó­ły tego, co wytwa­rza w posta­ci kon­kret­nych infor­ma­cji; arte­fak­ty biz­ne­so­we są mecha­ni­zmem do zapi­su tych infor­ma­cji w jed­nost­kach, któ­re są kon­kret­ne, iden­ty­fi­ko­wal­ne, samo­opi­su­ją­ce się i nie­po­dziel­ne; jest to kon­cep­cja arte­fak­tów, czy­li obiek­tów seman­tycz­nych, w kon­tek­ście tech­ni­ki kon­stru­owa­nia for­mal­nych, ale intu­icyj­nych opi­sów ope­ra­cyj­nych przed­się­bior­stwa: arte­fak­ty biz­ne­so­we (lub doku­men­ta­cja biz­ne­so­wa) sta­no­wią pod­sta­wę dla fak­to­ry­za­cji wie­dzy. Nigam, A., & Caswell, N. S. (2003). Business arti­facts: An appro­ach to ope­ra­tio­nal spe­ci­fi­ca­tion. IBM Systems Journal42(3), 428?445. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​4​2​3​.​0​428

asocjacja

patrz: zwią­zek

atomowy proces biznesowy

patrz: ele­men­tar­ny pro­ces biznesowy

audyt

nie­za­leż­na oce­na danej orga­ni­za­cji, sys­te­mu, pro­ce­su, pro­jek­tu lub pro­duk­tu; przed­miot audy­tu jest bada­ny pod wzglę­dem zgod­no­ści z okre­ślo­ny­mi stan­dar­da­mi, wzor­ca­mi, lista­mi kon­tro­l­ny­mi, prze­pi­sa­mi pra­wa, nor­ma­mi lub prze­pi­sa­mi wewnętrz­ny­mi orga­ni­za­cji (poli­ty­ki, pro­ce­du­ry)

baza dokumentowa

(doku­men­to­wa baza danych) typ bazy NoSQL, naj­bar­dziej zna­ną bazą doku­men­to­wą jest MongoDB, bazy tego typu prze­cho­wu­ją dane w posta­ci struk­tu­ral­nych (np. JSON, XML) lub nie­struk­tu­ral­nych cią­gów zna­ków, zale­ta­mi baz doku­men­to­wych są: nawet 1000 krot­nie krót­szy czas pobra­nia doku­men­tu w sto­sun­ku do baz RDBMS (rela­cyj­ne bazy danych), intu­icyj­ny model danych (natu­ral­ne doku­men­ty), moż­li­wość dyna­micz­nej zmia­ny struk­tu­ry danych bez koniecz­no­ści inge­ren­cji w już zebra­ne dane i ich struk­tu­ry, powszech­ność i uni­wer­sal­ność for­ma­tów takich XML i JSON, peł­na zgod­ność z sys­te­ma­mi obiek­to­wy­mi (nie jest potrzeb­na war­stwa ORM), brak potrze­by sto­so­wa­nia języ­ków typu SQL.źr.:

mongoDB. (2020, October). MongoDB Architecture Guide: Overview. A MongoDB White Paper. https://info-mongodb-com.s3.us-east‑1.amazonaws.com/MongoDB_Architecture_Guide.pdf?utm_campaign=Int_OC_MongoDB-Architecture-Guide_01_20_WW%20-%20Autoresponder&utm_medium=email&utm_source=eloqua&utm_term=Thank%20you%20for%20downloading%20the%20MongoDB%20Architecture%20Guide

BCE

wzo­rzec Boundary-Control-Entity wywo­dzi się z opu­bli­ko­wa­nej w 1992 r. meto­dy OOSE opar­tej na przy­pad­kach uży­cia, autor­stwa Ivara Jacobsona, zakła­da mode­lo­wa­nie struk­tu­ry kom­po­nen­tów z uży­ciem trzech typów blo­ków kon­struk­cyj­nych (kla­sy o jed­nej okre­ślo­nej odpo­wie­dzial­no­ści): «boun­da­ry» (gra­ni­ca sys­te­mu, inter­fejs), «con­trol» (ste­ro­wa­nie, reali­za­cja logi­ki sys­te­mu), «enti­ty» (utrwa­lo­ny obiekt biz­ne­so­wy, repre­zen­tu­je zro­zu­mia­ły dla czło­wie­ka ele­ment infor­ma­cji, danych); w UML są to ste­reo­ty­py klas lub obiek­tów, wszyst­kie powin­ny mieć ope­ra­cje, mode­le abs­trak­cyj­ne mogę nie mieć atry­bu­tów; (Kama et al., 2011; Żeliński, 2019), poni­żej pod­sta­wo­wa struk­tu­ra reali­za­cji usłu­gi apli­ka­cji (przy­pad­ku użycia):

Graficzna for­ma pre­zen­ta­cji, od lewej odpo­wied­nio ste­reo­ty­py: «boun­da­ry» , «con­trol» , «entity»Wzorzec BCE bywa czę­sto sto­so­wa­ny łącz­nie z inny­mi wzor­ca­mi pro­jek­to­wy­mi. Poniższy przy­kład obra­zu­je przy­kła­do­wą archi­tek­tu­rę z zasto­so­wa­niem innych wzor­ców archi­tek­to­nicz­nych (repo­si­to­ry, enve­lo­pe, saga/scenario):Zastosowanie wzor­ce BCE wraz ze ste­reo­ty­pa­mi okre­śla­ją­cy­mi role klas. «Document» jest tre­ścią atry­bu­tu doku­ment (jest to czę­sto ciąg zna­ków np. w for­ma­cie JSON lub XML, patrz wzo­rzec envelope)

Poniżej dia­gram przy­pad­ków uży­cia opi­su­ją­cy kon­tekst powyż­sze­go kom­po­nen­tu:Diagram przy­pad­ków uży­cia jak kon­tekst (zakres)Wzorzec BCE jest czę­sto błęd­nie utoż­sa­mia­ny z wzor­cem MVC.

BMM

Business Motivation Model, nota­cja opu­bli­ko­wa­na przez orga­ni­za­cję Object Management Group (https://​www​.omg​.org/​s​p​e​c​/​B​MM/), dostar­cza model poję­cio­wy do ana­li­zy, two­rze­nia, doku­men­to­wa­nia biz­ne­spla­nu i metod zarzą­dza­nia oraz sys­tem sym­bo­li pozwa­la­ją­cy two­rzyć dia­gra­my mode­lu­ją­ce ele­men­ty misji i wizji, stra­te­gii i celów biz­ne­so­wych orga­ni­za­cji, nota­cja BMM odwo­łu­je do nota­cji BPMN i SBVR a tak­że do mode­li struk­tur orga­ni­za­cyj­nych, poni­żej szkie­let systemu:

BPMN

Business Process Model and Notation, sys­tem poję­cio­wy i gra­ficz­na nota­cja pozwa­la­ją­ca mode­lo­wać i doku­men­to­wać w gra­ficz­nej for­mie pro­ce­sy biz­ne­so­we i pro­ce­du­ry; pozwa­la tak­że na mode­lo­wa­nie i doku­men­to­wa­nie współ­pra­cy mie­dzy orga­ni­za­cja­mi. (spe­cy­fi­ka­cja: https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/)

capability requirement

(wymóg doty­czą­cy zdol­no­ści) rodzaj wyma­ga­nia opi­su­ją­cy zdol­ność, któ­rą orga­ni­za­cja lub sys­tem musi zapew­nić, aby zaspo­ko­ić potrze­bę inte­re­sa­riu­sza (patrz tak­że: wyma­ga­nia biznesowe).(źr.: NIST SP 800 – 37 Rev. 2)

CIM

ang. Computation Independent Model; pierw­szy etap pro­ce­su MDA (ang. Model Driven Architecture, model nie­za­leż­ny od tech­no­lo­gii prze­twa­rza­nia) (Model Driven Architecture (MDA) | Object Management Group, n.d.); zawie­ra model pro­ce­sów biz­ne­so­wych zorien­to­wa­ny na biz­nes (nie zawie­ra żad­nych tech­no­lo­gii) oraz ana­li­zę poję­cio­wą i regu­ły biz­ne­so­we (SBVR), ana­li­za poję­cio­wa jest naj­istot­niej­szym ele­men­tem CIM, gdyz zapew­nia jed­no­znacz­ność poję­cio­wą oraz spój­ny i nie­sprzecz­ny sys­tem pojęć:

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011.
? IFIP International Federation for Information Processing 2011(patrz tak­że słow­nik IGI Global)

CRUD

to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń); są to czte­ry pod­sta­wo­we ope­ra­cje na doku­men­tach (lub tak zwa­nych kar­to­te­kach, obiek­tach słu­żą­cych do zapa­mię­ty­wa­nia danych, pier­wot­nie doty­czy­ło tak zwa­nych encji w bazach rela­cyj­nych, obiek­ta­mi odpo­wie­dzial­nym za prze­cho­wy­wa­nie doku­men­tów są repo­zy­to­ria (Repository); skrót ten tak­że jest wyko­rzy­sty­wa­ny do okre­śla­nia praw do doku­men­tów na mode­lach pro­ce­sów biz­ne­so­wych i jako alter­na­tyw­ne sce­na­riu­sze przy­pad­ków uży­cia w tak zwa­nych macier­zach CRUD:

(ź.:Imam, A. A., Basri, S., Ahmad, R., Watada, J., & González-Aparicio, M. T. (2018). Automatic sche­ma sug­ge­stion model for NoSQL docu­ment-sto­res data­ba­ses. Journal of Big Data5(1), 46. https://doi.org/10.1186/s40537-018‑0156‑1 Truica, C.-O., Radulescu, F., Boicea, A., & Bucur, I. (2015). Performance eva­lu­ation for CRUD ope­ra­tions in asyn­chro­no­usly repli­ca­ted docu­ment orien­ted data­ba­se. 2015 20th International Conference on Control Systems and Computer Science, 191 – 196.
Gupta, S. (2012). Simplifying Use Case Models using CRUD Patterns2(2), 3.

dane

fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach, infor­ma­cje wyra­żo­ne w pew­nym języ­ku (s.j.p. ency­klo­pe­dia PWN)

decyzja

posta­no­wie­nie będą­ce wyni­kiem doko­na­nia wybo­ru (s.j.p.); decy­zja ? nawet bar­dzo skom­pli­ko­wa­na ? nie jest pro­ce­sem a zaist­nia­łym fak­tem, odpo­wie­dzią na zasta­ne warun­ki [przyp. J. Żeliński], (patrz tak­że tabli­ca decy­zyj­na” i drze­wo decyzyjne”)

dedukcja

[łac. deduc­tio ?wypro­wa­dze­nie?], log. rozu­mo­wa­nie (wnio­sko­wa­nie), któ­re posia­da cechę nie­za­wod­no­ści, tzn. od praw­dzi­wych prze­sła­nek pro­wa­dzi do praw­dzi­wych wnio­sków dzię­ki zasto­so­wa­niu nie­za­wod­nej regu­ły wnio­sko­wa­nia (wnio­sko­wa­nie); (patrz: sys­tem deduk­cyj­ny, rachu­nek zdań)wybrane pod­sta­wo­we regu­ły wnioskowania:

  • pra­wo wyłą­czo­ne­go środ­ka (z dwóch zdań: zda­nia lub jego zaprze­cze­nia jed­no zawsze jest praw­dzi­we), pra­wo to jest odpo­wied­ni­kiem regu­ły ter­tium non datur (łac. trze­ciej moż­li­wo­ści nie ma)
  • pra­wo sprzecz­no­ści, cza­sem tak­że pra­wo nie­sprzecz­no­ści (nie może być jed­no­cze­śnie praw­dzi­we zda­nie i jego zaprzeczenie)
  • pra­wo sylo­gi­zmu, pra­wo prze­chod­no­ści impli­ka­cji (jeże­li z jed­ne­go zda­nia wyni­ka dru­gie i z dru­gie­go trze­cie, to z pierw­sze­go wyni­ka trzecie)
  • pra­wa transpozycji:
    • jeże­li z jed­ne­go zda­nia wyni­ka dru­gie, to z zaprze­cze­nia dru­gie­go wyni­ka zaprze­cze­nie pierw­sze­go, pra­wo to jest odpo­wied­ni­kiem ary­sto­te­le­sow­skiej regu­ły wnio­sko­wa­nia modus tol­len­do tol­lens (łac. spo­sób zaprze­cza­ją­cy przy pomo­cy zaprzeczenia)
    • jeże­li z zaprze­cze­nia zda­nia wyni­ka dru­gie zda­nie, to z zaprze­cze­nia dru­gie­go wyni­ka pierw­sze, pra­wo to jest odpo­wied­ni­kiem ary­sto­te­le­sow­skiej regu­ły wnio­sko­wa­nia modus tol­len­do ponens (łac. spo­sób potwier­dza­ją­cy przy pomo­cy zaprzeczenia)
    • jeże­li z jed­ne­go zda­nia wyni­ka zaprze­cze­nie dru­gie­go, to z dru­gie­go wyni­ka zaprze­cze­nie pierw­sze­go, pra­wo to jest odpo­wied­ni­kiem ary­sto­te­le­sow­skiej regu­ły wnio­sko­wa­nia modus ponen­do tol­lens (łac. spo­sób zaprze­cza­ją­cy przy pomo­cy potwierdzenia)
  • pra­wo reduk­cji do absur­du (reduc­tio ad absur­dum): jeże­li z pierw­sze­go zda­nia wyni­ka jed­no­cze­śnie i dru­gie i zaprze­cze­nie dru­gie­go, to pierw­sze jest fałszywe
  • pra­wo Dunsa Szkota: jeże­li zda­nie jest fał­szy­we, to wyni­ka z nie­go każ­de inne zda­nie (nazy­wa­ne cza­sa­mi regu­łą manipulacji)

definicja

(defi­ni­cja rów­no­ścio­wa) skła­da się z 3 czę­ści: 1. Definiendum (wyra­że­nia defi­nio­wa­ne­go), 2. Spójnika defi­ni­cyj­ne­go ? wyra­że­nia posta­ci: jest to, zna­czy, ozna­cza, nazy­wa­my deno­tu­je, zna­czy tyle samo, co, ewen­tu­al­nie funk­to­ra zda­nio­twór­cze­go ??? albo ?=?, 3. Definiensa (wyra­że­nia defi­niu­ją­ce­go); sens sło­wa ?rów­no­ścio­wa? w odnie­sie­niu do defi­ni­cji wią­że się w popraw­nej defi­ni­cji z rów­nym ( w zna­cze­niu takim samym) zakre­sem defi­nien­dum i defi­nien­sa; zna­cze­nie defi­nien­dum powin­no być takie same, jak defi­nien­sa. (Hołówka, 2012; Malinowski, 2019; Ziembiński, 2014) 

definicja realna

kla­sy­fi­ka­tor, odno­si się do desy­gna­tów (kon­kret­nych przed­mio­tów), a nie ich ozna­cze­nia w danym języ­ku (defi­ni­cja spra­woz­daw­cza), poda­je taką cha­rak­te­ry­sty­kę przed­mio­tu, któ­rą moż­na przy­pi­sać tyl­ko i wyłącz­nie dane­mu przed­mio­to­wi; defi­ni­cja real­na powin­na poda­wać cechy (kon­sty­tu­tyw­ne) przed­mio­tu; (zda­niem Zygmunta Ziembińskiego defi­ni­cje real­ne powsta­ją na pod­sta­wie mil­czą­ce­go zało­że­nia, doko­ny­wa­ne­go przez bada­czy, że jest moż­li­we i uda­ło się wydzie­lić przed­mio­ty zali­czo­ne do przed­mio­tów dane­go rodza­ju) (Hołówka, 2012; Malinowski, 2019; Ziembiński, 2014) (ang. inten­tio­nal definition)

definicja sprawozdawcza

log. defi­ni­cja zda­ją­ca spra­wę z przy­ję­te­go w danym języ­ku spo­so­bu rozu­mie­nia zna­czeń wyra­zów (opi­so­wa) (Hołówka, 2012; Malinowski, 2019; Ziembiński, 2014) (ang. lexi­cal definitions)

definicja zakresowa

enu­me­ra­cja, enu­me­ra­tor, jest two­rzo­na poprzez wyli­cze­nie (np. dzień tygo­dnia to ponie­dzia­łek, wto­rek, śro­da, czwar­tek, pią­tek, sobo­ta, nie­dzie­la) (Hołówka, 2012; Malinowski, 2019; Ziembiński, 2014) (ang. exten­sio­nal definition)

diagram

w nauce ter­min ten jest uży­wa­ny na oba spo­so­by; na przy­kład Anderson (2003) stwier­dził bar­dziej ogól­nie, że dia­gra­my są obra­zo­wy­mi, ale abs­trak­cyj­ny­mi przed­sta­wie­nia­mi infor­ma­cji, a mapy, wykre­sy linio­we, wykre­sy słup­ko­we, pla­ny inży­nie­ryj­ne i szki­ce archi­tek­tów są przy­kła­da­mi dia­gra­mów, pod­czas gdy foto­gra­fie i wideo nimi nie są”. Z dru­giej stro­ny Lowe (1999) zde­fi­nio­wał dia­gra­my jako abs­trak­cyj­ne gra­ficz­ne przed­sta­wie­nia przed­mio­tu, któ­ry reprezentują”.W sen­sie szcze­gó­ło­wym dia­gra­my i wykre­sy sta­no­wią prze­ci­wień­stwo gra­fi­ki kom­pu­te­ro­wej, ilu­stra­cji tech­nicz­nych, info­gra­fik, map i rysun­ków tech­nicz­nych, przed­sta­wia­jąc raczej abs­trak­cyj­ne niż dosłow­ne repre­zen­ta­cje infor­ma­cji”. Istota dia­gra­mu może być postrze­ga­na jako:forma zbu­do­wa­na z wizu­al­nych ele­men­tów, któ­re nie poka­zu­ją danych ilo­ścio­wych, ale raczej związ­ki i abs­trak­cyj­ne infor­ma­cje, zbu­do­wa­ne z ele­men­tów takich jak kształ­ty geo­me­trycz­ne, któ­re są połą­czo­ne linia­mi, strzał­ka­mi lub inny­mi łącza­mi wizualnymi.Anderson, M., Cheng, P., & Haarslev, V. (2003). Theory and Application of Diagrams: First International Conference, Diagrams 2000, Edinburgh, Scotland, UK, September 1 – 3, 2000 Proceedings. Springer.Lowe, R. (1999). Cognitive Science Approaches To Understanding Diagrammatic Representations.

digital twin

(ang. cyfro­wy bliź­niak) idea po raz zasto­so­wa­na w 1960 roku kie­dy to ame­ry­kań­ska agen­cja kosmicz­na NASA potrze­bo­wa­ła stwo­rzyć fizycz­nie zdu­pli­ko­wa­ne sys­te­my na Ziemi, aby dopa­so­wać je do sys­te­mów w prze­strze­ni kosmicz­nej; jako for­mal­na kon­cep­cja powsta­ła w 2002 roku (przy­pi­sy­wa­na Michaelowi Grievesowi, wów­czas z Uniwersytetu Michigan, w 2002 r.), w lite­ra­tu­rze poja­wia się od ok. 2016 roku; cyfro­we bliź­nia­ki są wyni­kiem cią­głe­go dosko­na­le­nia w two­rze­niu pro­jek­tów pro­duk­tów i dzia­łań inży­nie­ryj­nych: prze­szły dro­gę od ręcz­ne­go kre­śle­nia rysun­ków pro­duk­tów i spe­cy­fi­ka­cji inży­nier­skich, przez kom­pu­te­ro­wo wspo­ma­ga­ne pro­jek­to­wa­nie, do inży­nie­rii sys­te­mów opar­tej na mode­lach. W obsza­rze sys­te­mo­wych ana­liz orga­ni­za­cji, tak zwa­nych ana­liz biz­ne­so­wych, każ­da fir­ma może stwo­rzyć cyfro­wą kopię swo­ich pro­ce­sów (model pro­ce­sów: cyfro­wy bliź­niak pro­ce­sów biz­ne­so­wych) w celu pro­wa­dze­nia ana­liz wpły­wu zmian na całość. Taki model to model rze­czy­wi­ste­go pro­ce­su, usłu­gi lub pro­duk­tu, a nawet całej orga­ni­za­cji, któ­ry umoż­li­wia testo­wa­nie róż­nych sce­na­riu­szy w śro­do­wi­sku o zero­wym ryzy­ku (czy­li na modelach).Cyfrowe bliź­nia­ki nie tyl­ko mode­lu­ją infra­struk­tu­rę, mode­lu­ją tak­że pro­ce­sy biz­ne­so­we, pozwa­la­ją użyt­kow­ni­ko­wi testo­wać nowe pro­ce­du­ry, dane wej­ścio­we i inne zmien­ne, aby zoba­czyć, jak wpły­wa­ją one na wydaj­ność pro­ce­su, pozwa­la­ją spraw­dzić, jak zmia­ny w jed­nym obsza­rze wpły­wa­ją na cały eko­sys­tem orga­ni­za­cji. Są np. bar­dzo przy­dat­ne w ana­li­zach wpły­wu wdro­żeń sys­te­mów IT na organizację.

Stworzenie takie­go mode­lu powi­nien być jed­nym z pierw­szych kro­ków do trans­for­ma­cji pro­ce­sów biz­ne­so­wych w fir­mie i wdro­żeń sys­te­mów ERP.

Dorrer, M. G. (2020). The digi­tal twin of the busi­ness pro­cess model. Journal of Physics: Conference Series1679(3), 032096. https://​doi​.org/​1​0​.​1​0​8​8​/​1​742 – 6596/1679/3/032096

Singh, M., Fuenmayor, E., Hinchy, E. P., Qiao, Y., Murray, N., & Devine, D. (2021). Digital twin: Origin to futu­re. Applied System Innovation4(2), 36.

Jones, D., Snider, C., Nassehi, A., Yon, J., & Hicks, B. (2020). Characterising the Digital Twin: A sys­te­ma­tic lite­ra­tu­re review. CIRP Journal of Manufacturing Science and Technology29, 36 – 52. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​c​i​r​p​j​.​2​0​2​0​.​0​2​.​002

dogmat

twier­dze­nie przyj­mo­wa­ne za pew­ne i praw­dzi­we jedy­nie na mocy auto­ry­te­tu oso­by, któ­ra je wygłasza

doksastyczny

opar­ty na zało­że­niu (przy­pusz­cze­niu)

dokument

nośnik infor­ma­cji umoż­li­wia­ją­cy zapo­zna­nie się z jej tre­ścią (USTAWA z dnia 23 kwiet­nia 1964 r. Kodeks cywil­ny); ta praw­na defi­ni­cja ozna­cza, że jest nim każ­dy utrwa­lo­ny mate­riał np. w posta­ci tek­stu, foto­gra­fii lub jaki­kol­wiek inny przed­miot, mają­cy war­tość informacyjną; 

dokument elektroniczny

praw­na defi­ni­cja poję­cia doku­ment elek­tro­nicz­ny to: sta­no­wią­cy odręb­ną całość zna­cze­nio­wą zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej i zapi­sa­ny na infor­ma­tycz­nym nośni­ku danych (na podst. USTAWA z dnia 17 lute­go 2005 r. o infor­ma­ty­za­cji dzia­łal­no­ści pod­mio­tów reali­zu­ją­cych zada­nia publicz­ne), patrz tak­że: arti­fact-cen­tric para­digm; na pod­sta­wie defi­ni­cji poję­cia doku­ment (patrz słow­nik) moż­na wywo­dzić, że ww. zbiór danych, zapi­sa­ny na, innym niż elek­tro­nicz­ny, nośni­ku, są doku­men­tem (i tak np. doku­ment elek­tro­nicz­ny” po jego wydru­ko­wa­niu jest dokumentem”).Rozporządzenie Parlamentu Europejskiego i Rady (UE) z dnia 23 lip­ca 2014 r. w spra­wie iden­ty­fi­ka­cji elek­tro­nicz­nej i usług zaufa­nia w odnie­sie­niu do trans­ak­cji elek­tro­nicz­nych na ryn­ku wewnętrz­nym oraz uchy­la­ją­ce dyrek­ty­wę 1999/93/WE, zwa­ne dalej ?elDAS?, w art. 3 pkt 35 defi­niu­je doku­ment elek­tro­nicz­ny jako każ­dą treść prze­cho­wy­wa­ną w posta­ci elek­tro­nicz­nej, w szcze­gól­no­ści tekst lub nagra­nie dźwię­ko­we, wizu­al­ne lub audio­wi­zu­al­ne. Rozporządzenie elDAS nie róż­ni­cu­je doku­men­tu ze wzglę­du na spo­sób jego spo­rzą­dze­nia. Upraszczając, każ­da treść w posta­ci elek­tro­nicz­nej jest w świe­tle elDAS – doku­men­tem elektronicznym.Tym samym np. skan ofer­ty (zawie­ra­ją­cy treść ofer­ty) mie­ści się w defi­ni­cji doku­men­tu elek­tro­nicz­ne­go w rozu­mie­niu elDAS.

drzewo decyzyjne

gra­ficz­na meto­da wspo­ma­ga­nia pro­ce­su podej­mo­wa­nia decy­zji (doko­ny­wa­nia wybo­ru), każ­de drze­wo moż­na zamie­nić na zestaw reguł decy­zyj­nych, dla dużej licz­by warian­tów moż­li­wych, gdy sens ma mała ich licz­ba, narzę­dzie bar­dzo nie­efek­tyw­ne i trud­ne do aktu­ali­za­cji, decy­zja z uży­ciem drze­wa decy­zyj­ne­go podej­mo­wa­na jest w wie­lu kro­kach, tylu ile pozio­mów węzłów ma dane drze­wo decy­zyj­ne (porów­naj z tabli­ca decyzyjna”)

Dublin Core

spe­cy­fi­ka­cja stan­da­ry­zu­ją­ca meta­da­ne (ety­kie­ty i zawar­tość) doku­men­tów, zale­ca­na dla sys­te­mów records mana­ge­ment” (zarza­dza­nie aktami/dokumentami/informacją) ich spe­cy­fi­ka­cję zawie­ra doku­ment DCMI Metadata Terms.

dygitalizacja

(digi­ta­li­za­cja, cyfry­za­cja) nada­wa­nie posta­ci cyfro­wej danym pisa­nym i dru­ko­wa­nym, zawar­tym na nośni­kach magne­tycz­nych lub innych (s.j.p.)

EFFBD

Enhanced Function Flow Block Diagram (wię­cej: https://​www​.vitech​corp​.com/​r​e​s​o​u​r​c​e​s​/​c​o​r​e​/​o​n​l​i​n​e​h​e​l​p​/​d​e​s​k​t​o​p​/​V​i​e​w​s​/​E​n​h​a​n​c​e​d​_​F​u​n​c​t​i​o​n​_​F​l​o​w​_​B​l​o​c​k​_​D​i​a​g​r​a​m​_​(​E​F​B​D​)​.​htm)

ekonomia

nauka o pra­wach rzą­dzą­cych pro­duk­cją, wymia­ną i podzia­łem dóbr w spo­łe­czeń­stwie; też: nauka o racjo­nal­nym gospo­da­ro­wa­niu (źr. s.j.p.)

ekosystem inżynierii cyfrowej

tak­że Digital Engineering Ecosystem, obej­mu­je wza­jem­nie połą­czo­ne śro­do­wi­ska cyfro­we przed­się­biorstw, sie­ci inte­re­sa­riu­szy i dane seman­tycz­ne, któ­re umoż­li­wia­ją wymia­nę cyfro­wych arte­fak­tów z wia­ry­god­ne­go źró­dła w celu reali­za­cji swo­ich celów (źr. OMG MBSE wiki)

elementarny

(tak­że ato­mo­wy”) w mode­lo­wa­niu: nie­pod­le­ga­ją­cy dal­szej dekom­po­zy­cji (źr. OMG​.org)

elementarny proces biznesowy

zada­nie wyko­ny­wa­ne przez jed­ną oso­bę, w jed­nym miej­scu i okre­ślo­nym cza­sie, w odpo­wie­dzi na okre­ślo­ne zda­rze­nie biz­ne­so­we; zada­nie to pro­wa­dzi do uzy­ska­nia mie­rzal­nej war­to­ści biz­ne­so­wej; po jego wyko­na­niu dane są w spój­nym sta­nie; (przy­pad­ki uży­cia powin­ny reali­zo­wać ele­men­tar­ne pro­ce­sy biz­ne­so­we, cytat z : UML i wzor­ce pro­jek­to­we, Craig Larman)

enumeracja

pre­cy­zyj­ne wyli­cze­nie (lista) dopusz­czal­nych war­to­ści, nazw rze­czy itp; enu­me­ra­tyw­ne” wyli­cze­nie ozna­cza, że inne nazwy, niż wymie­nio­ne, są nie­do­pusz­czal­ne (np. nazwy dni tygo­dnia lub mie­się­cy); w infor­ma­ty­ce ozna­cza zamknię­ty i nie­mo­dy­fi­ko­wal­ny słow­nik war­to­ści atrybutu 

envelope

(koper­ta), wzo­rzec pro­jek­to­wy sto­so­wa­ny do budo­wy repo­zy­to­riów tre­ści orga­ni­zo­wa­nych i prze­twa­rza­nych jako doku­men­ty; zakła­da, że dane są orga­ni­zo­wa­ne w kon­tek­sto­we agre­ga­ty jako dokumenty/formularze «Document» (JSON, XML, inne), doku­men­ty są prze­cho­wy­wa­ne jako war­to­ści atry­bu­tu doku­ment” obiek­tu «enti­ty» będą­ce­go jego nośni­kiem, wyszu­ki­wa­nie (indek­so­wa­nie) odby­wa się na bazie meta­da­nych sta­no­wią­cych dodat­ko­we atry­bu­ty tego nośnika:

reali­za­cja wzor­ca Koperta (Envelope)Podstawowe zale­ty i korzy­ści: oddzie­le­nie logi­ki prze­twa­rza­nia i wydaj­no­ści apli­ka­cji od struk­tu­ry danych, unie­za­leż­nie­nie się od róż­no­rod­no­ści i zmian struk­tu­ry doku­men­tów, prze­cho­wy­wa­nie sta­tu­su doku­men­tów poza doku­men­tem. Odmianą tego wzor­ca jest sto­so­wa­nie reper­to­riów czy­li tema­tycz­nych (dzie­dzi­no­wych, kon­tek­sto­wych) sepa­ro­wa­nych zesta­wów metadanych:Repertoria

W tym przy­pad­ku roz­dzie­lo­no role prze­cho­wy­wa­nia od indek­so­wa­nia: obiek­ty kla­sy Kontekst to tyl­ko dzie­dzi­no­we (tema­tycz­ne) meta­da­ne z odno­śni­kiem do miej­sca prze­cho­wy­wa­nia doku­men­tu, doku­men­ty prze­cho­wy­wa­ne są w koper­tach” Dokument ozna­czo­nych tyl­ko atry­bu­tem ID. Tak np. dzia­ła sys­tem biblio­tecz­ny, w któ­rym do jed­ne­go księ­go­zbio­ru (doku­men­ty) są osob­no kata­lo­gi: wg. auto­ra, wg. rodza­ju, wg. tytu­łu itp.. Ta wer­sja jest wyko­rzy­sty­wa­na gdy doku­men­ty są trzy­ma­ne w chmu­rze w bazie NoSQL typu Key Value, a logi­ka (w tym wła­śnie reper­to­ria) są w naszej macie­rzy­stej apli­ka­cji. Wtedy czę­sto mamy tyl­ko jed­no reper­to­rium jako logicz­ne powią­za­nie infor­ma­cji o doku­men­tach, z tymi doku­men­ta­mi. Jeden z opi­sów wzorca:Feldman, D. (2018, sier­pień 10). Design Patterns: The Envelope Design Pattern [Blog]. MarkLogic. https://​www​.mar​klo​gic​.com/​b​l​o​g​/​e​n​v​e​l​o​p​e​-​d​e​s​i​g​n​-​p​a​t​t​e​rn/Przykłady zastosowań:Zelinski, J. (2021). Digital docu­ments as data car­riers and a method of data mana­ge­ment guaran­te­eing the unam­bi­gu­ity of the recor­ded infor­ma­tion. W Management and Strategies for Digital Enterprise Transformation (T. 1). IGI Global. https://​www​.igi​-glo​bal​.com/​c​h​a​p​t​e​r​/​d​i​g​i​t​a​l​-​d​o​c​u​m​e​n​t​s​-​a​s​-​d​a​t​a​-​c​a​r​r​i​e​r​s​-​a​n​d​-​a​-​m​e​t​h​o​d​-​o​f​-​d​a​t​a​-​m​a​n​a​g​e​m​e​n​t​-​g​u​a​r​a​n​t​e​e​i​n​g​-​t​h​e​-​u​n​a​m​b​i​g​u​i​t​y​-​o​f​-​t​h​e​-​r​e​c​o​r​d​e​d​-​i​n​f​o​r​m​a​t​i​o​n​/​2​7​5​700

epistemiczny

opar­ty na wiedzy

epistemologia

teo­ria lub meto­do­lo­gia nauki upra­wia­na w świe­tle filo­zo­ficz­nej teo­rii pozna­nia, tak­że, jako teo­ria pozna­nia, dział filo­zo­fii trak­tu­ją­cy o przed­mio­cie, tre­ści, pro­ce­sach, spo­so­bach, gra­ni­cach i kry­te­riach ludz­kie­go poznania

ERD

model związ­ków encji, okre­śla­ny jest rów­nież jako: model E‑R lub ERD. Skróty te pocho­dzą od angiel­skiej nazwy Entity Relationship Diagram; meto­da zapre­zen­to­wa­na zosta­ła po raz pierw­szy przez Petera Chena w 1976 roku; póź­niej­szych, drob­nych mody­fi­ka­cji w dia­gra­mie doko­na­li mię­dzy inny­mi Charles Bachman oraz James Martin; jest to jed­na z naj­po­pu­lar­niej­szych, dotych­czas zapro­jek­to­wa­nych, metod mode­lo­wa­nia danych (źr.: mFiles); ERD to nota­cja słu­żą­ca do mode­lo­wa­nia danych w mode­lu rela­cyj­nym (dia­gram ERD), zakła­da­ją­cym usu­wa­nie redun­dan­cji danych w bazie danych, to zna­czy, że okre­ślo­ne dane prze­cho­wy­wa­ne są raz w jed­nym miej­scu (tabe­la) i lin­ko­wa­ne są do innych, powią­za­nych z nimi logicz­nie, (nor­ma­li­za­cja mode­lu danych) danych; alter­na­tyw­ną meto­dą zarzą­dza­nia dany­mi, opra­co­wa­ną pod koniec lat 90-tych, są bazy zwa­ne NoSQL (Not only SQL), zysku­ją­ce coraz więk­szą popu­lar­ność z uwa­gi na więk­szą wydaj­ność i ska­lo­wal­ność, szcze­gól­nie w sys­te­mach BigData. 

ERP

System Enterprise Resource Planning (ERP) jest sys­te­mem infor­ma­tycz­nym przed­się­bior­stwa
zapro­jek­to­wa­nym w celu inte­gra­cji i opty­ma­li­za­cji pro­ce­sów biz­ne­so­wych i trans­ak­cji w kor­po­ra­cji. ERP to kon­cep­cje i sys­te­my opar­te na prze­my­śle i jest powszech­nie akcep­to­wa­ne przez prze­mysł jako prak­tycz­ne roz­wią­za­nie w celu osią­gnię­cia inte­gra­cji sys­te­mów infor­ma­cyj­nych przed­się­bior­stwa. [Moon, Y. B. (2007). Enterprise Resource Planning (ERP): A review of the lite­ra­tu­re. International Journal of Management and Enterprise Development4(3), 235. https://​doi​.org/​1​0​.​1​5​0​4​/​I​J​M​E​D​.​2​0​0​7​.​0​1​2​679]

evidence-based analysis

w inży­nie­rii opro­gra­mo­wa­nia podej­ście do ana­li­zy i pro­jek­to­wa­nia opar­te na dowo­dach, czy­li na moż­li­wych do potwier­dza­nie fak­tach zamiast na subiek­tyw­nych rela­cjach i ocze­ki­wa­niach (patrz tak­że arti­fact-cen­tric paradigm)Kitchenham, B. A., Dyb?, T., & J?rgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.

fakt

to, co zaszło lub zacho­dzi w rze­czy­wi­sto­ści (źr. SJP PWN), w nota­cji SBVR ele­ment łączą­cy poję­cia w wyra­że­nie (pre­dy­kat zda­nio­twór­czy łączą­cy nazwy w zdanie)

falsyfikacja

zasa­da logi­ki mówią­ca, że wska­za­nie fak­tu nie­zgod­ne­go z teo­rią oba­la teo­rię; odmia­na jed­ne­go z rozu­mo­wań zwa­ne­go spraw­dza­niem; ter­min ten roz­po­wszech­nio­ny został za spra­wą kry­tycz­ne­go racjo­na­li­zmu Karla Poppera i obec­nie sta­no­wi pod­sta­wę meto­dy nauko­wej; wnio­sko­wa­nie fal­sy­fi­ku­ją­ce prze­bie­ga według sche­ma­tu modus tol­len­do tol­lens; modus tol­lens (łac. modus tol­len­do tol­lens, spo­sób zaprze­cza­ją­cy przy pomo­cy zaprze­cze­nia) ? wnio­sko­wa­nie logicz­ne, regu­ła logi­ki mówią­ca, że jeśli zaak­cep­tu­je­my, że z X wyni­ka Y oraz to, że Y jest fał­szy­we, to musi­my zaak­cep­to­wać też fał­szy­wość X. 

Filozofia informatyki

Filozofia infor­ma­ty­ki zaj­mu­je się zagad­nie­nia­mi onto­lo­gicz­ny­mi i meto­do­lo­gicz­ny­mi wyni­ka­ją­cy­mi z dys­cy­pli­ny aka­de­mic­kiej infor­ma­ty­ki, a tak­że prak­ty­ką two­rze­nia opro­gra­mo­wa­nia oraz jego komer­cyj­nym i prze­my­sło­wym wdro­że­niem. Dokładniej, filo­zo­fia infor­ma­ty­ki roz­wa­ża onto­lo­gię i epi­ste­mo­lo­gię sys­te­mów obli­cze­nio­wych, kon­cen­tru­jąc się na pro­ble­mach zwią­za­nych z ich spe­cy­fi­ka­cją, pro­gra­mo­wa­niem, wdra­ża­niem, wery­fi­ka­cją i testo­wa­niem. Złożona natu­ra pro­gra­mów kom­pu­te­ro­wych zapew­nia, że ??wie­le poję­cio­wych pytań pod­no­szo­nych przez filo­zo­fię infor­ma­ty­ki ma pokrew­ne pyta­nia w filo­zo­fii mate­ma­ty­ki , filo­zo­fii nauk empi­rycz­nych i filo­zo­fii tech­no­lo­gii.
(źr. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​c​o​m​p​u​t​e​r​-​s​c​i​e​n​ce/)

funkcjonalność

(funk­cjo­nal­ny), okre­ślo­na funk­cja sys­te­mu, zada­nie, moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez pro­gram kom­pu­te­ro­wy (apli­ka­cję), patrz tak­że potrzeba

generalizacja

uogól­nie­nie opar­te na wybra­nych cechach wspól­nych ele­men­tów (defi­ni­cji) uogól­nia­nych, utwo­rze­nie defi­ni­cji o posze­rzo­nym zakre­sie: uogól­nie­nie obej­mu­ją­ce zna­cze­nia pojęć generalizowanych

homunkulus

w filo­zo­fii infor­ma­ty­ki wizu­ali­za­cja isto­ty ludz­kiej, gdzie każ­da część cia­ła jest pro­por­cjo­nal­na do obsza­ru, któ­ry zaj­mu­je ona w mózgu. (Searle, 1990, 2013)

ICOM

meto­da, sys­tem mode­lo­wa­nia pro­ce­su biz­ne­so­we­go z uży­ciem pojęć: wej­ście, wyj­ście, ste­ro­wa­nie, mecha­nizm (ang. Input, Output, Controll, Mechanizm), zasto­so­wa­na mię­dzy inny­mi w nota­cji IDEF0

idealizacja

w meto­do­lo­gii: model teo­re­tycz­ny przyj­mu­ją­cy okre­ślo­ne cechy dla nie­ist­nie­ją­cych w rze­czy­wi­sto­ści warun­ków, dosko­na­łych w danym zakre­sie, meto­da ide­ali­za­cji i kon­kre­ty­za­cji: (meto­do­lo­gia) dwu­eta­po­wa meto­da badaw­cza pole­ga­ją­ca w pierw­szym eta­pie na ide­ali­za­cji bada­nych obiek­tów, kon­stru­owa­niu typów ide­al­nych”, mode­li teo­re­tycz­nych” i wypro­wa­dza­niu praw ide­ali­za­cyj­nych, w dru­gim eta­pie zaś na stop­nio­wej kon­kre­ty­za­cji (aprok­sy­ma­cji) usta­lo­nych praw i teo­rii ide­ali­za­cyj­nych przez stop­nio­we uchy­la­nie zało­żeń ide­ali­zu­ją­cych i mody­fi­ka­cję tych praw i teo­rii, przy­bli­ża­ją­cą je do warun­ków rze­czy­wi­stych; meto­da ta jest sto­so­wa­na we wszyst­kich naukach empi­rycz­nych jako pod­sta­wa wszel­kich teo­rii nauko­wych; ide­ali­zu­je­my coś” (Stokhof et al., 2011), patrz tak­żę: Weisberg, M. (2007). Three Kinds of Idealization: The Journal of Philosophy104(12), 639 – 659. https://​doi​.org/​1​0​.​5​8​4​0​/​j​p​h​i​l​2​0​0​7​1​0​4​1​240, oraz Matthews, M. R. (2004). Idealisation and Galileo’s pen­du­lum disco­ve­ries: Historical, phi­lo­so­phi­cal and peda­go­gi­cal con­si­de­ra­tions. Science & Education13(7 – 8), 689 – 715.znane powszech­nie przy­kła­dy ide­ali­za­cji: waha­dło ide­al­necia­ło dosko­na­le czar­ne, i wie­le innych (cie­ka­wy arty­kuł: The pen­du­lum swing)

IDEF0

nota­cja mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z rodzi­ny metod IDEF (IDEF? Function Modeling Method) opar­ta na meto­dzie ICOM

implementacja systemu

rze­czy­wi­sta kon­struk­cja inży­nier­ska, wyra­żo­na jako kon­struk­cja mecha­nicz­na, opro­gra­mo­wa­nie kom­pu­te­ro­we itp. (patrz archi­tek­tu­ra sys­te­mu, J. Żeliński, Zastosowanie nota­cji UML i Ogólnej Teorii Systemów w mode­lo­wa­niu odpo­wie­dzi sys­te­mów, 2019), zna­cze­nie imple­men­ta­cji” nie jest ści­śle zde­fi­nio­wa­ne, ale ozna­cza bar­dziej wyra­fi­no­wa­ną lub wyszu­ka­ną for­mę w odnie­sie­niu do pew­ne­go kon­tek­stu mode­lo­wa­nia (UML, 2.5.1. rozdz. 7.7.3.4. Realization).

IMRaD

for­mat (struk­tu­ra) IMRaD odno­si się do opra­co­wa­nia podzie­lo­ne­go na czte­ry głów­ne sek­cje: wpro­wa­dze­nie (uza­sad­nie­nie pro­wa­dze­nia bada­nia lub eks­per­ty­zy), meto­dy (jakich narzę­dzi i metod uży­to), wyni­ki (co odkry­to, osią­gnię­to, wyja­śnio­no) i dys­ku­sja (co to zna­czy i co dalej) oraz stresz­cze­nie (pod­su­mo­wa­nie cało­ści umiesz­cza­ne na począt­ku); taka struk­tu­ra tek­stu jest wyma­ga­na od publi­ka­cji nauko­wych, a tak­że zale­ca­na do rapor­to­wa­nia wszel­kich ana­liz, sys­te­ma­tycz­nych badań w naukach spo­łecz­nych, naukach przy­rod­ni­czych lub inży­nie­rii i infor­ma­ty­ce. (Wu, 2011):

Wu, J. (2011). Improving the wri­ting of rese­arch papers: IMRAD and bey­ond. Landscape Ecology26(10), 1345 – 1349. https://doi.org/10.1007/s10980-011‑9674‑3

informacja

to, co powie­dzia­no lub napi­sa­no o kimś lub o czymś, tak­że zako­mu­ni­ko­wa­nie cze­goś, dane prze­twa­rza­ne przez kom­pu­ter (na podst. SJP); infor­ma­cja: infor­ma­cja to to jak czło­wiek zro­zu­miał dane, mozna to przed­sta­wić tak:

Dane vs. Informacja [Data vs. Information] (J.Żeliński, opra­co­wa­nie wła­sne)Prawo:Informacja może być tak­że przed­mio­tem umów zle­ceń i o dzie­ło. W przy­pad­ku umów o dzie­ło, może sta­no­wić sobą być utwór w rozu­mie­niu pra­wa autor­skie­go. Informacja nie jest dzie­łem, jeże­li sta­no­wi jedy­nie zapis (rela­cja), jest wte­dy efek­tem sta­ran­ne­go dzia­ła­nia. Dzieło, jako przed­miot umo­wy, musi być z góry okre­ślo­ne i musi mieć for­mę ucie­le­śnio­ną (nie więc dzie­łem wykład czy refe­rat, są one sta­ran­nym dzia­ła­niem). Informacja może sta­no­wić sobą know-how, pod warun­kiem jed­nak, że łącz­nie: jest nie­ujaw­nio­na, jest istot­na, jest ziden­ty­fi­ko­wa­na (ozna­czo­na). Jest to war­tość nie­ma­te­rial­na, jed­nak jej postać musi być ucie­le­śnio­na (utrwa­lo­na, jako treść: doku­ment). Informacja nie może być przed­mio­tem wła­sno­ści (bo nie moż­na jej jako takiej komuś odebrać)!Informacja to dane opi­su­ją­ce świat, prze­twa­rza­nie infor­ma­cji to zbie­ra­nie danych, ich udo­stęp­nia­nie oraz mody­fi­ko­wa­nie. Sam fakt posia­da­nia okre­ślo­nych danych nie sta­no­wi i ich prze­twa­rza­nia, gdyż prze­twa­rza­nie danych ozna­cza zdol­no­ści do ich inter­pre­ta­cji, to zaś wyma­ga co naj­mniej odczy­ta­nia. System infor­ma­cyj­ny zbiór metod, narzę­dzi i nośni­ków danych, pozwa­la­ją­cy na doko­ny­wa­nie wyżej opi­sa­nych ope­ra­cji. Literatura:Barański, M. (2018). Informacja jako przed­miot zobo­wią­za­nia umow­ne­go. Studia Iuridica72, 41?69. https://​www​.rese​arch​ga​te​.net/​p​u​b​l​i​c​a​t​i​o​n​/​3​2​4​5​7​1​7​6​4​_​I​n​f​o​r​m​a​c​j​a​_​j​a​k​o​_​p​r​z​e​d​m​i​o​t​_​z​o​b​o​w​i​a​z​a​n​i​a​_​u​m​o​w​n​e​g​o​/​d​o​w​n​l​oadPapakitsos, E. C. (2020). Reconsidering the histo­ry and con­text of infor­ma­tion scien­ce. International Journal of Advanced Scientific Research, Volume 5(Issue 4), 5, 43?47.Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tuhttps://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006

inżynieria

pro­jek­to­wa­nie oraz kon­stru­owa­nie obiek­tów lub urzą­dzeń tech­nicz­nych (źr. s.j.p. PWN)

inży­nie­ria oprogramowania

(1) zasto­so­wa­nie sys­te­ma­tycz­ne­go, zdy­scy­pli­no­wa­ne­go i mie­rzal­ne­go podej­ścia do roz­wo­ju, dzia­ła­nia i utrzy­ma­nia opro­gra­mo­wa­nia; to zna­czy: zasto­so­wa­nie zasad inży­nie­rii do two­rze­nia opro­gra­mo­wa­nia,
(2) tak­że bada­nie metod i narzę­dzi do prac jak powyżej.(żr.: IEEE)

inżynieria systemów

pro­jek­to­wa­nie zło­żo­nych struk­tur opi­su­ją­cych sys­te­my i ich zacho­wa­nie, pro­jek­ty sys­te­mów wyra­ża­ne są w posta­ci ich modeli:

Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysmlOliver, D. W., Kelliher, T. P., & Keegan, J. G. (1997). Engineering com­plex sys­tems with models and objects. McGraw-Hill.Model: Wzór (opis) cze­goś, co ma być wyko­na­ne (Mirriam-Webster 1981).

know-how

ozna­cza pakiet nie­opa­ten­to­wa­nych infor­ma­cji prak­tycz­nych, wyni­ka­ją­cych z doświad­cze­nia i prze­pro­wa­dzo­nych testów, o nie­jaw­nym, istot­nym i okre­ślo­nym cha­rak­te­rze (Rozporządzenie Komisji (UE) nr 316/2014 z dnia 21 mar­ca 2014 r. w spra­wie sto­so­wa­nia art. 101 ust. 3 Traktatu o funk­cjo­no­wa­niu Unii Europejskiej do kate­go­rii poro­zu­mień o trans­fe­rze tech­no­lo­gii (CELEX: 32014R0316), oraz Rozporządzenie Unii Europejskiej nr 772/2004 w spra­wie sto­so­wa­nia art. 81 ust. 3 Traktatu do kate­go­rii poro­zu­mień o trans­fe­rze tech­no­lo­gii)Know-how nie ma cha­rak­te­ru odkryw­cze­go, nie moż­na więc go opa­ten­to­wać, nie zna­czy to jed­nak, że przed­się­bior­ca nie może go chro­nić na inne spo­so­by. Według usta­wy o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji (Ustawa z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji. (n.d.). Retrieved from http://​isap​.sejm​.gov​.pl/​i​s​a​p​.​n​s​f​/​D​o​c​D​e​t​a​i​l​s​.​x​s​p​?​i​d​=​W​D​U​1​9​9​3​0​4​7​0​211): Art. 11.1 Czynem nie­uczci­wej kon­ku­ren­cji jest prze­ka­za­nie, ujaw­nie­nie lub wyko­rzy­sta­nie cudzych infor­ma­cji sta­no­wią­cych tajem­ni­cę przed­się­bior­stwa albo ich naby­cie od oso­by nie­upraw­nio­nej, jeże­li zagra­ża lub naru­sza inte­res przed­się­bior­cy. (?). Przez tajem­ni­cę przed­się­bior­stwa rozu­mie się nie­ujaw­nio­ne do wia­do­mo­ści publicz­nej infor­ma­cje tech­nicz­ne, tech­no­lo­gicz­ne, orga­ni­za­cyj­ne przed­się­bior­stwa lub inne infor­ma­cje posia­da­ją­ce war­tość gospo­dar­czą, co do któ­rych przed­się­bior­ca pod­jął nie­zbęd­ne dzia­ła­nia w celu zacho­wa­nia ich poufności.

komponent

część skła­do­wa, sta­no­wią­ca zamknię­ty kon­struk­cyj­nie ele­ment sys­te­mu, mogą­ca być odręb­nym przed­mio­tem dosta­wy lub reali­za­cji, cechu­ją­ca się okre­ślo­nym zacho­wa­niem (inter­fejs), wła­snym cyklem życia, mogą­ca być wymie­nio­na na inną, o tych samych cechach zewnętrz­nych, bez wpły­wu na pozo­sta­łe ele­men­ty sys­te­mu i sys­tem jako całość (na podst, UML, v.2.5.1)

komputer

urzą­dze­nie defi­nio­wa­ne jako pro­ce­sor + pamięć + pro­gram” (Murawski, R. (Red.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.)

komunikacja

prze­ka­zy­wa­nie i odbie­ra­nie infor­ma­cji w kon­tak­cie z dru­gą oso­bą, komu­ni­ka­cja wyma­ga usta­le­nia sys­te­mu komu­ni­ka­cji jakim jest język komu­ni­ka­cji, w posta­ci: słow­ni­ka pojęć lub (i) zde­fi­nio­wa­nych zna­ków (seman­ty­ka), zesta­wu dopusz­czal­nych związ­ków pomię­dzy poję­cia­mi ich zna­czeń (syn­tak­ty­ka), oraz kon­tek­stu dzie­dzi­no­we­go usta­la­ją­ce­go zna­cze­nia pojęć, jeże­li język jest kon­tek­sto­wy (prag­ma­ty­ka) (żr. opr. wła­sne na pod­sta­wie, Semiotyka” Umberto Eco, Pisma seman­tycz­ne, Frege); przy­kła­da­mi sfor­ma­li­zo­wa­nych sys­te­mów komu­ni­ka­cji są notacje.

koncepcja wdrożenia

doku­ment opi­su­ją­cy całość pla­no­wa­nych prac i ich efek­ty, zawie­ra opis tego w jaki spo­sób Dostawca dostar­czy i wdro­ży ofe­ro­wa­ne Rozwiązanie, jest to pierw­szy etap (doku­ment) prac dostaw­cy roz­wią­za­nia, zawie­ra­ją­cy mię­dzy inny­mi ana­li­zę gap-fit”, czy­li oce­nę stop­nia zgod­no­ści ofe­ro­wa­ne­go roz­wią­za­nia z wyma­ga­nia­mi; doku­ment opi­su­ją­cy kon­cep­cję wdro­że­nia powi­nien zawie­rać, dla każ­de­go wyma­ga­nia: potwier­dze­nie zgod­no­ści z wyma­ga­niem lub pro­po­zy­cję alter­na­tyw­ną, opis spo­so­bu reali­za­cji wyma­ga­nia oraz har­mo­no­gram tych prac.

kontekst

frag­ment tek­stu potrzeb­ny do dokład­ne­go rozu­mie­nia danych wyra­zów lub wyra­żeń, zespół odnie­sień nie­zbęd­nych do zro­zu­mie­nia utwo­ru lite­rac­kie­go, dzie­ła nauko­we­go itp. (źr. s.j.p. PWN), w mode­lo­wa­niu okre­śla prze­strzeń poję­cio­wą pre­cy­zu­ją­ca seman­ty­kę znaków

korelacja

ana­li­za kore­la­cji w sta­ty­sty­ce pole­ga na zba­da­niu czy dwie zmien­ne są ze sobą istot­nie sta­ty­stycz­nie powią­za­ne; nie bada ona związ­ku przy­czy­no­wo-skut­ko­we­go a po pro­stu współ­wy­stę­po­wa­nie dwóch zmien­nych; gdy bada­my czy dwie zmien­ne są sko­re­lo­wa­ne ze sobą to nie wie­my, któ­ra zmien­na wpły­wa na któ­rą; wie­my tyl­ko, że war­tość jed­nej zmien­nej rośnie/maleje w przy­pad­ku wzrostu/spadku war­to­ści dru­giej zmien­nej (tak­że wystę­po­wa­nie lub brak występowania)

łańcuch odpowiedzialności

wzo­rzec archi­tek­to­nicz­ny zakła­da­ją­cy, że prze­ka­zy­wa­nie żądań do klas bar­dziej spe­cja­li­zo­wa­nych odby­wa się kaska­do­wo, bez pomi­ja­nia klas mają­cych pośred­nie, ogól­niej­sze odpowiedzialności,

mapa procesów

poję­cie nie­sfor­ma­li­zo­wa­ne, bywa uży­wa­ne wymien­nie z poję­ciem archi­tek­tu­ra pro­ce­sów; mapą pro­ce­sów naj­czę­ściej nazy­wa­ny dia­gram (dia­gra­my) obra­zu­ją­cy związ­ki pomię­dzy pro­ce­sa­mi na wyso­kim pozio­mie ogól­no­ści zwa­nym pro­ce­sy end-2-end (na tym pozio­mie jeden pro­ces obra­zo­wa­ny jest jako jeden sym­bol), przy­kła­dem czę­sto spo­ty­ka­nej for­my two­rze­nia map pro­ce­sów jest nota­cja ope­ru­ją­ca wyłącz­nie poję­cia­mi wej­ście, pro­ces, wyjście: 

mapa procesu

poję­cie to bywa sto­so­wa­ne zamien­nie z poję­ciem model pro­ce­su lub dia­gram pro­ce­su, patrz tak­że mapa pro­ce­sów

MBSE

Inżynieria sys­te­mów opar­ta na mode­lach (MBSE) jest sfor­ma­li­zo­wa­ną meto­do­lo­gią, któ­ra jest uży­wa­na do wspie­ra­nia wyma­gań, pro­jek­to­wa­nia, ana­li­zy, wery­fi­ka­cji i wali­da­cji zwią­za­nych z roz­wo­jem zło­żo­nych sys­te­mów. W prze­ci­wień­stwie do inży­nie­rii skon­cen­tro­wa­nej na doku­men­tach, MBSE sta­wia mode­le w cen­trum pro­jek­to­wa­nia sys­te­mu. Zwiększone roz­po­wszech­nie­nie śro­do­wisk mode­lo­wa­nia cyfro­we­go w cią­gu ostat­nich kil­ku lat dopro­wa­dzi­ło do wzro­stu popu­lar­no­ści MBSE. W stycz­niu 2020 roku NASA odno­to­wa­ła ten trend, infor­mu­jąc, że MBSE jest coraz czę­ściej wyko­rzy­sty­wa­ny zarów­no przez prze­mysł, jak i rząd jako spo­sób na śle­dze­nie zło­żo­no­ści sys­te­mu”. (źr. Krótkie wpro­wa­dze­nie do MBSE).

MDA

ang. Model Driven Architecture (archi­tek­tu­ra zorien­to­wa­na na mode­le), archi­tek­tu­ra opar­ta na otwar­tych stan­dar­dach OMG (Object Management Group), pozwa­la na odse­pa­ro­wa­nie w ana­li­zie i pro­jek­to­wa­niu logi­ki biz­ne­so­wej, logi­ki apli­ka­cji i jej imple­men­ta­cji (źr. www​.omg​.org/mda).MDA defi­niu­je trzy typy mode­li: CIM, PIM, PSM (patrz pozo­sta­łe defi­ni­cje w słow­ni­ku). Model CIM (biz­ne­so­wy) to nie­za­leż­ny od tech­no­lo­gii model opi­su­ją­cy cele biz­ne­so­we (BMM), pro­ce­sy biz­ne­so­we (BPMN) oraz logi­kę tych pro­ce­sów i wspól­ny słow­nik (SBVR). Model ten powi­nien tak­że zawie­rać struk­tu­ry danych (doku­men­tów, tu UML). Model PIM (UML) to model opi­su­ją­cy wewnętrz­ną archi­tek­tu­rę i logi­kę pla­no­wa­nej do wdro­że­nia apli­ka­cji (opro­gra­mo­wa­nia). Zakres tego wdro­że­nia okre­śla sie z uży­ciem dia­gra­mu przy­pad­ków uży­cia (nie on ele­men­tem ani CIM ani PIM, to łącz­nik). Model PSM to pro­jekt wyko­na­nia opro­gra­mo­wa­nia w okre­ślo­nym śro­do­wi­sku deve­lo­per­skim. Tu prak­tycz­nie powsta­je jedy­nie model wdro­że­nia (UML) i doku­men­ta­cja kodu w for­mie wybra­nej przez wyko­naw­cę. Poniżej dia­gram obra­zu­ją­cy związ­ki mie­dzy tymi modelami.

Struktura mode­li w MDA. Po lewej stro­nie typo­wy pro­ces MDA, po pra­wej pró­ba uży­cia mode­li wyko­ny­wal­nych BPMN (BPEL4WS) w miej­sce PIM, ścież­ka ta jed­nak nie przy­ję­ła się. Czytaj tak­że: MDA – Cztery pro­duk­ty czy­li dwa eta­py: wyma­ga­nia i pro­duktZelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. W Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (s. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

MDE

Model-dri­ven engi­ne­ering (MDE), meto­do­lo­gia ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­na na two­rze­nie mode­li danej dzie­dzi­ny, w tym mode­li poję­cio­wych i innych, budo­wa­nych z wie­lu róż­nych per­spek­tyw w celu opi­sa­nia pro­ble­mu i jego spe­cy­fi­ki; bazu­je na sto­so­wa­niu abs­trak­cji i mode­li mecha­ni­zmów rzą­dzą­cych daną dzie­dzi­ną zamiast deta­licz­nych wyli­czeń i algorytmów.

mechanizm

spo­sób, w jaki coś powsta­je, prze­bie­ga lub dzia­ła (słow­nik j.polskiego PWN), np. spo­sób dzia­ła­nia orga­ni­za­cji, opro­gra­mo­wa­nia; w nauce mecha­ni­zmy są obiek­ta­mi o okre­ślo­nych wła­sno­ściach i pro­ce­sa­mi zor­ga­ni­zo­wa­ny­mi w taki spo­sób, że powo­du­ją one regu­lar­ne zmia­ny, począw­szy od począt­ku, czy też warun­ków począt­ko­wych, aż do zakoń­cze­nia dzia­ła­nia lub warun­ków koń­co­wych (sta­ty­stycz­nie okre­ślo­na kore­la­cja nie jest mode­lem, nie okre­śla ona związ­ku przy­czy­no­wo-skut­ko­we­go, jest jedy­nie stwier­dze­niem sta­ty­stycz­nej powta­rzal­no­ści) (Machamer, P., Darden, L., & Craver, C. F. (2000). Thinking abo­ut mecha­ni­sms. Philosophy of Science67(1), 1?25.); .„mecha­nizm jest wyja­śnie­niem powią­za­nia, któ­re­go Hume szu­kał mię­dzy przy­czy­ną a skut­kiem”, mecha­nizm zacho­wa­nia jest zło­żo­nym sys­te­mem, któ­ry opi­su­je to zacho­wa­nie poprzez inte­rak­cję wie­lu kom­po­nen­tów, przy czym inte­rak­cję mię­dzy kom­po­nen­ta­mi moż­na opi­sać opi­sać jako związ­ki uogól­nień (gene­ra­li­za­cji) kom­po­nen­tów tego sys­te­mu” (Glennan, 1996), (patrz tak­że: Mechanism in Science)

mechatronika

dział tech­ni­ki łączą­cy ele­men­ty mecha­ni­ki, budo­wy maszyn, elek­tro­ni­ki, auto­ma­ty­ki, robo­ty­ki oraz infor­ma­ty­ki (s.j.p. PWN); tak­że dzie­dzi­na nauki o sys­te­mach łączą­cych w sobie ele­men­ty mecha­ni­ki i opro­gra­mo­wa­nia (Mhenni et al., 2014) 

meta-

jako przed­ro­stek ozna­cza opis jeden poziom opi­su (uogól­nie­nia) wyżej (patrz MOF), (Gašević et al., 2009)

metadane

ina­czej dane o danych?, lub też infor­ma­cja o infor­ma­cji?; meta­da­ny­mi są np. nazwy kolumn tabel i zesta­wień, defi­ni­cje i nazwy pól for­mu­la­rzy, znacz­ni­ki XML. (patrz tak­że Metadane).

metamodel

gene­ra­li­za­cja mode­lu, inny­mi sło­wy jeże­li model to abs­trak­cja okre­ślo­nej rze­czy­wi­sto­ści, to meta­mo­del jest uogól­nie­niem okre­ślo­nej kla­sy (zbio­ru) takich mode­li (abs­trak­cji), dany meta­mo­del sys­te­mu repre­zen­tu­je wszyst­kie sys­te­my zgod­ne z tym meta­mo­de­lem, meta­mo­del to kla­sa mode­li, meta­mo­del defi­niu­je seman­ty­kę i syn­tak­ty­kę okre­ślo­nej kla­sy modeli

metoda

sys­te­ma­tycz­nie sto­so­wa­ny spo­sób (Kotarbiński), w obiek­to­wych tech­ni­kach pro­jek­to­wa­nia, spo­sób reali­za­cji ope­ra­cji kla­sy (obiek­tu)

metoda naukowa

dzia­ła­nie pole­ga­ją­ce na usys­te­ma­ty­zo­wa­nym i sfor­ma­li­zo­wa­nym docho­dze­niu do praw­dy, któ­re­go celem jest obiek­ty­wi­za­cja wyni­ków jakim jest teo­ria wyja­śnia­ją­ca obser­wo­wa­ne fak­ty (mecha­nizm ich powsta­wa­nia). Metoda nauko­wa powin­na być odróż­nia­na od celów i pro­duk­tów nauki, takich jak wie­dza, prze­wi­dy­wa­nia czy kon­tro­la. Metody są środ­ka­mi, za pomo­cą któ­rych te cele są osią­ga­ne. Metodę nauko­wą nale­ży rów­nież odróż­nić od meta-meto­do­lo­gii, któ­ra obej­mu­je war­to­ści i uza­sad­nie­nia sto­ją­ce za kon­kret­ną cha­rak­te­ry­sty­ką meto­dy nauko­wej (tj. meto­do­lo­gii) – war­to­ści takie jak obiek­tyw­ność, odtwa­rzal­ność, pro­sto­ta czy dotych­cza­so­we suk­ce­sy. Proponuje się regu­ły meto­do­lo­gicz­ne, któ­re mają rzą­dzić meto­dą, a meta-meto­do­lo­gicz­nym pyta­niem jest, czy meto­dy prze­strze­ga­ją­ce tych reguł speł­nia­ją dane war­to­ści. Wreszcie, meto­da róż­ni się, do pew­ne­go stop­nia, od szcze­gó­ło­wych i kon­tek­stu­al­nych prak­tyk, poprzez któ­re meto­dy są wdra­ża­ne. Te ostat­nie mogą obej­mo­wać: kon­kret­ne tech­ni­ki labo­ra­to­ryj­ne; for­ma­li­zmy mate­ma­tycz­ne lub inne spe­cja­li­stycz­ne języ­ki uży­wa­ne w opi­sach i rozu­mo­wa­niach; środ­ki tech­no­lo­gicz­ne lub inne środ­ki mate­rial­ne; spo­so­by komu­ni­ko­wa­nia i dzie­le­nia się wyni­ka­mi, czy to z inny­mi naukow­ca­mi, czy z ogó­łem spo­łe­czeń­stwa; lub kon­wen­cje, zwy­cza­je, wymu­szo­ne oby­cza­je i insty­tu­cjo­nal­ne kon­tro­le tego, jak i czym zaj­mu­je się nauka.” (Scientific Method)

metodologia

zespół nauko­wo opra­co­wa­nych metod (SJP)

metodyka

zbiór metod (SJP)

mikro aplikacja

inte­rak­tyw­ny moduł opro­gra­mo­wa­nia zapro­jek­to­wa­ny tak, aby dzia­łał jako w peł­ni zako­do­wa­na apli­ka­cja lub stro­na inter­ne­to­wa; apli­ka­cja, któ­ra jest bar­dzo skon­cen­tro­wa­na na wyko­ny­wa­niu tyl­ko jed­ne­go zada­nia (wspie­ra jed­no zada­nie, aktyw­ność pro­ce­su biz­ne­so­we­go); w odróż­nie­niu od poję­cia mikro­ser­wis, jest skon­cen­tro­wa­na na okre­ślo­nym celu (value); mikro apli­ka­cja jest z zasa­dy samo­wy­star­czal­nym kom­po­nen­tem, poję­cie to powsta­ło w odpo­wie­dzi na mikro­ser­wi­sy, któ­re sta­ły się zbyt roz­drob­nio­ne, nazwa mikro­ser­wis coraz czę­ściej jest inte­pre­to­wa­ną jako samo­dziel­na ope­ra­cja, co dopro­wa­dzi­ło do nara­sta­ją­cej kom­pli­ka­cji zarzą­dza­nia taką architekturą, 

mikroserwis

kon­cep­cja budo­wy archi­tek­tu­ry apli­ka­cji opar­ta na zało­że­niu, że budo­wa i roz­wój apli­ka­cji to wie­le odręb­nych pro­stych usług zamiast jed­nej mono­li­tycz­nej cało­ści, w archi­tek­tu­rze mikro­ser­wi­sów usłu­gi są drob­no­ziar­ni­ste, a pro­to­ko­ły są lekkie;

model

abs­trak­cyj­na kon­struk­cja wyra­żo­na wzo­ra­mi mate­ma­tycz­ny­mi, sche­ma­tem blo­ko­wym lub algo­ryt­mem, opi­su­ją­ca mecha­nizm zacho­wa­nia się okre­ślo­nej rze­czy­wi­sto­ści (sys­te­mu) i wyja­śnia­ją­ca te zacho­wa­nia (Kühne, 2006); opi­sa­ny w okre­ślo­nym języ­ku sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rze­czy­wi­sto­ści, może zostać wyra­żo­ny wzo­ra­mi mate­ma­tycz­ny­mi lub sche­ma­tem blo­ko­wym (model nomi­nal­ny, abs­trak­cyj­ny), patrz tak­że mecha­nizm jako model, (Craver & Tabery, 2019).

Modelowanie pole­ga na abs­tra­ho­wa­niu od okre­ślo­nych szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm, jed­nak obser­wo­wal­na zmia­na sta­nów maszy­ny” nie jest mode­lem (opi­sem) mecha­ni­zmu jej dzia­ła­nia (Craver & Tabery, 2019).Frigg, R., & Hartmann, S. (2018). Models in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2018). Metaphysics Research Lab, Stanford University. Retrieved from https://​pla​to​.stan​ford​.edu/​a​r​c​h​i​v​e​s​/​s​u​m​2​0​1​8​/​e​n​t​r​i​e​s​/​m​o​d​e​l​s​-​s​c​i​e​n​ce/Craver, C., & Tabery, J. (2019). Mechanisms in Science. W E. N. Zalta (Red.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/tak­że: Model: Wzór (opis) cze­goś, co ma być wyko­na­ne” (Mirriam-Webster 1981); Frigg, R., & Hartmann, S. (2006). Scientific models.

model biznesowy

Według M. E. Portera model biz­ne­so­wy jest opi­sem dzia­łal­no­ści przed­się­bior­stwa, któ­ra zapew­nia mu zyski. Sprowadza się to do okre­śle­nia roli orga­ni­za­cji w ryn­ko­wym łań­cu­chu war­to­ści, w jakim dzia­ła oraz opi­sa­nia mecha­ni­zmu two­rze­nia tej war­to­ści wewnątrz orga­ni­za­cji. Modele takie wyra­ża się obec­nie w posta­ci pro­ce­sów biz­ne­so­wych i struk­tur oraz ich dyna­mi­ki. Typowe ele­men­ty mode­lu biz­ne­so­we­go: ryn­ko­wy nad­rzęd­ny łań­cuch war­to­ści, model wewnętrz­ne­go łań­cu­cha war­to­ści, model ryn­ko­wych pię­ciu sił, tak­że kon­tek­sto­wa ana­li­za SWOT (źr. M.E.Porter Strategia kon­ku­ren­cji).

model dziedziny systemu

(doma­in model), jest to model opi­su­ją­ce zacho­wa­nie się sys­te­mu, model ten opi­su­je reak­cje okre­ślo­ne­go sys­te­mu na bodź­ce, czy­li tak zwa­ną logi­kę dzie­dzi­no­wą, w przy­pad­ku opro­gra­mo­wa­nia wspie­ra­ją­ce­go zarza­dza­nie orga­ni­za­cją, jest to logi­ka biz­ne­so­wa i prze­twa­rza­ne dane (patrz M.Fowler: An object model of the doma­in that incor­po­ra­tes both beha­vior and data); np. model dzie­dzi­ny sys­te­mu (apli­ka­cji) słu­żą­ce­go do wysta­wia­nia fak­tur sprze­da­ży, to model opi­su­ją­cy spo­sób two­rze­nia tre­ści fak­tur na pod­sta­wie zamó­wień: ceny brut­to, upu­sty, war­to­ści podat­ków itp., w przy­pad­ku sto­so­wa­nia wzor­ca archi­tek­to­nicz­ne­go MVC (Model, View, Controler) jest to kom­po­nent Model, reali­zu­ją­cy logi­kę zacho­wa­nia się systemu.

model pojęciowy

upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi (OMG​.org, 2019)

model procesu

dia­gram (sche­mat blo­ko­wy) obra­zu­ją­cy pro­ces (np. .biz­ne­so­wy) wg. usta­lo­nej kon­wen­cji z uży­ciem okre­ślo­nej notacji

model systemu

przed­sta­wie­nie inte­re­su­ją­cych nas istot­nych wła­ści­wo­ści rze­czy­wi­ste­go (lub two­rzo­ne­go) sys­te­mu w dogod­nej dla nas posta­ci. Model sys­te­mu jest z regu­ły uprosz­cze­niem rze­czy­wi­sto­ści. Powinien zewnętrz­nie zacho­wy­wać się podob­nie jak sys­tem, acz­kol­wiek może mieć inną struk­tu­rę wewnętrz­ną.
Modele: (1) kon­cep­cyj­ne albo jako­ścio­we, (2) fizycz­ne, (3) kom­pu­te­ro­we, (4) mate­ma­tycz­ne. (źr. Findeisen, (Ed.). (1985). Analiza sys­te­mo­wa — Podstawy i meto­do­lo­gia. Państw. wydawn. nauk. )

modelowanie

pro­ces ana­li­zy i two­rze­nia mode­li okre­ślo­nej rze­czy­wi­sto­ści, pod­sta­wo­wym celem mode­lo­wa­nia w ana­li­zach jest: prze­wi­dy­wa­nie, zro­zu­mie­nie, eks­plo­ra­cja, komu­ni­ka­cja; typo­wy pro­ces mode­lo­wa­nia to: two­rze­nie mode­li men­tal­nych – nie­for­mal­nych repre­zen­ta­cji świa­ta, szki­ców, następ­nie ma miej­sce two­rze­nie mode­li for­mal­nych, te mogą być two­rzo­ne jako mode­le mate­ma­tycz­ne lub jako sche­ma­ty blo­ko­we wyko­na­ne z uży­ciem sfor­ma­li­zo­wa­nych nota­cji (Steven Lade, 2019). 

moduł

wyod­ręb­nio­ny ele­ment archi­tek­tu­ry roz­wią­za­nia (sys­te­mu infor­ma­tycz­ne­go) peł­nią­cy usta­lo­ną funk­cję, łatwy do okre­śle­nia i wyko­rzy­sta­nia jako część więk­szej cało­ści (sł. j.polskiego).

modus ponendo ponens

[łac., ?spo­sób potwier­dza­ją­cy potwier­dze­niem?], log. pra­wo rachun­ku zdań (sylo­gi­zmu kate­go­rycz­no-hipo­te­tycz­ne­go), według któ­re­go praw­dzi­wość poprzed­ni­ka praw­dzi­wej impli­ka­cji pocią­ga za sobą praw­dzi­wość następ­ni­ka tej implikacji[(p -> q) i p] -> q (inter­pre­tu­je­my: jeże­li q wyni­ka z p, i p jest praw­dą, to q jest prawdą)

modus tollendo ponens

[łac., ?spo­sób potwier­dza­ją­cy zaprze­cze­niem?], log. pra­wo rachun­ku zdań (sylo­gi­zmu alter­na­tyw­ne­go), według któ­re­go fał­szy­wość jed­ne­go ze zdań praw­dzi­wej alter­na­ty­wy pozwa­la wnio­sko­wać o praw­dzi­wo­ści drugiego.[(p lub q) i ~p] -> q (inter­pre­tu­je­my: jeże­li praw­dą jest p lub q, i p nie jest praw­dą, to praw­dą jest q)

MVC

Podstawowy, obiek­to­wy wzo­rzec archi­tek­to­nicz­ny, jest jed­nym z naj­czę­ściej cyto­wa­nych (i naj­czę­ściej błęd­nie cyto­wa­nych) wzor­ców (źr.: https://​mar​tin​fow​ler​.com/​e​a​a​C​a​t​a​l​o​g​/​m​o​d​e​l​V​i​e​w​C​o​n​t​r​o​l​l​e​r​.​h​tml).Utożsamiany jest czę­sto błęd­nie z trój­war­stwo­wą archi­tek­tu­rą struk­tu­ral­ną, gdzie View to inter­fejs użyt­kow­ni­ka, Controller to logi­ka biz­ne­so­wa a Model to baza danych. Jednak fak­tycz­nie są to: View to war­stwa pre­zen­ta­cji, Model to logi­ka biz­ne­so­wa (model biz­ne­so­wy, dana tak­że a nie tyl­ko), Controller to śro­do­wi­sko wyko­naw­cze cało­ści. Dlatego bar­dziej ade­kwat­ny sche­mat to:

(źr.: https://​www​.code​ca​de​my​.com/​a​r​t​i​c​l​e​/​mvc)

Z per­spek­ty­wy wdro­że­nia, model ten wyglą­dał by tak:

Komponenty MVC na tle całe­go systemu

nadzór autorski

jed­no z nie­zby­wal­nych upraw­nień z kata­lo­gu autor­skich praw oso­bi­stych, przy­słu­gu­ją­ce każ­de­mu twór­cy z mocy usta­wy o pra­wie autor­skim i pra­wach pokrew­nych, pole­ga­ją­ce na moż­li­wo­ści nad­zo­ru spo­so­bu wyko­rzy­sta­nia i eks­plo­ata­cji wła­sne­go utwo­ru przez inne oso­by fizycz­ne i praw­ne, przy­kła­dem peł­nie­nia nad­zo­ru autor­skie­go jest pra­wo pro­jek­tan­ta i archi­tek­ta do nad­zo­ru spo­so­bu reali­za­cji (imple­men­ta­cji) jego pro­jek­tu przez inwe­sto­ra i wyko­naw­cę, w szcze­gól­no­ści wyda­wa­nia zgo­dy na wpro­wa­dza­nie zmian do tego pro­jek­tu; wyko­naw­ca (deve­lo­per) wyko­nu­je w takim przy­pad­ku (realizacja/implementacja pro­jek­tu) utwór zależ­ny (źr. USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrewnych).

nauka

w sze­ro­kim zna­cze­niu, ogół wie­dzy ludz­kiej uło­żo­nej w sys­tem zagad­nień: zbie­ra­nie i kla­sy­fi­ko­wa­nie fak­tów (s.j.p.); w wąskim zna­cze­niu, meto­dy mode­lo­wa­nia, abs­trak­cji i ide­ali­za­cji, pomi­ja­ją­ce w zja­wi­skach aspek­ty mniej istot­ne, by docie­rać do wewnętrz­nych mecha­ni­zmów i pra­wi­dło­wo­ści, ukry­tych przed naszy­mi zmy­sła­mi: wyja­śnia­nie fak­tów; celem nauki, w wąskim sen­sie, jest budo­wa­nie teo­rii nauko­wych: Teoria nie tyl­ko wyja­śnia zna­ne fak­ty; umoż­li­wia rów­nież naukow­com prze­wi­dy­wa­nie tego, co powin­ni obser­wo­wać, jeśli teo­ria jest praw­dzi­wa. Teorie nauko­we są spraw­dzal­ne. Nowe dowo­dy powin­ny być zgod­ne z teo­rią. Jeśli tak nie jest, teo­ria jest udo­sko­na­la­na lub odrzu­ca­na. Im dłu­żej utrzy­mu­ją się cen­tral­ne ele­men­ty teo­rii – im wię­cej prze­wi­du­je ona obser­wa­cji, im wię­cej testów prze­cho­dzi, tym wię­cej fak­tów wyja­śnia – tym sil­niej­sza jest teo­ria.” (K.Popper, Logika odkry­cia naukowego).Kluczowe poję­cie w obec­nej nauce to model” (https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​m​o​d​e​l​s​-​s​c​i​e​n​ce/) i mecha­nizm” (https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/); patrz tak­że pseu­do­nau­ka (https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​p​s​e​u​d​o​-​s​c​i​e​n​ce/) i struk­tu­ra teo­rii nauko­wych (https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​t​r​u​c​t​u​r​e​-​s​c​i​e​n​t​i​f​i​c​-​t​h​e​o​r​i​es/).

nauka o informacji

(ang. infor­ma­tion scien­ce), jest to inter­dy­scy­pli­nar­na nauka, któ­ra bada wła­ści­wo­ści i zacho­wa­nie infor­ma­cji, siły rzą­dzą­ce prze­pły­wem i wyko­rzy­sta­niem infor­ma­cji oraz tech­ni­ki, zarów­no ręcz­ne, jak i mecha­nicz­ne, prze­twa­rza­nia infor­ma­cji w celu opty­mal­ne­go prze­cho­wy­wa­nia, wyszu­ki­wa­nia i roz­po­wszech­nia­nia (Borko, 1968); patrz tak­że: Informatyka jako dys­cy­pli­na nauko­watak­że: nauka i prak­ty­ka zaj­mu­ją­ca się efek­tyw­nym gro­ma­dze­niem, prze­cho­wy­wa­niem, wyszu­ki­wa­niem i wyko­rzy­sty­wa­niem infor­ma­cji. Zajmuje się zapi­sy­wal­ny­mi infor­ma­cja­mi i wie­dzą oraz tech­no­lo­gia­mi i powią­za­ny­mi usłu­ga­mi, któ­re uła­twia­ją zarzą­dza­nie nimi i ich wyko­rzy­sty­wa­nie. (What Is Information Science?).

nazwa

kla­sa, wyraz albo połą­cze­nie wyra­zo­we ozna­cza­ją­ce kogoś lub coś (patrz tak­że pojęcie)

notacja

ozna­cze­nie cze­goś umow­ny­mi zna­ka­mi; też: zbiór takich zna­ków i ich wza­jem­nych związ­ków (na pod­sta­wie sł j.polskiego)

ontologia

for­mal­na (sfor­ma­li­zo­wa­na) repre­zen­ta­cja pew­nej dzie­dzi­ny wie­dzy (opi­su okre­ślo­nej rze­czy­wi­sto­ści), na któ­rą skła­da się zapis zbio­rów pojęć (ang. con­cept) i związ­ków (aso­cja­cja, ang. asso­cia­tion) mię­dzy nimi, zapis ten two­rzy sche­mat poję­cio­wy, któ­ry będąc opi­sem danej dzie­dzi­ny wie­dzy, może słu­żyć jed­no­cze­śnie jako pod­sta­wa do wnio­sko­wa­nia o wła­ści­wo­ści opi­sy­wa­nych onto­lo­gią pojęć (obec­nie tyl­ko w teo­rii) (Oxford Advanced Learner?s Dictionary, n.d.); onto­lo­gia jako spo­sób for­mal­nej spe­cy­fi­ka­cji wie­dzy z inte­re­su­ją­cej nas dzie­dzi­ny, zna­la­zła zasto­so­wa­nie w tech­no­lo­giach infor­ma­cyj­nych i komu­ni­ka­cji,Patrz także:Ontologia jest spe­cy­fi­ka­cją kon­cep­tu­ali­za­cji. Słowo onto­lo­gia” wyda­je się gene­ro­wać wie­le kon­tro­wer­sji w dys­ku­sjach o AI (amg. Artificial Intelligence, sztucz­na inte­li­gen­cja). Ma ono dłu­gą histo­rię w filo­zo­fii, w któ­rej odno­si się do przed­mio­tu ist­nie­nia. Często jest też mylo­ne z epi­ste­mo­lo­gią, któ­ra doty­czy wie­dzy i pozna­nia. W kon­tek­ście dzie­le­nia się wie­dzą, uży­wa­my ter­mi­nu onto­lo­gia w zna­cze­niu spe­cy­fi­ka­cji kon­cep­tu­ali­za­cji. Oznacza to, że onto­lo­gia jest opi­sem (jak for­mal­na spe­cy­fi­ka­cja pro­gra­mu) pojęć i związ­ków, któ­re mogą ist­nieć dla agen­ta lub spo­łecz­no­ści agen­tów. Ta defi­ni­cja jest zgod­na z uży­ciem onto­lo­gii jako zbio­ru pojęć-defi­ni­cji, ale jest bar­dziej ogól­na. I z pew­no­ścią jest to inne zna­cze­nie tego sło­wa niż jego uży­cie w filo­zo­fii. (Gruber, 2009)?Ontologia for­mal­nie repre­zen­tu­je wie­dzę jako hie­rar­chię pojęć w obrę­bie dome­ny, uży­wa­jąc wspól­ne­go słow­nic­twa do ozna­cza­nia typów, wła­ści­wo­ści i wza­jem­nych rela­cji mię­dzy tymi poję­cia­mi. Ontologie są struk­tu­ral­ny­mi rama­mi orga­ni­zo­wa­nia infor­ma­cji i są wyko­rzy­sty­wa­ne w sztucz­nej inte­li­gen­cji, sie­ci seman­tycz­nej, inży­nie­rii sys­te­mów, inży­nie­rii opro­gra­mo­wa­nia, infor­ma­ty­ce bio­me­dycz­nej, biblio­te­ko­znaw­stwie, zakład­kach w przed­się­bior­stwach i archi­tek­tu­rze infor­ma­cji jako for­ma repre­zen­ta­cji wie­dzy o świe­cie lub jakiejś czę­ści to. Tworzenie onto­lo­gii domen ma rów­nież fun­da­men­tal­ne zna­cze­nie dla defi­ni­cji i wyko­rzy­sta­nia struk­tu­ry archi­tek­tu­ry kor­po­ra­cyj­nej.? (źr.: https://​enter​ra​so​lu​tions​.com/​b​l​o​g​/​o​n​t​o​l​o​g​y​-​p​o​w​e​r​-​u​n​d​e​r​s​t​a​n​d​i​ng/)

open/closed principle

zasa­da otwar­te-zamknię­te (ang. Open/Closed prin­ci­ple): prak­ty­ka pro­jek­to­wa­nia mówią­ca, że apli­ka­cje powin­ny być otwar­te na roz­sze­rze­nie, ale zamknię­te na mody­fi­ka­cje, ozna­cza to pro­jek­to­wa­nie archi­tek­tu­ry tak, by roz­wój opro­gra­mo­wa­nia opie­rał się na przy­ro­ście kodu a nie na jego mody­fi­ko­wa­niu, dzię­ki temu roz­wój ten nie wyma­ga każ­do­ra­zo­we­go re-fak­to­rin­gu i testo­wa­nia cało­ści a jedy­nie two­rze­nia i testo­wa­nia nowych komponentów

opi­nia prawna

pomoc­ni­czy mate­riał ana­li­tycz­ny zwią­za­ny z prak­tycz­ny­mi pro­ble­ma­mi praw­ny­mi doty­czą­cy­mi jed­nost­ko­wej spra­wy lub kon­kret­ne­go przy­pad­ku; zazwy­czaj spo­rzą­dza­ny jest na zamó­wie­nie przez wykwa­li­fi­ko­wa­ne­go praw­ni­ka, naj­czę­ściej adwo­ka­ta lub rad­cę praw­ne­go; przed­mio­tem opi­nii praw­nej jest co do zasa­dy pra­wo i jego aktu­al­ny stan, opi­nie wyma­ga­ją­ce wie­dzy spe­cja­li­stycz­nej poza­praw­nej o okre­ślo­nym przed­mio­cie, nie są opi­nią praw­ną, np. defi­ni­cja utwo­ru w rozu­mie­niu pra­wa jest dogma­tem, jed­nak skla­sy­fi­ko­wa­nie tego czy okre­ślo­na treść – np. pro­gra­mu kom­pu­te­ro­we­go, doku­men­ta­cji – jest utwo­rem w myśl tej defi­ni­cji, nie jest opi­nią praw­ną a dzie­dzi­no­wą (poza­praw­ną),

Opis Techniczny Oprogramowania

pro­jekt sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we opi­su­ją­ce mecha­ni­zmy dzia­ła­nia i struk­tu­ry infor­ma­cji. (Jezierski, 2019), w inży­nie­rii jest to model (Kühne, T. 2006).(źr.: Jezierski, J. (2019, czerw­ca). Ochrona pro­gra­mów kom­pu­te­ro­wych w pra­wie wła­sno­ści inte­lek­tu­al­nej – część I – PARP – Centrum Rozwoju MŚP. PARP. https://www.parp.gov.pl/component/content/article/57199:ochrona-programow-komputerowych-w-prawie-wlasnosci-intelektualnej-czesc‑i, nie są takim opi­sem same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94))Kühne, T. (2006). Matters of (Meta-) Modeling. Software & Systems Modeling, 5(4), 369 – 385. https://doi.org/10.1007/s10270-006‑0017‑9(patrz tak­że https://​it​-con​sul​ting​.pl/​p​r​a​w​a​-​a​u​t​o​r​a​-​a​n​a​l​i​z​y​-​i​-​o​c​h​r​o​n​a​-​k​n​o​w​-​h​o​w​-​o​r​g​a​n​i​z​a​c​j​i​-​a​n​a​l​i​z​o​w​a​n​ej/)

opracowanie

roz­pra­wa, pra­ca poświę­co­na jakie­muś zagad­nie­niu lub czy­jejś dzia­łal­no­ści, autor­ski pro­dukt pra­cy, tak­że raport

oprogramowanie

tak­że pro­gram, kod umoż­li­wia­ją­cy użyt­ko­wa­nie kom­pu­te­ra w okre­ślo­nym celu (źr. SJP PWN), patrz tak­że apli­ka­cja, np. opro­gra­mo­wa­nie apli­ka­cyj­ne, opro­gra­mo­wa­nie systemowe.

paradygmat

przy­ję­ty spo­sób widze­nia rze­czy­wi­sto­ści w danej dzie­dzi­nie, dok­try­nie itp. (źr. sł.j.p. PWN)

paradygmat obiektowy

opis rze­czy­wi­sto­ści opar­ty o zało­że­nie, że sys­tem moż­na opi­sać z pomo­cą ukła­du samo­dziel­nych i współ­pra­cu­ją­cych obiek­tów, cechu­ją­cych sie her­me­ty­za­cją i poli­mor­fi­zmem; obiekt wyróż­nia się okre­ślo­nym sta­nem i zacho­wa­niem (ope­ra­cje); w przy­pad­ku pro­gra­mo­wa­nia obiek­to­we­go, języ­ki obiek­to­we reali­zu­ją reu­ży­cie kodu jako dzie­dzi­cze­nie (Korson, T., McGregor, T., & Mcgregor, J. (1990). Understanding Object- Oriented: A Unifying Paradigm. Communications of the ACM September, 1990. Vol. 33: Pp. 40 – 60. Includes Bibliography.33https://​doi​.org/​1​0​.​1​1​4​5​/​8​3​8​8​0​.​8​4​459)Z uwa­gi na to, że dzie­dzi­cze­nie łamie zasa­dą her­me­ty­za­cji, jako reu­ży­cie kodu, jest zastę­po­wa­ne poję­cie sza­blo­nu (tem­pla­te) (OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/).

PIM

an.g Platform Independent Model (model nie­za­leż­ny od plat­for­my, tech­no­lo­gii wyko­na­nia) (Model Driven Architecture (MDA) | Object Management Group, n.d.); we wzor­cu archi­tek­to­nicz­nym MVC (Model View Controler) jest to model kom­po­nen­tu Model sta­no­wią­cy nie­za­leż­ny od plat­for­my model funk­cjo­nal­no­ści i zacho­wa­nia biz­ne­so­we­go apli­ka­cji lub sys­te­mu zin­te­gro­wa­ne­go, zbu­do­wa­ny przy uży­ciu nota­cji UML i innych powią­za­nych stan­dar­dów mode­lo­wa­nia OMG (źr. https://​www​.omg​.org/​m​da/)

podpis elektroniczny

pod­pis elek­tro­nicz­ny ozna­cza dane w posta­ci elek­tro­nicz­nej, któ­re są dołą­czo­ne lub logicz­nie powią­za­ne z inny­mi dany­mi w posta­ci elek­tro­nicz­nej, i któ­re uży­te są przez pod­pi­su­ją­ce­go jako pod­pis” (arty­kuł 3, punkt 10), pod­pi­su­ją­cy musi być też oso­bą fizycz­ną (art. 3, pkt 9), ozna­cza to tak­że, że «pod­pis elek­tro­nicz­ny» to każ­de dane świa­do­mie uży­te do pod­pi­sa­nia (ozna­cze­nia) jakiejś tre­ści w posta­ci elek­tro­nicz­nej w spo­sób umoż­li­wia­ją­cy wyka­za­nie ich związ­ku z pod­pi­sy­wa­ną treścią.Wymogi dla zaawan­so­wa­nych pod­pi­sów elek­tro­nicz­nych (Artykuł 26): a) jest uni­kal­nie przy­po­rząd­ko­wa­ny pod­pi­su­ją­ce­mu; b) umoż­li­wia usta­le­nie toż­sa­mo­ści pod­pi­su­ją­ce­go; c) jest skła­da­ny przy uży­ciu danych słu­żą­cych do skła­da­nia pod­pi­su elek­tro­nicz­ne­go, któ­rych pod­pi­su­ją­cy może, z dużą dozą pew­no­ści, użyć pod wyłącz­ną swo­ją kon­tro­lą; d) jest powią­za­ny z dany­mi pod­pi­sa­ny­mi w taki spo­sób, że każ­da póź­niej­sza zmia­na danych jest roz­po­zna­wal­na. Oznacza to, każ­da treść w for­mie doku­men­to­wej (zło­że­nie oświad­cze­nia woli w posta­ci doku­men­tu, w spo­sób umoż­li­wia­ją­cy usta­le­nie oso­by skła­da­ją­cej oświad­cze­nie, źr. Kodeks Cywilny, Art. 77) wzbo­ga­co­na o moż­li­wość stwier­dze­nia wpro­wa­dze­nia zmia­ny, sta­no­wi sobą doku­ment pod­pi­sa­ny zaawan­so­wa­nym pod­pi­sem elek­tro­nicz­nym”. Taką moż­li­wo­ścią jest np. tak­że bez­piecz­ne prze­trzy­my­wa­nie egzem­pla­rza doku­men­tu do celów porów­naw­czych (usłu­ga tak zwa­ne­go elek­tro­nicz­ne­go nota­riu­sza). Istotne jest, że pod­pi­so­wi elek­tro­nicz­ne­mu nie moż­na odmó­wić skut­ku praw­ne­go ani dopusz­czal­no­ści jako dowo­du w postę­po­wa­niu sądo­wym wyłącz­nie z tego powo­du, że pod­pis ten ma postać elek­tro­nicz­ną lub że nie speł­nia wymo­gów dla kwa­li­fi­ko­wa­nych pod­pi­sów elek­tro­nicz­nych” (art. 25, pkt 1 eIDAS), co ozna­cza, że w prak­ty­ce moż­na zasto­so­wać dowol­ny typ pod­pi­su elek­tro­nicz­ne­go, o ile tyl­ko speł­nia warun­ki jak powy­żej (pod­pis kwa­li­fi­ko­wa­ny jest jedy­nie szcze­gól­nym przy­pad­kiem pod­pi­su elektronicznego).Dokument pod­pi­sa­ny odręcz­nie z pomo­cą table­tu lub skan odręcz­nie pod­pi­sa­ne­go doku­men­tu jest tak­że pod­pi­sa­nym doku­men­tem. Minimum wyma­gań koniecz­nych do uzna­nia zna­ku pisar­skie­go za pod­pis jest to, by wyra­żał, co naj­mniej nazwi­sko, umoż­li­wiał iden­ty­fi­ka­cję auto­ra, przy­naj­mniej według takich kry­te­riów, jak cechy indy­wi­du­al­ne i powta­rzal­ne (por. uchwa­ła skła­du sied­miu sędziów Sądu Najwyższego z dnia 30 grud­nia 1993 r., III CZP 146/93, OSNC 1994, nr 5, poz. 94; posta­no­wie­nie Sądu Najwyższego z dnia 17 czerw­ca 2009 r., IV CSK 78/09, nie publ;. wyrok Sądu Najwyższego z dnia 27 czerw­ca 2007 r., II CSK 124/07, OSNC 2008, nr 9, poz. 102). O auten­tycz­no­ści odręcz­ne­go pod­pi­su, w razie spo­ru, decy­du­je gra­fo­log. eIDAS (ang. elec­tro­nic IDentification, Authentication and trust Services) Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lip­ca 2014 r. w spra­wie iden­ty­fi­ka­cji elek­tro­nicz­nej i usług zaufa­nia w odnie­sie­niu do trans­ak­cji elek­tro­nicz­nych na ryn­ku wewnętrz­nym. Dokument obo­wią­zu­je w całej Unii Europejskiej od 1 lip­ca 2016 roku i jest sto­so­wa­ny bez­po­śred­nio w pol­skim porząd­ku prawnym.

pojęcie

myślo­we odzwier­cie­dle­nie istot­nych cech przed­mio­tu lub zjawiska

polimorfizm

w para­dyg­ma­cie obiek­to­wym, cecha obiek­tów pole­ga­ją­ca na tym, że imple­men­ta­cja ope­ra­cji (meto­da) jest her­me­ty­zo­wa­na a efekt wywo­ła­nia takiej ope­ra­cji może być inny dla róż­nych obiek­tów, zależ­nie od tego do jakie­go obiek­tu zosta­nie skie­ro­wa­ne wywo­ła­nie, np. mamy trzy obiek­ty: muraż, tyn­karz, akro­ba­ta, każ­dy z tych obiek­tów ma ope­ra­cją weź się do robo­ty”, wywo­ła­nie tej ope­ra­cji u każ­de­go z tych obiek­tów da inny efekt, ade­kwat­ny do odpo­wie­dzial­no­ści (roli) obiektu.

polityka biznesowa

okre­ślo­ny spo­sób, wyznacz­nik, dzia­ła­nia osób kie­ru­ją­cych jakąś insty­tu­cją lub orga­ni­za­cją, pre­cy­zo­wa­ny w szcze­gó­łach z pomo­cą imple­men­tu­ją­cych poli­ty­kę reguł biz­ne­so­wych, jest ele­men­tem stra­te­gii orga­ni­za­cji (na podst. sł. j. pol­skie­go PWN, patrz tak­że regu­ły biz­ne­so­we” i stra­te­gia”)

potrzeba

funk­cja, któ­rej bra­ku­je do osią­gnię­cia celu lub wyko­na­nia dzia­ła­nia (źr. zale­ce­nia UZP)

prace rozwojowe

naby­wa­nie, łącze­nie, kształ­to­wa­nie i wyko­rzy­sty­wa­nie dostęp­nej aktu­al­nie wie­dzy i umie­jęt­no­ści z dzie­dzi­ny nauki, tech­no­lo­gii i dzia­łal­no­ści gospo­dar­czej oraz innej wie­dzy i umie­jęt­no­ści do pla­no­wa­nia pro­duk­cji oraz two­rze­nia i pro­jek­to­wa­nia nowych, zmie­nio­nych lub ulep­szo­nych pro­duk­tów, pro­ce­sów i usług, z wyłą­cze­niem prac obej­mu­ją­cych ruty­no­we i okre­so­we zmia­ny wpro­wa­dza­ne do pro­duk­tów, linii pro­duk­cyj­nych, pro­ce­sów wytwór­czych, ist­nie­ją­cych usług oraz innych ope­ra­cji w toku, nawet jeże­li takie zmia­ny mają cha­rak­ter ulep­szeń, w szczególności:

  • opra­co­wy­wa­nie pro­to­ty­pów i pro­jek­tów pilo­ta­żo­wych oraz demon­stra­cje, testo­wa­nie i wali­da­cję nowych lub ulep­szo­nych pro­duk­tów, pro­ce­sów lub usług w oto­cze­niu sta­no­wią­cym model warun­ków rze­czy­wi­ste­go funk­cjo­no­wa­nia, któ­rych głów­nym celem jest dal­sze udo­sko­na­le­nie tech­nicz­ne pro­duk­tów, pro­ce­sów lub usług, któ­rych osta­tecz­ny kształt nie został określony,
  • opra­co­wy­wa­nie pro­to­ty­pów i pro­jek­tów pilo­ta­żo­wych, któ­re moż­na wyko­rzy­stać do celów komer­cyj­nych, w przy­pad­ku gdy pro­to­typ lub pro­jekt pilo­ta­żo­wy sta­no­wi pro­dukt koń­co­wy goto­wy do wyko­rzy­sta­nia komer­cyj­ne­go, a jego pro­duk­cja wyłącz­nie do celów demon­stra­cyj­nych i wali­da­cyj­nych jest zbyt kosztowna(źr. Ustawa z dnia 15 stycz­nia 2015 r. o zmia­nie usta­wy o zasa­dach finan­so­wa­nia nauki oraz nie­któ­rych innych ustaw)

pragmatyka

dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem są spo­łecz­ne i sytu­acyj­ne warun­ki funk­cjo­no­wa­nia języ­ka oraz cele, jakie mówią­cy chce osią­gnąć przez uży­cie okre­ślo­nych wyra­zów i wyra­żeń (źr. s.j.p. PWN)

prawnik

w pol­skim pra­wie oso­ba, któ­ra ukoń­czy­ła wyż­sze stu­dia praw­ni­cze w Polsce i uzy­ska­ła tytuł magi­stra lub ukoń­czy­ła sto­sow­ne zagra­nicz­ne stu­dia uzna­wa­ne w Polsce (sło­wo praw­nik” nie ma defi­ni­cji wprost w słow­ni­ku j.polskiego); w pro­jek­tach typo­wą rolą praw­ni­ka jest opra­co­wa­nie tre­ści umo­wy cywil­nej pomię­dzy dostaw­cą i odbior­cą roz­wią­za­nia, odpo­wie­dzial­no­ścią praw­ni­ka jest zapew­nie­nie zgod­no­ści zawie­ra­nej umo­wy z aktu­al­nym sta­nem praw­nym oraz zgła­sza­nie ryzyk jakie treść tej umo­wy stwa­rza dla stron umo­wy, przed­miot umo­wy (opis efek­tu lub sta­ran­ne­go dzia­ła­nia) jest usta­la­ny przez stro­ny umo­wy w spo­sób nie­ko­li­du­ją­cy z obo­wią­zu­ją­cym prawem

prawo

[tu] ogół prze­pi­sów i norm praw­nych regu­lu­ją­cych sto­sun­ki mię­dzy ludź­mi (danej spo­łecz­no­ści), zespół norm praw­nych, przed­miot pro­fe­sji praw­ni­ka

predykat

funk­tor zda­nio­twór­czy od (co naj­mniej jed­ne­go) argu­men­tu nazwo­we­go; takie wyra­że­nie, któ­re z ter­mi­nem jed­nost­ko­wym da nam zda­nie; np. w zda­niu Jugosławia roz­pa­dła się” wyra­że­nie roz­pa­dła się” jest pre­dy­ka­tem jed­no­ar­gu­men­to­wym (funk­to­rem zda­nio­twór­czym od jed­ne­go argu­men­tu nazwo­we­go), w zda­niu Tomek lubi Basię” wyra­że­nie lubi” jest pre­dy­ka­tem dwu­ar­gu­men­to­wym (funk­to­rem zda­nio­twór­czym od dwóch argu­men­tów nazwo­wych), w zda­niu Arystoteles umi­ło­wał praw­dę bar­dziej niż Platona” wyra­że­nie umi­ło­wał? bar­dziej niż” jest pre­dy­ka­tem trój­ar­gu­men­to­wym (funk­to­rem zda­nio­twór­czym od trzech argu­men­tów nazwo­wych); w spe­cy­fi­ka­cji SBVR pre­dy­ka­ty są opi­sa­ne jako fak­ty” a nazwy (argu­ment nazwo­wy) jako ter­mi­ny” (poję­cia).

Privacy by Design

ozna­cza ochro­nę danych poprzez [wła­ści­we] pro­jek­to­wa­nie tech­no­lo­gii”, jest to zasa­da mówią­ca, że ochro­na danych w pro­ce­du­rach prze­twa­rza­nia danych jest naj­le­piej prze­strze­ga­na, gdy jest już zin­te­gro­wa­na z tech­no­lo­gią w momen­cie jej two­rze­nia [wbu­do­wa­na w logi­kę sys­te­mu], zasa­da ta jest czę­sto roz­sze­rza­na gene­ral­nie na wbu­do­wy­wa­nie zasad (reguł) w mecha­nizm dzia­ła­nia pro­jek­to­wa­nych sys­te­mów, inny­mi sło­wy: sys­tem (mecha­nizm jego dzia­ła­nia) nie tyle powi­nien pozwa­lać na prze­strze­ga­nie pra­wa, co nie powi­nien pozwo­lić na jego łamanie.(na pod­sta­wie: https://​gdpr​-info​.eu/​i​s​s​u​e​s​/​p​r​i​v​a​c​y​-​b​y​-​d​e​s​i​gn/)

problem złośliwy

pro­blem zło­śli­wy (ang. wic­ked pro­blem) to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja, praw­dzi­wy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia roz­wią­za­nia, pro­ble­my, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle pro­ble­ma­mi złośliwymi”.W pla­no­wa­niu i poli­ty­ce zło­śli­wy pro­blem to pro­blem, któ­ry jest trud­ny lub nie­moż­li­wy do roz­wią­za­nia z powo­du nie­kom­plet­nych, sprzecz­nych i zmien­nych wyma­gań, któ­re czę­sto trud­no roz­po­znać. Odnosi się do idei lub pro­ble­mu, któ­re­go nie da się napra­wić, gdzie nie ma jed­ne­go roz­wią­za­nia, a zło­śli­wy” ozna­cza raczej opór przed roz­wią­za­niem niż zło. Inna defi­ni­cja mówi o pro­ble­mie, któ­re­go spo­łecz­na zło­żo­ność ozna­cza, że nie ma on okre­ślo­ne­go punk­tu koń­co­we­go”. Ponadto, ze wzglę­du na zło­żo­ne współ­za­leż­no­ści, wysi­łek wło­żo­ny w roz­wią­za­nie jed­ne­go aspek­tu takie­go pro­ble­mu może ujaw­nić lub stwo­rzyć inne problemy.Rittel i Melvin M. Webber for­mal­nie opi­sa­li kon­cep­cję zło­śli­wych pro­ble­mów po raz pierw­szy w roz­pra­wie z 1973 roku (Rittel & Webber, 2014; 1973; Coffey, 2017).

procedura

skoń­czo­ny i nie­po­dziel­ny zbiór (lub ciąg) instruk­cji (lub reguł lub instruk­cji), opi­su­ją­cy (reali­zu­ją­cy) okre­ślo­ne zada­nie (Angius, 2021)

proces

prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian (źr. s.j.p. PWN)

proces biznesowy

zada­nie lub zestaw połą­czo­nych zadań, wyko­ny­wa­nych w celu uzy­ska­nia okre­ślo­ne­go rezul­ta­tu (Davenport & Short, 1990); BPM (busi­ness pro­cess mana­ge­ment) odno­si się do zarzą­dza­nia i wspar­cia dla zbio­ru wza­jem­nie powią­za­nych pro­ce­sów biz­ne­so­wych, czę­sto w ramach orga­ni­za­cji, obej­mu­je to zarzą­dza­nie wszyst­ki­mi nie­zbęd­ny­mi zaso­ba­mi (np. ludz­ki­mi) w celu zapew­nie­nia osią­gnię­cia celu biz­ne­so­we­go, obsłu­gę wyjąt­ko­wych przy­pad­ków, wpro­wa­dza­nie potrzeb­nych zmian, zapew­nie­nie zgod­no­ści z nowy­mi prze­pi­sa­mi i regu­la­cja­mi, wdra­ża­nie nowych tech­no­lo­gii oraz lep­sze zarzą­dza­nie zaso­ba­mi (Cohn & Hull, 2009), (Rummler & Brache, 2000), (Porter, 1998), 

Product Owner

jed­no­oso­bo­wa rola w pro­jek­cie, któ­ra odpo­wia­da za mak­sy­ma­li­za­cję korzy­ści jakie odno­si klient (nabyw­ca) z pro­duk­tu, przede wszyst­kim poprzez zarzą­dza­nie zakre­sem pro­duk­tu i wyma­ga­nia­mi oraz prze­ka­zy­wa­nie tej wie­dzy zespo­ło­wi deve­lo­per­skie­mu (dostaw­cy pro­duk­tu), pośred­ni­czy w komu­ni­ka­cji pomię­dzy zespo­łem wyko­naw­cy a inte­re­sa­riu­sza­mi pro­jek­tu po stro­nie zama­wia­ją­ce­go; z regu­ły peł­ni role ana­li­ty­ka biz­ne­so­we­go w eta­pie ana­li­zy biz­ne­so­wej, poprze­dza­ją­cym reali­za­cję (źr. Scott Ambler Agile Modeling: The Product Owner Role).


The role of Product Owner (Scott Ambler, Agile Modeling)

produkt

każ­dy obiekt ryn­ko­wej wymia­ny oraz wszyst­ko to, co może być ofe­ro­wa­ne na ryn­ku, pro­duk­tem może być dobro mate­rial­ne, usłu­ga (pro­fe­sjo­nal­na), miej­sce, orga­ni­za­cja bądź idea, przyj­mu­je się, że ma okre­ślo­ne cechy, nazwę, cenę ; tak­że każ­dy okre­ślo­ny efekt czy­jejś pra­cy pro­gram komputerowy

stan­dar­do­wo w języ­ku pol­skim defi­nio­wa­ny jako: ciąg instruk­cji napi­sa­nych w języ­ku zro­zu­mia­łym dla kom­pu­te­ra”, z uwa­gi na ist­nie­nie języ­ków pro­gra­mo­wa­nia wyż­sze­go pozio­mu i kom­pi­la­to­rów, jest to gene­ral­nie ciąg instruk­cji wyra­żo­ny w dowol­nej, ale sfor­ma­li­zo­wa­nej for­mie, w obec­nych cza­sach pro­gram kom­pu­te­ro­wy jest to każ­da for­ma jego jed­no­znacz­ne­go wyrażenia: 

Programming is not sole­ly abo­ut con­struc­ting softwa­re — pro­gram­ming is abo­ut desi­gning softwa­re [Programowanie to nie tyl­ko two­rze­nie opro­gra­mo­wa­nia – pro­gra­mo­wa­nie to pro­jek­to­wa­nie oprogramowania.]. 

(Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049)

projekt

doku­ment zawie­ra­ją­cy obli­cze­nia, rysun­ki itp. doty­czą­ce wyko­na­nia jakie­goś obiek­tu lub urzą­dze­nia, tak­że opro­gra­mo­wa­nia (na podst. s.j.p. PWN), tak­że opi­sa­ny i nazwa­ny zbiór aktyw­no­ści, któ­rych celem jest powsta­nie takie­go doku­men­tu (pro­dukt)

przestrzeń nazw

zestaw pojęć, któ­rych defi­ni­cje się wza­jem­nie wyklu­cza­ją, wypeł­nia­ją­cych zna­cze­nia­mi, w spo­sób zupeł­ny, pewien ści­śle okre­ślo­ny, zamknię­ty obszar poję­cio­wy (dzie­dzi­no­wy); poję­cia danej prze­strze­ni nazw pozwa­la­ją na jed­no­znacz­ne opi­sa­nie dowol­ne­go bytu dane­go obsza­ru poję­cio­we­go (dzie­dzi­no­we­go) na usta­lo­nym pozio­mie abs­trak­cji; swo­bo­da łącze­nia pojęć w zda­nia (budo­wa­nie opi­su z uży­ciem pojęć danej prze­strze­ni nazw) może być ogra­ni­czo­ne okre­ślo­ny­mi regu­ła­mi; zna­cze­nie pojęć to ich seman­ty­ka, regu­ły ich łącze­nia to syn­tak­ty­ka, prze­strzeń nazw wraz z jej syn­tak­ty­ka to nota­cja (opr. wł. J.Żeliński)

przypadek użycia

(usłu­ga apli­ka­cji) repre­zen­tu­je okre­ślo­ne, ini­cjo­wa­ne przez akto­ra (użyt­kow­ni­ka), zacho­wa­nie, któ­re­go celem jest z góry okre­ślo­ny i przy­dat­ny dla akto­ra rezul­tat, może zawie­rać moż­li­we warian­ty jego pod­sta­wo­we­go zacho­wa­nia (zestaw zacho­wań sys­te­mu sku­pio­ny wokół jed­ne­go kon­tek­stu), w tym wyjąt­ko­we zacho­wa­nie takie jak obsłu­ga błę­dów, ozna­cza kon­kret­ne (w celu uzy­ska­nia kon­kret­ne­go efek­tu) uży­cie Systemu (apli­ka­cji); klu­czo­we poję­cia sko­ja­rzo­ne z Przypadkami Użycia to Aktor i System (na pod­sta­wie UML v.2.5.1., www​.omg​.org).

PSM

ang. Platform Specific Model; trze­ci etap pro­ce­su MDA (ang. model spe­cy­ficz­ny dla uży­tej tech­no­lo­gii), (Model Driven Architecture (MDA) | Object Management Group, n.d.); jest to peł­ny model archi­tek­tu­ry imple­men­ta­cji (sta­no­wi roz­sze­rze­nie mode­lu PIM); (patrz tak­że słow­nik IGI Global)

rachunek zdań

teo­ria log. roz­wa­ża­ją­ca związ­ki mię­dzy zda­nia­mi w obrę­bie zdań zło­żo­nych; ?teo­ria spój­ni­ków log., ich seman­tycz­nych wła­ści­wo­ści oraz wszel­kich pojęć, któ­re moż­na defi­nio­wać, odwo­łu­jąc się wyłącz­nie do postu­la­tów okre­śla­ją­cych sens spój­ni­ków logicz­nych; za pomo­cą funk­to­rów zda­nio­twór­czych może­my two­rzyć róż­ne sche­ma­ty zdań lub funk­cji zda­nio­wych zło­żo­nych; w popraw­nym wnio­sko­wa­niu waż­ną rolę odgry­wa­ją takie zda­nia zło­żo­ne, któ­re są zawsze praw­dzi­we bez wzglę­du na war­to­ści logicz­ne zdań, z któ­rych zosta­ły zbu­do­wa­ne; zda­nia takie nazy­wa­my pra­wa­mi lub tau­to­lo­gia­mi rachun­ku zdań (pra­wa rachun­ku zdań).

RACI

akro­nim od angiel­skich słów: Responsible, Accountable, Consult, Inform. Oznaczają kolejno:

  • R – Responsible, to oso­ba odpo­wie­dzial­na za reali­za­cję (wyko­na­nie) zada­nia i jego pro­dukt,
  • A – Accountable to oso­ba odpo­wia­da­ją­ca za powsta­ły produkt, 
  • C – Consult, to oso­ba posia­da­ją­ca wie­dzę mery­to­rycz­ną o przed­mio­cie zada­nia, jest eks­per­tem dzie­dzi­no­wym, jest to oso­ba dostęp­na na żąda­nie jako konsultant, 
  • I – Informed, to oso­ba, któ­ra jest infor­mo­wa­na o zakoń­cze iu i wytwo­rze­niu pro­duk­tu zadania.

Macierz ta wyko­rzy­sty­wa­na do doku­men­to­wa­nia zakre­su odpo­wie­dzial­no­ści w pro­ce­sach i procedurach:

Przykład macie­rzy RACI.

realizacja systemu

spe­cy­fi­ka­cja cech sys­te­mu: metod ope­ra­cji oraz typów i war­to­ści atry­bu­tów, wyra­żo­na w posta­ci wzo­rów mate­ma­tycz­nych, algo­ryt­mów lub tablic, opi­su­ją­cych powsta­wa­nie odpo­wie­dzi sys­te­mu na bodź­ce (J.Żeliński, Zastosowanie nota­cji UML i Ogólnej Teorii Systemów w mode­lo­wa­niu odpo­wie­dzi sys­te­mów, 2019); model sza­blo­nów, syn­te­zy mode­li, ram, skład­ni­ków itp. (UML v.2.5.1. Rozdz. 7.7.3.4 Realization).

reguła decyzyjna

pro­ce­du­ra porów­ny­wa­nia i łącze­nia decy­zji cząst­ko­wych w celu otrzy­ma­nia decy­zji koń­co­wej (final­nej) (na podst. Czesław S. Nosal, Psychologia decy­zji kadro­wych. Strategie. Kryteria. Procedury., Wydawnictwo Profesjonalnej Szkoły Biznesu, Kraków 1997, ISBN: 83 – 85441 – 68 – 9 (38+0)

reguły biznesowe

w orga­ni­za­cji: zbiór ogra­ni­czeń wyzna­cza­ją­cych gra­ni­cę pomię­dzy dopusz­czal­ny­mi i nie­do­pusz­czal­ny­mi dzia­ła­nia­mi w orga­ni­za­cji, regu­łą biz­ne­so­wą jest ogra­ni­cze­nie spe­cy­ficz­ne dla danej orga­ni­za­cji, zde­fi­nio­wa­ne dla całe­go jej obsza­ru funk­cjo­no­wa­nia. (źr. R.Ross Business Rule Concepts: Getting to the Point of Knowledge”, www​.busi​nessru​les​gro​up​.org), (patrz tak­że poli­ty­ka biz­ne­so­wa), w sys­te­mie infor­ma­cyj­nym: zasa­dy, wyra­żo­ne zda­nia­mi w języ­kiem natu­ral­nym, zbu­do­wa­ne ze zde­fi­nio­wa­nych w biz­ne­so­wym słow­ni­ku pojęć (nazw doku­men­tów, ich atry­bu­tów, war­to­ści atry­bu­tów) i fak­tów (pre­dy­ka­tów) two­rzą­cych zda­nia prawdziwe.

repozytorium

wzo­rzec archi­tek­to­nicz­ny, któ­re­go cechą jest obiekt reali­zu­ją­cy inter­fejs sepa­ru­ją­cy kolek­cję obiek­tów prze­cho­wu­ją­cych dane od oto­cze­nia, celem sto­so­wa­nia jest her­me­ty­za­cja utrwa­la­nia; dość czę­stym błę­dem jest obcią­ża­nie repo­zy­to­rium ope­ra­cją two­rze­nia nowych obiek­tów; klu­czo­wą cechą tego wzor­ca jest to, że nie reali­zu­je on logi­ki dzie­dzi­no­wej, inter­fejs do kolek­cji to tyl­ko ope­ra­cje zapisz() i przy­wo­łaj(), przej­mu­je jed­nak na sie­bie kon­tro­lę dostę­pu do tych danych (zgod­nie z zasa­dą, że nośnik danych nie wie kto może go czytać) 

REST API

Representational sta­te trans­fer (REST), styl archi­tek­to­nicz­ny opro­gra­mo­wa­nia, któ­ry został stwo­rzo­ny w celu kie­ro­wa­nia pro­jek­to­wa­niem i roz­wo­jem archi­tek­tu­ry sie­ci WWW (World Wide Web); defi­niu­je zestaw ogra­ni­czeń doty­czą­cych tego, jak powin­na zacho­wy­wać się archi­tek­tu­ra sys­te­mu roz­pro­szo­ne­go, takie­go jak np. sieć WWW; REST kła­dzie nacisk na ska­lo­wal­ność inte­rak­cji mię­dzy kom­po­nen­ta­mi, jed­no­li­te inter­fej­sy, nie­za­leż­ne wdra­ża­nie kom­po­nen­tów oraz two­rze­nie archi­tek­tu­ry war­stwo­wej, uła­twia­ją­cej bufo­ro­wa­nie kom­po­nen­tów w celu zmniej­sze­nia opóź­nień, wymu­sza­nie bez­pie­czeń­stwa i her­me­ty­za­cję star­szych sys­te­mów. REST jest sto­so­wa­ny w całej bran­ży opro­gra­mo­wa­nia i sta­no­wi powszech­nie akcep­to­wa­ny zestaw wytycz­nych do two­rze­nia bez­sta­no­wych, nie­za­wod­nych inter­fej­sów API, umoż­li­wia­ją­cych dostęp do zaso­bów za pomo­cą para­me­trów zako­do­wa­nych w adre­sie URL z wyko­rzy­sta­niem for­ma­tów JSON lub XML do prze­ka­zy­wa­nia danych.

Standardowe pole­ce­nia REST:

GETpobie­ra­nia danych (np. żąda­nie wyda­nia tre­ści okre­ślo­nej fak­tu­ry, lub kolek­cji faktur)
POSTzacho­wa­nie nowych danych (np. żąda­nie zacho­wa­nia tre­ści nowej faktury)
PUTaktu­ali­za­cja ist­nie­ją­cych danych (np. żąda­nie nad­pi­sa­nia tre­ści okre­ślo­nej faktury)
PATCHróż­ni­co­wa aktu­ali­za­cja ist­nie­ją­cych danych (np. żąda­nie aktu­ali­za­cji okre­ślo­nych pól tre­ści okre­ślo­nej faktury)
DELETEusu­wa­nia ist­nie­ją­cych danych (np. żąda­nie usu­nię­cia tre­ści okre­ślo­nej faktury)
Modelowanie inter­fej­sów na dia­gra­mie kom­po­nen­tów UML i ich spe­cy­fi­ko­wa­nie na dia­gra­mie klas.

Na powyż­szym dia­gra­mie poka­za­no dwa kom­po­nen­ty: Klient (żąda usług) i Serwer (świad­czy usłu­gi). Przepływ danych może być w dwie stro­ny: pole­ce­nie get do Klienta oraz pole­ce­nia cre­ate i upda­te do ser­we­ra, jed­nak ini­cjo­wa­ny jest z zasa­dy przez kom­po­nent Klient (usłu­go­bior­ca).

rozwiązanie

pro­jekt i reali­za­cja okre­ślo­nych zało­żeń archi­tek­to­nicz­nych, kon­struk­cyj­nych, itp., w tym np. pro­jekt zmian orga­ni­za­cyj­nych, wyma­ga­ne do tego celu narzę­dzia i środ­ki np. oprogramowanie

SA-CAD

System Architecting CAD (SA-CAD), wyko­rzy­sty­wa­ny do wspo­ma­ga­nia kon­cep­cyj­ne­go pro­jek­to­wa­nia wie­lo­dy­scy­pli­nar­nych pro­duk­tów o zło­żo­nej struk­tu­rze; SACAD powi­nien wspie­rać hie­rar­chicz­ną dekom­po­zy­cję sys­te­mu opi­sy na pozio­mie sys­te­mu oraz roz­wój zacho­wań i struk­tu­ry pod­sys­te­mów i komponentów.

Komoto, H., & Tomiyama, T. (2012). A fra­me­work for com­pu­ter-aided con­cep­tu­al design and its appli­ca­tion to sys­tem archi­tec­ting of mecha­tro­nics pro­ducts. Computer-Aided Design, 44(10), 931 – 946. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​c​a​d​.​2​0​1​2​.​0​2​.​004

saga

wzo­rzec archi­tek­to­nicz­ny sto­so­wa­ny do obsłu­gi sce­na­riu­szy i trans­ak­cji o dłu­gim cza­sie życia, pier­wot­nie w sys­te­mach z baza­mi danych w mode­lu rela­cyj­nym, obec­nie sto­so­wa­ny do inte­gra­cji kom­po­nen­tów i mikro­ser­wi­sów, jako imple­men­ta­cji kon­tro­li całe­go sce­na­riu­sza sekwen­cji wywo­ły­wa­nych ope­ra­cji innych obiek­tów, w jed­nym dedy­ko­wa­nym do tego obiekcie:


Problem: hazard czy­li trud­ne do prze­wi­dze­nia zacho­wa­nie sys­te­mu (kolej­ność akcji) w przy­pad­ku wywo­łań ad-hoc mię­dzy kom­po­nen­ta­mi bez koordynacji. 
Rozwiązanie: Saga czy­li jeden dodat­ko­wy kom­po­nent (lub apli­ka­cja, tu ESB) kon­tro­lu­je w 100% sekwen­cję 9scenariusz) akcji, dzię­ki cze­mu wyeli­mi­no­wa­no zja­wi­sko hazar­du i umoż­li­wio­no dodat­ko­wo reali­za­cję trans­ak­cyj­no­ści w zło­żo­nym, kom­po­nen­to­wym sys­te­mie. Wzorzec sto­so­wa­ny w inte­gra­cji apli­ka­cji i w wewnętrz­nej archi­tek­tu­rze opar­tej na mikroserwisach. 

Dürr, K., Lichtenthäler, R., & Wirtz, G. (2021). An Evaluation of Saga Pattern Implementation Technologies. ZEUS, 74 – 82. Garcia-Molina, H., & Salem, K. (1987). Sagas. ACM Sigmod Record16(3), 249 – 259. Štefanko, M., Chaloupka, O., Rossi, B., van Sinderen, M., & Maciaszek, L. (2019). The Saga pat­tern in a reac­ti­ve micro­se­rvi­ces envi­ron­ment. Proc. 14th Int. Conf. Softw. Technologies (ICSOFT 2019), 483 – 490.
Oliveira Rocha, H. F. (2022). Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices. Apress. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 1‑4842 – 7468‑2
Garcia-Molina, H., & Salem, K. (1987). Sagas. ACM Sigmod Record, 16(3), 249 – 259.
Štefanko, M., Chaloupka, O., Rossi, B., van Sinderen, M., & Maciaszek, L. (2019). The Saga pat­tern in a reac­ti­ve micro­se­rvi­ces envi­ron­ment. Proc. 14th Int. Conf. Softw. Technologies (ICSOFT 2019), 483 – 490.

SBVR

Semantics Of Business Vocabulary And Rules, (https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/), spe­cy­fi­ka­cja OMG defi­niu­ją­ca meto­dę two­rze­nia reguł biz­ne­so­wych oraz budo­wa­nie biz­ne­so­we­go słow­ni­ka pojęć, spe­cy­fi­ka­cja zawie­ra tak­że opis nota­cji do two­rze­nia tak zwa­nych dia­gra­mów fak­tów, są one gra­ficz­ną repre­zen­ta­cją biz­ne­so­we­go słow­ni­ka pojęć i jed­no­cze­śnie meto­dą mode­lo­wa­nia i kon­tro­li spój­no­ści dome­no­we­go sys­te­mu pojęć (ang. namespace).

scenariusz

zapla­no­wa­ny lub prze­wi­dy­wa­ny prze­bieg wyda­rzeń (źr. s.j.p. PWN)

SDLC

ang. Software Development Life Cycle (Cykl Życia Rozwoju Oprogramowania) defi­nio­wa­ny jako: Proces wytwa­rza­nia opro­gra­mo­wa­nia w kil­ku okre­ślo­nych klu­czo­wych eta­pach, mają­cy na celu wdro­że­nia jako­ści i wydaj­no­ści; pro­ces ten nie ma jed­nej usta­lo­nej posta­ci, naj­czę­ściej jest opi­sy­wa­ny jako ite­ra­cyj­ne fazy: pla­no­wa­nie, ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja i testy, wdro­że­nie i utrzymanie.

(Designing Security and Privacy Requirements in Internet of Things: A Survey)sekwen­cja

układ jakichś ele­men­tów, w któ­rym nastę­pu­ją one w okre­ślo­nej kolej­no­ści (źr. s.j.p. PWN)

semantyka

dział języ­ko­znaw­stwa, któ­re­go przed­mio­tem jest ana­li­za zna­czeń wyra­zów; dział semio­ty­ki zaj­mu­ją­cy się bada­niem związ­ków, jakie zacho­dzą mię­dzy wyra­że­nia­mi języ­ka a przed­mio­ta­mi, do któ­rych się one odnoszą

semiotyka

ogól­na teo­ria zna­ku w pro­ce­sie poro­zu­mie­wa­nia się ludzi

SOA

ang. Service Oriented Architecture, pol. archi­tek­tu­ra (apli­ka­cji) zorien­to­wa­na na usłu­gi (patrz tak­że usłu­ga apli­ka­cji), tak­że Service-Oriented Computing

software developer

wyko­rzy­stu­je swo­ją pro­fe­sjo­nal­ną wie­dzę i umie­jęt­no­ści do pisa­nia i mody­fi­ko­wa­nia opro­gra­mo­wa­nia w okre­ślo­nym języ­ku pro­gra­mo­wa­nia (tech­no­lo­gii), prze­zna­czo­ne­go do użyt­ku przez klien­tów koń­co­wych, doku­men­tu­je opro­gra­mo­wa­nie i testu­ją apli­ka­cje dla klien­tów, bie­rze udział w peł­nym cyklu badań, roz­wo­ju, testo­wa­nia i wpro­wa­dza­nia pro­duk­tu na rynek.
(na pod­sta­wie https://​www​.com​pu​ter​scien​ce​.org/​r​e​s​o​u​r​c​e​s​/​s​o​f​t​w​a​r​e​-​d​e​v​e​l​o​p​e​r​-​v​s​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​er/ i https://​www​.lewa​gon​.com/​t​e​c​h​-​j​o​b​s​/​w​e​b​-​d​e​v​e​l​o​p​m​e​n​t​/​f​u​l​l​-​s​t​a​c​k​-​d​e​v​e​l​o​per)

software engineer

(inży­nier opro­gra­mo­wa­nia) inży­nie­ro­wie opro­gra­mo­wa­nia sie­dzą na szczy­cie struk­tu­ry inży­nie­rii opro­gra­mo­wa­nia”. Stosują zasa­dy inży­nie­rii do two­rze­nia pro­gra­mów kom­pu­te­ro­wych i zarzą­dza­nia dany­mi. Wymagania zawo­do­we wykra­cza­ją poza wie­dzę tech­nicz­ną, ponie­waż inży­nie­ro­wie opro­gra­mo­wa­nia komu­ni­ku­ją się z róż­ny­mi pod­mio­ta­mi, od kode­rów po użyt­kow­ni­ków. W tym celu inży­nie­ro­wie opro­gra­mo­wa­nia muszą posia­dać solid­ną wie­dzę na temat algo­ryt­mów, języ­ków, struk­tur danych, ska­lo­wal­no­ści oraz naj­lep­szych prak­tyk w zakre­sie inży­nie­rii sys­te­mów i two­rze­nia stron inter­ne­to­wych. Stroną reali­za­cji zaj­mu­je się softwa­re deve­lo­per.
(na pod­sta­wie https://​www​.com​pu​ter​scien​ce​.org/​r​e​s​o​u​r​c​e​s​/​s​o​f​t​w​a​r​e​-​d​e​v​e​l​o​p​e​r​-​v​s​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​er/)

SPEM

Software & Systems Process Engineering Metamodel; spe­cy­fi­ka­cja defi­niu­je klu­czo­we eta­py, ele­men­ty i role pro­ce­su two­rze­nia opro­gra­mo­wa­nia: eta­py: ana­li­za, spe­cy­fi­ko­wa­nie przy­pad­ków uży­cia, model sys­te­mu, mode­lo­wa­nie reali­za­cji przy­pad­ków uży­cia; klu­czo­wa rola to ana­li­tyk projektant.

Kluczowe pro­duk­ty i role (źr. SPEM 2.0)
Kolejne sta­ny dla każ­de­go przy­pad­ków uży­cia jako ele­men­tu reali­za­cji zakre­su pro­jek­tu (źr. SPEM 2.0)

(źr. OMG SPEM 2.0).

stereotyp

jest to mecha­nizm roz­sze­rza­nia zakre­su zna­czeń ele­men­tów w języ­ku UML, któ­ry umoż­li­wia doda­wa­nie nowych słów klu­czo­wych do języ­ka UML w celu two­rze­nia nowych ele­men­tów mode­lu, sto­su­jąc odpo­wied­nie ste­reo­ty­py w mode­lu, moż­na spra­wić, że model będzie bar­dziej zro­zu­mia­ły; np. chcąc poka­zać roz­róż­nie­nie mode­li na HLD (wyso­ki poziom abs­trak­cji) i LLD (niski poziom abs­trak­cji) moż­na ozna­czyć pakie­ty gro­ma­dzą­ce te mode­le: «modelHLD» i «modelLLD», innym przy­kła­dem jest czę­sto sto­so­wa­ne roz­sze­rze­nie poję­cia Aktor na dia­gra­mach przy­pad­ków uży­cia na «human» i <>appli­ca­tion» (lub «sys­tem»)

przy­kład ozna­cze­nie ele­men­tu nota­cji UML stereotypem

(zobacz jak two­rzyć ste­reo­ty­py w Visual Paradigm)

stożek niepewności

narzę­dzie sto­so­wa­ne w zarza­dza­niu pro­jek­ta­mi do zarzą­dza­nia ryzy­kiem, jest to wykres empi­rycz­ny, ogól­nie obra­zu­je on male­ją­ce ryzy­ko pro­jek­tu wraz z postę­pem pro­ce­su pla­no­wa­nia i pro­jek­to­wa­nia, w inży­nie­rii opro­gra­mo­wa­nia uży­wa­ny do zobra­zo­wa­nia i zarzą­dza­nia ryzy­kiem pro­jek­tu wytwarzania/dostarczania oprogramowania:

strategia

prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie (s.j.p. PWN); Strategia wyra­ża cele dłu­go­ter­mi­no­we [przed­się­bior­stwa], odpo­wia­da­ją­ce gene­ral­nym kie­run­kom dzia­ła­nia (A.D. Chandler 1962) 

sylogizm

(w logi­ce tra­dy­cyj­nej) sche­mat wnio­sko­wa­nia, w któ­rym prze­cho­dzi się z dwu prze­sła­nek zawie­ra­ją­cych ten sam ter­min do kon­klu­zji zbu­do­wa­nej z pozo­sta­łych dwóch ter­mi­nów wystę­pu­ją­cych w prze­słan­kach, np. jeśli każ­dy czło­wiek jest ssa­kiem, a każ­dy ssak jest krę­gow­cem, to każ­dy czło­wiek jest kręgowcem

symulacja

sztucz­ne odtwa­rza­nie wła­ści­wo­ści dane­go obiek­tu lub zja­wi­ska za pomo­cą jego mode­lu (s.j.p.)

syntaktyka

dział semio­ty­ki bada­ją­cy wza­jem­ne sto­sun­ki i wła­ści­wo­ści budo­wy wyra­żeń języ­ka w pro­ce­sie poro­zu­mie­wa­nia się ludzi; skład­nia – nauka o budo­wie wypo­wie­dzeń, układ wypo­wie­dze­nia i jego budo­wa; też: funk­cja wyra­zu w zdaniu

SysML

Systems Modeling Language™ (OMG SysML®) jest gra­ficz­nym języ­kiem mode­lo­wa­nia ogól­ne­go prze­zna­cze­nia, słu­żą­cym do spe­cy­fi­ko­wa­nia, ana­li­zo­wa­nia, pro­jek­to­wa­nia i wery­fi­ko­wa­nia zło­żo­nych sys­te­mów, któ­re mogą obej­mo­wać sprzęt, opro­gra­mo­wa­nie, infor­ma­cje, per­so­nel, pro­ce­du­ry i obiek­ty. W szcze­gól­no­ści język ten dostar­cza gra­ficz­nych repre­zen­ta­cji z seman­tycz­ną pod­sta­wą do mode­lo­wa­nia wyma­gań sys­te­mo­wych, zacho­wa­nia, struk­tu­ry i para­me­trycz­no­ści, któ­ra jest uży­wa­na do inte­gra­cji z inny­mi mode­la­mi ana­li­zy inży­nier­skiej. (https://​www​.omg​sy​sml​.org/​w​h​a​t​-​i​s​-​s​y​s​m​l​.​htm), (patrz tak­że SysML FAQ)

system

w zna­cze­niu real­nym, obiekt kon­kret­ny lub mate­rial­ny (rzecz) zło­żo­ny z innych kon­kret­nych obiek­tów sta­no­wią­cych jego skład­ni­ki (czę­ści), któ­re są tak powią­za­ne ze sobą, że two­rzą całość wyod­ręb­nio­ną z oto­cze­nia (Chojnicki, 1988); zło­żo­na zor­ga­ni­zo­wa­na lub połą­czo­na gru­pa obiek­tów lub zbiór zasad, sche­mat, meto­da (Oxford English Dictionary, Second Edition, Oxford University Press, Oxford (1994)); patrz tak­że INCOSE: System Definition

system aksjomatyczny

log. zbiór tez, w któ­rym wyróż­nia się 2 pod­zbio­ry: aksjo­ma­ty oraz twier­dze­nia; sta­no­wi sys­tem zbu­do­wa­ny z okre­ślo­ne­go ukła­du aksjo­ma­tów (zw. jego aksjo­ma­ty­ką) oraz ze zbio­ru twier­dzeń sta­no­wią­cych ich logicz­ne kon­se­kwen­cje, tj. wywie­dzio­nych z tych aksjo­ma­tów na pod­sta­wie przy­ję­tych w danym sys­te­mie aksjo­ma­tycz­nym reguł wnioskowania.

system dedukcyjny

log. sys­tem zdań skła­da­ją­cy się z zało­żeń oraz twier­dzeń (zdań) pochod­nych, któ­re wywo­dzi się z tych zało­żeń na pod­sta­wie wyraź­nie sfor­mu­ło­wa­nych, deduk­cyj­nych reguł wyni­ka­nia logicz­ne­go; (patrz: logi­ka zdań)

tablica decyzyjna

tabli­ca decy­zyj­na jest okre­ślo­ną struk­tu­rą zbio­ru zwią­za­nych ze sobą warun­ków, reguł decy­zyj­nych i podej­mo­wa­nych dzia­łań. (S. Wrycza, 1996, s. 121), może być sto­so­wa­na jako meto­da doku­men­to­wa­nia kry­te­riów decy­zyj­nych w regu­łach biz­ne­so­wych (patrz regu­ły biz­ne­so­we) (źr. R.Ross Business Rule Concepts: Getting to the Point of Knowledge”), decy­zja z uży­ciem tabli­cy decy­zyj­nej podej­mo­wa­na jest w jed­nym kroku 

taksonomia

w mode­lach poję­cio­wych struk­tu­ra (drze­wo) związ­ków gene­ra­li­za­cji i specjalizacji

taktyka

spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu (s.j.p. PWN); meto­da postę­po­wa­nia mają­ca dopro­wa­dzić do okre­ślo­ne­go celu stra­te­gicz­ne­go (Ireneusz Durlik, Inżyneria Zarządzania. Strategia i Projektowanie Systemów Produkcyjnych) 

termin

wyraz lub wyra­że­nie o spe­cjal­nym zna­cze­niu w jakiejś dzie­dzi­nie (patrz też: nazwa, pojęcie)

tertium non datur

[wym. ter­cjum non datur, trze­ciej (moż­li­wo­ści) nie ma], pra­wo logicz­ne gło­szą­ce, że dwa zda­nia ze sobą sprzecz­ne nie mogą być jed­no­cze­śnie fał­szy­we (tak­że: pra­wo wyłą­czo­ne­go środka)

traditio brevi manu

jed­na z form prze­nie­sie­nia posia­da­nia, pole­ga na tym, iż prze­nie­sie­nie posia­da­nia jest samo­ist­ne i nastę­pu­je na mocy samej umo­wy mię­dzy stro­na­mi, np. prze­nie­sie­nie praw mająt­ko­wych do utwo­ru już wcze­śniej wyda­ne­go do zapo­zna­nia sie z nim, wyma­ga wyłącz­nie zwar­cia umo­wy i speł­nie­nia jej warun­ków, jakim jest np. akt zapła­ty (art. 351 KC).

traditio longa manu

jed­na z form prze­nie­sie­nia posia­da­nia (insty­tu­cja pra­wa rze­czo­we­go ozna­cza­ją­ca fakt wła­da­nia rze­czą), pole­ga na wyda­niu rze­czy rozu­mia­nym jako jej udo­stęp­nie­niu (np. klu­czy do samo­cho­du, dedy­ko­wa­ne­go odno­śni­ka do pobra­niu pli­ku doku­men­tu z sie­ci Internet), któ­re dają fak­tycz­ną wła­dzę nad rze­czą (art. 348 KC).

trójkąt semiotyczny

trój­kąt prze­sta­wia­ją­cy zwią­zek mię­dzy sym­bo­lem (zna­kiem, sło­wem), jego zna­cze­niem (defi­ni­cja), a rze­cza­mi (przed­mio­ta­mi) zna­czo­ny­mi (tak nazwa­ny­mi) (tak­że: Trójkąt Ullmanna)

źr. Logika ogól­na, Grzegorz Malinowski, PWN 2010.

UML

Unified Modeling Language, nota­cja (sys­tem poję­cio­wy) opu­bli­ko­wa­ny przez orga­ni­za­cję Object Management Group, model poję­cio­wy dla ana­li­ty­ków i archi­tek­tów sys­te­mów, twór­ców opro­gra­mo­wa­nia a tak­że innych, w tym biz­ne­so­wych, zorien­to­wa­nych na obiek­to­wy para­dyg­mat ana­li­zy i projektowania.

usługa

dzia­łal­ność gospo­dar­cza, odpłat­ne świad­cze­nie czyn­no­ści zwią­za­nych z ofe­ro­wa­ny­mi umie­jęt­no­ścia­mi i wiedzą

usługa aplikacji

pra­ca w posta­ci prze­two­rze­nia infor­ma­cji (danych), wyko­na­na przez apli­ka­cję na rzecz (upraw­nio­ne­go) żąda­ją­ce­go reali­za­cji tej usłu­gi (na podst. Encyklopedia PWN: usłu­ga – świad­cze­nie, pra­ca na rzecz kogoś, patrz tak­że apli­ka­cja, SOA)

WfMC

Workflow Management Coalition, orga­ni­za­cja stan­da­ry­zu­ją­ca słow­nic­two w obsza­rze BPM (ang. Business Process Management), stro­na orga­ni­za­cji: wfmc​.org.

wiedza

ogół wia­do­mo­ści zdo­by­tych dzię­ki bada­niom, ucze­niu się itp.; też: zasób infor­ma­cji z jakiejś dzie­dzi­ny (źr. sł.j.p. PWN)

wymagania

zespół warun­ków, któ­rym ktoś lub coś musi odpo­wia­dać (źr. sł.j.p. PWN), opis cech okre­ślo­ne­go roz­wią­za­nia warun­ku­ją­cych jego przy­dat­ność w reali­za­cji celu orga­ni­za­cji, (opr. wł. J.Żeliński na pod­sta­wie SOA, MDA oraz publi­ka­cji IIBA), warun­kiem takim może być: zgod­ność usług apli­ka­cyj­nych z ich opi­sem (dane wej­ścio­we i wynik operacji/usługi), zgod­ność archi­tek­tu­ry roz­wią­za­nia z pro­jek­tem, zgod­ność logi­ki biz­ne­so­wej z jej opi­sem, zgod­ność z ogra­ni­cze­nia­mi nało­żo­ny­mi na roz­wią­za­nie; wyma­ga­nia ozna­cza się (moż­na) pozio­mem istot­no­ści: musi…, nie musi…, zale­ca się by…, nie zale­ca się by… (źr. RFC2119).

wymagania biznesowe

ocze­ki­wa­nia wobec roz­wią­za­nia, wyra­żo­ne języ­kiem natu­ral­nym z per­spek­ty­wy przy­szłe­go użyt­kow­ni­ka tego roz­wią­za­nia (przez nie­go); klu­czo­wą cechą tych wyma­gań są potrze­by wyra­żo­ne w for­mie CO a nie JAK, chce osią­gnąć użyt­kow­nik. Jest to wyma­ga­nia opi­su­ją­cy zdol­ność, któ­rą orga­ni­za­cja lub sys­tem musi zapew­nić, aby zaspo­ko­ić potrze­bę inte­re­sa­riu­sza (Uwaga: Wymagania doty­czą­ce zdol­no­ści odno­szą­ce się do bez­pie­czeń­stwa i pry­wat­no­ści infor­ma­cji są wypro­wa­dza­ne z potrzeb ochro­ny inte­re­sa­riu­szy i odpo­wia­da­ją­cych im wyma­gań doty­czą­cych bez­pie­czeń­stwa i pry­wat­no­ści.). Także capa­bi­li­ty requ­ire­ments” (ang. wyma­ga­nia doty­czą­ce potencjału/zdolności). (patrz tak­że: capa­bi­li­ty requirements)

XML

(ang. eXtensible Markup Language, roz­sze­rzal­ny język znacz­ni­ków); inform. język for­mal­ny okre­śla­ją­cy uni­wer­sal­ny spo­sób zapi­su infor­ma­cji (doku­men­tów) przez pro­gra­my kom­pu­te­ro­we w spo­sób zawie­ra­ją­cy sfor­ma­to­wa­ny tekst oraz infor­ma­cje nie­tek­sto­we (meta­da­ne, odno­śni­ki do frag­men­tów doku­men­tu lub do innych doku­men­tów, rysun­ki itp.) np. moje dane to <imię>Jarosław</imię>, <nazwisko>Żeliński</nazwisko>, <email>j.zelinski@it-consulting.pl</email>; znacz­ni­ki: imię, nazwi­sko, ema­il, powin­ny mieć zde­fi­nio­wa­ne zna­cze­nia (meta­da­ne).

zadanie

ele­men­tar­na (nie­po­dziel­na) aktyw­ność, spo­sób jej reali­za­cji może być opi­sa­ny procedurą

Zasada Kerckhoffs’a

jed­na z pod­sta­wo­wych reguł współ­cze­snej kryp­to­gra­fii, zosta­ła sfor­mu­ło­wa­na pod koniec XIX wie­ku przez holen­der­skie­go kryp­to­lo­ga Augusta Kerckhoffs’a, mówi, że sys­tem kryp­to­gra­ficz­ny powi­nien być bez­piecz­ny nawet wte­dy, gdy są zna­ne wszyst­kie szcze­gó­ły jego dzia­ła­nia oprócz sekret­ne­go klu­cza; zasa­da ta może być roz­sze­rza­na tak­że na pro­ce­du­ry, to zna­czy, że bez­pie­czeń­stwo sys­te­mu nie powin­no zale­żeć od fak­tu ujaw­nie­nia pro­ce­dur utrzy­ma­nia jego bez­pie­czeń­stwa; zasa­da ta zosta­ła prze­for­mu­ło­wa­na (lub praw­do­po­dob­nie nie­za­leż­nie sfor­mu­ło­wa­na) przez ame­ry­kań­skie­go mate­ma­ty­ka Claude Shannon jako ? wróg zna sys­tem „, tj. ?nale­ży pro­jek­to­wać sys­te­my przy zało­że­niu, że wróg natych­miast się z nimi w peł­ni zapo­zna?; kon­cep­cja jest sze­ro­ko akcep­to­wa­na przez kryp­to­lo­gów, w prze­ci­wień­stwie do zasa­dy ?bez­pie­czeń­stwo poprzez zaciemnienie”.

związek

sto­su­nek mię­dzy rze­cza­mi, zja­wi­ska­mi itp. połą­czo­ny­mi ze sobą w jakiś spo­sób, sto­sun­ki łączą­ce ludzi opar­te na uczu­ciu, pokre­wień­stwie itp., kon­takt z kimś lub z czymś (SJP PWN), w nota­cji UML jest to aso­cja­cja i jej spe­cja­li­zo­wa­ne typy, są nimi: gene­ra­li­za­cja (spe­cja­li­za­cja, uogól­nie­nie), reali­za­cja, zależ­ność (w szcze­gól­no­ści zależ­ność uży­cia), kom­po­zy­cja (zwią­zek całość – część)