Archiwalne tagi Unified Modeling Language

Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście modelowania procesów biznesowych i systemowych (patrz tekst:  Diagramy procesów systemowych). Oba diagramy bardzo podobne do siebie choć BPMN 2.0 to już mega możliwości. Myślę, że kluczem do decyzji jest zastosowanie (czyt. Twoje potrzeby)

Lubię używać diagramów aktywności gdy:

Kilkanaście dni temu  opublikowałem 5 wskazówek dla analizy w ujęciu AGILE Scotta Amblera. Chciałbym je teraz uzupełnić o kolejne spostrzeżenia. Tym razem dotyczące przede wszystkim modeli.

1. Modele z czasem ewoluują
Możesz zacząć od podstawowego przypadku, ale szybko postanowisz przekształcić go w kilka systemowych przypadków użycia. Możesz również postanowić opracować zbiór diagramów Object-Role Model (ORM) umieszczone na białej tablicy jako wkład w diagram klas UML, który z kolei przekształci się w kod źródłowy.

2. Modele analiz muszą być jedynie wystarczająco dobre

Staraj się, aby twoje modele były jak najbardziej proste i o lekkiej konstrukcji. Skup się na zrozumieniu, nie na dokumentacji. Użyj najprostszych i najbardziej ogólnych z dostępnych narzędzi. Zdaj sobie sprawę z tego, że Twoje modele nie muszą być doskonałe.

Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one:

1. Aktywny udział osób zainteresowanych jest najbardziej istotny
Musisz ściśle współpracować z osobami zainteresowanymi w celu szczegółowego zgłębienia domeny biznesowej. Osoby zainteresowane powinny dostarczać informacji, modelować wraz z Tobą, dostarczać opinie i w odpowiedniej chwili podejmować decyzje.

2. Tworzenie oprogramowania zgodnie z metodą agile to proces ewolucyjny

Kiedy modelujesz analitycznie podczas projektu agile, zazwyczaj skupiasz się na małym podzestawie wymogów naraz. Na przykład, w przypadku projektu XP, Ty i Twój partner od programowania możecie pracować razem z udziałowcem projektu w celu przeanalizowania pojedynczej user story, jednej z setek, a następnie przejść do jej zaprojektowania i wdrożenia. Taka analiza zazwyczaj zabiera kilka minut, w zależności od natury user story, tyle samo zabiera projektowanie. Następnie spędzasz klika godzin na wdrażaniu wymogu tylko po to, aby móc zacząć od nowa z nową user story. Inne podejścia agile, jak np. Feature-Driven Development  mogą wymagać nieco więcej czasu dla analizy i projektowania, ale i tak będą działać w ten sam, ewolucyjny sposób.

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…

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…

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…

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…

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ąć…

Close