UML jest niezrozumiały i nie wiadomo jak go stosować?

image Panuje powszechna opinia, że modele wyrażone w języku UML są niezrozumiałe i nie wiadomo jak go stosować. Problem czytelności diagramów jest tym bardziej istotny, gdy dokumentacji (jakże pieczołowicie) wykonanej w UML nie umie przeczytać Klient. Tak to problem, z którym czasem się spotykam. Wtedy zanim Klient zobaczy wartość modelowania  pozwalam nazywać poszczególne elementy notacji tak jak je nazwał klient przy zachowaniu odpowiedniego znaczenia tego elementu. I tak przykładowo aktor na początku nazywany jest ludzikiem z czasem jest nazywany systemem lub użytkownikiem by potem gdy klient wdraża już UML?a na stałe nazwać go poprawnie aktorem. Oczywiście pilnuję by znaczenie aktora na diagramach przypadków użycia nie zostało zniekształcone.  Ta metoda sprawdziła mi sie w u większości klientów, którzy nie używali UML. Niestety nie u wszystkich 🙁

Na koniec została sprawa jak stosować UML i kiedy? Nie ma jednoznacznej odpowiedzi na ten temat, gdyż użycie języka UML zależy od specyfiki realizowanego projektu, etapu na którym się ten projekt znajduje, czy znajomości języka UML przez różne osoby zaangażowane w dany projekt. Z tego też powodu potrzebne jest pewne doświadczenie. Ale jak zdobyć to doświadczenie, gdy książki mówią o notacji UML a nie o tym jak go stosować a przykłady z Internetu też są banalne? Na początek proponuję konsultacje u doświadczonej osoby, która ma za sobą kilka projektów z wykorzystaniem UML. Byłoby rewelacyjnie gdyby taka osoba nadzorowała nasze prace – była takim Aniołem Stróżem UML. Myślę, że takie spotkania dadzą więcej niż nawet kilkudniowe szkolenie.

Technorati Tagi: UML,Unified Modeling Language,proces wytwórczy oprogramowania
Podobne wpisy
BPMN vs diagramy aktywności

Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście więcej

Kolejne wskazówki dotyczące modelowania w ujęciu Agile

Kilkanaście dni temu  opublikowałem 5 wskazówek dla analizy w ujęciu AGILE Scotta Amblera. Chciałbym je teraz uzupełnić o kolejne spostrzeżenia. więcej

5 wskazówek dla analizy w ujęciu AGILE

Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one: 1. Aktywny udział więcej

Specyfikacja komponentów i interfejsów w Enterprise Architect

W trakcie projektowania systemów na poziomie komponentów istotnym jest aby dobrze wyspecyfikować kanały komunikacji pomiędzy komponentami. Poniżej w tekście tym, więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry