architektura kontrukcja

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura

Projekty infor­ma­tycz­ne się roz­ra­sta­ją, cała bran­ża ewo­lu­uje. Ostatnie 20 lat doświad­czeń poka­za­ło, że owszem sztu­ką jest stwo­rzyć i wdro­żyć opro­gra­mo­wa­nie, ale jesz­cze więk­szą sztu­ką jest je kon­ser­wo­wać, zmie­niać i roz­wi­jać. Wiele firm bory­ka się z powta­rza­ny­mi dłu­go­trwa­ły­mi i kosz­tow­ny­mi ana­li­za­mi przed­wdro­że­nio­wy­mi” poprze­dza­ją­cy­mi każ­dy kolej­ny pro­jekt wdra­ża­nia zmian. To sku­tek bra­ku aktu­al­nej doku­men­ta­cji posia­da­ne­go sys­te­mu. To jak pla­no­wa­nie nowej budo­wy w mie­ście nie mając aktu­al­nych pla­nów urba­ni­stycz­nych tego mia­sta: każ­dy nowy pro­jekt to ponow­ne doku­men­to­wa­nie sta­nu obec­ne­go, tyl­ko dla­te­go, że ktoś nie udo­ku­men­to­wał zmian wpro­wa­dzo­nych ostat­nim razem (być może poprzed­nio udo­ku­men­to­wał jakiś stan zasta­ny, jed­nak nie aktu­ali­zo­wał tej doku­men­ta­cji). Podobno deve­lo­per pamię­ta co mają jego klien­ci, jed­nak zmia­na deve­lo­pe­ra sta­je się wte­dy trud­na, a nie raz nie­moż­li­wa z powo­du złej umo­wy (pra­wo autor­skie) i bra­ku doku­men­ta­cji (wie­dza w gło­wach pro­gra­mi­stów, wdro­że­niow­ców, bywa, że nigdzie), to efekt zna­ny jako ven­dor lock-in.

Rozwiązaniem jest doku­men­ta­cja sys­te­mu. Co jest głów­nym wyzwa­niem w two­rze­niu doku­men­ta­cji sys­te­mu? Ustalenie kom­pro­mi­su mię­dzy szcze­gó­ło­wo­ścią doku­men­ta­cji a cza­sem i kosz­tem jej opra­co­wa­nia a potem aktu­ali­za­cji. Tym kom­pro­mi­sem jest archi­tek­tu­ra: struk­tu­ra opi­su­ją­ca co i do cze­go słu­ży: ele­men­ty sys­te­mu i ich wza­jem­ne powią­za­nia, ale bez anga­żo­wa­nia się w doku­men­to­wa­nie deta­li tych ele­men­tów (her­me­ty­za­cja). To dla­te­go bar­dzo przy­dat­ne jest kom­po­nen­to­we podej­ście do pro­jek­to­wa­nia i obiek­to­wy para­dyg­mat two­rze­nia opro­gra­mo­wa­nia.

Dzisiaj kil­ka słów o trzech książ­kach, każ­da z nich była na tym blo­gu krót­ko recen­zo­wa­na, razem sta­no­wią moim zda­niem pod­sta­wo­wy zestaw pro­jek­tan­ta. Pod poję­ciem pro­jek­to­wa­nia rozu­mie­my two­rze­nie pro­jek­tu sys­te­mu czy­li doku­men­to­wa­nie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książ­ka to rodzaj pod­su­mo­wa­nia. We wstę­pie czytamy:

Architektura opro­gra­mo­wa­nia – kon­cep­cyj­ny klej, któ­ry spa­ja każ­dą fazę pro­jek­tu, dla jego wie­lu inte­re­sa­riu­szy – jest powszech­nie uzna­wa­na za kry­tycz­ny ele­ment współ­cze­sne­go roz­wo­ju opro­gra­mo­wa­nia. Praktycy coraz czę­ściej prze­ko­nu­ją się, że poświę­ca­nie szcze­gól­nej uwa­gi archi­tek­tu­rze sys­te­mu opro­gra­mo­wa­nia przy­no­si wymier­ne korzy­ści. Bez archi­tek­tu­ry, któ­ra jest odpo­wied­nia dla roz­wią­zy­wa­ne­go pro­ble­mu, pro­jekt będzie się poty­kał, a naj­praw­do­po­dob­niej zakoń­czy się nie­po­wo­dze­niem. Ale nawet przy dosko­na­łej archi­tek­tu­rze, jeśli nie jest ona dobrze rozu­mia­na i prze­ka­zy­wa­na, pro­jekt ma małe szan­se powodzenia. 

Książka Documenting Software Architectures, dostar­cza naj­bar­dziej kom­plet­nych i aktu­al­nych wska­zó­wek, nie­za­leż­nie od języ­ka czy nota­cji, jak ująć archi­tek­tu­rę w powszech­nie zro­zu­mia­łej for­mie. Bazując na swo­im boga­tym doświad­cze­niu, auto­rzy naj­pierw poma­ga­ją zde­cy­do­wać, jakie infor­ma­cje nale­ży udo­ku­men­to­wać, a następ­nie, za pomo­cą wska­zó­wek i przy­kła­dów (w róż­nych nota­cjach, w tym UML), poka­zu­ją, jak wyra­zić archi­tek­tu­rę, aby inni mogli na jej pod­sta­wie z powo­dze­niem budo­wać, uży­wać i utrzy­my­wać sys­tem. Książka zawie­ra zasa­dy two­rze­nia solid­nej doku­men­ta­cji, cele i stra­te­gie doku­men­ta­cji, wido­ki i sty­le archi­tek­to­nicz­ne, doku­men­ta­cję inter­fej­sów opro­gra­mo­wa­nia i zacho­wa­nia opro­gra­mo­wa­nia oraz sza­blo­ny do zbie­ra­nia i orga­ni­zo­wa­nia infor­ma­cji w celu stwo­rze­nia spój­ne­go pakietu. 

Zdaniem auto­rów klu­czem są poję­cia: ele­ment sys­te­mu, jego cechy i związ­ki mię­dzy tymi ele­men­ta­mi. Zwracają uwa­gę na to, że zwią­zek mię­dzy ele­men­ta­mi to ich wza­jem­ne wywo­ły­wa­nie się (współ­pra­ca to nie rela­cje a uży­cie). Mając model poja­wia się dru­ga waż­na rzecz: adre­sa­ci infor­ma­cji czy­li per­spek­ty­wy opi­su sys­te­mu. Dlatego kolej­na istot­na rzecz to treść i for­ma pre­zen­to­wa­nia kontekstu. 

Kolejna książ­ka to Architektura Oprogramowania w Praktyce . Ze wstęu: Wielokrotnie nagra­dza­na i cie­szą­ca się dużym zain­te­re­so­wa­niem Architektura opro­gra­mo­wa­nia w prak­ty­ce, wyda­nie trze­cie, zosta­ła zna­czą­co zmie­nio­ne, aby odzwier­cie­dlić naj­now­sze osią­gnię­cia w tej dzie­dzi­nie. W książ­ce po raz kolej­ny przed­sta­wio­no kon­cep­cje i naj­lep­sze prak­ty­ki archi­tek­tu­ry opro­gra­mo­wa­nia – struk­tu­rę sys­te­mu opro­gra­mo­wa­nia oraz spo­sób, w jaki jego ele­men­ty mają ze sobą współdziałać. 

W tym wyda­niu auto­rzy sku­pi­li się na kon­cep­cji roz­wo­ju archi­tek­tu­ry. Każdy cykl roz­wo­ju poka­zu­je, w jaki spo­sób archi­tek­tu­ra wpły­wa na okre­ślo­ny kon­tekst, w któ­rym odgry­wa klu­czo­wą rolę, oraz jak jest kształ­to­wa­na przez ten kon­tekst. Konteksty te obej­mu­ją śro­do­wi­sko tech­nicz­ne, cykl życia pro­jek­tu, pro­fil biz­ne­so­wy orga­ni­za­cji oraz prak­ty­ki zawo­do­we archi­tek­ta. Autorzy znacz­nie roz­sze­rzy­li tak­że omó­wie­nie atry­bu­tów jako­ści, któ­re pozo­sta­ją cen­tral­nym ele­men­tem ich filo­zo­fii archi­tek­tu­ry – każ­de­mu z atry­bu­tów poświę­ci­li cały roz­dział – oraz roz­sze­rzy­li omó­wie­nie wzor­ców architektonicznych.” 

Autorzy cie­ka­wie pre­zen­tu­ją to jak i po co powsta­je doku­men­ta­cja: pro­ce­so­wo. Streszczają (pre­zen­tu­ją) treść książ­ki w posta­ci kil­ku pro­stych mode­li procesów:

Ta for­ma bar­dzo mi się spodo­ba­ła: poka­zu­je bodź­ce, model (arti­fact) logi­ki i efekt uzy­ska­ny. Generalnie auto­rzy w swo­jej książ­ce pre­zen­tu­ją prak­tycz­ne aspek­ty doku­men­to­wa­nia opro­gra­mo­wa­nia i sto­so­wa­nia tej doku­men­ta­cji. Pamiętajmy tak­że, że doku­men­ta­cja opro­gra­mo­wa­nia to przede wszyst­kim jego modele. 

Na koniec zosta­wi­łem książ­kę naj­star­szą: Large-Scale Software Architecture .

Jak piszą auto­rzy, celem pro­jek­to­wa­nia (doku­men­to­wa­nia) archi­tek­tu­ry dużych apli­ka­cji jest uchwy­ce­nie i opi­sa­nie prak­tycz­nych metod jego zobra­zo­wa­nia (udo­ku­men­to­wa­nia), mają­cych na celu zwięk­szyć efek­tyw­ność komu­ni­ka­cji zespo­łów pro­gra­mi­stów i ich zro­zu­mie­nia kon­tek­stu systemu.

W tej książ­ce auto­rzy poka­zu­ją, jak wyko­rzy­stać archi­tek­tu­rę opro­gra­mo­wa­nia już jako narzę­dzie na eta­pie zarzą­dza­nia roz­wo­jem apli­ka­cji, nie tyl­ko jako powy­ko­naw­czą doku­men­ta­cję po pod­ję­ciu wszyst­kich decy­zji pro­jek­to­wych. Prezentują w swo­jej książce:

  • Zwięzły opis wyko­rzy­sta­nia języ­ka UML w archi­tek­tu­rze dużych aplikacji, 
  • Architekturę opro­gra­mo­wa­nia i zasa­dy jej projektowania,
  • Zwracają uwa­gę na jej nie­za­leż­ność od tech­no­lo­gii i dostawców.
Struktura projektu UML

Tę książ­kę moż­na pod­su­mo­wać tak: każ­da archi­tek­tu­rę nale­ży doku­men­to­wać od ogó­łu do szcze­gó­łu, każ­dy model powi­nien być pro­sty i zwię­zły ale mode­li tych może być wie­le, każ­dy sys­tem to jego klu­czo­wa rola, jego wewnętrz­na struk­tu­ra i zacho­wa­nia jego skła­do­wych ele­men­tów oraz jego poję­cio­wy dzie­dzi­no­wy ogól­ny opis. 

Podsumowanie

Powyższe opi­sy to klu­czo­we cechy każ­dej z tych trzech pozy­cji. Moją inten­cją było pole­ce­nie tych trzech pozy­cji jako zesta­wu pre­zen­tu­ją­ce­go dość kom­plet­ną wie­dzę na temat sta­nu wie­dzy na temat pro­jek­to­wa­nia opro­gra­mo­wa­nia sku­pia­ją­ce­go się na jego archi­tek­tu­rze. Jako efekt uzy­sku­je­my doku­men­ta­cję rela­tyw­nie szczu­płą obję­to­ścio­wo, więc będzie czy­ta­na. Stosowanie stan­dar­du nota­cyj­ne­go, jakim jest UML, uzy­sku­je­my sze­ro­ki zasięg odbior­ców i uni­wer­sal­ność. Zwracają na to uwa­gę auto­rzy wszyst­kich tych trzech pozycji. 

Ostatnia pozy­cja to kla­sy­ka kom­po­nen­to­we­go podej­ścia do pro­jek­to­wa­nia. Pierwsze dwie powsta­ły kil­ka lat po fascy­na­cji auto­rów zwin­nym podej­ściem (agi­le). Podobnie jak Scott Ambler , odkry­li że zbyt­nie przy­kła­da­nie wagi do dzia­ła­ją­ce­go opro­gra­mo­wa­nia” na nie­ko­rzyść jego doku­men­ta­cji, powo­du­je szko­dy na kolej­nych eta­pach cyklu życia pro­duk­tu jakim jest aplikacja. 

Żadne opro­gra­mo­wa­nie nie powsta­je tyl­ko na jeden dzień, będzie komuś słu­ży­ło mie­sią­ca­mi, lata­mi, a świat nie stoi w miej­scu. sta­wia­nie tezy, że celem two­rze­nia opro­gra­mo­wa­nia jego powsta­nie jest szko­dli­we. Kluczem jest cykl życia opro­gra­mo­wa­nia, a jego doku­men­ta­cja to jedy­na for­ma komu­ni­ko­wa­nia się zmie­nia­ją­cych się osób, lata­mi zaan­ga­żo­wa­nych w utrzy­ma­nie i roz­wój aplikacji. 

Te trzy książ­ki to moim zda­niem mały zbiór rze­tel­nej wie­dzy, któ­ry powi­nien pomóc każ­de­mu począt­ku­ją­ce­mu i zagu­bio­ne­mu junio­ro­wi ana­li­zy biz­ne­so­wej” w nauce two­rze­nia wyso­kiej jako­ści doku­men­ta­cji. To tak­że wie­dza przy­dat­na dla doświad­czo­nych ana­li­ty­ków i pro­jek­tan­tów: zawsze war­to wie­dzieć jak robią to inni, mają­cy ogrom­ny doro­bek. Dokumentacja sys­te­mu to jedy­ne trwa­łe źró­dło wie­dzy o nim, jed­nak zła i nie­ak­tu­al­na doku­men­ta­cja jest gor­sza od jej braku… 

Źródła

Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord, R., & Stafford, J. (2015). Documenting Software Architecture (Second, Vol. 1 – 1). Pearson Education, Inc.
Bass, L., Clements, P., & Kazman, R. (2013). Software archi­tec­tu­re in prac­ti­ce (3rd ed). Addison-Wesley.
Ambler, S. W. (2002). Agile mode­ling. John Wiley & Sons.
Ambler, S. W. (2004). The object pri­mer. Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.
Garland, J., & Anthony, R. (2003). Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. J. Wiley.

Analiza efektywności i kosztów czyli symulacja procesu

Wstęp

Produktem mode­lo­wa­nia pro­ce­sów biz­ne­so­wych są jakieś dia­gra­my, i z tym jeste­śmy oswo­je­ni. Od cza­su do cza­su moż­na usły­szeć o symu­la­cjach pro­ce­sów, lecz to już jed­nak znacz­nie rza­dziej. O symu­la­cjach pro­ce­sów pisze się mniej: Google Scholar (lite­ra­tu­ra nauko­wa) poka­zu­je ok. 5 mln publi­ka­cji na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, na temat ich symu­la­cji 2 mln mniej. Ale już Google („cały Internet”) odpo­wied­nio: 2,3 mld. i 282 mln. Jak widać w powszech­nym obie­gu symu­la­cje, jako temat, to trzy rzę­dy (tysiąc­krot­nie) mniej­sza ilość tek­stów! (wyszu­ki­wa­ne były hasła ang. «busi­ness pro­cess mode­ling» oraz «busi­ness pro­cess simu­la­tion»). Zastanówmy się dla­cze­go i co moż­na osią­gnąć symulacją.

Czytaj dalej… Analiza efek­tyw­no­ści i kosz­tów czy­li symu­la­cja pro­ce­su”

Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp

Od lat spo­ty­kam się w lite­ra­tu­rze z zakre­su zarzą­dza­nia, z kry­ty­ką pocz­ty elek­tro­nicz­nej jako narzę­dziem zarzą­dza­nia czym­kol­wiek (patrz: Sabotaż…2013). Poczta elek­tro­nicz­na (podob­nie jak pakie­ty biu­ro­we w ogó­le) jest typo­wym przy­kła­dem mak­sy­my: uła­twie­nie nie zawsze jest ulep­sze­niem. W klien­cie pocz­ty elek­tro­nicz­nej zarów­no treść jak i spo­sób adre­so­wa­nia (co i do kogo, kopia, itp.) nie pod­le­ga żad­nej stan­da­ry­za­cji ani restryk­cji (pocz­ta elek­tro­nicz­na czę­sto słu­ży do wypro­wa­dza­nia danych z fir­my). Jak dodać do tego fakt, że załącz­ni­ki są nie­wi­docz­ne w narzę­dziach do lokal­ne­go wyszu­ki­wa­nia, że mamy na ser­we­rach fil­try anty­spa­mo­we któ­rych regu­ły nie pod­da­ją się kon­tro­li użyt­kow­ni­ków, że nie panu­je­my nad tym co inni mają w swo­ich skrzyn­kach pocz­to­wych, to mamy obraz abso­lut­ne­go bra­ku pano­wa­nia nad infor­ma­cją w orga­ni­za­cji i chaosu. 

Swego cza­su dr Paweł Litwiński, praw­nik, napi­sał kry­tycz­ny arty­kuł o zasto­so­wa­niu pocz­ty elek­tro­nicz­nej przez adwo­ka­tów. Jego tekst był sze­ro­ko cyto­wa­ny przez wie­lu auto­rów, tu jeden z takich arty­ku­łów. Wybrałem kil­ka waż­nych kwestii:

Praktyka poka­zu­je, że wie­lu adwo­ka­tów i rad­ców praw­nych korzy­sta z dar­mo­wych skrzy­nek, tak­że tych wprost zastrze­ga­ją­cych sobie pra­wo do ska­no­wa­nia korespondencji. […]

Konflikt pomię­dzy obo­wiąz­kiem ochro­ny infor­ma­cji a warun­ka­mi narzu­co­ny­mi w regu­la­mi­nach dar­mo­wych usług to jed­no. Czym innym są kwe­stie bezpieczeństwa.[…]

? Na logi­kę, lepiej żeby o mate­ria­łach obję­tych tajem­ni­cą adwo­kac­ką nie dowie­dział się żaden dostaw­ca, ale z dru­giej stro­ny, rzad­ko któ­rej kan­ce­la­rii praw­nej uda się samo­dziel­nie skon­fi­gu­ro­wać ser­wer pocz­to­wy tak, aby był rów­nie bez­piecz­ny i nie­awa­ryj­ny, jak infra­struk­tu­ra np. Gmaila. Oczywiście, moż­na zle­cić to zewnętrz­nej pol­skiej fir­mie, ale wte­dy mamy ten sam pro­blem z zaufa­niem, co w przy­pad­ku korzy­sta­nia z ser­we­rów np. Google ? zwra­ca uwa­gę Piotr Konieczny, eks­pert ds. cyber­bez­pie­czeń­stwa z ser­wi­su Niebezpiecznik​.pl. ? Abstrahując więc od aspek­tów praw­nych, roz­pa­tru­jąc pro­blem wyłącz­nie na płasz­czyź­nie bez­pie­czeń­stwa, tj. ochro­ny skrzyn­ki przed ata­ka­mi, moim zda­niem praw­ni­kom nie­dy­spo­nu­ją­cym budże­tem na bez­pie­czeń­stwo takim, jaki posia­da­ją pro­fe­sjo­nal­ni dostaw­cy usług pocz­to­wych, lepiej i pro­ściej było­by wyko­rzy­stać infra­struk­tu­rę np. Google?a ? doda­je. Jego zda­niem praw­ni­cy powin­ni przede wszyst­kim roz­wa­żyć moż­li­wość szy­fro­wa­nia kore­spon­den­cji. Wtedy zarów­no dar­mo­wy, jak i płat­ny dostaw­ca usług nie będzie w sta­nie jej podej­rzeć. Szyfrowanie jest bez wąt­pie­nia naj­bez­piecz­niej­szym spo­so­bem, ale wią­że się z koniecz­no­ścią dostar­cze­nia klu­cza czy hasła odbior­cy, a ten nie zawsze godzi się na takie nie­do­god­no­ści. Co wię­cej, klien­ci kan­ce­la­rii sami czę­sto korzy­sta­ją z dar­mo­wych skrzy­nek. ? I nie rozu­mie­ją, dla­cze­go pouf­ne infor­ma­cje nie powin­ny być na nie prze­sy­ła­ne. Moim obo­wiąz­kiem jest wów­czas poin­for­mo­wać takie­go klien­ta o zagro­że­niach z tym zwią­za­nych. Oczywiście jeśli mimo tego będzie chciał uży­wać takiej skrzyn­ki do kore­spon­den­cji ze mną, to nie mogę mu tego zabro­nić ? zwra­ca uwa­gę dr Paweł Litwiński. ? Z dru­giej stro­ny są rów­nież klien­ci, któ­rzy wręcz wyma­ga­ją, by w kore­spon­den­cji z nimi uży­wać jedy­nie skrzy­nek zało­żo­nych na ich ser­we­rach. Tak restryk­cyj­ną mają poli­ty­kę bez­pie­czeń­stwa. Chcąc dla nich pra­co­wać, adwo­kat czy rad­ca musi przy­stać na te warun­ki ? doda­je ekspert.

(patrz: Darmowe e‑maile nie dla praw­ni­ków. Dostawca pocz­ty ska­nu­je jej zawar­tość – Forsal​.pl)

W 2013 roku pisałem:

W więk­szo­ści przy­pad­ków treść umiesz­cza­na jest w tre­ści ema­il??a lub w załącz­ni­ku (załą­czo­ne doku­men­ty). Jeżeli treść ema­ila nie jest szy­fro­wa­na (a gene­ral­nie nie jest, o ile sami o to nie zadba­my, co jed­nak, jak poka­zu­je cyto­wa­ny Niebezpiecznik, nie jest try­wial­ne) nasza kore­spon­den­cja, prze­cho­dząc przez publicz­ne łącza sie­ci Internet, jest jaw­na i łatwa do pod­słu­chi­wa­nia. Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) niejawną?

(Patrz: Bezpieczny jak ema­il czy­li wca­le – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Przypomnę klu­czo­we tezy powyż­sze­go arty­ku­łu. Generalnie waż­nych doku­men­tów nie nale­ży prze­sy­łać jako załącz­ni­ki z dwóch powo­dów: nie wie­my co sie z nimi dzie­je po dro­dze, nie wie­my czy zosta­ły dostar­czo­ne, i kie­dy, gdyż bar­dzo wie­lu użyt­kow­ni­ków ema­il ma wyłą­czo­ne auto­ma­tycz­ne ode­sła­nie potwier­dze­nia w swo­jej poczcie, co skut­ku­je tym, że po pro­stu jest to nie­wia­ry­god­na for­ma potwier­dza­nia. Poniżej sche­mat poka­zu­ją­cy dro­gę pocz­ty email: 

Droga pocz­ty elektronicznej.

Środkowa część (Internet) to tak­że poten­cjal­ne kolej­ne pośred­ni­czą­ce ser­we­ry, nie wie­my co sie na nich dzie­je. Tak więc dwie klu­czo­we wady ema­il to poten­cjal­ne ska­no­wa­nie tre­ści po dro­dze oraz brak kon­tro­li nad dorę­cze­niem. Czy moż­na ina­czej? Owszem: do prze­ka­zy­wa­nia doku­men­tów moż­na użyć repo­zy­to­rium (ser­we­ra pli­ków) z kon­tro­lo­wa­nym dostę­pem. Poniżej sche­mat blo­ko­wy archi­tek­tu­ry nie­ma­ją­cej ww. wad prze­sy­ła­nia doku­men­tów mailem:

Dokumenty prze­ka­zy­wa­ne za pośred­nic­twem repozytorium

Dokumenty w dro­dze” nie opusz­cza­ją repo­zy­to­rium: z nasze­go kom­pu­te­ra ładu­je­my je na ser­wer wska­zu­jąc ewen­tu­al­nie okre­ślo­ne­go adre­sa­ta (lub robi to mecha­nizm obsłu­gu­ją­cy wymia­nę tre­ści pomię­dzy uczest­ni­ka­mi), okre­ślo­na oso­ba dosta­je mailem infor­ma­cje, że jest dla niej doku­ment, żeby go pobrać musi się zalo­go­wać do repo­zy­to­rium. W efek­cie treść (plik) nie jest nigdzie nara­żo­na na ska­no­wa­nie, podej­rze­nie go itp. Tu ema­il słu­ży wyłącz­nie do moni­to­wa­nia fak­tu, że jest doku­ment do nas adre­so­wa­ny i że moż­na do pobrać, co zosta­nie odnotowane.

Mając nawet pro­ste, dostęp­ne przez inter­net, repo­zy­to­rium, moż­na umie­ścić tam dowol­ny plik i mailem poin­for­mo­wać adre­sa­ta (wcze­śniej zakła­da­my mu tam kon­to), że powi­nien pobrać plik. Serwer reje­stru­je zarów­no moment zała­do­wa­nia pli­ku jak i jego pobra­nia, co jest gwa­ran­to­wa­nym zna­kiem cza­su nada­nia i dorę­cze­nia. Minus takie­go roz­wią­za­nia to ręcz­na obsłu­ga całe­go pro­ce­su, plus to pano­wa­nie nad wszyst­kim i bezpieczeństwo.

Sprawdzonym, od daw­na, na ryn­ku pomy­słem jest sys­tem work­flow z udo­stęp­nia­nym repo­zy­to­rium, auto­ma­ty­zu­ją­cy cały ten proces: 

Architektura sys­te­mu wymia­ny danych z Repozytorium.

Uogólniając moż­na go przed­sta­wić jako ser­wer usług:

System work­flow ste­ro­wa­ny regułami

System dorę­czeń to tak napraw­dę funk­cjo­nal­ność apli­ka­cji typu work­flow zorien­to­wa­ne­go na zada­nia (task mana­ger), mają­cej moż­li­wość udo­stęp­nie­nia jej kon­tra­hen­tom. Funkcjonalność taką ma wie­le sys­te­mów CRM, sys­te­mów help­desk, wie­le repo­zy­to­riów pozwa­la na skon­fi­gu­ro­wa­nie sub­skryp­cji zda­rzeń powią­za­nych z doku­men­ta­mi. Zbudowanie takie­go sys­te­mu opar­te­go na regu­łach, zamiast na macier­zach praw dostę­pu do doku­men­tów, zna­ko­mi­cie uprasz­cza całość i dodat­ko­wo pod­no­si bez­pie­czeń­stwo (bar­dzo uła­twia wdra­ża­nie RODO) . Ciekawą funk­cjo­nal­no­ścią jest moż­li­wość blo­ko­wa­nia moż­li­wo­ści pobra­nia doku­men­tu na lokal­ny dysk, dozwo­lo­ne jest jedy­nie prze­glą­da­nie tre­ści w prze­wi­ja­nym oknie (ofe­ru­ją to nie­któ­re tego typu systemy).

Systemy tego typu są tak­że wdra­ża­ne jako zamien­nik pocz­ty elek­tro­nicz­nej wewnątrz orga­ni­za­cji. Tam gdzie pod­sta­wo­wym wewnętrz­nym sys­te­mem komu­ni­ka­cji jest pocz­ta elek­tro­nicz­na pro­ble­mem są giną­ce doku­men­ty oraz brak dostę­pu do doku­men­tów (skrzy­nek) osób nie­do­stęp­nych, będą­cych poza fir­mą (chro­ba, dele­ga­cja itp.). Generalnie pocz­ta jako skład doku­men­tów” ma tę pod­sta­wo­wą wadę, że doku­men­ty są roz­pro­szo­ne i zarza­dza­nie nimi w jed­no­li­ty spo­sób jest nie­moż­li­we. Stosowanie współ­dzie­lo­nych dys­ków nie roz­wią­zu­je cał­ko­wi­cie pro­ble­mu, bo po pierw­sze nie da się budo­wać reguł dostę­pu, po dru­gie wymia­na doku­men­tów z oso­ba­mi spo­za fir­my jest bar­dzo trud­na (np. wyma­ga uru­cho­me­nia VPN co jest trud­ne, wyma­ga inge­ren­cji w cudzy kom­pu­ter, i coraz czę­ściej nie jest to moż­li­we w wie­lu firmach).

Tak więc pocz­ta elek­tro­nicz­na, jako swo­bod­na komu­ni­ka­cja mię­dzy ludź­mi owszem, jest przy­dat­na. Jednak jako narzę­dzie do zarzą­dza­nia komu­ni­ka­cją, prze­pły­wem tre­ści, doku­men­tów ich wydań i dorę­czeń, jest bar­dzo zawod­na. A war­to wie­dzieć, że praw­na ochro­na know-how w UE, czy­li w Polsce tak­że, to przede wszyst­kim obo­wią­zek ochro­ny tre­ści przez pod­miot chro­nią­cy (udo­stęp­nia­ją­cy) takie dane. Dlatego dość kurio­zal­nie wyglą­da każ­da fir­ma, któ­ra wysy­ła­jąc mailem umo­wę o pouf­no­ści (NDA) wysy­ła potem tak­że mailem te pouf­ne” dokumenty…

Na zakończenie

Rozwiązań, reali­zu­ją­cych opi­sa­ne wyżej funk­cje, nie bra­ku­je. Główną blo­ka­dą ich wdra­ża­nia jest przy­zwy­cza­je­nie do swo­bo­dy. Jednak pocz­ta elek­tro­nicz­na jest kla­sycz­nym przy­kła­dem tego, że uła­twie­nie nie zawsze jest ulep­sze­niem. O wdra­ża­niu sys­te­mów work­flow, panu­ją­cych nad komu­ni­ka­cją i jej pouf­no­ścią, mówi się podob­nie jak o sys­te­mach kopii zapa­so­wych: fir­my dzie­lą się na te, któ­re wdro­ży­ły sku­tecz­ny work­flow i na te któ­re wdrożą.

Kilka przy­kła­dów (nie ofe­ru­ję tych sys­te­mów, to nie są reko­men­da­cje a przykłady):

  • Biuro księ­go­we, któ­re mnie obsłu­gu­je, ode­szło od pro­ste­go sys­te­mu FK i komu­ni­ka­cji mailo­wej (prze­ka­zy­wa­nie doku­men­tów kosz­to­wych, wysy­ła­nie klien­tom dekla­ra­cji podat­ko­wych, rapor­tów itp.), obec­nie korzy­sta z podat​ki​po​dat​ki​.pl.
  • Zaczynałem jak wie­lu od pocz­ty elek­tro­nicz­nej, po kil­ku przy­go­dach z doku­men­ta­mi w pro­jek­tach (kto, co, kie­dy i komu) szyb­ko wdro­ży­łem dar­mo­wy, potem sup­por­to­wa­ny osTicket (na począ­tek bar­dzo dobry i łatwy we wdrożeniu). 
  • Z uwa­gi na spe­cy­fi­kę mojej pra­cy (pra­ca pole­ga­ją­ca na zbie­ra­niu danych i two­rze­niu rapor­tów z ana­liz, ich recen­zo­wa­nie przez klien­tów) uży­wam obec­nie do komu­ni­ka­cji bar­dziej zaawan­so­wa­ne­go opro­gra­mo­wa­nia PostMania.
  • U wie­lu klien­tów spo­ty­kam, popu­lar­ny w ser­wi­sach i fir­mach IT, Mantis.
  • Do zarzą­dza­nia pro­ce­sem nego­cjo­wa­nia i pod­pi­sy­wa­nia umów, wie­le firm i ich praw­ni­ków uży­wa opro­gra­mo­wa­nia Pergamin.
  • No i powszech­ny, z uwa­gi na pra­wo, ePUAP.

Polecam roz­wa­że­nie rezy­gna­cji z pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia doku­men­tów pro­jek­to­wych, nie tyl­ko z uwa­gi na ich bez­pie­czeń­stwo ale głów­nie z uwa­gi na zarzą­dza­nie nimi i kon­tro­le w całym cyklu życia dokumentu. 

Źródła

Paschke, A., & Kozlenkov, A. (2008). A Rule-based Middleware for Business Process Execution. 13.

Kiedy maszyna stanowa a kiedy jednak status?

Różnica mię­dzy sta­nem a sta­tu­sem obiektu

Wstęp

Od cza­su do cza­su wpa­da­ją mi maile z pyta­nia­mi jak to:

Chcę zamo­de­lo­wać dyna­micz­ne zacho­wa­nie / sta­ny smart­fo­na (np. wyłą­cze­nie smart­fo­na, ini­cja­li­za­cja, tryb czu­wa­nia, uży­cie) w dia­gra­mie maszy­ny sta­nów SysML. Dla sta­nu użyt­ko­wa­nia ist­nie­ją rów­nież pod­sta­ny takie jak dzwo­nie­nie, latar­ka lub robie­nie zdjęć. Nie jestem pewien czy powi­nie­nem mode­lo­wać te pod­sta­ny, a jeśli tak, to jak mogę je mode­lo­wać (szcze­gól­nie bio­rąc pod uwa­gę fakt, że każ­dy z tych pod­sta­nów może zmie­niać się w inny, jak rów­nież mogą one dzia­łać rów­no­le­gle).
Moim zda­niem są róż­ne opcje:
1.) Po pro­stu uwzględ­nić je jako aktyw­ność w uży­ciu sta­nu
2.) Wymodelować je w oddziel­nym dia­gra­mie maszy­ny sta­nów
3.) Modelować je w oddziel­nym dia­gra­mie aktyw­no­ści (czy mozna użyć dia­gra­mu aktyw­no­ści zamiast dia­gra­mu maszy­ny stanowej?)

