o modelowaniu procesów i systemów 

Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji pod adresem:

http://msdn.microsoft.com/en-us/library/dd380647.aspx

Szczególnie polecam rozdział 4.4 Use Models in Agile Development.

Jest rewolucja. I to nie mała. Otóż firma Microsoft w ramach Visual Studio z premedytacją omijała aspekt wizualnego projektowania sytemu przy użyciu UML. Aż do teraz.

W nowej wersji VS 2010 jest VS2010 Visualization and Modeling Feature Pack (http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx), dzięki któremu można wytwarzać modele na różnym poziomie abstrakcji i w konsekwencji synchronizować je z kodem aplikacji.

Przełom jest tym większy, że Microsoft proponuje tylko te techniki modelowania, które są uważane za składniki zwinnego modelowania (ang. Agile Modeling). 

Zmiany w oprogramowaniu i modelach są nieuniknione. Poniżej kilka słów na temat jak je przedstawić w EA i jak je raportować.

Przyjąłem, że zmiany dotyczą zmian w istniejącym już oprogramowaniu.

Zmiana jest zgłoszona w dowolnej formie przyjętej w organizacji natomiast w Enterprise Architect jest reprezentowane jako wymaganie, zmiana lub defekt (problem)

Wszystkie wymagania i elementy, które mają znaleźć się w kolejnym wydaniu powinny dostać odpowiedni numer wersji, np.: 1.1

przeczytaj pozostałą część »

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.

Na stronach producenta Enterprise Architecta można znaleźć instukcję jak  zainstalować EA pod linuxem używając Crossover. Niestety Crossover jest płatny, co prawda 70$ za licencje Crossover to może nie majątek, ale zawsze to dodatkowy wydatek. Poniżej tekst jak zainstalować Entrprise Architecta bez Crossover. Tutorial oprałem na popularnej dystrybucji Ubuntu 9.10- the Karmic Koala, ale powinno działać na innych systemach operacyjnych spod znaku pingwina.

Krok 1. Uśmiechnij się instalacja EA zajmie ok. 15 minut w zależności od szybkości łącza internetowego. Trzeba wykonać 7 kroków a pierwszy już za Tobą.

Krok 2. Instalujemy wine

Krok 3. Ściągamy winetrics

przeczytaj pozostałą część »

Ostatni czwartek i piątek spędziłem wspomagając bardzo ciekawą firmę. Otóż jest to Polska firma pisząca systemy wspierające szerokorozumianą e-administrację. Nasuwa sie pytanie a gdzie są te systemy? Otóż w USA. Tak tak Polskie, niewielkie, firmy mogą pisać oprogramowanie wspierające obywateli innych Państw. A my, obywatele 4,5,6 RP jesteśmy gorsi? Myślę, że nie ale za to bardziej specyficzni bo u nas znów ogłoszony zostanie przetarg, do którego będą mogły przystąpić (czyt. będą spełniać warunki formalne) 3-4 firmy, potem lista odwołań, i? kolejny przetarg? ach szkoda pisać. Nawiasem mówiąc to kolejna średniej wielkości firma w Polsce, z którą miałem okazję współpracować, która robi rzeczy wielkie. Szkoda, że są one niedoceniane na rynku lokalnym bo mało jest firm, które mają doświadczenie zdobyty w kilkunastu zagranicznych projektach.

Na koniec pragnę tylko pochwalić się, że jako konsultant otrzymałem dobre i bardzo dobre noty. Dziękuję.

Kilka tygodniu temu (http://www.wolski.waw.pl/2009/07/kkio-2009/) zapowiedziałem swój udział na Krajowej Inżynierii Oprogramowania. Tak tez się stało. 15 września w trakcie sesji pt: ?Modelowanie systemów? miałem okazję zaprezentować zarys metodyki WMB ( http://www.wolski.waw.pl/wmb/).

Moje wystąpienie na temat ?Zwinnego modelowania wymagań biznesowych w wytwarzaniu oprogramowania? spotkało się się z życzliwym przyjęciem uczestników  XI Krajowej Konferencji Inżynierii Oprogramowania, które zaowocowało żywą dyskusją.

Na koniec dodam, że moje wystąpienie było afiliowane i wykonane na rzecz firmy, w której jestem konsultantem, co uczyniło ją jedną z nielicznych firm komercyjnych, które poddały swoje nowatorskie rozwiązania z zakresu inżynierii oprogramowania ocenie niezależnych ekspertów z tej dziedziny.

Publikacja, która ukazała się jako rozdział w książce (okładka poniżej),  świadczy o pozytywnej recenzji i akceptacji drogi rozwoju jaka została obrana w obszarze zwinnego modelowania.

Długość iteracji i jej wielkości pod względem zasobów musi być skorelowana z celami i pracą, które ma być wykonana. Moje wytyczne:

Wielkość zespołu – większe zespoły wprowadzają większe koszty stałe i tym samym prowadzą do dłuższej iteracji. Następujące wytyczne zapewniają przydatny punkt wyjścia:

• 2 – 15 osób: iteracja 2-4 tygodniowa
• 16 – 30 osób: iteracja 4-6 tygodniowa
• 31 – 50 osób: iteracja 6-8 tygodniowa.

Cele iteracji – niektóre cele wymagają więcej czasu na ukończenie niż inne

Wielkość kosztów stałych – im więcej sprawozdawczości oraz innych przeciążeń administracyjnych, które są nakładane na zespół, tym dłuższe będą musiały być iteracje

Podział zespołu – im bardziej podzielony zespół, tym trudniejsza komunikacja oraz tym więcej czasu zajmie uzgodnienie decyzji prowadzących do zwiększonego poziomu planowania i dokumentowania oraz dłuższych iteracji

Dostępność zasobów – Im mniej czasu, który członkowie zespołu  mają przeznaczyć na projekt, tym więcej czasu upłynie na iteracje

Formalność projektu – niektóre projekty mają bardziej surowe wymogi odnośnie przeglądów formalnych i dokumentacji projektowej, wymagając więcej czasu na te czynności

W wielu firmach używane są równolegle maszyny z zainstalowanymi: Windowsem i Linuxem. Dość powszechny Enterprise Architect nie pozwala na wydajną pracę w środowisku Linux. W takiej sytuacji polecam produkty Visual Paradigm. Osobiście przetestowałem i uważam, że do większości projektów jest to narzędzie wystarczające i daleko bardziej użyteczne niż open source?owe programy takie jak Umbrello czy Dia.

Jeśli jednak można korzystać ze środowiska Windows to oczywiście polecam Enterprise Architecta

Model to nic innego jak reprezentacja pewnej rzeczy lub systemu charakteryzującego się miedzy innymi tym, że model:

• jest podobny do modelowanej rzeczy lub systemu gdyż różni się pod względem skali lub zachowania
• można go weryfikować, gdyż jego zachowanie odpowiada zachowaniu oryginału
• można przewidzieć złożoność oryginału, gdyż ma zachowaną jego strukturę na odpowiednim poziomie złożoności

W związku z powyższym warto budować modele oprogramowania, gdyż dzięki nim możemy poznać zachowanie i strukturę docelowego produktu.

W artykule zaprezentowano jak rozpocząć pracę z

i opis elementów tego narzędzia CASE.

Środowisko IBM Software Development Platform (SDP) o nazwie kodowej „Atlantic”, tworzy platformę współpracy dla zespołów deweloperskich w ramach środowiska Eclipse oraz pozwalają łączyć funkcje biznesowe, rozwojowe i operacyjne w ramach organizacji. Jednym ze składników SDP jest IBM Rational Software Architect (RSA) – zintegrowane narzędzie projektowe i programistyczne, które umożliwia wykorzystanie techniki programowania modelowego w języku UML do opracowywania dobrze zaprojektowanych aplikacji i usług.

Co to jest Rational Software Architect?

IBM Rational Software Architect jest nowoczesnym pełnym środowiskiem rozwoju aplikacji, które umożliwia projektowanie w języku UML 2.0 aplikacji oraz jej implementację. RSA jest to zbiór szeregu narzędzi (Rysunek 1), wspierających procesy wytwórcze systemów informatycznych.

Rysunek 1 Komponenty IBM Rational Software Architect’a

Każdy z przedstawionych komponentów RSA wspiera twórców oprogramowania w określonej dziedzinie.

Software Modeler to narzędzie do wizualnego modelowania i projektowania aplikacji, które pozwala efektywnie wykorzystywać standard UML 2.0, do komunikowania i dokumentowania tworzonych rozwiązań. Wspomaga analizę i projektowanie.

Web Developer jest przeznaczony dla twórców aplikacji web, zorientowanych na tworzenie dynamicznych stron WWW, Web Services. Web Developer jest łatwym w użyciu wizualnym narzędziem, które efektywnie utylizuje standardy JSF, EGL.

IBM Rational Application Developer for WebSphere Software stanowi wszechstronne, zintegrowane środowisko programowania (IDE), które pozwala szybko projektować, tworzyć, analizować, testować, profilować i wdrażać aplikacje internetowe i portalowe, aplikacje w technologii Java i J2EE oraz aplikacje wykorzystujące Web Services.

Zaprezentowana krótka charakterystyka komponentów składowych RSA pozwala pozycjonuje to narzędzie w grupie zaawansowanych produktów deweloperskich.

Instalacja

Instalację Rational Software Architect?a należy zacząć od sprawdzenia czy maszyna, na której chcemy zainstalować to środowisko projektowo programistyczne podoła wymaganiom sprzętowym i programowym. RSA wymaga minimalnie:
- procesora Intel(TM) Pentium(R) III 800 MHz (zalecany jest większy)
- pamięci RAM 768 MB (zalecany jest więcej)
- 3 GB wolnego miejsca na dysku twardym

Są to dość duże wymagania zwłaszcza odnośnie pamięci RAM i może być odrobinę kłopotliwe dla posiadaczy trochę starszych komputerów.

Jeśli chodzi o system operacyjny to ucieszą się zapewne miłośnicy Linuksa, gdyż RSA jest dostępny zarówno na platformę Windows jak i Linux. W artykule tym opisane zostanie instalacja w środowisku Windows. Tyle tytułem wstępu.

Zanim zaczniemy instalację musimy posiadać minimum 2 pliki. Pierwszy z nich jest programem rozpakowującym (extractor.exe), a drugim jest plik z rozszerzeniem .blin (*.bin), który zawiera pliki RSA (core installation files). W opcji można zainstalować także: Rational Software Architect Language Pack, Enterprise Generation Language (EGL), WebSphere Application Server V6.0 Test Environment, Agent Controller, WebSphere Portal Runtime Environment.

Program instalacyjny uruchamiany jest w dwóch etapach. W pierwszym uruchamiane jest program inicjujący instalację (rozpakuje pliki z RSA i opcjonalne komponenty). Drugi etap to właściwa instalacji Rational Software Architect?a. W czasie instalacji należy wybrać komponenty, które chcemy zainstalować (Rysunek 2). Instalacja RSA przebiega bez większych trudności, choć czasem komputer może sprawiać wrażenie, że się ?zawiesił?.

Rysunek 2. Wybór komponentów podczas instalacji RSA

Uruchomienie środowiska

Podczas uruchomienia Rational Software Architect’a proszeni jesteśmy o określenie katalogu (workspace). W którym przechowywane będą projekty. (rys 2)

Rysunek 3. Projekty w RSA

Rational Software Architect oferuje szereg szablonów projektowych. W zależności od potrzeb można projektować w UML, budować rozwiązania w Java, EJB, J2EE, C, C++. Z racji tego, że RSA jest bazuje na środowisku Eclipse i języku Java to umożliwia budowę rozwiązań uniezależnionych od platformy w tym pozwala na budowę szeregu aplikacji dedykowanych do pracy w środowisku Internet.

Rysunek 4. Projekty w RSA

Każdy wybór projektu uruchamia odpowiedni kreator projektu, podczas pracy którego należy podać nazwę projektu, określić miejsce położenia projektu (jeśli jest inne niż domyślna przestrzeń). W tak zdefiniowanym projekcie można już budować system.

Rational Software Architect, zwłaszcza początkującego twórcę systemów informatycznych, może przytłoczyć nadmiarem obszarów(Rysunek 5). Początkowy chaos widoków w miarę poznania środowiska przekształca się w miarę uporządkowany zestaw pomocnych informacji, z których w zależności od wymagań i upodobań można korzystać lub nie.

Rysunek 5. Widok projektu w RSA

W poniższej tabeli bardzo skrótowo omówiono znaczenie najważniejszych okien (dla porządku otrzymały one kolejne numery)

numer okna

opis

zdjęcie

1

Navigator- stanowi repozytorium artefaktów projektu. Można w nim stosować takie elementy jak klasy, foldery, pliki. Jest to główny element nawigacji projektem. Dodatkowo uwidacznia (elementy z krzyżykiem), które są niepoprawne

2

Edytor kodu jest miejscem, które służy do wpisywania kodu źródłowego aplikacji. Kolorowanie składni oraz podświetlanie błędów w składni programu to jego niewątpliwe zalety.

3

Właściwości (Properties) zawiera informacje o pliku, w którym istnieje edytowana klasa.

4

Konsola (Console) zawiera informacje o kompilacji programu lub o jego działaniu

5

Eksplorer pakietów (Package Explorer) zawiera informacje o umiejscowieniu klas i metod w konkretnych plikach

6

Problem ? obszar odpowiedzialny za wyświetlanie informacji o występujących błędach lub problemach z budowana aplikacją.

W tabeli 1 umieszczono najważniejsze widoki z jakich korzystać może użytkownik RSA.

Narzędzie uruchomione. W kolejnym artykule zostanie przedstawiony sposób projektowania w RSA

Artykuł napisano w 2005 roku. Od tego czasu wiedza i narzędzia mogły ulec zmianie.

Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie.

W tym przedsięwzięciu miałem swój skromy udział. Wystąpiłem z prezentacją możliwości wykorzystania w biznesie języka UML za pomocą modeli zbudowanych w Rational Software Architect. Moja prezentacja pt.: "Praktyczne wykorzystanie języka UML w Model Driven Development (MDD)" została wzbogacona o praktyczny przykład wykorzystania UML w MDD.

Prezentacja spotkała się z przychylnym przyjęciem słuchaczy (oceny w skali 1-5) – ważność tematu – 4,25; przygotowanie konsultanta – 4,58; sposób prezentacji tematu – 4,67. Największa dyskusja wywiązała się pomiędzy prelegentami