🚀 go-pugleaf

------ =_NextPart_000_01BE6F1D.3D41A6C0
Content-Type: text/plain; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable

Spedzilem dzisiaj pol dnia na studiowaniu Frolunda. Kilka przemyslen:

[1] Z punktu widzenia samej notacji w UML mozna pokazac to,
      co pokazuje Frolund w zaprezentowanym j=EAzyku. Kilka pierwszych
      fakt=F3w ponizej.

[2]=20
    Obiekty synchronizowane mozna pokazac na diagramie klas
    (dokladniej w punkcie 4). Natomiast idealnym miesjcem do=20
    pokazania zachowania obiektu z ograniczeniami sa STD's.=20
   Kazde zdarzenie "that matches a pattern"
    bedzie poprzedzone Guard Condition (warynek po slowie kluczowym IF).
   Czyli bedzie mozna  pokazac "dynamike" owych ograniczen,=20
   opisanych na modelu klas.

[3] Mozliwe rozszerzenia, opisywane w rozdziale 2.5 mozna
      uzyskac wprowadzajac dodatkowe Tagged Values oraz/lub Properties.

[4] Wydaje mi sie, iz u Frolunda, pewnym odpowiednikiem "destributed =
barier"
    jest pojecie "Synchronizer". Synchronizer obserwuje (troche, w =
sensie
    wzorca projektowego Observer) obiekty przez niego kontrolowane,
    nie wysylajac ani nie odbierajac jednak zadnych zdarzen, wiec jego =
STD
    bedzie mialo przejscia wyzwalane zdarzeniami warunkowymi
    (Conditional Event z UML). Dzieki temu, smialo bedzie mogl sie
    odwolywac do interfejsu obserwowanych klas i sterowac ich
    zachowaniem (wlaczajac w to wspomniane przez Pana sterowanie
    Agentami, w przypadku awarii).
    Z punktu widzenia diagramu klas, klasy pelniace role =
Synchronizer=F3w
    powinny byc oznaczane osobnym stereotypem (byc moze ze definiowanymi
    dla tego stereotypu ograniczneiami przechodzacymi na obsadzone nim
    elementy - w metamodelu jest to wlasnosc klasy Stereotype nazwana
    StereotypeConstraint).

    Poniewaz Synchronizer definiuje sie dla obiektow (a nie klas) stad
    koniecznym jest uzycie Collaboration Diagram w celu pokazania
    "miejsca" Synchronizera w systemie.

    [4a] Pattern: mozna je reprezentowac jako osobny "compartment".
         Kazdy Pattern bedzie sie skladal ze zwiazku z Instance
         (metamodel UML) a ten z kolei ma dostep do Operation
         poprzez Classifier.
         Wiec na diagramie mozna to znaczyc jako
         <<pattern>> obiekt.operacja(params) {exp}
         czyli
         STEREOTYPE instance.operation {TaggedValue}
         co bedzie odpowiadalo konstrukcji:
         DISABLE o.method IF exp
    [4b] Podobnie mozna opisac triggery:
         <<trigger>> pattern {action}
         co odpowiaa konstrukcji
         TRIGGER pattern -> action
    [4c] i tak dalej. Nie mam na razie pomuslu na ATOMIC,=20
            ale podswiadomie (:-)) ) czuje, ze da sie to ladnie zapsiac.


Wazne jest to, ze uzywa sie do tego jedynie mechnizm=F3w UML-a (bez =
podzialu
na "standardowe" i "dodatkowe"). Wobec tego, jezeli projektowany system
bedzie sie skladal z czesci "biznesowej" i nawizjmy to ogolnie RTS, =
w=F3wczas
przy pomocy jednej notacji mozna opisac obydwa przypadki. Z reguly jest =
tak,=20
iz za OGOLNOSC placi sie SPRAWNOSCIA. Tak jest i w tym przypadku.
Pewnie sa lepsze sposoby opisu, ale przy pomocy UML tez sie da.
Ot, cos za cos.


