Wprowadzenie

W 2021 roku pisa­łem o sto­so­wa­niu dia­gra­mu aktyw­no­ści UML w kon­tek­ście two­rze­nia Opisu Technicznego Oprogramowania, zwra­ca­jąc uwa­gę, że potrze­bą jest to, że w toku pro­jek­to­wa­nia systemu: 

Kolejny etap to doku­men­to­wa­nie metod ope­ra­cji (algo­rytm)

(Diagram aktyw­no­ści UML – kie­dy – Jarosław Żeliński IT-Consulting)

Uporządkujmy poję­cia. Słownik j.p.:

algo­rytm mat. ?ści­śle okre­ślo­ny ciąg czyn­no­ści, któ­rych wyko­na­nie pro­wa­dzi do roz­wią­za­nia jakie­goś zadania?

pro­ce­du­ra ?w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu?

Oba ww. poję­cia są czę­sto uży­wa­ne naprze­mien­nie. Encyklopedia PWN podaje:

algo­rytm: prze­pis postę­po­wa­nia pro­wa­dzą­cy do roz­wią­za­nia usta­lo­ne­go pro­ble­mu, okre­śla­ją­cy ciąg czyn­no­ści ele­men­tar­nych, któ­re nale­ży w tym celu wykonać.

Dlatego upo­rząd­ku­je­my te zna­cze­nia. Na bazie powyż­sze­go moż­na powie­dzieć, że 

algo­rytm to sekwen­cja czyn­no­ści, gdzie każ­da czyn­ność jest opi­sa­na okre­ślo­ną procedurą

Kilka słów o mode­lo­wa­niu (i dokumentowaniu):

• jeże­li pra­cu­ję nad zro­zu­mie­niem logi­ki dzia­ła­nia orga­ni­za­cji, nie ma zna­cze­nia język programowania,
• jeże­li chce udo­ku­men­to­wać to co odkry­łem w toku ana­li­zy, nie ma zna­cze­nia język programowania,
• jeże­li chce zapro­jek­to­wać archi­tek­tu­rę przy­szłej apli­ka­cji, nie ma zna­cze­nia język programowania,
• jeże­li chcę opi­sać wyma­ga­ne algo­ryt­my, nie ma zna­cze­nia język programowania,
• jeże­li chcę te algo­ryt­my roz­ło­żyć na poszcze­gól­ne kom­po­nen­ty archi­tek­tu­ry apli­ka­cji, nie ma zna­cze­nia język programowania,
• jeże­li chce spraw­dzić jak to zadzia­ła i czy zadzia­ła, nie ma zna­cze­nia język programowania.

Co ma zna­cze­nie? Znaczenie ma umie­jęt­ność doku­men­to­wa­nia wie­dzy. Język pro­gra­mo­wa­nia ma zna­cze­nie dla dewe­lo­pe­ra, bo tyl­ko on się nim posłu­gu­je. Po dru­gie imple­men­ta­cja (kodo­wa­nie) jest naj­kosz­tow­niej­szym eta­pem pro­jek­tu, więc nale­ży mini­ma­li­zo­wać zaan­ga­żo­wa­nie dewe­lo­pe­ra na rzecz eta­pu ana­li­zy i projektowania.

Jak to wygląda w notacji UML

W nota­cji UML mamy dwa poję­cia powią­za­ne z dia­gra­mem aktyw­no­ści: aktyw­ność (Activities) i zadanie/działanie/krok/akcja (Actions).

Aktywność:

Aktywności mogą opi­sy­wać obli­cze­nia pro­ce­du­ral­ne, two­rząc hie­rar­chie dzia­łań wywo­łu­ją­cych inne dzia­ła­nia lub, w mode­lu obiek­to­wym, mogą być wywo­ły­wa­ne pośred­nio jako meto­dy zwią­za­ne z ope­ra­cja­mi, któ­re są wywo­ły­wa­ne bezpośrednio. 

Zadanie:

Zadanie jest pod­sta­wo­wą jed­nost­ką spe­cy­fi­ka­cji zacho­wa­nia w UML. Zadanie może przyj­mo­wać zestaw danych na wej­ściu i pro­du­ko­wać zestaw danych na wyj­ściu. Niektóre zada­nia mogą mody­fi­ko­wać stan sys­te­mu, w któ­rym są wyko­ny­wa­ne. Zadania są zawar­te w zacho­wa­niach, a kon­kret­nie w aktyw­no­ściach (jako węzły wyko­ny­wal­ne) i interakcjach.

Powyższe moż­na zobra­zo­wać jak na poniż­szym diagramie. 

Diagramy jak powyż­szy raczej rzad­ko powsta­ją, jest to jed­nak popraw­ny dia­gram, na któ­rym uży­to aktyw­no­ści i zadań. Najczęściej sche­ma­ty te są bar­dziej zło­żo­ne i wte­dy na jed­nym dia­gra­mie – głów­nym – poka­zuj­my szkie­let algo­ryt­mu, a pro­ce­du­ry doku­men­tu­je­my na osob­nych pod­le­głych (sko­ja­rzo­nych) dia­gra­mach. Powyższe więc sta­no­wi­ło by kil­ka osob­nych, hie­rar­chicz­nie zor­ga­ni­zo­wa­nych, dia­gra­mów, gdzie na szczy­cie hie­rar­chii był­by szkie­let jak poniżej:

