o modelowaniu procesów i systemó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.

O tym, że modelowanie jest przydatne w projektowani wszelakich aplikacji, nie trzeba przekonywać nikogo. Cieszy mnie bardzo, gdy widzę, że kolejne firmy mają ten sam pogląd i razem wypracowujemy metodykę działania dla ich potrzeb. Tak też było w ostanie dni maja, w które prowadziłem szkolenie dla kilku osób z  firmy produkującej gry.  Bardzo dobrze spędziłem ten czas z dwóch powodów. Po pierwsze już dawno nie miałem tak wdzięcznego tematu do pracy. Po drugie uczestnicy ? rzeczowi, wymagający, doświadczeni programiści poszukujący rozwiązań szytych na ich miarę, co spowodowało, że szkolenie było bardzo intensywne i myślę, że udane. Świadczą o tym ankiety, w których otrzymałem same bardzo dobre oceny za ważność poruszanych tematów, ćwiczenia i moje przygotowanie. Na koniec cytat z ankiety z punktu Co najbardziej podobało Ci się w niniejszym szkoleniu: ?Duża liczba ćwiczeń praktycznych. Szkolenie zostało dostosowane do dziedziny jaką się zajmujemy?. Dziękuję za te słowa.

Mit: Zwinne zespoły nie produkują dokumentacji

Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie.

Mit: Zwinne zespoły nie potrzebują inwestować w wymagania

Fakt: Zwinne zespoły maniakalnie koncentrują się na spotkaniach z klientem związanych z określeniem wymagań. Nie potrzebują zapisywać wszystkiego na przód. Jeśli nie ma na miejscu klienta, zespoły używają bardziej tradycyjnych technik, takich jak przypadki użycia.

Mit: Zwinne zespoły nie tworzą modeli ani architektury systemu

Fakt: Zespoły tworzą wiele modeli (zazwyczaj ręcznie na białych kartach) w celu ułatwienia komunikacji. Badania wykazały, że większość zwinnych zespołów wykonuje modele by pomóc zrozumieć jak oni budują i konstruują system. Brak projektu całości na początku przedsięwzięcia nie oznacza braku projektowania. Najczęściej obok przypadków użycia powstają diagramy klas i aktywności.

Mit: Zwinne zespoły nie maja żadnych planów

Fakt: Zwinne zespołu projektują by nie było jak z Alicją w Kainie Czarów Lewisa Carrolla:

? Czy nie mógłby pan mnie poinformować, którędy powinnam pójść? ? mówiła dalej.
? To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść ? odparł Kot ? Dziwak.
? Właściwie wszystko mi jedno.
? W takim razie również wszystko jedno, którędy pójdziesz.
? Chciałabym tylko dostać się dokądś ? dodała Alicja w formie wyjaśnienia.
? Ach, na pewno tam się dostaniesz, jeśli tylko będziesz szła dość długo.

Mit: Zwinne zespoły szybko przestają być kontrolowane, robią cokolwiek jak lubią i kiedy chcą.

Fakt: Zespół jest właściwie bardzo zdyscyplinowany i bardzo skupiony.Zadania zawsze są wykonywane w ustalonym porządku, z priorytetem określonym przez klienta  przy pomocy przypadków użycia. Mierzenie osiągnięć celów nakreślonych przez przypadki użycia służy do jasnego oszacowania postępu i wydajności.

Mit: Jeśli jesteś zwinny, to nie potrzebujesz żadnych menadżerów

Fakt: Potrzebny jest menadżer by utworzyć dobre środowisko pracy i zaplanować iteracje w oparciu o przypadki użycia. Zwinny zespół dostarcza mierzalnych celów, określonych przez przypadki użycia. Menadżer za pomocą przypadków użycia szacuje ryzyko co umożliwia mu tym samym bardziej efektywne zarządzanie.

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?.

Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski

Seria: W praktyce
Wydawnictwo Naukowe PWN
Warszawa, 2007 r.
ISBN: 978-83-01-15251-2
Wydanie: pierwsze
Objętość: s. 308
Format: 16,5×24 cm
Oprawa: miękka

Książka przedstawia sposób modelowania systemów informacyjnych z wykorzystaniem podejścia obiektowego i języka UML 2.1. Czytelnik znajdzie w niej współczesne spojrzenie na modelowanie i projektowanie systemów informatycznych w ujęciu obiektowym zilustrowane praktycznymi przykładami wykorzystania języka UML w różnorodnych obszarach.

W książce zgromadzono wiedzę najlepszych praktyk oraz często popełnianych przez projektantów błędów. Pozwoliło to na zbudowanie unikatowego repozytorium obszernej wiedzy z zakresu modelowania za pomocą języka UML. Najważniejszą zaletą książki „Modelowanie systemów informatycznych w języku UML 2.1 w praktyce” jest skoncentrowanie się autorów na praktycznych aspektach wykorzystania języka UML. Autorzy prezentują w niej zastosowania tego języka w różnych obszarach, od projektowania systemów czasu rzeczywistego poprzez projektowanie baz danych aż po modelowanie systemów biznesowych.

Książka skierowana jest przede wszystkim do studentów kierunków informatycznych oraz kierunków ekonomicznych i zarządzania mających w programie modelowanie biznesowe i projektowanie systemów informacyjnych oraz do praktyków pracujących przy tworzeniu systemów informatycznych. Może być też przydatna jako pomoc przy prowadzeniu kursów i szkoleń z zakresu modelowania biznesowego i projektowania systemów w języku UML.

Książkę można zakupić w księgarni Argon: