🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

>> UML jest
>> wystarczająco bogaty (i rozszerzalny, chociażby przez stereotypy), żeby
>> pokryć całkiem spory kawałek procesu produkcyjnego.
> 
> Hmm... Jakoś nie dotarłem do tak obszernego kursu UML, czy coś
> polecasz?

No nie wiem. Cokolwiek - chociaż i tak ostatecznym ograniczeniem będą 
możliwości danego programu rysunkowego. Większość z nich jest raczej 
sztywna w tym temacie.

> Kłopot polega na tym jak np. zaznaczyć, żeby genrator stworzył
> pewną ilość
> specjalizacji szablonu w C++.

Dobre pytanie. W ogólym podejściu rozwiązaniem może być komentarz 
przyczepiony do szablonu, w formacie rozpoznawanym przez generator 
(zakładam, że taki komentarz i jego relacja z szablonem będą zaznaczone 
w XMI - jeśli nie, to jest problem).

W wersji najbardziej wypasionej program rysunkowy mógłby umożliwiać 
rozszerzenie metamodelu UML - wtedy mogłbyś dodać sobie nowe elementy do 
składni UML a z drugiej strony nauczyć generator ich obsługi.
Ale nie słyszałem o takich cudach.
(Oczywiście, nie mam na myśli samodzielnego hackowania open-source'owego 
programu UML, tylko rozszerzalność metamodelu przewidzianą przez 
projektantów tego programu. :-) )

> A druga sprawa. jak ładnie można pokazać np.: Javowe
> 
> class Foo < ? extends Bar >
> {}
> 
> To jest relatywnie silny kontrakt. I zapis ten dość mocno wpływa na
> wygląd klasy
> Foo i łączy ją z wyglądem klasy Bar, jaki on by nie był.
> Oczywiście z punktu widzenia
> konwersji UML -> Kod moge poprostu w << >> wpisać << ? extends Bar >>
> i powinien
> mi kod powstać dobry, bo generator powinien po prostu przepisać to co
> jest w << >>. Ale na rysunku jakby coś ginie. Poza wpiszem w << >> nie
> jest odnotowana żadna relacja.

Można to << >> przykleić nie do klasy Foo, ale do relacji pomiędzy Foo i 
Bar. Wtedy będzie widać, że jest to cecha relacji a nie cecha jednej klasy.

> Już nie mówię o C++ konstrukcjach typu:
> 
> // -- if construct ------------------------------------------------
> // Proposed by Krzysztof Czarnecki and Ulrich Eisenecker
> 
> template <bool If, class Then, class Else> struct IF { typedef Then
> RET; };
> 
> template <class Then, class Else> struct IF<false, Then, Else> {
>   typedef Else RET;
> 
> };
> 
> Takie kwiatki w kodzie bardzo wiele potrafią zrobić.

A ja bym tego nie modelował w UML tylko raczej potraktował jako element 
języka. Obecność czegoś takiego na diagramie kompletnie niczego nie 
wnosi, bo ostatecznie struct IF jest tylko narzędziem do wyrażania 
relacji pomiędzy tymi typami, które są właściwą domeną dla 
analityka/projektanta. Dlatego posłużyłbym się raczej pojęciem IF w 
stereotypach albo innych dekoracjach w relacjach pomiędzy tymi 
właściwymi typami, zakładając, że IF jest już częścią języka 
programowania (dotyczy to wszystkich konstrukcji typu MPL).
Odpowiedni generator potrafiłby taką iluzję stworzyć.

> Tak więc jeśli możesz wskazać na
> jakieś opracowania
> w których podjęte jest wyzwanie narysowania takich konstrukcji jak
> "boost::" to chętnie
> poczytam.

Nie znam żadnych takich opracowań. :-)


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/