🚀 go-pugleaf

On Mon, 15 Mar 1999 14:09:51 +0100, "Rafal Smotrzyk" <rav@smo3k.z.pl>
wrote:

>
>Andrzej Lewandowski wrote in message
><36ec314f.8464691@news-s01.ny.us.ibm.net>...
>
>>Zaraz, zaraz... "sieci funkcjonalne" - czy to samo co grafy funkcyjne?
>>Jezeli nie, to prosze o informacje.
>
>Sieci funkcjonalne to jak juz mowilem pochodna sieci Petri. O ile sieci
>Petri
>definiuja sposoby opisow procesow to sieci funkcjonalne definiuja sposoby
>opisow procesow ale w sposob bardziej strawny, praktyczny, intuicyjny. :-)
>Zajmuje sie nimi np. prof Godbersen z Berlina
>(http://www.tfh-berlin.de/~godberse/)

Zajrzalem tamze. Wyglada ze sieci funkcjonalne sa bardzo podobne o ile
nie tozsame z grafami funkcyjnymi. Grafy funkcyjne zostaly wymyslone
jakies 15 lat temu przez ludzi ze Slaska (lub AHG). Byla seria
artykulow w czasopismie Podstawy Sterowania o ile sobie przypominam.
Grafy funkcyjne zostaly wymyslone do opisu i symulacji ukladow
dynamicznych z czasem ciaglym a potem uogolnione na czas dyskretny i
"utokenizowane".  Niestety, nie pamietam nazwiska autorow - w koncu to
bylo jakis kawalek czasu temu, a nie mam tych czasopism pod reka.

>
>tokenow pozwala na definiowanie systemow dynamicznych (czyli bardziej
>rzeczywistych)
>od jakiejkolwiek statycznej notacji np. UML. Jesli mowimy, ze sieci opisuja
>przeplywy,
>to te przeplywy sa wlasnie przeplywami tokenow.

Tu sie zgadzam...

>Ot, taki blizszy przyklad: ktos tutaj ostatnio pisal o sieciach gazowych i

Ja pisalem.

>braku mozliwosci
>prostego zdefiniowania tych sieci (gazowych) w postaci klas. 

Nieporozumienie - ja nie pisalem o niemozliwosci zdefiniowania sieci
gazowych przy pomocy klas. ja pisalem o tym ze model obiektowy sieci
gazowej jest dosyc ubogi i jego definicja UMLowa zmiesci sie na
polowie strony. Pisalem tez ze do pelnego przedstawienia systemu
potrzebny jest opis dynamiki i rozplywu gazu w wezlach, a do tego
niezbedne jest narzedzie "wykraczajace poza UML".

> No tak, w
>porzadku, tylko
>modelowanie rzeczywistosci nie powinno polegac na jej prostym kopiowaniu -
>nie chcemy
>modelowac przeciez zaworow, rur etc. tylko przeplyw gazu, tak wiec elementem
>aktywnym
>w tym modelu nie jest zawor tylko strumien gazu i to wlasnie on powinien byc
>zdefiniowany
>jako klasa. W tym momencie dochodzimy do wniosku, ze notacja statyczna nic
>nam tu nie
>da bo tutaj mozemy zdefiniowac tylko strukture a my chcemy opisac przeplyw.

I tu tez sie zgadzam. Przeplyw gazu w rurociagu opisuje sie rownaniem
rozniczkowym czastkowym (a wlasciwie dwoma rownaniami). Rzeczywiscie,
przy modelowniu obiektowym trzeba we wlasciwy sposob zdefiniowac
obiekty, i oczywiscie rurociag jest obiektem, ale nie dostatecznie
bogatym aby opisac przeplyw gazu. Generalnie, obiektami musza byc
zmienne stanu (tak jak sie je definiuje w teorii ukladow dynamicznych,
patrz Zadeh i Desoer). Rurociag jako obiekt zawiera kolekcje obiektow
zwanych "zmienna stanu". Na ten temat obiektowego modelowania ukladow
dynamicznych mozna znalezc informacje pod nastepujacym adresem:

http://www.roguewave.com/products/resources/exchange/oonski1.html

Niestety, nie mam innych papierow w wersji on-line.

>W sieciach
>funkcjonalnych strumien gazu moze byc opisany tokenem, ktory przeplywa w
>sieci - w takim
>przypadku znowu mozemy opisac strukture rur i zaworow jako siec ale mozemy
>takze opisac zawory i rury takze jako tokeny a spotkanie tych dwoch rodzajow
>tokenow
>bedzie nam dawalo konkretne zdarzenia w rzeczywistosci np. otwarcie zaworu.

Niestety nie da sie przeplywu gazu opisac tokenami.

Zreszta, zauwazyc nalezy ze do opisu ukladow dynamicznych istnieje
specjalna notacja od lat uzywana przez inzynierow automatykow (patrz
prace o grafach funkcyjnych). Byla ona wymyslona na wiele lat przed
pokazaniem sie UMLu. Ciekawe byloby sprobowanie polaczenia obu
notacji. Kolego Subieta, moze "zapuscic" jakiegos entuzjaste na ten
problem?...

A.L.