Wreszcie się ukazała, a już myślałem, że się nie uda jej wydać na Święta.
Mowa o książce kolegi Szymona Drejewicza, z którym miałem okazję współpracować przez jakiś czas w jednej firmie. Znając Szymona, przyłożył się do roboty i choć jeszcze nie czytałem, pozycja na pewno znajdzie się w mojej biblioteczce, abym mógł ją mieć pod ręką w razie potrzeby.

Zrozumieć BPMN

Więcej o tytule pod linkiem wydawcy, można tam również ją kupić (i chyba tylko tam na razie).

Ponieważ narzędzie opisywane przeze mnie poprzednim razem yUML, choć fajnie wygląda, okazało się być niewystarczające dla bardziej skomplikowanych diagramów, a twórca tego narzędzia olał moją prośbę o pomoc, postanowiłem szukać dalej.
W końcu opisanie diagramu jest na prawdę fajnie, a ręce, szczególnie programistów, nie zwyczajne do klikania myszką.

Oto co znalazłem:

1. UML Graph
Można za jego pomocą narysować diagram klas i sekwencji. To narzędzie nawet trochę przegina w stronę programowania. Tekst definiujący diagram klas na pierwszy rzut oka wygląda jak kod w javie. Drugim przegięciem jest to, że autorom najwyraźniej składnia pseudo-javowa nie leżała w przypadku diagramu sekwencji, więc zastosowali zupełnie inne podejście. Takie trochę rozdwojenie jaźni.
Narzędzie jest w javie więc jest “niezależne-javowo” od platformy systemowej.

Strona domowa jest pod adresem http://www.umlgraph.org/.

2. TextUML Toolkit
Motto tego narzędzia brzmi “Model as fast as you can type”. Ciekawe motto ;).
Narzędzie jest środowiskiem tekstowej budowy modeli, a do ich wyświetlania używa EclipseGraphviz, które samo w sobie jest ciekawym narzędziem.
Mamy tutaj pełne wsparcie środowiska jak podświetlanie składni i inne bajery.

Strona domowa jest pod adresem http://sourceforge.net/apps/mediawiki/textuml/index.php?title=TextUML_Toolkit.

3. Meta UML
O, to wygląda ładnie. Nie dość, że można w tym narysować całkiem sporo (Diagramy klas, aktywności, przypadków użycia, maszyn stanów i pakietów). Można tu rysować niezłe bajery, łącznie z zaawansowanymi elementami diagramów, jak i kolorkami poszczególnych elementów.

Strona domowa jest pod adresem http://metauml.sourceforge.net/, a najnowsza instrukcja dla użytkownika, jaką znalazłem to http://sunet.dl.sourceforge.net/project/metauml/metauml_manual/0.2.5/metauml_manual_0.2.5.pdf.

4. Plant UML
To jest dopiero ciekawostka. Nie dość, że można to zintegrować z eclipsem, to jeszcze z WORDem ;). Piszesz sobie w wordzie tekst, po czym klikasz przycisk i się tekst zamienia na diagram UML, przecież to jest piękne ;).
Narzędzie umożliwia zrobienie diagramów klas, przypadków użycia, sekwencji, aktywności, komponentów, maszyn stanów, i obiektów. Jednym słowem ful wypas w wordzie.

Strona domowa: http://plantuml.sourceforge.net/

5. Stary dobry LaTEX
Jak ktoś nie lubi WORDa, to z pewnością lubi LaTEXa
I to jest właśnie narzędzie dla niego. Szkoda, że można liczyć jedynie na diagramy sekwencji (więcej nie znalazłem), sam bym chętnie z tego skorzystał szczególnie, że diagram sekwencji wygląda całkiem sensownie.

Strona: http://www.texample.net/tikz/examples/pgf-umlsd/.

Żadne z narzędzi, jakie znalazłem nie udostępnia serwisu, który po prostu generuje diagram, jak robi to yUML. Szkoda, że się wywala na diagramach z większa ilością elementów, ale może twórcy coś z tym zrobią. Wyglądają na zapracowanych, skoro nie odpowiadają na maile (w sumie ich trochę rozumiem ).
No nic, trzeba wierzyć, że narzędzie się będzie rozwijało, albo powstanie jakieś inne. Na razie wszystkie, które znalazłem wymagają niestety instalacji czegoś.

A tak apropos, szukam chętnych, do potestowania powyższych przykładów i opisania swoich doświadczeń w komentarzu pod spodem. Ja się na razie zatrzymałem na przeszukaniu sieci i poczytaniu dokumentacji.

