> Bardziej myślę w drugą stronę: czy systemy embedded nie są o tyle specyficzne, że
dałoby się dla nich względnie łatwo stworzyć takie narzędzia.

Nie, bo jeśli patrzysz na te systemy jako na komunikujące się samodzielne węzły, to
jest to normalny system rozproszony. To, że akurat mieści się w jednym pudełku a nie
w serwerowni, nic nie zmienia. Moduł A komunikuje się z modułem B przy użyciu
protokołu X. To działa w każdej skali.

> Tutaj bardziej mi chodzi o coś w rodzaju przepływu informacji/zdarzeń.

OK. Ale to też nie jest problem specyficzny dla embedów.
Jeżeli dla embedów miałoby coś być specyficznego, to raczej współzależności fizyczne,
np. fakt posiadania jednego zasilacza, albo niezamierzone "protokoły komunikacyjne"
jak interferencja elektromagnetyczna, albo np. zbieg okoliczności polegający na
jednoczesnym przegrzaniu się. Ale to też można wyobrazić sobie w większej skali, np.
w serwerowni.

Czyli nic specjalnego. Jeśli mowa jest o jakichkolwiek protokołach komunikacyjnych,
to masz system rozproszony.

> > Ale, ale. Dlaczego chcesz *generować* kod? Co chcesz przez to zyskać?
> Mam też taki problem z "niewykonywalną dokumentacją", że nie znam jakichś dobrych
sposobów, żeby ją przetestować, i że może się łatwo zdesynchronizować z
rzeczywistością.

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ą.

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ą.

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