o modelowaniu procesów i systemów 

W Enterprise Architect gdy chcemy zmieć status lub wersję wszystkich elementów zawartych w danym pakiecie to wystarczy wybrać w menu kontekstowym wybrać Package Control i na samym dole Update Package Status…

Następnie należy określić parametry zmiany i sprawa jest zakończona.

Wybór narzędzia CASE wspomagającego proces akwizycji i zarządzania wymaganiami jest trudny. Poniżej zamieszczam link do zestawienia cech wybranych narzędzi.

Zestawienie to jest tłumaczeniem badań jakie zostały opublikowane przez The International Council on Systems Engineering (INCOSE). Na stronach tej organizacji można znaleźć oryginał z bogatszą listą produktów.

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 ostatnią sobotę na moim blogu wystartowały konsultacje online

Konsultacje online to usługa usługa doradztwa udzielana przez Internet za pomocą platformy o nazwie System Konsultacji Online (SKO). Platforma ta znajduje się pod adresem:

http://www.wolski.waw.pl/konsultacje-online/

Konsultacje online są dedykowane tym wszystkim, którzy mają wątpliwości lub problemy związane z inżynierią oprogramowania a nie mogą (z różnych przyczyn) skorzystać z konsultacji tradycyjnych. Usługa ta świetnie się sprawdza w sytuacjach gdy rozwiązanie danego problemu musi nastąpić w miarę szybko. W najszybszym wariancie odpowiedź zostanie udzielona w przeciągu 24 godzin od odnotowania wpłaty.

Koszt jednej konsultacji online to wydatek rzędu kilkudziesięciu złotych. Każde zapytanie jest wyceniane indywidualnie a cena jest uzależniona nie tylko od złożoności pytania ale także od czasu realizacji usługi.

Myślę, że konsultacje online znajdą  przede wszystkim zastosowanie w sytuacjach gdy podczas pracy nad projektem wątpliwości pojawiają się sporadycznie i angażowanie zewnętrznych konsultantów do odpowiedzi na jedno lub kilka pytań jest nieopłacalne.

Konsultacje online to także anonimowość zadającego pytanie, gdyż zarówno w czasie korzystania z usługi dane osobowe mogą być nieprawdziwe a system płatności za te usługi po za adresem e-mail nie przekazuje żadnych danych osobowych płatnika.

?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy:

• przypadek użycia zapewnia wartość aktorom,
• krótki opis zwięźle opisuje cel przypadku użycia,
• przypadek użycia jest kompletny i sensowny,
• wydarzenie rozpoczynające przypadek użycia jest jasne,
• sposób i czas zakończenia przypadku użycia jest jasny,
• stosowana terminologia jest jasna, a istotne terminy zdefiniowane w słowniczku lub podobnym,
• rozpoczęcie i zakończenie przepływu alternatywnego
  jest jasne a każdy przepływ alternatywny posiada jasne
  odniesienie do sposobu, w jaki się zaczyna i dokąd zawrócona jest kontrola po tym jak zostanie wykonany,
• przypadek użycia jest możliwy do zweryfikowania,
• wszystkie kroki są indywidualnie ponumerowane,
• aby uprościć długie i złożone przepływy zdarzeń, wykorzystywane są podprzepływy w postaci dekompozycji aktywności

Powyższy dekalog sprawdzanych parametrów pozwala na utrzymywanie w repozytorium projektu w miarę sensownych przypadków użycia.

Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często mówimy tylko o funkcjonalności i o tym w jaki sposób system ma realizować procesy biznesowe.  Powstaje pytanie jak skutecznie uzupełnić wymagania także o takie szczegóły jak rozmieszczenie przycisków, format raportu, pola edycji systemu. Po prostu ludziom trudno jest stworzyć krok po kroku opis systemu, którego nigdy nie widzieli. Z tego też powodu jestem zwolennikiem by przypadki użycia wraz z diagramem klas i aktywności opowiadały o systemie skupiając się przede wszystkim  na jego funkcjach.

Do uszczegółowienia wielu  aspektów system, które do specyfikacji są żmudne i czasochłonne polecam prototyp.

Wytworzenie wczesnego prototypu opartego o przypadki użycia może powołać system do życia, co sprawia, że znacznie łatwiej jest gromadzić informacje zwrotne wymagane do ukończenia specyfikacji przypadków użycia. Takie podejście powoduje iż dokumentacja w UML nie jest zbyt złożona co wpisuje się nurt zwinnego modelowania.

The Rational Edge to, moim zdaniem, jeden z najlepszych magazynów wydawanych w formie elektronicznej. Cenię go bardzo także za to, że w sposób niesłychanie merytoryczny traktował o produktach Rationala i nie tylko. The Rational Edge to teksty, które miały i mają niesamowity wpływ na rozwój inżynierii oprogramowania. Pierwsze wydanie miało miejsce 15 grudnia 2000 roku i można było wnim przeczytać teksty Jim Rumbaugh?a – ?Trends in UML and e-development? i Philippe Kruchtena?a ?From Waterfall to Iterative Development? ? KLASYKA. Po niemalże dekadzie na rynku z miesięcznika zrobił się kwartalnik a obecnie IBM zastąpił Rational Edge  nowym wydawnictwem Leading Innovation.

Umarł The Rational Edge niech żyje Leading Innovation.

Niestety moim zdaniem Leading Innovation nie dorasta do pięt swojemu poprzednikowi bo to co jest pod hasłem Rational leading innovation library to miernota.  Widać wyraźnie, że IBM zagubił się w swojej wizji rozwiązań wspierających inżynierię oprogramowania. Wydaje mi się, że akwizycja Rational?a i Telelogica nie pomogły. Co z tego, że IBM posiada w swoim portfolio największą grupę narzędzi CASE jak one się dublują (patrz DOORS i RequisitePro, System Architect i Software Architect). Istna wieża Babel, w której nie ma ducha innowacyjności i twórczego podejścia do inżynierii oprogramowania, z jaką można było się spotkać na łamach The Rational Edge w tekstach wielu wybitnych fachowców. Szkoda, że trak się stało. Liczę jednak na prawa natury, która nie lubi pustki. Czym wypełni brak kolejnych wydać The Rational Edge. Zobaczymy.

W sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie.    Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia

Od pewnego czasu o moje uszy obija się nazwa BoUML. Co to jest? To jest narzędzie do open source?owe narzędzie do modelowania. Zaintrygowany pochlebnymi opiniami zainstalowałem i oto moja króciutka opinia. Naprawdę króciutka, bo całe dobro i zło danego narzędzia wychodzi w projektach.

Podoba mi się, że klasę (a więc także aktora i przypadek użycia) można opisać nie tylko za pomocą pola description ale także jest dedykowane miejsce dla wszelkich warunków i ograniczeń.

A teraz największa porażka. Brak polskich liter.

przeczytaj pozostałą część »

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