| UML w ramach metodyk wytwarzania oprogramowania |
|---|
| Napisane przez Sun 17 Sep 2006 przez Artur (3737 cztane) |
|
UML w ramach metodyk wytwarzania oprogramowania (cz.1 - metodyki ciężkie) Autor: Tomasz Para Artykuł ten nie ma na celu nauki UML (a wręcz zakłada jego znajomość). Jego celem jest naświetlenie pewnych spraw i problemów związanych z używaniem UML. Ze względu na obszerność tematu, zostaną tutaj tylko pokrótce zaprezentowane zagadnienia związane z tymi problemami, a zainteresowani zgłębieniem wiedzy będą musieli sięgnąć do literatury fachowej. Często się zdarza, że dopiero co opanowawszy język UML, jego poszczególne składowe i diagramy, jesteśmy w stanie wymodelować zadany problem w wybranym diagramie. Dostajemy zadanie zrobienia przypadków użycia dla księgarni internetowej - żaden problem; diagram klas dla oprogramowania HR - zaraz będzie gotowy; diagramy sekwencji, aktywności, współpracy, itd. nie mają przed nami żadnych tajemnic. Wszystko jest w najlepszym porządku aż do momentu gdy sami mamy wymodelować system. I tu pojawią się pytania: od czego zacząć, w jakiej kolejności wykonywać kolejne diagramy, komu przekazywać rezultaty prac, itd. Czujemy się jak pomocnik stolarza, który umie obsługiwać wszystkie narzędzia w warsztacie, ale sam nie potrafi zbudować żadnego mebla. Tak właśnie wygląda praca analityka, który zna tylko UML, ale nie wie w jakim kontekście może go używać. W tym momencie z pomocą przychodzą metodyki wytwarzania oprogramowania (czyli zbiory reguł, określające przebiegi poszczególnych etapów procesu wytwórczego oprogramowania). Jako że metodyki te określają cały cykl wytwórczy (od fazy koncepcji poprzez wykonanie aż do testów i wdrożenia), a niniejszy artykuł dotyczy UML, więc skupimy się na tych fazach poszczególnych metodyk, w których UML występuje. Oczywiście jak to w życiu bywa, nie powstała jedna metodyka, ale wiele różnych - każda ze swoimi wadami i zaletami, każda mająca swoich zwolenników i przeciwników. Ogólnie metodyki można podzielić na dwie główne grupy: - metodyki ciężkie - Prince II oraz Rational Unified Process (RUP) - zbiory reguł wytwarzania oprogramowania z dużym naciskiem na dokumentowanie każdego posunięcia, - metodyki lekkie (zwinne) - np. eXtreme Programing, SCRUM, Crystal Methods, których podstawowym założeniem jest postawienie nacisku na produkcję działającego oprogramowania, a nie dokumentowanie go. Metodyki lekkie są ponadto nastawione na zmianę i zarządzanie nią. Poza wyżej wymienionymi grupami jest jeszcze trzecia, pośrednia grupa do której należy np. metodyka ICONIX. Metodyki z tej grupy starają się być szybkie i elastyczne (jak metodyki lekkie), a jednocześnie dobrze dokumentować projekt (jak metodyki ciężkie). Nie ma idealnej metodyki ani nawet najlepszej, która dawałaby za każdym razem najlepsze rezultaty spośród wszystkich metodyk. Optymalnie należałoby dopierać metodykę pod kątem prowadzonego projektu, ale opanowanie tylu metodyk i prowadzenie różnych projektów różnymi metodykami wiązałoby się z ogromnymi kosztami w firmie i zapewne pewnym chaosem organizacyjnym. Dlatego zazwyczaj firmy wdrażają jedną metodykę i ją stosują do wszystkich prowadzonych przez siebie projektów informatycznych. Na początek skupmy się na metodykach ciężkich (a konkretnie na metodyce RUP firmy IBM). Metodyka RUP definiuje zakres prac i odpowiedzialności dla każdego uczestnika projektu. Za pomocą interaktywnej pomocy w każdej chwili można sprawdzić jaki powinien być kolejny krok pracy dla wybranej osoby. Nas oczywiście najbardziej interesuje zakres prac analityka (bo to on przecież najwięcej posługuje się UML). Na rys. 1 przedstawiono zadania za które jest odpowiedzialny analityk systemowy oraz artefakty (dokumenty, wytwory) które powinny być rezultatem jego działań. Rys. 1 Zadania dla analityka systemowego wg RUP Na podstawie tego schematu oraz reguł zawartych w pomocy RUP, można określić następujący plan prac związanych z analizowaniem systemu: 1. Zdefiniowanie dokumentu Requirements Management Plan. 2. Opracowanie dokumentu Vision, w tym: a) Zebranie potrzeb udziałowców; b) Powiązanie potrzeb udziałowców z funkcjami systemu 3. Opisanie działania systemu za pomocą przypadków użycia i scenariuszy 4. Opracowanie diagramów obrazujących budowę i działanie systemu: a) przypadków użycia b) klas c) sekwencji d) współpracy e) aktywności Jak łatwo zauważyć, w metodyce tej UML pojawia się stosunkowo późno (punkt 4 - diagramy). Wcześniej prowadzona jest zwyczajowa analiza wymagań klienta, ale jej wyniki są zapisywane w formie tekstowej (m.in. scenariusze przypadków użycia). Dopiero z tych scenariuszy wyprowadzamy diagram przypadków użycia. Po przypadkach użycia zajmujemy się diagramem klas, a następnie bazując na nim budujemy diagramy sekwencji, a z nich możemy wygenerować diagram współpracy. Na koniec zostaje do wykonania diagram aktywności. Cały czas bazujemy na podstawowych elementach UML zgodnie z jego zasadami i w tej metodyce nie zachodzą żadne modyfikacje tego języka. Gdyby pominąć elementy tej metodyki niezwiązane z UML, to można zauważyć, że ogranicza się ona do określenia kolejności stosowania poszczególnych diagramów oraz określenia źródła danych do tych diagramów. Metodyka ta najlepiej nadaje się do prac związanych z dużymi projektami informatycznymi. Lubią ją również początkujący analitycy, bowiem wskazuje im kolejne kroki ich pracy, a co najważniejsze pokazuje od czego zacząć. Oczywiście zgodnie z regułami RUP, szablon ten może być zmieniony i dostosowany do potrzeb danego projektu lub firmy. Ale przed wprowadzeniem jakichkolwiek zmian, należy pamiętać, że schemat ten został wypracowany na podstawie doświadczeń i analizy innych projektów i zapewnia najbardziej zoptymalizowaną ścieżkę prac analityka. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.