On Thursday, March 25, 2021 at 11:41:12 AM UTC-4, Maciej Sobczak wrote:
> > Diagram mniej więcej tak wyglądał:
https://github.com/panicz/writings/blob/master/archi
ve/events-commands.png
> Na moje oko to jest deployment diagram. Tzn. nie ma na tym diagramie nic, czego nie
dałoby się pokazać na standardowym dep-diag ("schemat wdrożenia"?), modulo oczywiście
notacja.
>
> https://en.wikipedia.org/wiki/Deployment_diagram
> --
> Maciej Sobczak * http://www.inspirel.com

Tutaj wiecej podobnych przykladow
https://galaxy.hua.gr/~mara/publications/caine05.pdf
https://www.visual-paradigm.com/guide/uml-unified-mo
deling-language/what-is-deployment-diagram/
Ten pierwszy troche stary

A tutaj ciekawostka - nie na temat ale interesujace (diagramy w Pythonie) - z mojego
punktu widzenia ma jedna dobra strone - latwe sledzenie zmian przez diff ;-)
https://shekhargulati.com/2020/04/21/software-archit
ecture-diagrams-as-code/

do góry

> > https://en.wikipedia.org/wiki/Deployment_diagram
> Może czegoś nie rozumiem, ale z tego co rozumiem, deployment diagram wymienia
jedynie komponenty wymagane do wdrożenia i ewentualnie zależności między nimi.

A Twój diagram pokazał coś innego?

> U mnie są wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem.

No właśnie to wszystko ma swoje miejsce w dep-diag. Z powyższej strony:

"what hardware components ("nodes") exist (e.g., a web server, an application server,
and a database server), what software components ("artifacts") run on each node
(e.g., web application, database), and how the different pieces are connected (e.g.
JDBC, REST, RMI)."

Nawet protokoły komunikacyjne można wskazać.

> Być może wszystko "da się pokazać" na UMLowym diagramie, ale wydaje mi się, że w
pewnej mierze wynika to z tego, że zawsze można np. dorzucić komentarz.

Nie. Raczej z tego, że sam metamodel UML jest dość swobodny i można nawet tworzyć
własne typy połączeń między elementami diagramu.

> Ja sobie myślę o schematach które by miały bardziej sformalizowaną czy
zoperacjonalizowaną semantykę.

Ale nie da się mówić o sformalizowanej semantyce, jeśli diagram miałby być tylko
obrazkiem. Formalizm widać dopiero w tym, jak ten obrazek jest dalej przetwarzany, a
to zależy tylko od Ciebie. Napisz sobie skrypt przetwarzający diagram (generator
kodu?), który robić coś konkretnego z połączeniami jakiegoś typu w diagramie i to
będzie ten formalizm. UML jest frameworkiem do tworzenia takich procesów projektowych
a nie kompletnym i zamkniętym rozwiązaniem.

Tu jest to ładnie wyjaśnione:

https://www.visual-paradigm.com/guide/uml-unified-mo
deling-language/uml-extexsibility-mechanism/

Chyba to co chcesz zrobić najłatwiej osiągnąć tzw. stereotypami. To nie są
komentarze, tylko własne "typy" istniejących bytów, np. połączeń. Możesz mieć np.
strzałkę między modułami w dep-diag z wymyślonym stereotypem "<<serial comms>>" i ta
strzałka będzie (dla konsumenta diagramu, czy to człowiek, czy generator kodu)
oznaczać komunikację łączem szeregowym. Itd. Wątek? Proszę bardzo: "<<active>>". Bo
to nawet jest luźniejsze pojęcie, niż "<<thread>>", który wskazuje na istnienie OS a
przecież w systemie wbudowanym nie musi go być.
W ten sposób można przerysować cały Twój diagram, z zachowaniem wszystkich
informacji.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> OK, w takim razie zmieniam tytuł wątku na "narzędzia do wizualizacji systemów
rozproszonych" :)
>
> Zna ktoś jakieś ciekawe?

Deployment diagram? :-D

> > To tylko przepychasz problem w inne miejsce. Diagramy też mają dokumentację w
postaci adnotacji, czy innych wlepek tekstowych. Albo w postaci dokumentu Word o
nazwie "Dokumentacja do diagramu 123.xyz.beta.docx". I to też może się rozjechać z
rzeczywistością.
> No, chyba że tego nie stworzysz. To wtedy tego nie ma, i nie może się rozjechać.

Ale do tego nie potrzeba diagramów. Jest cała masa kodu źródłowego, którego
dokumentacja nigdy się nie rozjeżdża, bo jej nie ma. Przepchnięcie problemu braku
dokumentacji na inny poziom abstrakcji (albo do innej notacji na tym samym poziomie
abstrakcji, bo to też się zdarza ludziom robić, patrz np. wyrażenie logiczne vs.
schemat bramek logicznych - to jest ten sam ciul, chociaż mają różną wartość szpanu)
tego problemu wcale nie rozwiązuje.

> > Jeżeli diagram służy do generowania kodu, to *nie* jest dokumentacją, tak samo
jak kod źródłowy (który też służy do generowania czegoś) nie był dokumentacją.
> Dlaczego nie?

https://en.wikipedia.org/wiki/Documentation

--
Maciej Sobczak * http://www.inspirel.com

do góry

> A tutaj ciekawostka - nie na temat ale interesujace (diagramy w Pythonie) - z
mojego punktu widzenia ma jedna dobra strone - latwe sledzenie zmian przez diff ;-)
> https://shekhargulati.com/2020/04/21/software-archit
ecture-diagrams-as-code/

Śledzenie zmian w diff to bardzo poważna zaleta, bo typowe narzędzia na tej części
się spektakularnie wykładają. Co jest o tyle absurdalne, że motywacje do używania
diagramów pojawiają się w projektach powyżej jakiegoś poziomu złożoności, gdzie
dokładnie z tego samego powodu pojawiają się też potrzeby śledzenia historii zmian,
czy w ogóle pracy zespołowej na wielu wersjach, itd. Czyli schemat działania jest
taki:
- robimy duży projekt, więc zatrudniamy tabun ludzi
- mamy Git, Jenkins i co tam jeszcze, pierdylion branchów i pierdyliard wersji w
każdym branchu
- merge'ujemy branche we wszystkich kierunkach
- jesteśmy już tak poważni, że kupujemy program do robienia diagramów...
- i dupa.

Diagram generowany kodem to dobry pomysł również z tego powodu, że można zrobić
meta-modelowanie, czyli np. zrobić coś w pętli zamiast copy-paste (np. dużo podobnych
bloczków).

Ale Python to i tak słaby wybór do takiej roboty. Lepszy byłby język o swobodniejszej
składni, np. Wolfram albo od biedy Scheme. Tam można robić cuda bez ograniczeń ze
strony istniejących reguł a tych w Pythonie jest zdecydowanie za dużo do takich
zastosowań.

--
Maciej Sobcza * http://www.inspirel.com

do góry

piątek, 26 marca 2021 o 17:16:29 UTC+1 Maciej Sobczak napisał(a):
> > > https://en.wikipedia.org/wiki/Deployment_diagram
> > Może czegoś nie rozumiem, ale z tego co rozumiem, deployment diagram wymienia
jedynie komponenty wymagane do wdrożenia i ewentualnie zależności między nimi.
> A Twój diagram pokazał coś innego?

Tak, wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem

> > U mnie są wątki, struktury, urządzenia i relacje korespondencji między strukturą
a rzeczywistym bytem.
> No właśnie to wszystko ma swoje miejsce w dep-diag. Z powyższej strony:
>
> "what hardware components ("nodes") exist (e.g., a web server, an application
server, and a database server), what software components ("artifacts") run on each
node (e.g., web application, database), and how the different pieces are connected
(e.g. JDBC, REST, RMI)."
>
> Nawet protokoły komunikacyjne można wskazać.

a wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem?

do góry

piątek, 26 marca 2021 o 17:26:17 UTC+1 Maciej Sobczak napisał(a):

> > > Jeżeli diagram służy do generowania kodu, to *nie* jest dokumentacją, tak samo
jak kod źródłowy (który też służy do generowania czegoś) nie był dokumentacją.
> > Dlaczego nie?
> https://en.wikipedia.org/wiki/Documentation

To nie jest uzasadnienie. To jest link do Wikipedii.

Pierwsze zdanie artykułu mówi:

"Documentation is any communicable material that is used to describe, explain or
instruct regarding some attributes of an object, system or procedure, such as its
parts, assembly, installation, maintenance and use"

Kod źródłowy jest komunikowalny i może być użyty do wyjaśnienia pewnych atrybutów
systemu, więc nadal nie rozumiem.

do góry

On Friday, March 26, 2021 at 12:41:03 PM UTC-4, Maciej Sobczak wrote:
> > A tutaj ciekawostka - nie na temat ale interesujace (diagramy w Pythonie) - z
mojego punktu widzenia ma jedna dobra strone - latwe sledzenie zmian przez diff ;-)
> > https://shekhargulati.com/2020/04/21/software-archit
ecture-diagrams-as-code/
> Śledzenie zmian w diff to bardzo poważna zaleta, bo typowe narzędzia na tej części
się spektakularnie wykładają. Co jest o tyle absurdalne, że motywacje do używania
diagramów pojawiają się w projektach powyżej jakiegoś poziomu złożoności, gdzie
dokładnie z tego samego powodu pojawiają się też potrzeby śledzenia historii zmian,
czy w ogóle pracy zespołowej na wielu wersjach, itd. Czyli schemat działania jest
taki:
> - robimy duży projekt, więc zatrudniamy tabun ludzi
> - mamy Git, Jenkins i co tam jeszcze, pierdylion branchów i pierdyliard wersji w
każdym branchu
> - merge'ujemy branche we wszystkich kierunkach
> - jesteśmy już tak poważni, że kupujemy program do robienia diagramów...
> - i dupa.

Zgadzam sie z kolega w 100% - najlepszy przyklad z brzegu merge Simulink models -
trzeba uzywac ich narzedzia bo normalny diff nic nie potrafi zrobic - a narzedzie od
MATLAB/Simulink "sucks"

>
> Diagram generowany kodem to dobry pomysł również z tego powodu, że można zrobić
meta-modelowanie, czyli np. zrobić coś w pętli zamiast copy-paste (np. dużo podobnych
bloczków).
>
> Ale Python to i tak słaby wybór do takiej roboty. Lepszy byłby język o
swobodniejszej składni, np. Wolfram albo od biedy Scheme. Tam można robić cuda bez
ograniczeń ze strony istniejących reguł a tych w Pythonie jest zdecydowanie za dużo
do takich zastosowań.

Na bezrybiu i rak ryba ;-)

>
> --
> Maciej Sobcza * http://www.inspirel.com

do góry

W dniu 26.03.2021 o 17:41, Maciej Sobczak pisze:
>> A tutaj ciekawostka - nie na temat ale interesujace (diagramy w Pythonie) - z
mojego punktu widzenia ma jedna dobra strone - latwe sledzenie zmian przez diff ;-)
>> https://shekhargulati.com/2020/04/21/software-archit
ecture-diagrams-as-code/
>
> Śledzenie zmian w diff to bardzo poważna zaleta, bo typowe narzędzia na tej części
się spektakularnie wykładają. Co jest o tyle absurdalne, że motywacje do używania
diagramów pojawiają się w projektach powyżej jakiegoś poziomu złożoności, gdzie
dokładnie z tego samego powodu pojawiają się też potrzeby śledzenia historii zmian,
czy w ogóle pracy zespołowej na wielu wersjach, itd. Czyli schemat działania jest
taki:
> - robimy duży projekt, więc zatrudniamy tabun ludzi
> - mamy Git, Jenkins i co tam jeszcze, pierdylion branchów i pierdyliard wersji w
każdym branchu
> - merge'ujemy branche we wszystkich kierunkach
> - jesteśmy już tak poważni, że kupujemy program do robienia diagramów...
> - i dupa.
>
> Diagram generowany kodem to dobry pomysł również z tego powodu, że można zrobić
meta-modelowanie, czyli np. zrobić coś w pętli zamiast copy-paste (np. dużo podobnych
bloczków).
>
> Ale Python to i tak słaby wybór do takiej roboty. Lepszy byłby język o
swobodniejszej składni, np. Wolfram albo od biedy Scheme. Tam można robić cuda bez
ograniczeń ze strony istniejących reguł a tych w Pythonie jest zdecydowanie za dużo
do takich zastosowań.

Może to:

https://plantuml.com/

--
pzdr
Roman

do góry

> > A Twój diagram pokazał coś innego?
> Tak, wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem

To wszystko to są właśnie decyzje wdrożeniowe, które można pokazać na deployment
diagram.

> > "what hardware components ("nodes") exist (e.g., a web server, an application
server, and a database server), what software components ("artifacts") run on each
node (e.g., web application, database), and how the different pieces are connected
(e.g. JDBC, REST, RMI)."
> >
> > Nawet protokoły komunikacyjne można wskazać.
> a wątki, struktury, urządzenia i relacje korespondencji między strukturą a
rzeczywistym bytem?

A czego nie zrozumiałeś z dotychczasowej wymiany na ten temat?
Mam Ci narysować Twój własny diagram?

--
Maciej Sobczak * http://www.inspirel.com

do góry

> Może to:
>
> https://plantuml.com/

Super. To jest właśnie prosta składnia, niezaśmiecona regułami istniejącego języka
(jak Python), który powstał zupełnie w innym celu.
Podoba mi się strzałka jako infix operator, tak to właśnie powinno wyglądać. A -> B i
wiadomo o co chodzi.

Skoro już rzucamy przykładami, to jakiś czas temu udało mi się popełnić takie
narzędzie, chociaż notacje UMLopodobne nie były priorytetem. Chodziło bardziej o
programowalny layout, czyli ustalenie, jakie są względne relacje "geograficzne"
między elementami dowolnego diagramu:

http://inspirel.com/prodiams/

Cele te same, ale z założenia integruje się ze środowiskiem Wolframa, więc jest
naturalnie programowalne.

--
Maciej Sobczak * http://www.inspirel.com

do góry