Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji pod adresem:
http://msdn.microsoft.com/en-us/library/dd380647.aspx
Szczególnie polecam rozdział 4.4 Use Models in Agile Development.
Jest rewolucja. I to nie mała. Otóż firma Microsoft w ramach Visual Studio z premedytacją omijała aspekt wizualnego projektowania sytemu przy użyciu UML. Aż do teraz.
W nowej wersji VS 2010 jest VS2010 Visualization and Modeling Feature Pack (http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx), dzięki któremu można wytwarzać modele na różnym poziomie abstrakcji i w konsekwencji synchronizować je z kodem aplikacji.
Przełom jest tym większy, że Microsoft proponuje tylko te techniki modelowania, które są uważane za składniki zwinnego modelowania (ang. Agile Modeling).
Co zrobić w sytuacji gdy do wykonania danej funkcji, opisanej przez przypadek użycia, potrzeba w tym samym momencie więcej niż jednego aktora? Czy można pokazać to na diagramie przypadków użycia? Otóż nie.
Diagram przypadków użycia nie definiuje nam tego kto w jakiej sytuacji, w jakim momencie korzysta z danej funkcji. Relacja aktor – przypadek użycia mówi jedynie o tym kto korzysta z funkcjonalności dostarczanej przez dany PU. W sytuacji gdy do realizacji fragmentu bądź całego scenariusza potrzeba dwóch aktorów to na diagramie PU wskazujemy na działanie obu aktorów poprzez asocjację.
Natomiast ich jednoczesne działanie procentujemy na diagramie aktywności zaznaczmy stosując tory (partycje) pionowe i poziome.
Dzięki zastosowaniu partycji pionowych i poziomych i zmapowaniu ich na aktorów można wskazać na te fragmenty scenariusza, które są realizowane przez obu aktorów równocześnie. Technika ta może być przydatna zarówno przy modelowaniu procesów biznesowych jak i projektowaniu systemów informatycznych.
W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany ?Requirement?
Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE?
Dużo się mówi na temat modelowania systemów informatycznych w języku UML. A co z systemami, które nie są informatycznymi? Za nim odpowiem na to pytanie warto przypomnieć sobie czym jest system a pomoże mi w tym zestawienie jakie zrobił Robert Gwiazdowski, którego pozwalam sobie zacytować:
Pod pojęciem systemu nauka rozumie zintegrowaną całość, której własności nie są prostą sumą własności poszczególnych części tej całości, istnienie jednak szereg związków i interakcji pomiędzy nimi. (E. Laszlo, Systemowy obraz świata, Warszawa 1978; L. von Bertalanffy, Ogólna teoria systemów, Warszawa 1984) ?Doniosłą cechą systemów jest tkwiący w samej ich istocie charakter dynamiczny. Systemy pod względem formy nie są sztywnymi strukturami; ich forma wyraża zmienne, a jednocześnie trwałe przejawy procesów zachodzących w systemach?. (F. Capra, Punkt zwrotny, Warszawa 1987) Funkcjonowanie systemu stanowi rezultat zachodzących w nich pętli sprzężeń zwrotnych polegających na tym, że element A oddziaływa na element B, B na C, zaś C zwrotnie na A. W systemie nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.
Z powyższych definicji wynika, że system składa się ze struktur, które zmieniają swój stan ? przejawiają zachowanie. Jest to wspólna cecha systemów informatycznych (np.: struktura: klasa, zachowanie metoda, która zmienia stan klasy) i systemów nieinformatycznych (np.: struktura: siłownik, zachowanie: uruchomienie dźwigni, która zmienia położenie ? stan -siłownika).
Reasumując skoro UML nadaje sie do modelowania systemów informatycznych to nadaje się także do modelowania wszystkich innych typów systemów ze szczególnym naciskiem na automatykę i robotykę. Nie można też zapomnieć o innych dziedzinach społecznych nie związanych z informatyką, gdzie są stosowane różnej maści systemy (np.: system wynagrodzeń). W obszarach nietechnicznych UML sprawdza się bardzo dobrze przy modelowaniu procesów biznesowych, gdzie także możemy odnotować, że (cytując R. Gwiazdowskiego) element A oddziaływa na element B, B na C, zaś C zwrotnie na A. Co w konsekwencji pozwala sądzić, że w modelach biznesowych (ponownie cyt.) nie działa linearny łańcuch przyczyn i skutków, lecz zjawisko nielinearnej współzależności.
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, postaram się przedstawić kilka technik umożliwiających pracę na tym poziomie abstrakcji.
Kilka tygodni temu pisałem o specyfikacji UML w wersji 2.2. Obiecałem wtedy, że jak ją przejrzę to napiszę o zmianach. Niniejszym informuję, że specyfikacja została przeze mnie
przejrzana. Dzięki wersji specyfikacji z ?bar code?, na której są zaznaczone zmiany w stosunku do wersji 2.1.2 przejrzenie ponad 600 stron zajęło mi rozsądną ilość czasu. Co nowego w wersji 2.2? Otóż nic ciekawego. Istotnie zmian jest sporo, ale wszystkie to kosmetyka. Nic znaczącego UML 2.2 nie wnosi do świata inżynierii oprogramowania. Ja od dziś oficjalnie, bez zmian w modelach, przechodzę na UML 2.2.
Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM w architekturze MDA. Teraz chciałbym pokazać jak taką transformację zrobić w Enterprise Architect.
Zrobię to na przykładzie wzorca projektowego Adapter, którego celem jest którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach.
Zaprezentowany model jest odseparowany od swojej implementacji. Aby wykonać model PSM należy
Zazwyczaj sporo mówi się na temat tego, że model musi być odseparowany od swojej implementacji. Oznacza to, że w pierwszej fazie modelowania nie należy
zastanawiać się nad tym, jak będzie wyglądała implementacja. Dopiero po zatwierdzeniu projektu można dostosować model już do środowiska implementacji. Sprzyja to reużyciu całych fragmentów projektów. Stosując taka zasadę idealnie działa się zgodnie z MDA czyli Model Driven Architecture. Model-Driven Architecture ? to sposób budowania oprogramowania w oparciu o modele i ich transformacje.
W MDA wyróżnia się 4 poziomy (modele):
Patrząc na ten podział modelem odseparowanym od implementacji będzie model PIM, którego ideą jest zaprezentowanie rozwiązania zgodnego z wymaganiami.
PSM natomiast stanowi odwzorowanie abstrakcji zamodelowanych w PIM na konkretne rozwiązania charakterystyczne dla danej platformy lub języka programowania. Mówiąc inaczej PSM jest uszczegółowioną formą PIM lub jego konkretnym wystąpieniem.
Narzędzia CASE w różnym stopniu wspierają takie podejście. Czasem jest to wygenerowanie modelu implementacji jak ma to miejsce w narzędziach z rodziny Rational (nawiasem mówiąc w produktach Rational mówi się o Model Driven Development (MDD), który jest rozszerzoną wersją MDA) lub modelu platformy jak ma to miejsce w Enterprise Architect.
Przykład transformacji w EnterpriseArchitect można znaleźć w poście Transformacja PIM-PSM w Enterprise Architect
Na koniec należy wspomnieć, że dwukierunkowość transformacji PIM ?> PSM i PSM ?>PIM nie jest zawsze możliwa.
W dniach 7-8 maja prowadziłem w Warszawie szkolenie z projektowania systemów informatycznych. Nikt z uczestników szkolenia nie miał wątpliwości, że modele w UML są przydatne a jednocześnie metodyki z nurtu Agile odrzucają modelowanie. Oczekiwania wobec szkolenia krążyły wobec tematów co i jak dokumentować w UML? Jak obszerną dokumentację wykonywać? Jak połączyć modelowanie w UML z zwinnymi (ang. Agile) metodykami takimi jak XP czy Scrum. W trakcie szkolenia zaprezentowałem istotę metodyk zwinnych i ciężkich oraz zaprezentowałem klucz - łącznik pozwalający na połączenie modeli wyrażonych w UML z zwinnym podejściem. Wskazałem także jak zaprezentowane rozwiązanie może dodatkowo pozwolić na lepsze wymiarowanie projektu np.: w zakresie ustalenia zakresu iteracji ? sprintu jak to mówią wyznawcy Scrum.
Wydaje mi się, że szkolenie spełniło oczekiwania jego uczestników o czym świadczą ankiety: w zakresie sposobu prezentacji tematu, przydatności szkolenia i mojego przygotowania otrzymałem same dobre i bardzo dobre oceny. Dziękuję szczególnie za jedną opinię w punkcie: ?Co się Państwu najbardziej podobało w niniejszych warsztatach??, która brzmi ?Kompetencja prowadzącego i sposób prowadzenia szkolenia?. 
Każdy czasem zastanawia się nad wyborem najlepszego narzędzia do modelowanie w UML. Moim zdaniem nie ma idealnej recepty pomagającej dokonać wyboru. Dlatego też trzeba napisać swoje wymagania odnośnie narzędzia a potem przeklikać to i owo w kilku narzędziach do modelowania. Indywidualne odczucia powinny zdecydować. Nie mniej jednak można próbować posiłkować się rankingami. Jednym z nich jest ankieta wykonana na formu uml-forum.com gdzie 10 kwietnia dla uczestników tej ankiety najlepszym narzędziem uznany został Enterprise Architect na drugim miejscu EclipseUML a na trzecim (o zgrozo) Visio. 
W ciągu ostatnich dwóch dni (6-7.04) przekonałem sie po raz kolejny jak ważne są warsztaty praktyczne oparte o praktyczne problemy klienta. W trakcie dwudniowego szkolenia z modelowania procesów biznesowych z wykorzystaniem języka UML w trakcie warsztatów realizowany był CASE klienta i tradycyjnie w takiej sytuacji padało więcej pytań niż zazwyczaj a uczestnicy szkolenia byli bardziej zaangażowani. Moją opinię potwierdzają ankiety uczestników szkolenia, w których po za dobrymi i bardzo dobrymi ocenami, jakie zebrałem za przedstawienie tematu i moje przygotowanie połowa ankietowanych w pozycji ankiety ?co najbardziej podobało ci się w trakcie szkolenia? wpisało: warsztaty lub zajęcia praktyczne, lub ćwiczenia.
Wszystkie prawa zastrzeżone 
modesto group All rights reserved
