o modelowaniu procesów i systemów 

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?

przeczytaj pozostałą część »

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.

przeczytaj pozostałą część »

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

przeczytaj pozostałą część »

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):

• Computation Independent Model (CIM) (albo: domain model; vocabulary) – model biznesowy, nie precyzujący zakresu odpowiedzialności oprogramowania
• Platform Independent Model (PIM) – abstrakcyjna specyfikacja systemu
• Platform Specific Model (PSM) – model odwzorowany na konkretne rozwiązania wybranej platformy
• Implementation Model – proste przełożenie decyzji z modelu platformowego

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.

Jest już nowa wersja UML – 2.2. O zmianach napiszę jak ją przejrzę.

Poza stronami OMG zamieszczam poniżej linki do całej specyfikacji:

Jakiś czas temu  w tekście o UML (Język UML a normy ISO) napisałem, że wersja 1.4.2 języka UML stała się norma ISO/IEC 19501

Obecnie najnowsza norma ISO odnośnie języka UML to ISO/IEC 19505, która reprezentuje standard UML w wersji 2.1.2

Poniżej zamieszczam linki do obu specyfikacji reprezentujących normy ISO:

ISO/IEC 19501

• ISO/IEC 19501 (UML 1.4.2)

ISO/IEC 19505

• ISO/IEC 19505 (UML 2.1.2 Infrastructure)
• ISO/IEC 19505 (UML 2.1.2 Superstructure)

W dniach 19-20 marca 2009 roku miałem olbrzymią przyjemność prowadzić dwudniowe szkolenie dla z modelowania procesów biznesowych z wykorzystaniem języka UML.  Olbrzymia przyjemność płynęła z kilku powodów. Po po pierwsze spotkałem specjalistów o dużym doświadczeniu zawodowym. Po drugie szkolenie uważam za udane, gdyż udało się zrealizować wszystkie zaplanowane ćwiczenia, także te do samodzielnego wykonania. Myślę, że podobnie jak ja myślą uczestnicy szkolenia co zostało uwidocznione w ankietach przeprowadzonych po szkoleniu. Otrzymałem same dobre i bardzo dobre noty a w punkcie za przygotowanie konsultanta otrzymałem wyłącznie bardzo dobre oceny.

Najważniejsze jest jednak to, że uczestnicy tego szkolenia, 4 osoby z jednej największej w Polsce firmy działającej na rynku bankowo-ubezpieczeniowym, szkoliły się za własne pieniądze i w ramach swojego urlopu wypoczynkowego. W tym miejscu chciałem wyrazić publicznie swoje słowa uznania dla osób, które wyłożyły swoje pieniądze po to by inwestować nie tylko w siebie ale de facto także w swojego pracodawcę. 

I na koniec najważniejsza nagroda dla mnie jako trenera i konsultanta. Pozwolę sobie zacytować jednego z uczestników: “Na wstępie pragnę wyrazić swoje zadowolenie ze szkolenia. Jeśli wcześniej miałbym wątpliwości, co do użyteczności modelowania rzeczywistości biznesowej w UML to szkolenie zupełnie by je unicestwiło. Moje oczekiwania w stosunku do szkolenia zostały zaspokojone 100%. …”