Takie i podob­ne pyta­nia poja­wia­ją się w mailach do mnie czę­sto, ale zanim na nie odpo­wiem tu, opi­szę czym jest model (dia­gram) maszy­ny sta­no­wej. Pokażę tak­że dla­cze­go, np. pró­by wdra­ża­nia obie­gów doku­men­tów na bazie wzor­ca maszy­ny sta­no­wej” spra­wia­ją ogrom­ne kło­po­ty, lub po pro­stu się nie udają.

Na począ­tek to, co znaj­dzie­my np. w Longman English Dictionary:

sta­tus: a situ­ation at a par­ti­cu­lar time, espe­cial­ly in an argu­ment, discus­sion etc. (sytu­acja w okre­ślo­nym cza­sie, zwłasz­cza w kłót­ni, dys­ku­sji itp.)
sta­te: the phy­si­cal or men­tal con­di­tion that some­one or some­thing is in (stan fizycz­ny lub psy­chicz­ny, w jakim znaj­du­je się ktoś lub coś)

Tak więc gene­ral­nie sta­tus to ogląd obiek­tu z zewnątrz, stan to cecha obiek­tu. Innymi sło­wy moja cho­ro­ba to mój stan, ale moja nie­zdol­ność do pra­cy to aktu­al­ny mój sta­tus (wyni­ka on nie z cho­ro­by, a z usta­le­nia, że cho­rzy nie pra­cu­ją). Zapraszam do lektury. 

Czytaj dalej… Kiedy maszy­na sta­no­wa a kie­dy jed­nak sta­tus?”
Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

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

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

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

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

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

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

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

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

Czytaj dalej… Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje”