o modelowaniu procesów i systemów 

Listopad dla mnie to przede wszystkim przygotowania do projektu o kodowej nazwie?tormigo? ? lubię myśleć o tym projekcie, że to będzie mała rewolucja, ale o tym napisze w odpowiednim czasie. Ponadto przeprowadziłem dwa szkolenia. Jedno z zakresu modelowania procesów biznesowych, drugie z zakresu modelowaniu w UML z wykorzystaniem Enterprise Architect. Szkolenia były przeprowadzane, dla różnych organizacji. Oba wydarzenia łączyło to, że podstawą działań było dokładne i permanentne zrozumienie procesu biznesowego. Dlaczego? Moim zdaniem dziś nie można mówić o modelowaniu systemów IT bez analizy procesu biznesowego ? to podstawa działań.

W anonimowych ankietach, w obu organizacjach, otrzymałem dobre i bardzo dobre oceny za moje przygotowanie i przeprowadzenie szkolenia. Najbardziej w pamięci utkwiły mi dwa komentarze. W jednej z ankiet dot. szkolenia zakresu modelowaniu w UML z wykorzystaniem Enterprise Architect w punkcie co najbardziej podobało Ci się na niniejszym szkoleniu: ?Ćwiczenia praktyczne i konkretny pomysł, co przekazać słuchaczom (co rzadko się zdarza)?.  Natomiast w ankiecie dot. szkolenia z modelowania biznesowego zostałem nagrodzony jednym słowem: ?Perfekcyjnie?. Wielkie dzięki

Ostatnie kilka wpisów:

• Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect
• Enterprise Architect i MDG Integration for Eclipse w praktyce
• MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect
• Mały sekret reverse i forward engineering w Enterprise Architect
• Pisanie kodu w Enterprise Architect

dotyczyło metod integracji kodu z jej modelem. Przedstawiłem to zagadnienie w różnych wariantach z pluginem (MDG Integration for Eclipse) i bez. Teraz czas na podsumowanie i pytanie czy jest sens synchronizować model z jego implementacją w trakcie kodowania. Moim skromnym zdaniem NIE. Dlaczego?

przeczytaj pozostałą część »

W poprzednich tekstach (Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect, MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect) pisałem o inżynierii wstecz w Enterprise Architect. Teraz czas na mały sekret.

przeczytaj pozostałą część »

Czy można pisać kod aplikacji w Enterprise Architect? Tak można i zaprezentuje to na przykładzie z którego korzystałem w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect

przeczytaj pozostałą część »

W tekście Enterprise Architect i MDG Integration for Eclipse w praktyce opisałem wstępnie wtyczkę MDG Integration for Eclipse, która ułatwia integrację Enterprise Architecta ze środowiskiem Eclipse. Teraz postaram się zaprezentować możliwości wtyczki w zakresie synchronizacji kodu z modelem.

przeczytaj pozostałą część »

Tradycyjną metodę inżynierii wstecz opisałem kilka dni temu w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect. Dziś chciałbym się skupić na płatnej wtyczce jaką można zastosować do Enterprise Architecta celem synchronizacji modeli ze środowiskiem JAVA czyli MDG Integration for Eclipse.

przeczytaj pozostałą część »

Mechanizm inżynierii wstecz (ang. reverse engineering) wstecz jest użyteczny w tedy, gdy mamy napisany program i chcemy go udokumentować za pomocą modeli UML. Powstała w ten sposób dokumentacja jest modelem implementacji. W Enterprise Architect można dokonać tego poprzez wybór odpowiedniego parametru w menu kontekstowym pakietu do którego będzie importowany kod.

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.

Planowanie w oparciu o kamienie milowe obejmuje określenie pożądanych wyników projektu i planowania progresji wobec nich poprzez serię kamieni milowych. Można określić dwa typy kamieni milowych:

• Kamienie milowe wypuszczenia – punkty, w których są udostępniane główne produkty wypuszczenia
• Wewnętrzne kamienie milowe – punkty, w których dokonuje się istotnego obiektywnie wymiernego postępu wobec zakończenia rozwiązania.

Każdy kamień milowy jest określony w zakresie celów, które muszą być osiągnięte oraz kryteriów oceny dla obiektywnej oceny, czy zostały osiągnięte. Każdy kamień milowy prezentuje:

• istotny punkt kontrolny projektu
• możliwość oceny dokonanego postępu i ponowną ocenę przyszłych planów
• możliwość dostosowywania się do planów.

Korzystając z techniki kamieni milowych pamiętaj aby zidentyfikować główne produkty kamieni milowych. Pamiętaj także, że granice iteracji zapewniają jasno określone wewnętrzne kamienie milowe dla projektów iteracyjnych.

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ęść »

Jak widać uległ zmianie design bloga co zostało podyktowane faktem, że od 2 listopada moje teksty stały się kanałem informacyjnyno-merytorycznym wcielonym w struktury firmy  Modesto (www.modesto.pl).

Wraz ze ?zmianą designu? znikają wszystkie reklamy ? co ja osobiście uważam za plus. Ponadto blog przechodzić będzie na nowy serwer co może spowodować drobne perturbacje.

Przy okazji chciałem się pochwalić, że w ostatnim miesiącu moja strona odnotowała troszkę ponad 3000 odwiedzin. Dziękuję.