Są ochotnicy?

W dyskusjach bliskich darmowemu kursowi uml, który można znaleźć tutaj,
często poruszanym tematem było narzędzie do modelowania, które byłoby proste i najlepiej darmowe.
Różne propozycje padały, ale na takie coś, jak znalazłem dzisiaj bym nie wpadł.
Znalazłem na prawdę “proste” narzędzie do rysowania na szybko diagramów UML. Narzędzie jest tekstowe (na stronie głównej nawet jest notka “I love UTF8!”) i trzeba się tylko nauczyć składni, ale diagramy rysuje na prawdę ładne
Weźmy jako przykład kawałek diagramu ze wspomnianego kursu.

# Diagram z przykładu z http://darmowy-kurs-uml.scire.pl
[Klient]^[Firma]
[Klient]^[Osoba]
[Faktura]*->1[Klient]
[Faktura]1->*[PozycjaFaktury]
[PozycjaFaktury]*->1[Towar]

W wyniku dostaniemy bardzo ładny obrazek w formacie png, który wygląda następująco:

Prawda, że ładne? A jeszcze ten tryb odręcznego rysowania …

Wspomniane narzędzie to yUML, które można znaleźć na http://yuml.me/.
Można rysować diagramy klas, diagramy aktywności i diagramy przypadków użycia.

Tekst można wprowadzać w wersji podstawowej przez formularz na stronie, ale są też dodatkowe narzędzia, z których najbardziej spodobało mi się to na Androida.

Ciekaw jestem do czego mogłoby się wam takie narzędzie przydać i czy się wam podoba. Bardzo proszę, napiszcie w komentarzach.

Słownikowa definicja analityka systemowego mówi, że jest to osoba, która potrafi analizować złożone problemy organizacji w celu opisania tych problemów i przedstawienia ich w formie możliwej do przetwarzania przez systemy informatyczne. No dobrze, ale co to tak naprawdę znaczy? Kto powinien być analitykiem systemowym, informatyk, czy znawca badanej dziedziny? Jaką uczelnię powinien skończyć, aby poprawnie wywiązywać się ze swoich zadań? Powinien reprezentować interesariuszy biznesowych, a może zespół informatyczny, który będzie wykonywał prace projektowe. Gdzie w ogóle uczą bycia analitykiem systemowym? Hm, sporo tych pytań i nie bardzo wiadomo jak na nie odpowiedzieć. Ja jednak spróbuje to zrobić w tym artykule.

Wróćmy na początek do definicji. Wygląda na to, że analityk systemowy powinien przynajmniej być w stanie zrozumieć daną dziedzinę biznesową, bo inaczej jak by miał analizować „złożone problemy organizacji”. Tę tezę potwierdza również fakt, że musi to wszystko później opisać ludziom, którzy będą implementować jego rozwiązania w systemie informatycznym. Musi to zrobić w taki sposób, aby nie powtórzyła się znana historyjka z huśtawką (gdzie huśtawka spełnia wszystkie wymagania, ale nie da się na niej huśtać).

A więc analityk systemowy nie tylko musi zebrać wymagania i przetłumaczyć je na język bardziej strawny przez informatyków, ale również dopilnować, aby jego intencje zostały zrealizowane we właściwy sposób przez zespół informatyczny.

Spójrzmy na sprawę z jeszcze innej perspektywy. Co będzie jeśli wymagania są zebrane, system w połowie zaimplementowany, a rząd wprowadzi nową ustawę, która całkowicie wywróci projekt do góry nogami? Albo co będzie jak sprawdzi się powszechna opinia, że użytkownicy biznesowi sami nie wiedzą czego chcą dopóki czegoś nie zobaczą? Kto wtedy będzie odpowiedzialny za wyprostowanie sprawy?

Kto powinien być analitykiem systemowym?

Najlepiej jakby była to osoba z doświadczeniem. Wynika to z tego, że rzadko uczy się na uczelniach analizy systemowej. Na informatyce jest to elementem inżynierii oprogramowania i uczą tego zwykle informatycy. Z kolei na uczelniach dziedzinowych gorzej jest z nauczaniem elementów „twardej” wiedzy informatycznej (oczywiście pewnie znajda się wyjątki). A tymczasem analityk powinien być dość zaawansowany technicznie, aby wiedział co się da zrobić, a czego nie. Z drugiej strony powinien umieć słuchać i nie bać się pytać, gdy czegoś nie rozumie. Parafrazując znaną maksymę „analityk ma dwoje uszu, a tylko jedne usta po to, aby dwa razy więcej słuchać niż mówić”. Jednak mówić powinien, szczególnie wypytać o wszystko czego nie rozumie, więc nieśmiałość i poczucie wstydu z byle powodu odpada.

