GoldenLine
Zaloguj się
Damian Kamiński

Damian Kamiński Zamieniam informacje
w wiedzę ...

Temat: UML - i jego "milion" wersji ...

Mając styczność z różnymi projektami różnych firm, odnoszę wrażenie że każda specyfikacje UML’a rozumie po swojemu, prosty przykład wymagalności na relacji pomiędzy encjami , czy też oznaczeń ile-do-ile.

Jakie doświadczenia i spostrzeżenia co do „personalizowania” standardów UML ?
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: UML - i jego "milion" wersji ...

Damian K.:
Mając styczność z różnymi projektami różnych firm, odnoszę wrażenie że każda specyfikacje UML’a rozumie po swojemu, prosty przykład wymagalności na relacji pomiędzy encjami , czy też oznaczeń ile-do-ile.

Jakie doświadczenia i spostrzeżenia co do „personalizowania” standardów UML ?

Diagramy związków encji (bo chyba o nie pytasz) nie są elementem standardu UML. Po drugie jest kilka różnych notacji ERD (Entity Relationship Diagram), o którą pytasz? Specyfikacja UML jest tylko jedna (podobnie jak matka :)) http://uml.org

Potwierdzam jednak, że w różnych projektach można zobaczyć rożne "cuda" i "tfurczość" :)
Link do wypowiedziLink

konto usunięte

Temat: UML - i jego "milion" wersji ...

[author]Jarosław
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: UML - i jego "milion" wersji ...

Szymon B.:
Zgoda co do notacji UML'owej - jest jedna, natomiast co do różnych "cdów i tfurczoś", może to wynikać z różnych narzędzi. Wystarczy porównać notacje chociażby pomiędzy Rationalem Modelerem (bez względu na wersję) a Enterprise Architectem, i już widzimy różnicę, nie wspominając o ARGO UML.

Nie rozumiem.... różnicę w czym?

każdy z tych pakietów CASE (ja dodam używam Visual Paradigm Agilian) ma swoje dodatki więc poza UML można tam znaleźć diagramy ERD, DFD, Requirements diagram, proste diagramy procesów, i cała mase innych wynalazków z poza UML, ale jest to zawsze czysty UML plus coś tam.

Pomijam oczywiscie kwestrie czysto estetyczne w tych pakietach (tylko bw, kolorowane pola itp....)
Link do wypowiedziLink

konto usunięte

Temat: UML - i jego "milion" wersji ...

Co do czystego UML'a to zgodzę się z tym, że jest on raczej podstawą powstania tych narzędzi, natomiast co do notacji zastosowanej w konkretnych diagramach to ... no może diagramy klas i przypadków użycia są wszędzie podobne (czytaj: wręcz identyczne), cała reszta śmiem twierdzić, że jest to już raczej ta 'cała masa dodatków', o której piszesz a w te dodatki wpleciony UML. 'Cuda' o których rozmawiamy spotykane w różnych projektach, wynikają w dużej mierze, jak mi się wydaje, z wykorzystania właśnie tych 'dodatków' bardziej niż z wykorzystania 'czystego' UML'a.

Ale przyznasz sam, że lepiej jest pracować w projekcie (może bardziej brać udział), w którym jest nawet 'kulawa' dokumentacja UML'owa, niż w projekcie w którym nie ma żadnej dokumentacji.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: UML - i jego "milion" wersji ...

Szymon B.:
Ale przyznasz sam, że lepiej jest pracować w projekcie (może bardziej brać udział), w którym jest nawet 'kulawa' dokumentacja UML'owa, niż w projekcie w którym nie ma żadnej dokumentacji.

Co do tego to chyba każdy "normalny" człowiek jest zgodny :). Mimo, że używam słowa Agile w swoich projektach absolutnie nie znaczy to "na odwal i bez kwitów"...

W kwestii "czystości" UML czy innych wynalazków. Ja na to patrzę w ten sposób: jeżeli jakikolwiek model (diagram) ma być jednoznacznie intepretowalny musi mieć zdefiniowane semantyke i syntaktykę (słownik symboli i zasady dopuszczalnego ich łączenia między sobą). Model bez tego to brakoróbstwo i amatorszczyzna.

Można narysować dowolne obrazki i będą dobre pod warunkiem, że na początku umieścimy te dwie definicje. Zamiast jednak tworzyć własne notacje można użyć standardowej np. UML czy BPMN co pozwala powołać się na standard zamiast wymyślania i tworzenia własnego.

W niektórych nieskomplikowanych projektach tworzę własną prostą notację (znaczy mam już zrobioną na użytek takich projektów). W projektach większych i dla nieznanych mi odbiorców z reguły stosuję standardy.

UML to teraz 13 typów diagramów ale w większości projektów rzadko używa sie wiecej niż 5, z reguły są to:
- na etapie analizy: diagram klas, diagram ER (poza UML), przypadki użycia (UC), diagram wdrożenia (do udokumentowania dostępnego obecnego środowiska)
- na etapie projektowania, udokładnienie klas, diagram przejść, scenariusze dla UC, diagramy interakcji.

Oczywiscie wiele zależy od typu projektu.
Link do wypowiedziLink
Sławomir Bańkowski

Sławomir Bańkowski PhD student,
Consultant,
Lecturer, Senior
Software Engineer

Temat: UML - i jego "milion" wersji ...

A co jak do dyspozycji jest Rational Rose i trzeba narysować kompozycję (silną agregację)? W mojej wersji Rose nie widziałem takiego symbolu (może czas zamienić wersję na nowszą).
Niestety w dokumentacjach UML znajdziemy wiele dobrych oznaczeń, które niekoniecznie są we wszystkich dostępnych programach. Osobiście umieszczam dodatkową notkę, którą komentuję dlaczego użyłem takiego znaku.
A z "personalizacją" się spotkałem, gdy było dużo więcej komentarzy do diagramu niż elementów na tym diagramie UML.
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: UML - i jego "milion" wersji ...

Sławomir B.:
A co jak do dyspozycji jest Rational Rose i trzeba narysować kompozycję (silną agregację)? W mojej wersji Rose nie widziałem takiego symbolu (może czas zamienić wersję na nowszą).
Niestety w dokumentacjach UML znajdziemy wiele dobrych oznaczeń, które niekoniecznie są we wszystkich dostępnych programach.

To nie jest uwaga do Ciebie a do osoby, która dokonywała wyboru ale to nie ma rady. Tak jest z każdym programem: albo spełnia wymagania albo nie :)... ale programiści wiedzą o tym najlepiej ...
Osobiście umieszczam dodatkową notkę, którą komentuję dlaczego użyłem takiego znaku.
A z "personalizacją" się spotkałem, gdy było dużo więcej komentarzy do diagramu niż elementów na tym diagramie UML.

To co teraz napiszę to tylko moje subiektywne odczucie "modelarza":

- jeżeli ktos używa "zbyt starej" wersji oprogramowania to ma kłopot, rzadko programista czy analityk, raczej jego pracodawca robi "pseudooszczędności".

- jeżeli już musimy zawęzić agregację do kompozycji to zamiast komentarza lepiej użyć ograniczenia (linia przerywana i opis w klamrach {})

- nie wiem co znaczyła ta "personalizacja" ale diagram z ogromna liczba komentarzy świadczy raczej o nieumiejętności modelowania.

Moja praktyka pokazuje (co potwierdza literatura), że w ramach jednego typu diagramu powino wystarczyć ok. sześć symboli. Jeżeli analityk używa znacznie więcej i wielu komentarzy to prawdopodobnie nie rozumie jeszcze modelowanego przedmiotu i wszelkie niezrozumiałe rzeczy obrazuje (ukrywa) pod postacią nowych symboli i komentarzy.

Dlatego tak wazna jest semantyka, syntaktyka i ich przestrzeganie bo to zmusza do zastanowienia sie nad modelowanym przedmiotem i niejako "każe" go zrozumieć. Prędzej czy później wyjdzie to, że albo programista albo użytkownik zapyta "co to?".
Link do wypowiedziLink
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: UML - i jego "milion" wersji ...

Dodatek :)

Śledze ten wątek i musze potwierdzić, że z nieznanych mi powodów dostawcy niektórych narzędzi do modelowania mają "swoje" implementacje czegoś co jest standardem czyli np. UML.

Nie ukrywam, że musiałem dobrze poszperać zanim znalazłem narzędzie bez "swojej intepreracji" notacji. Używam Visual-Paradigm UML i BPVA. System nadąża za zmianami w UML i pozwala zrobić wszystko to co jest w dokumentacji do UML. Działający w tle validator natychmiast pokazuje próby niezgodne z syntaktyką ale także daje wybór.

Rational jest, o ile mi wiadomo, "nagięty" na RUP'a stąd ma troszkę dziwnych "biznesowych" symboli jako (dopuszczalne w UML) rozszerzenie notacji. Osobiście to do mnie nie przemawia. Głownie dlatego, że klienci biznesowi nie rozumieją tych diagramów.

Stosuję raczej zasady opisane w zaleceniach do SOA czyli procesy modeluję procesowo (BPMN) a obiektowe elementy projektu obiektowo (UML). Specyfikację wymagań opracowuje na bazie modelu procesowego, na bazie tych wymagań projektuje obiektową architekturę systemu i jego implementacje. Dzięki temu klient ma swoją dokumetację a wykonawca swoją.

Nie sądze by jakiemukolwiek odbiorcy biznesowemu był do szczęścia potrzebny model UML systemu, który się dla niego wykonuje. Granicą komunikacji pomiędzy zleceniodawcą a wykonacą jest moim zdaniem specyfikacja wymagań i scenariusze przypadków użycia ale już nie diagramy UML (przypadków użycia także już nie).
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

UML - konferencja we Wrześniu




Wyślij zaproszenie do
Anuluj