O UML 2.0, czyli co nowego w projektowaniu (część 5)

O metodyce i o tym, że projektować każdy musi

Sebastian Wyrwał wyrwal@firma-informatyczna.com

 

Idąc za modą należałoby nasze rozważania odnieść do… śpiewania. Popularne powiedzenie mówi „Śpiewać każdy może”. Któraś ze znanych osób pyta jednak „ale czy musi?”.

Wiele mniej lub bardziej znanych osób garnie się do śpiewania, co widać choćby w popularnym programie telewizyjnym. Zadane przed chwilą pytanie można troszkę sparafrazować i zapytać: „Czy projektować każdy musi?”. Z projektowaniem jest jednak zupełnie na odwrót. Wiele firm woli nie projektować lub robi to mało konsekwentnie. Wydaje się, że jest wiele przyczyn tego stanu rzeczy.

Dominujące, to obawa, że:

  • UML i narzędzia są zbyt obszerne;
  • Zastosowanie UML wydłuża proces wytwarzania oprogramowania;
  • Wdrożenie UML i narzędzia wydaje się być dość kosztowne;
  • UML nie poprawi komunikacji z klientem;
  • UML „nie mówi” jak projektować.

Pierwszy „zarzut” jest prawdziwy, ale tylko z pozoru. Wiele osób obecnie kończących informatykę zetknęło się z językiem UML na studiach. Aby uczestniczyć w pracach projektowych nie trzeba znać „całego” UML-a, wystarczy dobrze znać i umieć zastosować najczęściej używane konstrukcje. Notacja dla niektórych rodzajów diagramów jest bardzo prosta. Z reguły wystarczy krótkie solidne szkolenie, aby opanować podstawy UML w stopniu pozwalającym na tworzenie własnych diagramów. Oprócz składni, której można nauczyć się z książek, istotne jest praktyczne wskazanie zakresu użycia poszczególnych rodzajów diagramów i sposobu pobieżnej weryfikacji ich zgodności.

Drugi zarzut dotyczy wydłużenia procesu wytwarzania. Stworzenie każdego projektu wymaga czasu. Z drugiej strony można zapytać: czy można zbudować dom bez projektu? Oczywiście (pomijając polskie regulacje prawne) można. Ba, nawet jest program w telewizji (satelitarnej) gdzie takie przedsięwzięcia są prezentowane. Z punktu widzenia widza są nawet dość ciekawe. Jednakże z punktu widzenia rodziny, która w budowanym domu ma zamieszkać, czasem zdarzają się duże problemy związane z przekroczeniem budżetu projektu, niedopasowaniem różnych elementów konstrukcji etc. Problem jednak w tym, iż średniej wielkości system informatyczny jest tworem bardziej od domu złożonym, a wymagania jemu stawiane są bardziej narażone na zmiany. System informatyczny musi w praktyce prawie zawsze integrować się z innymi systemami. Tych różnic można by po głębszym zastanowieniu wskazać wiele. Każdy kto pyta, czy projektowanie w odniesieniu do oprogramowania jest niezbędne, powinien zastanowić się, czy zdecydowałby się na budowę domu bez projektu dla siebie. Następnie powinien się zastanowić, czy mając komercyjną firmę budującą domy na sprzedaż, zdecydowałby się na rozpoczęcie prac budowlanych bez projektu.

Trzeci z zarzutów dotyczy kosztów wdrożenia języka UML. Oczywiście koszty takie mogą być bezpośrednie i pośrednie. Bezpośrednie koszty, to zakup narzędzia i szkolenia, ewentualnie utworzenie osobnej serwerowni na serwer z centralnym repozytorium i infrastrukturą. Koszty zakupu narzędzia i szkolenia z reguły są dość niskie. Gdyby się uprzeć, można je zminimalizować używając bezpłatnych narzędzi lub wtyczek do środowisk programistycznych, których cena wynosi około 100 zł. Szkice projektów można wykonywać przy użyciu „kartki i ołówka” (co sprzyja uczeniu się). Jeśli chodzi o serwerownię z własną infrastrukturą, to nie od razu trzeba ją mieć.

Co do kosztów pośrednich, to nieumiejętne „przestawianie” całej organizacji na UML może być dość kosztowne. Koszty te można minimalizować poprzez stopniowe wprowadzenie języka UML, choćby do dokumentowania prowadzonych już projektów. Należy opracować plan jego wdrożenia, choćby w formie szkicu, lub zlecić opracowanie takiego planu. Proces wdrożenia języka UML może w różnych firmach mieć odmienny przebieg, zależnie od: specyfiki realizowanych projektów, etapu na którym się te projekty znajdują, czy znajomości języka UML przez różne osoby zaangażowane w projekt. Oczywiście wdrożenie UML w organizacji, to co innego niż wdrożenie konkretnego narzędzia. Wdrożenie narzędzia w średnio dużych i mniejszych firmach, które nie chcą budować oddzielnej serwerowni dla repozytorium projektów, jest dość proste. Wdrożenie języka UML i jakiegoś, choćby prostego procesu, wymaga analizy potrzeb klienta, znajomości specyfiki prowadzonych projektów i sposobu ich wytwarzania, jaki przyjęła organizacja z uwzględnieniem osób biorących udział w projekcie.

Czwarty z zarzutów dotyczący komunikacji z klientem jest dość poważny. Gdy klient nie zna języka UML, to nie będzie chciał czytać UML-owych dokumentów. Nie znaczy to, że my nie możemy ich tworzyć „dla siebie”, pokazując klientowi w miarę potrzeby np. diagramy procesów biznesowych (np. w uproszczonej notacji ze stereotypami) i diagramów przypadków użycia. Sprawa tego „w jakie diagramy klient ma wgląd” jest kwestią umów z nim zawartych. Zastosowanie języka UML wydaje się jak najbardziej celowe nawet wtedy, gdy klient nie ma wglądu w diagramy, a jedynie czyta dokumenty w języku naturalnym powstałe na ich podstawie.

Ostatni zarzut jest niestety prawdziwy. Specyfikacja języka UML nie mówi jak projektować. Sprawy związane z przebiegiem procesu projektowania określa metodyka.

W niniejszym odcinku, poza omówieniem1 pewnego pozornie drobnego ale bardzo ważnego błędu w znanym systemie, zostaną pobieżnie omówione dwie metodyki z rodziny USDP: bezpłatny proces OpenUP/Basic i płatny RUP. Co metodyki mają wspólnego z językiem UML? Określają, kto, co i kiedy robi. W zastosowaniach praktycznych trudno jest omawiać język UML w oderwaniu od metodyki. Osoby uczące się języka UML najczęściej pytają nie o szczegóły samego języka UML, ale o to, co i w jakiej kolejności należy robić. To właśnie określa metodyka.

Dlaczego mały błąd może kosztować kilkanaście tysięcy złotych?

W dniu 25 kwietnia 2007 r. radio podało wiadomość, iż osobie ze Śląska udało się kupić kilka samochodów (od różnych sprzedających) za śmiesznie małe pieniądze na aukcjach internetowych. Była mowa o kwocie 18 zł (!), podczas gdy intencją sprzedającego była sprzedaż za 18 000 zł. Całe zamieszanie powstało stąd, iż sprzedający wystawiając przedmiot na aukcję pomylił separator oddzielający złote od groszy. W owym systemie aukcyjnym separatorem jest przecinek (,) co widać np. oglądając inne aukcje lub choćby patrząc na opłaty za wyróżnienia aukcji. Jest to zgodne z tym, czego uczy się na lekcjach matematyki. Wikipedia zaleca jako separator kropkę (.), co jest rzekomo zgodne z ogólnoświatowymi zaleceniami. Oczywiście nie warto wdawać się w dyskusję nad wyższością przecinka nad kropką, czy szukać informacji na ten temat w materiałach dostępnych w serwisie aukcyjnym. Przecinek z kropką pomylić jest łatwo, dlatego dobrym pomysłem byłoby wprowadzenie dwóch oddzielnych pól formularza dla złotych i groszy oraz podawanie kwoty np. słownie do zatwierdzania. W systemie bankowości elektronicznej, o którym była mowa w poprzednim odcinku, wykonując przelew, osobno wpisuje się złote, a osobno grosze, co jest bardzo dobrym rozwiązaniem. Widać, że projektowanie oprogramowania wymaga wiele wyobraźni, a dużych problemów należy spodziewać się zawsze na styku człowiek – komputer. Gdyby chcieć podać dwa najtrudniejsze regiony w projektowaniu systemów informatycznych, to będą to:

  • styk opisu niesformalizowanego w języku naturalnym z (częściowo choćby) sformalizowanym opisem,
  • styk człowiek – komputer.

Podsumowując tę myśl można powiedzieć, że tam gdzie to, co ludzkie styka się z tym, co „maszynowe” znajduje się źródło wielu groźnych problemów. Stąd tak ważne jest modelowanie biznesowe i inżynieria wymagań.

Metodyki

O tym, że opanowanie specyfikacji języka UML nie uczyni z nikogo projektanta, mówiono już wielokrotnie. Wciąż jednak są osoby które uważają, że „nie warto czytać opracowań”, bo specyfikacje UML wystarczają. Można zapytać, czy ci którzy tak mówią, zaprojektowali cokolwiek, czy może są tylko teoretykami. A może wypowiadają się na jakikolwiek temat, bo nic konkretnego nie mają do powiedzenia? Warto jednak przeanalizować, choćby pobieżnie te metodyki wytwarzania oprogramowania, które dobrze „współpracują” z językiem UML. Są to np.:

  • USDP
  • RUP
  • OpenUP/Basic

USDP (ang. Unified Software Development Process) jest generycznym procesem, który dobrze „współpracuje” z językiem UML. Co ważne – proces ten jest bezpłatny. Jest on:

  • kierowany ryzykiem i przypadkami użycia,
  • zorientowany na architekturę,
  • iteracyjny i przyrostowy.

Proces ten musi być jednak przystosowany do potrzeb konkretnego projektu. Obejmuje to:

  • opracowanie standardów,
  • opracowanie szablonów dokumentów,
  • opracowanie, wybór, dostosowanie narzędzi,
  • definiowanie kamieni milowych.

Podstawowymi składowymi procesów z rodziny USDP są:

  • dziedziny,
  • dyscypliny,
  • role,
  • zadania,
  • kroki,
  • artefakty.

Zadania są pogrupowane w dyscypliny. Artefakty są pogrupowane w dziedziny. Role wykonują zadania i wytwarzają lub przekształcają artefakty. Zadania składają się z kroków. W wykonywaniu różnych zadań uczestniczą różne role.

Pięć kluczowych dyscyplin w USDP to:

  • wymagania – specyfikacja wymagań,
  • analiza – jej rezultatem ma być określenie jak spełnić wymagania,
  • projektowanie – doskonalenie modelu stworzonego na etapie analizy,
  • implementacja – wytworzenie kodu źródłowego i testy jednostkowe,
  • testowanie – przeprowadzenie testów.

W procesie USDP występują cztery fazy:

  • rozpoczęcie – określenie wizji systemu,
  • opracowanie – opracowanie architektury,
  • wytworzenie – zbudowanie systemu,
  • przekazanie – przekazanie produktu użytkownikom.

RUP (Rational Unified Process) jest instancją USDP i jest komercyjnym produktem firmy IBM. RUP może być traktowany jako pewnego rodzaju baza wiedzy z „dobrymi praktykami” projektowymi.

OpenUP/Basic

Można powiedzieć, że proces OpenUP jest bratem procesu RUP, gdyż oba wywodzą się z USDP. Z dokumentacji procesu OpenUP [4] można dowiedzieć się, iż opisywany proces jest iteracyjny, minimalny, kompletny i rozszerzalny. Podobnie jak w pozostałych procesach z rodziny USDP występują tu role, które wykonują składające się z kroków zadania, produkując artefakty. Zadania są pogrupowane w dyscypliny, zaś artefakty w dziedziny. Podobnie jak w USDP, w obrębie procesu występują cztery fazy:

  • rozpoczęcie (ang. inception),
  • opracowanie (ang. elaboration),
  • wytworzenie (ang. construction),
  • przekazanie (ang. transition).

W obrębie każdej fazy może występować wiele iteracji. Zakończenie danej iteracji w obrębie fazy to osiągnięcie małego kamienia milowego, a wyjście z fazy to duży punkt milowy, którego osiągnięcie wiąże się ze spełnieniem celów danej fazy. Zakończeniu faz odpowiadają następujące punkty milowe:

  • rozpoczęcie – punkt milowy: cel cyklu życia, czyli określenie, co chcemy wytworzyć;
  • opracowanie – punkt milowy: architektury, czyli określenie jaka ma być architektura tworzonego systemu;
  • wytworzenie – punkt milowy: wewnętrznej sprawności;
  • przekazanie – punkt milowy: wypuszczenia produktu.

W procesie OpenUP/Basic obowiązują cztery podstawowe zasady [4]:

  • Współpraca w celu dostosowania interesów (różnych osób) i wypracowania wspólnego rozumienia:
    • aktywne dzielenie się informacjami z osobami zaangażowanymi w projekt;
  • Równoważenie sprzecznych priorytetów w celu maksymalizacji korzyści odbiorców systemu:
    • zdefiniowanie problemu, który ma być rozwiązany przy pomocy tworzonego systemu,
    • określenie ograniczeń dla zespołu wytwarzającego (czas, koszty, etc.),
    • określenie ograniczeń dla tworzonego rozwiązania;
  • Skupienie się na architekturze systemu:
    • budowanie modeli na wyższym poziomie abstrakcji,
    • skupianie się np. na wzorcach, a nie na detalach,
    • zastosowanie luźno ze sobą związanych komponentów,
    • ponowne użycie istniejących już bytów;
  • Podział pracy na niewielkie iteracje, demonstrowanie wyników i ich ocena oraz otrzymywanie „sprzężenia zwrotnego” od odbiorców systemu:
    • zarządzenie ryzykami,
    • wczesne atakowanie ryzyk,
    • identyfikacja i zarządzanie zmianami,
    • obiektywne mierzenie postępu.

W obrębie głównego procesu OpenUP/Basic występują cztery podprocesy:

  • Współpraca i komunikacja w zespole;
  • Powiadamianie o zamiarach odbiorców zespołu projektowego;
  • Zarządzanie;
  • Tworzenie rozwiązania.

Z punktu widzenia UML najistotniejsze jest tworzenie rozwiązania, gdyż pozostałe podprocesy wiążą się bardziej z zarządzaniem. Bardzo istotne jest jednak to, że zastosowanie języka UML wpływa na poprawienie komunikacji w zespole.

W procesie OpenUP/Basic występuje 7 ról. Są to [4]:

  • Analityk – tworzy wizję systemu, uszczegóławia wymagania, znajduje wymagania, tworzy słownik, definiuje PU, tworzy model PU;
  • Każdy – zgłasza żądanie zmiany;
  • Architekt – tworzy i demonstruje architekturę, analizuje wymagania dotyczące architektury;
  • Developer – projektuje i implementuje rozwiązanie. Tworzy i wykonuje testy jednostkowe;
  • Projekt Manager – planuje projekt, planuje i zarządza iteracjami, ocenia rezultaty;
  • Odbiorca – każdy zainteresowany projektem i jego wynikiem;
  • Tester – tworzy, implementuje i przeprowadza testy.

Dyscypliny procesu OpenUP/Basic i zadania w ich obrębie [4]:

  • Analiza i projektowanie
    • analiza wymagań dotyczących architektury
    • demonstracja architektury
    • zaprojektowanie rozwiązania
    • stworzenie architektury
  • Konfiguracja i zarządzanie zmianami
    • żądanie zmian
  • Implementacja
  • implementacja testów jednostkowych
  • implementacja rozwiązania
  • przeprowadzenie testów jednostkowych
  • Zarządzanie projektem
    • ocena rezultatów
    • planowanie iteracji
    • zarządzanie iteracją
    • planowanie projektu
  • Wymagania
    • zdefiniowanie wizji
    • znalezienie wymagań
    • uszczegółowienie wymagań
  • Testowanie
    • stworzenie testów
    • implementacja testów
    • przeprowadzenie testów

W odróżnieniu od procesu RUP2 w procesie Open-UP/Basic nie występuje dyscyplina modelowania biznesowego.

Warto przyjrzeć się bliżej przykładowemu zadaniu z metodyki OpenUp/Basic [4]3:

Nazwa zadania: Zaprojektowane rozwiązania (ang. design the solution).

 

Główna rola: deweloper

 

Dodatkowe role: analityk, architekt, odbiorca, tester

 

Asystujący: brak

Wejście:

  • obligatoryjne: architektura, dodatkowe wymagania, przypadki użycia
  • fakultatywne: projekt (dla iteracji różnych od pierwszej)
  • zewnętrzne: brak

Wyjście:

projekt

 

Opis: Zadanie polega na zaprojektowaniu części systemu, nie całego systemu…4

 

Kroki:5

  • Zrozumienie szczegółów wymagań
  • Identyfikacja elementów projektu
  • Określenie, jak elementy współpracują, aby realizować scenariusz
  • Udoskonalenie decyzji projektowych
  • Zaprojektowanie składowych wewnętrznych
  • Poinformowanie o rozwiązaniach projektowych innych osób zaangażowanych w projekt
  • Zaprojektowanie struktury bazy danych
    • Opracowanie struktury tabel i widoków
    • Relacje pomiędzy tabelami
    • Wyzwalacze zapewniające integralność danych
    • Ograniczenia dla kolumn
    • Wartości domyślne dla kolumn
    • Procedury wbudowane i funkcje
  • Sprawdzenie jakości, spójności projektu

Widać, iż typowy opis zadania to:

  • Nazwa zadania;
  • Role, czyli kto bierze udział w realizacji zadania;
  • Wejście, czyli zestaw artefaktów, potrzebnych do wykonania danego zadania;
  • Wyjście, czyli zestaw tworzonych artefaktów;
  • Opis, czyli co jest przedmiotem zadania;
  • Kroki i ich opisy, czyli jak realizować zadanie.

Proces RUP

Proces RUP jest składową narzędzia IBM Rational Method Composer, które jest oparte o platformę Eclipse, choć oczywiście nie jest darmowe. Z wyglądu jest podobne do bezpłatnego narzędzia Eclipse Process Framework Composer, które stworzono dla procesu OpenUP/Basic. Oczywiście płatny RUP jest dużo bardziej rozbudowany niż darmowy OpenUP/Basic. Niemniej jednak, na pewnym poziomie widoczne jest duże podobieństwo – zarówno w zakresie procesów, jak i narzędzi. Wynika to z tego, że oba procesy mają wspólnego przodka, a jest nim proces USDP. Oba narzędzia są oparte o Eclipse, służą w zasadzie do tego samego, czyli do opracowywania i publikowania procesów dla organizacji, mają także tę samą filozofię.

W RUP-ie występuje około 30 ról, w OpenUP/Basic jest ich 7, czyli ponad 4 razy mniej. Oczywiście specyficzne implementacje zarówno RUP jak i OpenUP/Basic mogą dodawać dodatkowe role, np. związane z technologią implementacji lub ze specyfiką potrzeb klienta. Pomimo, że role nie odpowiadają wprost pracownikom (tzn. jeden pracownik może pełnić wiele ról), wyraźnie widać, że RUP jest bardziej odpowiedni dla większych firm, a OpenUP/Basic dla mniejszych.

W procesie RUP (dla dużych projektów), w obrębie dyscypliny analiza i projektowanie wyróżniono ponad 20 zadań, które dość dokładnie opisują, co należy „robić” w przebiegu projektu. W procesie OpenUP/Basic wyróżniono zaledwie cztery zadania, które bardzo szczegółowo opisują czynności, które należy podjąć. Zarówno w RUP-ie jak i OpenUP/Basic, w obrębie danego zadania wyodrębniono kroki. W obrębie omawianej dyscypliny wyróżniono decyzję dotyczącą np. tego, jak używać artefaktów będących np. diagramami tworzonymi w języku UML.

Przykładowe procesy RUP dostarczane wraz z narzędziem, to RUP dla dużych projektów i RUP dla małych projektów. RUP dla małych projektów jest „mniejszy” tzn. występuje w nim mniej ról, pominięta jest też dyscyplina modelowania biznesowego. RUP jest „dokładniejszy” niż OpenUP/Basic, co w praktyce oznacza, że może on pokazać – po dogłębnym zrozumieniu – jak prowadzić projekt w UML, czyli jakie diagramy, w jaki sposób i w jakiej kolejności należy tworzyć. Proces OpenUP/Basic jest „mniej dokładny” ale można go znacznie szybciej wdrożyć w organizacji. W konsekwencji może on zarówno pomóc prowadzić przedsięwzięcie informatyczne jak i – po dogłębnym zrozumieniu – podpowie jak wykorzystać język UML w projekcie. Oczywiście możliwe i zalecane jest dostosowanie procesu projektowania OpenUP/Basic (jak i RUP) do konkretnych wymagań klienta. Dostosowanie takie powinno opierać się o specyfikę realizowanych przez organizację projektów. Na marginesie warto zauważyć, że powoli zanika rola typowego programisty a jego miejsce zajmuje deweloper, czyli projektant – programista.

 

Literatura

[1] Unified Modeling Language: Infrastructure version 2.0. www.omg.org, Marzec 2006
[2] Unified Modeling Language: Superstructure version 2.0. www.omg.org, Sierpień 2005
[3] The Rational Unified Process – an Introduction, Second Edition, Phillippe Kruchten, Addison-Wesley 2000
[4] Dokumentacja procesu OpenUP/Basic; www.eclipse.org/epf/
[5] Dokumentacja narzędzia Eclipse Process Framework Composer 1.0.2a; www.eclipse.org/epf/
[6] Dokumentacja narzędzia IBM Rational Method Composer (narzędzie: www.ibm.com)
[7] Dokumentacja procesu RUP dostarczana wraz z narzędziem IBM Rational Method Composer

 

c.d.n.