Dodatkowo bardzo przydatne jest, jeśli analityk zna się na dziedzinie, której problemy analizuje. Analityk będzie dużo rozmawiał z biznesem i jeśli będzie ciągle zadawał pytania w stylu „co to jest prolongata” doprowadzi do irytacji swoich rozmówców. Ale i tak lepsze to niż udawać, że się wszystko rozumie.

Rola i odpowiedzialność w projekcie

Z grubsza rzecz biorąc, rolą analityka systemowego w projekcie jest zbieranie i zarządzanie wymaganiami. Aby tego dokonać analityk musi zadbać o to, aby znane mu były przynajmniej te procesy biznesowe, które mają jakąś interakcję z budowanym systemem.

Po zrozumieniu niezbędnych procesów biznesowych, analityk systemowy zajmuje się wydobywaniem wymagań na system. Musi zatem zlokalizować miejsca styku procesów biznesowych z systemem i opisać to, jak w poszczególnych procesach biznesowych wykorzystywany będzie system i kto z niego będzie w tych miejscach korzystał. Do opisywania tej części rzeczywistości, analityk na szczęście ma stosowne narzędzia, a na ich czele stoi UML (ang. Unified Modeling Language).

W następnym etapie, analityk musi opisać jak dana interakcja z systemem (przypadek użycia) będzie obsługiwana przez system.

Warsztat łącznika dwóch światów

Procesy biznesowe – niby nie jest niezbędne ich rozumienie, zawsze można skupić się na wymaganiach funkcjonalnych i zapomnieć o zrozumieniu merytoryki procesów biznesowych. Jednak użytkownicy, którzy opowiadają o swoich wymaganiach zwykli o czymś zapominać. Ponieważ lepiej żeby sobie przypomnieli już na samym początku, podczas rozmów o tym jak pracują i próby zrozumienia procesów biznesowych, można ograniczyć przeoczenia, czy niedociągnięcia. Trzeba też pamiętać, że ludzie biznesu nie robią tego złośliwie, raczej niektóre rzeczy wydają się tak oczywiste, że „nie warto o nich wspominać”. Do modelowania procesów biznesowych można wykorzystać diagramy aktywności w UML. Są też bardziej dedykowane notacje, jak BPMN (ang. Business Process Modeling Notation).

Funkcjonalność systemu – do modelowania funkcjonalności używa się zwykle diagramu przypadków użycia (ang. Use Case Diagram). Są na nim dwa główne artefakty. Pierwszy z nich – Aktor – obrazuje osobę lub urządzenie korzystające z systemu. Drugi artefakt, to Przypadek użycia (ang. Use Case) odzwierciedla on funkcję systemu, którą wykorzystuje Aktor. Należy zaznaczyć, że aktor jest zawsze na zewnątrz Systemu, a Przypadek użycia obrazuje to, co się dzieje wewnątrz.

Realizacja funkcji systemu – aby dowiedzieć się jak działa dana funkcja systemu niezbędny jest opis danego przypadku użycia. Służą do tego scenariusze. Można je opisywać za pomocą języka naturalnego, lub skorzystać z części UML jaką są diagramy aktywności.

Narzędzi informatycznych wspierających opisywanie systemów za pomocą języka UML jest mnóstwo. Niektóre próbują nawet (z lepszym lub gorszym skutkiem) z takiego opisu generować gotowy kod systemu lub przynajmniej szkielet kodu, który później programista może uzupełnić.

Ciekawa nisza

Z punktu widzenia planowania kariery zawodowej, niewątpliwie warto rozważyć karierę analityka systemowego. Jeśli już przepracujemy przed ekranem monitora wiele godzin i przejdzie nam ochota na poznawanie kolejnego rewolucyjnego języka programowania warto rozważyć pracę bliżej biznesu. Dzięki temu można poznać wielu ciekawych ludzi, a charakter tej pracy da nam również możliwość poznania wielu dziedzin biznesowych, bo przygotowując wymagania na system informatyczny można naprawdę dużo dowiedzieć się o tym jak działają nawet najbardziej złożone organizacje.

Jeśli więc lubisz technologię i nie chcesz się z nią całkowicie rozstawać, a jednocześnie chciałbyś poszerzać swoje horyzonty, polecam zajęcie analityka systemowego. Może się okazać, że z czasem zagniesz swoją wiedzą o bankowości niejednego bankowca, a o księgowości niejednego księgowego.