napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, wydarzenia
piątek 31 paź 2008
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.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
piątek 31 paź 2008
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:
miłej lektury 
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
piątek 31 paź 2008
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ęść »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
piątek 31 paź 2008
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ęść »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
piątek 31 paź 2008
Po zbudowaniu modelu analitycznego (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model analizy), który powstał na podstawie modelu przypadków użycia (Projekt i implementacja aplikacji JAVA w środowisku IBM Rational Software Architect – model przypadków użycia) można przejść do budowy modelu projektowego, który w naszym przypadku, będzie podstawa do wygenerowania szkieletu kodu aplikacji. Pierwszym krokiem tego etapu będzie dodanie do naszego projektu pustego szablonu projektowego, który będzie podstawą do zbudowania modelu projektu. Model ten dodaje się w sposób analogiczny jak poprzednie modele.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii modelowanie biznesowe, o inżynierii oprogramowania, szkolenia, teksty
środa 22 paź 2008
Modelowanie procesów biznesowych odgrywa co raz większe znaczenie. Wiele organizacji, które właśnie zamierzają wejść w świat modeli biznesowych ma problem jaki standard zapisu wybrać BPMN (Business Process Modeling Notation) czy UML (Unified Modeling Language)? Z tego też powodu i ja postanowiłem dorzucić swój kamyczek do ogródka. Na wstępie zaznaczam, ze znam obie notacje i poniżej reprezentuje tylko swoje subiektywne zdanie.
Niewątpliwie jest BPMN jest dedykowany do budowania modeli procesów biznesowych a UML jest dedykowany do modelowania systemów informatycznych, ale posiada dedykowane dla modelowanie procesów biznesowych rozszerzenie notacji. Wydawać się by mogło, że odpowiedź jest oczywista: modelowanie procesów biznesowych to BPMN, ale BPMN ma sporo ograniczeń w stosunku do UML. Oto kilka z nich:
-
BPMN modeluje tylko przepływy sterowanie a nie widać tu przepływu danych – w UML dane można zobrazować jako klasy i potem na diagramach aktywności pokazać je jako przepływ obiektów,
-
BPMN nie pozwala zamodelować struktury firmy – w UML są od tego diagramy pakietów
-
BPMN nie pozwala zamodelować hierarchii użytkowników – w UML za pomocą biznesowych aktorów i generalizacji można to zrobić
-
BPMN ma wiele elementów, które wymagają od osoby czytającej diagram znajomości niuansów BPMN – UML ma w modelu biznesowym mniej elementów notacji
-
znajomość notacji BPMN nie pozwala czytać modeli opisujących projektowany (lub działający) system informatyczny
-
BPMN oferuje jeden diagram do opisu organizacji – w UML można uzyskać opis organizacji z różnych perspektyw
BPMN w stosunku do UML ma też plusy:
Wybierając notację zapisu modeli biznesowych należy przede wszystkim zastanowić się do dlaczego chcemy modelować i do czego w przyszłosci będzie wykorzystywany model. Wydaje się mi ze ograniczenie zastosowanie notacji język UML dedykowanej dla modeli biznesowych w zakresie diagramów przypadków użycia, aktywności i klas oraz pakietów w zupełności pozwala odwzorować strukturę i czynności jakie realizuje prawie każda organizacja. Ponadto w przypadku decyzji o wsparciu wybranych obszarów firmy systemem informatycznym specyfikacja takiego systemu jest w znacznym stopniu gotowa. A to w wielu przypadkach wielkie oszczędności czasu i pieniędzy.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, wydarzenia
czwartek 9 paź 2008
Microsoft Technology Summit 2008 to kolejne miejsce spotkań technologii z jej praktyką – tym razem w wydaniu firmy Microsoft. W czasie pierwszego dnia miałem przyjemność być na rewelacyjnej prezentacji dot. zarządzania ryzykiem (Efektywne zarządzanie ryzykiem bez/z Team Foundation Server 2008?), którą prelegował Tadeusz Golonka. Już dawno nie zdarzyło mi się aby w przeciągu kilkudziesięciu minut otrzymać poważną dawkę wiedzy podany w sposób jasny i klarowny. Masa wskazówek, rozwiązań i praktycznych przykładów. Najważniejsze jest to, że mogłem zobaczyć i porównać swoje postępowanie jak zarządzać ryzykiem za pomocą arkusza kalkulacyjnego oraz narzędzi takich jak Team Foundation Server 2008. I nie chodzi tu o sztukę klikania a procedury postępowania i szacowania ryzyka w projektach IT tak by w czasie projektu nie mówić – “poprawimy w trakcie wdrożenia”.
napisane przez Michał Wolski | w kategorii wydarzenia
środa 8 paź 2008
Premiera Jazz i Rational Team Concert w Polsce (7 października 2008 w Centrum Artystycznym Fabryka Trzciny) to wydarzenie, którego nie mogłem opuścić. Dlaczego? Z pierwszych przecieków wynikało, że jest platforma firmy IBM, które ma być bazą do integracji zespołów projektowych na wszystkich obszarach procesu wytwórczego. Zacznę od tego czym jest JAZZ. Otóż produkt jest portalem współpracy przeznaczonym dla rozproszonych zespołów programistycznych, łączącym członków takich zespołów za pośrednictwem komunikatorów oraz maila.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 2 paź 2008
MDA jest podejściem, w którym UML jest traktowany jako język programowania. Głównym celem MDA jest tworzenia oprogramowania w oparciu o modele biznesowe oraz separacja modelu na zależny oraz niezależny od platformy. Dzięki MDA te same rozwiązania mogą być realizowane na wielu różnych platformach. Ponadto stworzone na bazie MDA systemy mogą być łatwo integrowane oraz łączone z innymi systemami. Nic nie stoi też na przeszkodzie aby ponownie używać opracowane rozwiązania.
Wyróżnia się cztery poziomy w MDA, ale najczęściej stosowane to:
-
Platform Independent Model (PIM), który można traktować jako abstrakcyjną specyfikację systemu, gdyż nie jest na tym poziomie wskazana konkretna platforma na której zostanie osadzone tworzone rozwiązanie,
-
Platform Specific Model (PSM), który jest modelem o najniższym poziome abstrakcji, odwzorowanym na konkretne rozwiązania wybranej platformy.
Transformacje są mechanizmem pozwalającym na transformowanie modeli jednego typu w drugi, również na różnych poziomach abstrakcji.
Rational Software Architekt posiada nie tylko możliwość budowania projektów w języku UML , ale także umożliwa wygenerowanie zrębów kodu źródłowego na podstawie modelu. Te transformacje to przede wszystkim możliwości generowania szkieletów kodu systemu za pomocą metod inżynierii wprzód oraz tworzenie na podstawie kodu aplikacji równoważnej mu specyfikacji wyrażonej w języku UML (za pomocą metod inżynierii wstecz).
przeczytaj pozostałą część »
