| UML w ramach metodyk wytwarzania oprogramowania, cześć 2 |
|---|
| Napisane przez Mon 02 Oct 2006 przez Artur (2913 cztane) |
|
UML w ramach metodyk wytwarzania oprogramowania (cz.2 - metodyki pośrednie) Autor: Tomasz Para Artykuł ten nie ma na celu nauki UML (a wręcz zakłada jego znajomość). Jego celem jest ukazanie jak UML jest stosowany w różnych metodykach. Ze względu na obszerność tematu, zostaną tutaj tylko pokrótce zaprezentowane zagadnienia związane z UML, a nie techniki prowadzenia tychże metodyk (zainteresowani zgłębieniem wiedzy będą musieli sięgnąć do literatury specjalistycznej). Do najbardziej rozpowszechnionych metodyk pośrednich należy metodyka ICONIX. Plasuje się ona pomiędzy rozbudowanym RUPâem, a minimalistycznym XP. Jest to metodyka typu „Use-Case Driven” - tak jak RUP, ale bez nadmiarowości jaką on wnosi. Jest to metodyka mocno porządkująca i upraszczająca korzystanie z UML. Zasada zdefiniowana przez trzech amigos mówi: „Można wymodelować 80% problemów, używając 20% UML”. Niestety nie określa, których 20% należy używać. Metodyka ICONIX właśnie stara się określić o które 20% chodzi. Definiuje ona kluczowy podzbiór najważniejszych i najpotrzebniejszych elementów języka UML oraz określa sposób i kolejność ich używania w trakcie prowadzenia projektu (skupia się na obszarze znajdującym się pomiędzy przypadkami użycia, a kodem). Zestaw ten został wypracowany praktycznie na przestrzeni dziesięciu lat i setek projektów informatycznych. Oczywiście uproszczenie zbioru elementów UML wymaga spełnienia pewnych założeń, przed rozpoczęciem projektu prowadzonego wg tej metodyki. Do głównych trzech założeń należą: - przeprowadzenie prototypowania, - posiadanie wstępnych projektów interfejsu, - zidentyfikowanie ogólnych przypadków użycia w systemie. Po spełnieniu tych wstępnych warunków, można przystąpić do procesu wytwórczego oprogramowania określonego przez metodykę ICONIX. Zakłada ona, że model projektowy będzie się składał z dwóch części: - dynamicznej, - statycznej, a kolejne etapy tworzenia tego modelu są określone w specyfikacji (rys. 1) Rys. 1 Schemat metodyki ICONIX Jak widać, cały proces wytwórczy zawiera się w pięciu typach diagramów: - model przypadków użycia - robustness diagram (niestety nie funkcjonuje odpowiednik polski tej nazwy) - diagram sekwencji - model dziedziny (domain model) - diagram klas Porównując z RUP, który tylko na samym etapie analizy miał 5 różnych diagramów, ten zestaw wygląda bardzo skromnie, ale przez to jest właśnie szybki i łatwy w opanowaniu. Zapewne wszystkie typy diagramów są dobrze znane z wyjątkiem jednego: robustness. W wyniku wspólnych prac trzech amigos, nie został on włączony do głównego standardu UML, ale ostatecznie znalazł się w załączniku do UML pt: „Objectory Process-Specific Extension”. Jego głównym zadaniem jest pomoc w przejściu od przypadków użycia do diagramu sekwencji. Prześledźmy krok po kroku proces postępowania według metodyki ICONIX. 1) Cały proces rozpoczyna się od modelu dziedziny (można to uznać za pewien rodzaj glosariusza dotyczącego pojęć związanych z naszym problemem - innymi słowy jest to zestaw najważniejszych pojęć opisujących dziedzinę problemu). Dzięki takiemu zdefiniowaniu pojęć możemy uniknąć niejednoznaczności opisów przy tworzeniu przypadków użycia. W ujęciu UML model dziedziny jest to bardzo ogólny diagram klas, pozbawiony atrybutów i operacji poszczególnych klas (przykład na rys.2). Rys. 2 Model dziedziny 2) Drugim etapem jest etap tworzenia przypadków użycia. Zawiera się w tym zarówno opis słowny jak i graficzny diagram (rys 3). Rys. 3 Diagram przypadków użycia 3) Etapem ułatwiającym przejście z diagramu przypadków użycia do diagramu sekwencji jest robustness analysis. Jej rezultatem jest robustness diagram, który jest podobny do diagramu współpracy, ale jego anatomiczna budowa bazuje na diagramie klas. Tyle, że zamiast normalnych klas UML używamy trzech typów obiektów (rys. 4): - boundary, - entity, - control, Rys. 4 Obiekty na robustness diagram Każdy przypadek użycia posiada co najmniej jeden diagram tego typu. Komunikacja na tym diagramie podlega ścisłym regułom (rys. 5). Rys. 5 Reguły komunikacji na diagramie robustness Przykładowy diagram na rys. 6. Rys. 6 Robustness diagram 4) Następnie bazując na robustness diagram tworzymy tradycyjny diagram sekwencji. Obiektom ujawnionym na robustness diagram powinniśmy teraz przypisać odpowiednie zachowania (operacje) i umieścić nowe informacje na diagramie sekwencji. 5) Ostatnim etapem przed kodowaniem jest zbudowanie modelu klas tworzonego systemu w oparciu o wcześniej zebrane informacje. Jak więc można zauważyć, proces ICONIX w bardzo dużym stopniu bazuje na diagramach UML, definiując optymalny ich zestaw do wykorzystania oraz ścieżkę ich użycia. ICONIX nie narzuca żadnych wymagań co do tworzenia dokumentów tekstowych (nie są one wymagane do procesu), sugerując jedynie, aby były one krótkie i zwięzłe, pozbawione nadmiarowych informacji (np. za zbyt rozbudowane uznaje wzorce przypadków użycia stosowane w RUP). Zainteresowani jak dokładnie przeprowadzić proces ICONIX powinni sięgnąć do książki: „Applying Use Case Driven Object Modeling with UML” D. Rosenberg, K. Scott. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.