Wprowadzenie

W 2021 roku pisałem o stosowaniu diagramu aktywności UML w kontekście tworzenia Opisu Technicznego Oprogramowania, zwracając uwagę, że potrzebą jest to, że w toku projektowania systemu:

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

(Diagram aktywności UML – kiedy – Jarosław Żeliński IT-Consulting)

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

algorytm mat. ?ściśle określony ciąg czynności, których wykonanie prowadzi do rozwiązania jakiegoś zadania?

procedura ?w językach programowania: wydzielony fragment algorytmu?

Oba ww. pojęcia są często używane naprzemiennie. Encyklopedia PWN podaje:

algorytm: przepis postępowania prowadzący do rozwiązania ustalonego problemu, określający ciąg czynności elementarnych, które należy w tym celu wykonać.

Dlatego uporządkujemy te znaczenia. Na bazie powyższego można powiedzieć, że

algorytm to sekwencja czynności, gdzie każda czynność jest opisana określoną procedurą

Kilka słów o modelowaniu (i dokumentowaniu):

• jeżeli pracuję nad zrozumieniem logiki działania organizacji, nie ma znaczenia język programowania,
• jeżeli chce udokumentować to co odkryłem w toku analizy, nie ma znaczenia język programowania,
• jeżeli chce zaprojektować architekturę przyszłej aplikacji, nie ma znaczenia język programowania,
• jeżeli chcę opisać wymagane algorytmy, nie ma znaczenia język programowania,
• jeżeli chcę te algorytmy rozłożyć na poszczególne komponenty architektury aplikacji, nie ma znaczenia język programowania,
• jeżeli chce sprawdzić jak to zadziała i czy zadziała, nie ma znaczenia język programowania.

Co ma znaczenie? Znaczenie ma umiejętność dokumentowania wiedzy. Język programowania ma znaczenie dla dewelopera, bo tylko on się nim posługuje. Po drugie implementacja (kodowanie) jest najkosztowniejszym etapem projektu, więc należy minimalizować zaangażowanie dewelopera na rzecz etapu analizy i projektowania.

Jak to wygląda w notacji UML

W notacji UML mamy dwa pojęcia powiązane z diagramem aktywności: aktywność (Activities) i zadanie/działanie/krok/akcja (Actions).

Aktywność:

Aktywności mogą opisywać obliczenia proceduralne, tworząc hierarchie działań wywołujących inne działania lub, w modelu obiektowym, mogą być wywoływane pośrednio jako metody związane z operacjami, które są wywoływane bezpośrednio.

Zadanie:

Zadanie jest podstawową jednostką specyfikacji zachowania w UML. Zadanie może przyjmować zestaw danych na wejściu i produkować zestaw danych na wyjściu. Niektóre zadania mogą modyfikować stan systemu, w którym są wykonywane. Zadania są zawarte w zachowaniach, a konkretnie w aktywnościach (jako węzły wykonywalne) i interakcjach.

Powyższe można zobrazować jak na poniższym diagramie.

Diagramy jak powyższy raczej rzadko powstają, jest to jednak poprawny diagram, na którym użyto aktywności i zadań. Najczęściej schematy te są bardziej złożone i wtedy na jednym diagramie – głównym – pokazujmy szkielet algorytmu, a procedury dokumentujemy na osobnych podległych (skojarzonych) diagramach. Powyższe więc stanowiło by kilka osobnych, hierarchicznie zorganizowanych, diagramów, gdzie na szczycie hierarchii byłby szkielet jak poniżej:

Notacja UML daje nam narzędzie dekomponowania modeli algorytmów na dwa poziomy: poziom aktywności i poziom zadań (czynności):

Algorytmy jako element opisu technicznego

Autor książki: Rzecz o istocie informatyki. Algorytmika. opisuje metody tworzenia i dokumentowania algorytmów . Polecam te książkę z uwagi na jej walory i edukacyjne i praktyczne.

Bardzo często kluczowym elementem opisu systemu jest mechanizm jego działania, a nie jedynie jego architektura. Modele na poziomie architektury HLD i LLD (patrz artykuł o modelowaniu architektury) skupiają sie na scenariuszach współdziałania komponentów systemu. Jeżeli dany system jest przede wszystkim systemem zarządzającym danymi (informacją) to poziom architektury i logika jej działania wystarcza do udokumentowania mechanizmu działania tego systemu.

Jednak część systemów, mniej lub bardziej intensywnie, przetwarza dane. Pod pojęciem przetwarzania danych rozumiemy ich przekształcenie, innymi słowy w toku przekształcenia powstają nowe lub zmienione dane. Np. działanie 2+2=4 tworzy nowe dane (cyfra 4) na podstawie danych istniejący (dwie cyfry 2). Działanie 3/2=1,5 tworzy dane (jeżeli wynik zostanie zapisany jako nowa cyfra) lub przekształca (jeżeli wartość 1,5 zastąpi wartość 3).

Poniższy diagram to przykład z ww. książki:

Diagram ten to często spotykana forma prezentacji algorytmów. Wadą tego diagramy jest niejednoznaczność symboli: jeden romb “porównaj…” reprezentuje czynność, a drugi “czy….” spełnienie określonego warunku. Problem w tym, że albo uznamy, że badanie tego warunku to czynność, albo że odpowiedź na zadane pytanie jest stwierdzeniem faktu, a badania dokonano wcześniej. Podobnie jak “sprawdzam czy ktoś jest w domu” vs. “(stwierdzono, że) nikogo nie ma w domu”. Wbrew pozorom to nie jest to samo bo stwierdzenie faktu nie jest pracą (czynnością) a czynność, i reprezentujący ją symbol, JEST pracą.

Diagram aktywności UML rygorystycznie oddziela semantykę (znaczenia, reprezentację) aktywności, danych i stwierdzenia faktu, jakim jest spełnienie określonego warunku. Powyższy algorytm wykonany w notacji UML:

Podsumowanie

Opis Techniczny Oprogramowania, jako dokumentacja mechanizmu jego działania, wymaga precyzji gdyż stanowi dokumentację know-how (może też być elementem dokumentacji patentu). Dokumentacja taka nie może być kodem źródłowym określonego (jednego z wielu na rynku) języków programowania, gdyż musi być “suchym” opisem mechanizmu działania, a nie przykładem jednej z wielu możliwych implementacji. Zwraca na to uwagą także autor ww. książki. Dlatego dokumentacja systemu, to nie jest jego przykładowa implementacja (“działający kod”), to jest istota jego działania wyrażona jako abstrakcyjny model.

Dodatkowe opisy i przykłady: Diagramy Aktywności.

Źródła

.