środa, 29 sierpnia 2007

Ankieta o UML oraz Unified Process

Jakiś czas temu otworzyłem na blogu ankietę, pytającą o stosunek do języka UML. Wyniki ankiety są wzorcowe, jeżeli można tak powiedzieć :) Oto one:

"UML...
- trzeba wszystko w tym modelować!!! - 0%;
- używać gdy potrzeba - 75%;
- jak muszę to używam - 12%;
- spalić na stosie specyfikację! - 12%.

Pierwszą opcję można było odebrać jako symbol procesu wodospadowego (liniowego), w którym najpierw wykonywało się drobiazgowy projekt, a następnie przekazywano do "produkcji" programistom. Oczywiście teraz już nikt tak nie robi :) Tak samo nie ma sensu wykonywać kompletnej dokumentacji w UML do wykonanego kodu - w końcu dobry kod sam się "komentuje". Drugą dostępną opcją w ankiecie było przesłanie Agile Development - tylko tyle UMLa, aby zrozumieć problem, nie więcej. Trzecia pozycja: "jak muszę to używam" to ukłon do programistów, którzy muszą dokumentować swoją twórczość w UMLu, a niezbyt im się to podoba ;) Ostatnia opcja... no cóż, w małych projektach zalety modelowania nie są aż tak dobrze widoczne jak w większych. "Za dużo UMLa" może zniechęcać... wszyscy (prawie :P) to znamy.

Unified Process
Jak już piszę o UMLu to przedstawię pewien schemat, zaczerpnięty z książki "Applying UML and Patterns", który pokazuje przebieg procesu/metodyki wytwarzania oprogramowania, zwanej Unified Process. Jest to podstawowa metodyka iteracyjna, jej pochodne to: RUP, Agile UP, XP, Scrum, itp.
Ok, teraz najważniejsze, po co komu "proces"?! Czy nie wystarczy, aby każdy robił "swoje"? W małych projektach na pewno, w dużych takie podejście powoduje problemy (dowodem na to jest pewien post na grupie dyskusyjnej pl.praca.dyskusje z końca roku 2006 dot. dużej firmy programistycznej w Polsce ;). UP mówi kto/jakie/kiedy dokumenty/diagramy/kody wytwarza - można by powiedzieć: "taki ogromny plik todo" :D
No to teraz konkretny schemat - oparty na wspomnianej książce:

(based on "Applying UML and Patterns", 3rd ed)

Powyższy schemat przedstawia jedną iterację (długość jednej iteracji to około miesiąc). Po ogólnej analizie problemu, iterację rozpoczyna się od wykonania diagramów przypadków użycia (ud), aby zidentyfikować nazwy i relacje między przypadkami użycia (części wspólne, itp). Następnie na podstawie diagramu ud pisze się teksty przypadków użycia, czyli parustronicowe dokumenty przedstawiające działanie systemu z punktu widzenia użytkownika. Mając przypadki użycia tworzy się systemowy diagram sekwencji (SSD), na którym system traktuje się jako "black box", a użytkownik wykonuje na nim konkretne operacje (w przedstawionym porządku). Te trzy wymienione elementy (ud, use cases, SSD) razem tworzą "Use-Case Model" i stanowią podstawę dalszej analizy problemu.
Korzystając z powyższego modelu można zbudować model domenowy ("Domain Model"). Jest to uproszczony diagram klas (tylko atrybuty i relacje), ale nie służy on do reprezentacji klas języka programowania, tylko domen problemu. Na powyższym schemacie przykładowe domeny to "Sprzedaż", "Kasa" i "KatalogProduktów", relacje między nimi i ich atrybuty pozwalają na statyczną analizę problemu - czyli rozłożenie problemu na czynniki pierwsze.

Mając wykonane dwa powyższe modele można przystąpić do budowy modelu projektu ("Design Model"). Ten model jest inspirowany bezpośrednio przez dwa poprzednie, ale nie w stosunku 1:1 (dlatego słowo "inspirowany" jest jak najbardziej na miejscu). W jego ramach tworzy się _jednocześnie_ diagram klas (DCD) oraz diagram sekwencji, a stworzone diagramy mogą być wykorzystane przez programistów. Oczywiście diagramy nie mają pokryć 100% kodu, ani nawet nie 50%. Diagramy mają być wskazówką i przedstawiać "high level architecture". Dzięki budowie modelu łatwiej jest zmusić programistów, aby pisane przez nich kody współgrały ze sobą. Dodatkowo widząc graficzną strukturę kodu łatwiej jest zastosować wzorce projektowe, wzorce aplikacyjne i przede wszystkim zasady projektowania obiektowego. Dzięki temu wytwarzany kod jest lepszy jakościowo.

Oczywiście Unified Process jest konfigurowalny, w razie konieczności można dodać, czy usunąć pewne elementy (np. w prostych przypadkach tworzenie modelu domenowego może być zbędne, natomiast w skomplikowanych problemach pomocny może być dodatkowy model analityczny).

No to się rozpisałem, ale w sumie uprzedzałem, że coś z książki "Applying" umieszczę na blogu ;)

Brak komentarzy: