🚀 go-pugleaf

Date sent:      	Sun, 14 Mar 1999 15:53:53 +0100
Send reply to:  	objects@sprocket.ict.pwr.wroc.pl
From:           	Artur Kasprzyk <potis@wr.onet.pl>
To:             	Multiple recipients of list <objects@sprocket.ict.pwr.wroc.pl>
Subject:        	ODP: UML czyli 'Unified Modeling Language'

> 
> Z tego co zrozumialem z opisu (chociaz, nie sadze abym problem calkiem zrozumial)
> mozna:
> [1] do opisu niezaleznych agentow wykorzystac konstrukcje UML nazywana
>       Active Object. Ona wlasnie sluzy do tego, by pokazac na diagramie
>       wielowatkowosc/wspolbieznosc. Inicjowanie tych obiektow mozna
>       pokazac zarówno na Collaboration Diagram jak i Sequence Diagram
>      (na tym drugim bedzie to ladniej widac).
> [2] warunki synchronizacji dostepu do wspolnych elementow nalezaloby 
>       jednak zdefiniowac na STD's (zarówno dla "wykonawców" jak i owego
>      kontrolera nazywanego "distributed barrier"). 
> [3] Sposób obslugi zadan naplywajacych do obiektow mozna okreslac stosujac
>        odpowiednie stereotypy dla operacji: sequential, quarded, concurrent (pisze
>        z pamieci, wiec moge sie mylic).

Mozna, ale dostaje sie opis docyc powierzchowny i trzeba 
podeprzec sie czyms dodatkowym aby bylo wiadomo o co chodzi. 
"Distributed barrier" to taki algorytm ktory umozliwia niezaleznym 
agentom wspolne dojscie do wniosku ze pewna praca zostala 
zakonczona. Jezeli tak sie stalo, to moga miedzy soba wymienic 
wyniki tej pracy i kontynuowac dalej. 

UML ma dosyc ubogie mechanizmy do opisu synchronizacji, i 
opisanie czegos takiego jak powyzej w "czystym" UMLu nie 
pojdzie. Trzeba bowiem opisac nie relacje miedzy obiektami, a ich 
KOLEKTYWNE ZACHOWANIE. Do tego, poki co, porzebny jest 
jakis formalizm podobny do OCL.

Inny przyklad: od lat zajmuje sie problemem symulacji i sterowania 
sieci gazowniczych. Oczywiscie, problem jak najbardziej 
obiektowy i UML az sie prosi. Tyle tylko ze caly projekt zmiesci 
sie na polowce strony: klasa Rurociag z 4 podklasami, klasa 
Wezel z kilkoma podklasami (w wezle moze byc zawor, 
kompresor, odbiorca i zrodlo). No i juz. Relacje miedzy obiektami 
sa wiecej niz trywialne. Odcinek gazociagu dolaczony jest do 
dwoch wezlow, a kazdy wezel ma dolaczony co najmniej jeden 
odcinek rurociagu (moze byc wiecej). To co nie jest trywialne to 
algorytm obliczania rozplywu gazu w wezlach, a tego w zaden 
sposob w UMLu opisac sie nie da. Potzrebny jest jakis formalizm. 
Po mojemu jest to kolejny przypadek gdy UML nie tyle ze sie nie 
daje zastosowac, co niewiele z tego zastosowania wynika.

Ogolnie rzecz biorac, wydaje sie ze sa dwa rodzaje problemow: 
tych gdy ilosc klas jest niewielka, ale maja bardzo skomplikowane 
zachowanie, oraz takie gdzie ilosc klas jest bardzo duza, a 
zachowanie stosunkowo proste. Problemy "biznesowe" wszelkiego 
rozaju to wlasnie kategoria druga. Istotne jest w nich jak obiekty ze 
soba wspolpracuja a wspolpraca moze byc bardzo skomplikowana. 
Dla tych problemow UML jest idealny.

W systemach pierwszego rodzaju wspolpraca miedzy obiektami 
jest statyczna (lub prawie statyczna): struktura sieci gazowej jest 
taka jaka jest  i nie zmienia sie zbyt czesto. Istotny jest skladnik 
algorytmiczny. Wszelkie problemy numeryczne, obliczeniowe, 
optymalizacyjne itd. naleza do tej kategorii. Jak rowniez moj 
system rozproszony ktory nie jest systemem tranzakcyjnym, a 
systemem modelujacym i optymalizujacym pewne sytuacje.

Biorac pod uwage przeszlosc zawodowa "trzej amigos" jasne jest 
ze ciaza oni ku systemom 2 rodzaju i ich notacje oraz metodologie 
sa zorientowane na wspomaganie takich wlasnie systemow.

A.L.