o modelowaniu procesów i systemów 

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.

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.

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)

Celem modelowania biznesowego jest:

• zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia,
• ocena wpływu zmiany w organizacji,
• zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób,
• wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację,
• zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasuje się w organizację.

Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji. Jedną z technik prezentacji dynamiki i struktury firmy  jest język UML.

Czasami dostaję pytanie: Ile kosztuje modelowanie w UML? Moja odpowiedź brzmi: Dużo, ale koszty się zwracają z zyskiem. Skąd ten zysk skoro modelowanie w UML to czas ludzi, którzy zamiast pisać kod siedzą i modelują a od tego kodu nie przybywa. Moi rozmówcy mają obawy, że to korzystanie z UML wydłuża proces budowy oprogramowania. Pozornie tak i pewnie, można zacząć od razu budować kod (wiele firm działa tak z powodzeniem do dziś), tylko dlaczego jak budujemy dom to najpierw go planujemy? Przecież można włączyć betoniarkę, kupić cegły i do dzieła. Ale my najpierw planujemy dom, może po to by się nie zawalił, może po to by spełniał nasze oczekiwania. Potem jak zatwierdzimy plany to w trakcie budowy są oczywiście pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd. itp.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. W pisaniu kodu często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Oszczędność o której pisałem na początku to czas jaki tracimy na poprawianie (lub pisanie od nowa) źle funkcjonujących komponentów.  Dziwne jest czasem dla mnie to, że przy budowie domu zatrudnia się obligatoryjnie architekta który go planuje (lub kupuje gotowy projet), a przy budowie oprogramowania, które jest dużo bardziej skomplikowane oszczędza się na projekcie.  Na szczęście moi klienci już dojrzeli korzyści z modelowania i dzięki temu mam co robić bo modelowanie w UML nie musi być ani czasochłonne, ani trudne i kosztowne. 

Panuje powszechna opinia, że modele wyrażone w języku UML są niezrozumiałe i nie wiadomo jak go stosować. Problem czytelności diagramów jest tym bardziej istotny, gdy dokumentacji (jakże pieczołowicie) wykonanej w UML nie umie przeczytać Klient. Tak to problem, z którym czasem się spotykam. Wtedy zanim Klient zobaczy wartość modelowania  pozwalam nazywać poszczególne elementy notacji tak jak je nazwał klient przy zachowaniu odpowiedniego znaczenia tego elementu. I tak przykładowo aktor na początku nazywany jest ludzikiem z czasem jest nazywany systemem lub użytkownikiem by potem gdy klient wdraża już UML?a na stałe nazwać go poprawnie aktorem. Oczywiście pilnuję by znaczenie aktora na diagramach przypadków użycia nie zostało zniekształcone.  Ta metoda sprawdziła mi sie w u większości klientów, którzy nie używali UML. Niestety nie u wszystkich

Na koniec została sprawa jak stosować UML i kiedy? Nie ma jednoznacznej odpowiedzi na ten temat, gdyż użycie języka UML zależy od specyfiki realizowanego projektu, etapu na którym się ten projekt znajduje, czy znajomości języka UML przez różne osoby zaangażowane w dany projekt. Z tego też powodu potrzebne jest pewne doświadczenie. Ale jak zdobyć to doświadczenie, gdy książki mówią o notacji UML a nie o tym jak go stosować a przykłady z Internetu też są banalne? Na początek proponuję konsultacje u doświadczonej osoby, która ma za sobą kilka projektów z wykorzystaniem UML. Byłoby rewelacyjnie gdyby taka osoba nadzorowała nasze prace – była takim Aniołem Stróżem UML. Myślę, że takie spotkania dadzą więcej niż nawet kilkudniowe szkolenie.

Czy warto znać UML? Myślę, że tak tym bardziej, że zdaniem Instytutu Gartner’a w 2006 roku z języka UML korzystało ponad 10 milionów specjalistów z branży IT. Gartner szacuje, że w 2008 r. ok. 70% organizacji związanych z wytwarzaniem oprogramowania korzysta z UML. Więcej na temat przyszłości modelowania można przeczytać w artykule Andrew Watson’a (http://www.uml.org/Visual_Modeling.pdf). Polecam ten tekst.

Niniejszy artykuł napisałem kilka lat temu i w oryginale został wydany w Software Developer’s Journal Extra nr 18, (IBM Software Development Platform  Projektowanie SI, str.  34-38,   ISSN:1734-7661) w 2005 roku. Tekst publikuję, gdyż tego wydania nie ma już na rynku a opisana sposób postępowania jest nadal w miarę aktualny.

W artykule zaprezentowano zestaw kolejnych kroków, które prowadzą od projektu wyrażonego w języku UML do implementacji w języku JAVA aplikacji – książki adresowej, która dane kontaktowe przechowuje w pliku XML. Do budowy oprogramowania wykorzystano IBM Rational Software Architect. W kolejno wykonywanych krokach najpierw zostanie zbudowany model w języku UML 2.0 a następnie na podstawie modelu zostanie zaprezentowana implementacja w języku JAVA fragmentu aplikacji. Tekst z racji swojej obszerności podzieliłem na 3 części:

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy

• Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – implementacja

miłej lektury

Pierwszym krokiem po włączeniu Rational Software Architect’a jest wybór miejsca, w którym znajdować się będzie nasz projekt (ang. workspace). W tym przypadku zamiast domyślnego katalogu umieścimy nasze rozwiązanie w katalogu Projekt

przeczytaj pozostałą część »

Po zdefiniowaniu wymagań (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia ) na system przychodzi kolej na modele, które opiszą nam z jakich elementów jest zbudowany system i jak te elementy ze sobą współpracują. Modele te buduje się w modelu analizy (ang. Analysis Model), który należy dodać do naszego projektu w sposób podobny jak to miało miejsce z modelem przypadków użycia z tym, że wybierany jest szablon Analysis Model. W tym miejscu należy wspomnieć, że model analityczny jest opcjonalnym elementem projektu. W przypadku prostych modeli można od razu budować model projektu. W naszym przypadku dla celów edukacyjnych zbudujemy ten model by następnie uszczegółowić go w modelu projektu.

W zdefiniowanym modelu analitycznym w katalogu Analysis Building Block należy utworzyć realizacje przypadków użycia. Realizacje to są elementy współpracy (ang. Collaboration), które powinny nosić nazwę przypadku użycia, którego są realizacją. Elementy współpracy jest to jeden z elementów języka UML 2.0 i dodaje się go poprzez menu kontekstowe, które jest uruchamiane prawym klawiszem myszy.

przeczytaj pozostałą część »