W zalaczenie przesylam diagram klas i diagram wspolpracy, przykladowo
opisujacy
jaki sSynchronizer. Diagramy utworzylem w milym narzedziu VisualUML =
(demo
mozna znalezc
na stronach www.visualuml.com lub potis.com.pl


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

Nie wystarczy STD dla takiego "agregatu"

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

Prosze pamietac, ze OCL jest integraln aczescia UML !

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

Sluszna uwaga. Takich sytuacji/dylematow jest wiecej. Zdarzylo mi=20
sie tworzyc dwa systemy, w kt=F3rych byly 4 powazne przypadki uzycia a =
okolo
100 klas na etapie projektu. Stwierdziismy jednak, ze dzieki tym 4
przypadkom PRECYZYJNIE okreslilismy zakres systemu. I tyle.
Wiecej nie trzeba.
|=20
| Ogolnie rzecz biorac, wydaje sie ze sa dwa rodzaje problemow:=20
| tych gdy ilosc klas jest niewielka, ale maja bardzo skomplikowane=20
| zachowanie, oraz takie gdzie ilosc klas jest bardzo duza, a=20
| zachowanie stosunkowo proste. Problemy "biznesowe" wszelkiego=20
| rozaju to wlasnie kategoria druga. Istotne jest w nich jak obiekty ze=20
| soba wspolpracuja a wspolpraca moze byc bardzo skomplikowana.=20
| Dla tych problemow UML jest idealny.
|=20
| W systemach pierwszego rodzaju wspolpraca miedzy obiektami=20
| jest statyczna (lub prawie statyczna): struktura sieci gazowej jest=20
| taka jaka jest  i nie zmienia sie zbyt czesto. Istotny jest skladnik=20
| algorytmiczny. Wszelkie problemy numeryczne, obliczeniowe,=20
| optymalizacyjne itd. naleza do tej kategorii. Jak rowniez moj=20
| system rozproszony ktory nie jest systemem tranzakcyjnym, a=20
| systemem modelujacym i optymalizujacym pewne sytuacje

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

Pewnie "decydentem" jest w tym przypadku rynek. No coz, Rational
nie prowadzi dzialalnosci charytatywnej ... moze jak juz wszyscy amigos =
beda=20
mieli prywatne helikoptery, zabiora sie za systemy 1 rodzaju.
Ciekaw jestem, czy Activiy Diagram nie rozwiazywaloby czesciowo
problemu "ualgorytmizowania" modelu. Dla kazdej zlozonej operacji
tworzymy Activity Diagram (moze z jakimis elementami dociazonymi
stereotypmi), kt=F3ry pokazuje wlasnie cala zlozonosc algorytmu. =
Activity
Diagram chyba jedyni edo tego mozna sensownie wykorzystac. Obrazuje
on procesu, dane oraz zmiany kt=F3re procesy powoduja w danych.
Co Pan na to ?
.
Pozdrawiam, Artur Kasprzyk

 =20

------ =_NextPart_000_01BE6F1D.3D41A6C0
Content-Type: application/octet-stream; name="clsSynchronizer[1].Vob"
Content-Transfer-Encoding: base64

CAAGAEhlYWRlcggAFQBWaXN1YWwgVU1MIENoYXJ0IEZpbGUEAHsUjj8IAAwAY2xzVW50aXRsZWQy
CAAVAFN5bmNocm9uaXplciAoQ0QpIFsxXQgABQBDbGFzcwMABQAAgAgAAQBQAgBkAAMAAAAAAAMA
AAAAAAMAAAAAAAMAAAAAAAMAAAAAAAMAAAAAAAIAAAAIAA8ASFAgTGFzZXJKZXQgSUlJAgABAAIA
CQACAAEAAgB4AAsA//8CAAEAAgAyAAIAMgACAEsAAgBLAAMA/////wMA/////wMAVzEAAAMACQAA
AAMAgwEAAAMAX////wMAAQAAAAgADQBTeW5jaHJvbml6ZXJBCAAFAENsYXNzAwAtAAAAAwBsAAAA
AgBsAAIAvQALAAAACwAAAAgADABTeW5jaHJvbml6ZXIIAAAAAwAAAAAAAwAAAAAAAgABAAgAAAAD
ANcxAAADAD8AAAADAI8BAAALAAAACwAAAAgAAAALAAAACAAAAAsAAAALAAAACwAAAAsAAAALAAAA
CAAAAAgAAAALAAAACAAAAAgAAAAIAAAAAgAAAAsAAAAIAAAACAAAAAgAAAAIABEAU3luY2hyb25p
emVyQS5DbHMLAAAACAAAAAsAAAAIAAAACwAAAAgAAAAIAAAACAAFAEFyaWFsAgAKAAMAAAAAAAsA
AAALAAAACwAAAAgAAAAIAAAACAAAAAMAAgAAAAgAFgBTeW5jaHJvbml6ZXJBdHRyaWJ1dGUxCwAA
AAgAAAAIAAAACAAHAEJvb2xlYW4LAAAACAAAAAgAAAAIAAQAdHJ1ZQsAAAAIAAAACAAAAAsAAAAL
AAAACwAAAAsAAAALAAAACAAAAAgAAAALAAAACAAAAAsAAAAIAAAACAAAAAgAAAAIABYAU3luY2hy
b25pemVyQXR0cmlidXRlMgsAAAAIAAAACAAAAAgABwBCb29sZWFuCwAAAAgAAAAIAAAACAAFAGZh
bHNlCwAAAAgAAAAIAAAACwAAAAsAAAALAAAACwAAAAsAAAAIAAAACAAAAAsAAAAIAAAACwAAAAgA
AAAIAAAACAAAAAMABAAAAAgACABvLm1ldGhvZAsAAAALAAAACAAAAAsAAAALAAAACwAAAAgADABl
eHAsIG5hbWU9UDEIAAAACAAHAHBhdHRlcm4IAAAACAAAAAgAAAAIAAAACAAAAAMAAAAAAAgACQBv
Lm1ldGhvZDILAAAACwAAAAgAAAALAAAACwAAAAsAAAAIAA0AZXhwMiwgbmFtZT1QMggAAAAIAAcA
cGF0dGVybggAAAAIAAAACAAAAAgAAAAIAAAAAwAAAAAACAAJAG9hLm1ldGhvZAsAAAALAAAACAAA
AAsAAAALAAAACwAAAAgABwBhY3Rpb25zCAAAAAgABwB0cmlnZ2VyCAAAAAgAAAAIAAAACAAAAAgA
AAADAAAAAAAIAAYAUDEsIFAyCwAAAAsAAAAIAAAACwAAAAsAAAALAAAACAAAAAgAAAAIAAYAYXRv
bWljCAAAAAgAAAAIAAAACAAAAAgAAAADAAAAAAADAAAAAAADAAAAAAADAAAAAAADAAAAAAADAAAA
AAACAAAACAALAFRpdGxlIEJsb2NrCAAAAAMADAAAAAMADAAAAAIAIAECACQACwAAAAsAAAADAAAA
AAADAAAAAAADAAAAAAACAAEACwAAAAgABQBBcmlhbAIACgADAAAAAAALAAAACwAAAAsAAAADAAAA
AAADAAAAAAADAAAAAAA=

------ =_NextPart_000_01BE6F1D.3D41A6C0
Content-Type: application/octet-stream; name="colSynchronizer[1].Vob"
Content-Transfer-Encoding: base64

CAAGAEhlYWRlcggAFQBWaXN1YWwgVU1MIENoYXJ0IEZpbGUEAHsUjj8IABIAY29sU3luY2hyb25p
emVyWzFdCAAXAFN5bmNocm9uaXplciAoQ29sRCkgWzFdCAANAENvbGxhYm9yYXRpb24DAAUAAIAI
AAEARAIAZAADAAAAAAADAAAAAAADAAAAAAADAAAAAAADAAAAAAADAAAAAAACAAAACAAPAEhQIExh
c2VySmV0IElJSQIAAQACAAkAAgABAAIAeAALAP//AgABAAIAMgACADIAAgBLAAIASwADAP////8D
AP////8DAAMAAAAIAAwAU3luY2hyb25pemVyCAAGAE9iamVjdAMANgAAAAMAkAAAAAIAJAACAEwA
CwD//wsAAAAIAAwAU3luY2hyb25pemVyCAAAAAMAAAAAAAMAAAAAAAIAAQAIAAAACwAAAAsA//8I
AAIAU0ELAAAACAAAAAgAAAALAAAACAABAFMCAAAACAAAAAgAAAALAAAACAAAAAgABQBBcmlhbAIA
CgADAAAAAAALAAAACwAAAAsAAAAIAAAAAwAAAAAAAwAAAAAAAgAAAAIAAAAIAAAAAgAAAAMAAAAA
AAsAAAALAAAACwAAAAgAAAAIAAkAT2JzZXJ2ZWQxCAAGAE9iamVjdAMAqwAAAAMAkAAAAAIAJAAC
AEgACwD//wsAAAAIAAAACAAAAAMAAAAAAAMAAAAAAAIAAQAIAAAACwD//wsA//8IAAIAT0ELAAAA
CAAAAAgAAAALAP//CAABAE8CAAAACAAAAAgACQBUcmFuc2llbnQLAAAACAAAAAgABQBBcmlhbAIA
CgADAAAAAAALAAAACwAAAAsAAAAIAAAAAwAAAAAAAwAAAAAAAgAAAAIAAAAIAAAAAgAAAAMAAAAA
AAsAAAALAAAACwAAAAgAAAAIAAIATzIIAAYAT2JqZWN0AwA2AAAAAwDGAAAAAgA2AAIAUQALAAAA
CwAAAAgAAAAIAAAAAwAAAAAAAwAAAAAAAgABAAgAAAALAP//CwD//wgAAwBPQTILAAAACAAAAAgA
AAALAP//CAACAE8yAgAAAAgAAAAIAAkAVHJhbnNpZW50CwAAAAgAAAAIAAUAQXJpYWwCAAoAAwAA
AAAACwAAAAsAAAALAAAACAAAAAMAAAAAAAMAAAAAAAIAAAACAAAACAAAAAIAAAADAAAAAAALAAAA
CwAAAAsAAAAIAAAAAwAAAAAAAwACAAAACAAkAFN5bmNocm9uaXplcl9PYnNlcnZlZDFfSW50ZXJh
Y3Rpb24gMQgADQBJbnRlcmFjdGlvbiAxCAALAEludGVyYWN0aW9uCAAMAFN5bmNocm9uaXplcggA
BgBPYmplY3QIAAkAT2JzZXJ2ZWQxCAAGAE9iamVjdAsA//8IAAAACAAAAAMAAAAAAAMAAAAAAAIA
AQAIAAAACAAAAAgAAAAIAAAAAwAAAAAAAwAAAAAAAgAAAAIAAAAIAAUAQXJpYWwCAAoAAwAAAAAA
CwAAAAsAAAALAAAAAwACAAAAAwCCAAAAAwCiAAAAAwCrAAAAAwCiAAAAAwAAAAAACAAdAFN5bmNo
cm9uaXplcl9PMl9JbnRlcmFjdGlvbiAyCAANAEludGVyYWN0aW9uIDIIAAsASW50ZXJhY3Rpb24I
AAwAU3luY2hyb25pemVyCAAGAE9iamVjdAgAAgBPMggABgBPYmplY3QLAP//CAAAAAgAAAADAAAA
AAADAAAAAAACAAEACAAAAAgAAAAIAAAACAAAAAMAAAAAAAMAAAAAAAIAAAACAAAACAAFAEFyaWFs
AgAKAAMAAAAAAAsAAAALAAAACwAAAAMAAgAAAAMAXQAAAAMAtAAAAAMAXQAAAAMAxgAAAAMAAAAA
AAIAAAAIAAsAVGl0bGUgQmxvY2sIAAAAAwAMAAAAAwAMAAAAAgA+AQIAJAALAAAACwAAAAMAAAAA
AAMAAAAAAAMAAAAAAAIAAQALAAAACAAFAEFyaWFsAgAKAAMAAAAAAAsAAAALAAAACwAAAAMAAAAA
AAMAAAAAAAMAAAAAAA==

------ =_NextPart_000_01BE6F1D.3D41A6C0--