Notacja UML daje nam narzę­dzie dekom­po­no­wa­nia mode­li algo­ryt­mów na dwa pozio­my: poziom aktyw­no­ści i poziom zadań (czyn­no­ści):

Algorytmy jako element opisu technicznego

Autor książ­ki: Rzecz o isto­cie infor­ma­ty­ki. Algorytmika. opi­su­je meto­dy two­rze­nia i doku­men­to­wa­nia algo­ryt­mów . Polecam te książ­kę z uwa­gi na jej walo­ry i edu­ka­cyj­ne i praktyczne. 

Bardzo czę­sto klu­czo­wym ele­men­tem opi­su sys­te­mu jest mecha­nizm jego dzia­ła­nia, a nie jedy­nie jego archi­tek­tu­ra. Modele na pozio­mie archi­tek­tu­ry HLD i LLD (patrz arty­kuł o mode­lo­wa­niu archi­tek­tu­ry) sku­pia­ją sie na sce­na­riu­szach współ­dzia­ła­nia kom­po­nen­tów sys­te­mu. Jeżeli dany sys­tem jest przede wszyst­kim sys­te­mem zarzą­dza­ją­cym dany­mi (infor­ma­cją) to poziom archi­tek­tu­ry i logi­ka jej dzia­ła­nia wystar­cza do udo­ku­men­to­wa­nia mecha­ni­zmu dzia­ła­nia tego systemu.

Jednak część sys­te­mów, mniej lub bar­dziej inten­syw­nie, prze­twa­rza dane. Pod poję­ciem prze­twa­rza­nia danych rozu­mie­my ich prze­kształ­ce­nie, inny­mi sło­wy w toku prze­kształ­ce­nia powsta­ją nowe lub zmie­nio­ne dane. Np. dzia­ła­nie 2+2=4 two­rzy nowe dane (cyfra 4) na pod­sta­wie danych ist­nie­ją­cy (dwie cyfry 2). Działanie 3/2=1,5 two­rzy dane (jeże­li wynik zosta­nie zapi­sa­ny jako nowa cyfra) lub prze­kształ­ca (jeże­li war­tość 1,5 zastą­pi war­tość 3). 

Poniższy dia­gram to przy­kład z ww. książki:

Diagram ten to czę­sto spo­ty­ka­na for­ma pre­zen­ta­cji algo­ryt­mów. Wadą tego dia­gra­my jest nie­jed­no­znacz­ność sym­bo­li: jeden romb ​„porów­naj…” repre­zen­tu­je czyn­ność, a dru­gi ​„czy.…” speł­nie­nie okre­ślo­ne­go warun­ku. Problem w tym, że albo uzna­my, że bada­nie tego warun­ku to czyn­ność, albo że odpo­wiedź na zada­ne pyta­nie jest stwier­dze­niem fak­tu, a bada­nia doko­na­no wcze­śniej. Podobnie jak ​„spraw­dzam czy ktoś jest w domu” vs. „(stwier­dzo­no, że) niko­go nie ma w domu”. Wbrew pozo­rom to nie jest to samo bo stwier­dze­nie fak­tu nie jest pra­cą (czyn­no­ścią) a czyn­ność, i repre­zen­tu­ją­cy ją sym­bol, JEST pracą. 

Diagram aktyw­no­ści UML rygo­ry­stycz­nie oddzie­la seman­ty­kę (zna­cze­nia, repre­zen­ta­cję) aktyw­no­ści, danych i stwier­dze­nia fak­tu, jakim jest speł­nie­nie okre­ślo­ne­go warun­ku. Powyższy algo­rytm wyko­na­ny w nota­cji UML:

Podsumowanie

Opis Techniczny Oprogramowania, jako doku­men­ta­cja mecha­ni­zmu jego dzia­ła­nia, wyma­ga pre­cy­zji gdyż sta­no­wi doku­men­ta­cję know-how (może też być ele­men­tem doku­men­ta­cji paten­tu). Dokumentacja taka nie może być kodem źró­dło­wym okre­ślo­ne­go (jed­ne­go z wie­lu na ryn­ku) języ­ków pro­gra­mo­wa­nia, gdyż musi być ​„suchym” opi­sem mecha­ni­zmu dzia­ła­nia, a nie przy­kła­dem jed­nej z wie­lu moż­li­wych imple­men­ta­cji. Zwraca na to uwa­gą tak­że autor ww. książ­ki. Dlatego doku­men­ta­cja sys­te­mu, to nie jest jego przy­kła­do­wa imple­men­ta­cja („dzia­ła­ją­cy kod”), to jest isto­ta jego dzia­ła­nia wyra­żo­na jako abs­trak­cyj­ny model. 

Źródła

.