Książka nad książkami

Gdyby co dziesiąty programista ją przeczytał to świat byłby lepszy...

Mam na myśli "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" autorstwa Craiga Larmana (amazon).

Książka wpadła mi w ręce (właściwie to na dysk;) już jakiś czas temu, ale niedawny zakup papierowej wersji nakłonił mnie do zareklamowania jej każdemu kto ma tyle wolnego czasu aby tu zajrzeć;)

Tytuł jest mylący - można by z niego wywnioskować, że jest to kolejna książka prezentująca kilka wzorców na nudnych czy kuriozalnych przykładach (do tego jeszcze w UMLu zamiast w Javie).
Nic bardziej mylnego proszę Państwa! Larman zastosował prastary indiański chłyt marketingowy - bo jak powszechnie wiadomo wszystko co ma w tytule "wzorzec projektowy" sprzedaje się lepiej od tego co nie ma w tytule tego chwytliwego zwrotu (choćby był to podręcznik do HTMLa;).

Tak na prawdę książka jest poświęcona zagadnieniu Unified Process - wszelkie skojarzenia z RUP są jak najbardziej zdrowe. Po prostu chłopaki z Rationala wzięli sobie czysty i piękny byt myślowy, dobździali do tego kawał autystycznego kombajnu i tony szablonów dokumentów, których i tak nikt nie czyta;P

Larman prezentuje nam proces wytwarzania oprogramowania... Właściwie to prowadzi nas za rękę przez jego kolejne fazy - gdyż jest to oczywiście proces iteracyjny.

Natomiast rzekomi bohaterowie książki pełnią tak na prawdę następujące role:
- UML - jest scenografią
- Wzorce projektowe - są niczym starożytny grecki chór budzący sumienie projektantów gdy zastanawiają się czy i tym razem nie wystarczyłoby prymitywne i prostackie rozwiązanie (no i oczywiście są wspomnianym chwytem marketingowym).

Na tym tle rozgrywają się dwa dramaty (żeby już tak po całości pojechać Antykiem), czyli dwa przykładowe systemy, których wytworzenie jest naszym zadaniem:
- jeden z nich to typowy nudny system korporacyjny - innymi słowy to na co jesteśmy skazani w codziennej pracy zawodowej (tu przestroga do studentów: zmieńcie sobie kierunek studiów póki nie jest jeszcze za późno;)
- drugi to komputerowa reifikacja gry Monopoly - przynajmniej jakaś odmiana:)

Zatem mamy dwa totalnie odmienne problemy i jeden spójny sposób (proces) na ich wytworzenie...

Pokrótce:
Najpierw zapoznajemy się z filozofią iteracyjności (chyba nie ma takiego słowa, bo spellcheck mi to podkreśla;), ewolucyjności i zwinności.
Następnie po zapoznaniu się z dwoma problemami przechodzi do fazy wstępnej w której należy określić wizję projektu, określamy krytyczne wymagania i juzkejsy.

W pierwszej (już właściwej) fazie pracujemy nad modelem domeny, pilnujemy się aby iteracyjne wprowadzać wymagania (nie robimy wszystkiego na raz, bo wyjdzie nam wodospad, czyli projekt skończy w szambie), poznajemy GRASP i wiele innych rzeczy...

W drugiej fazie uszczegóławiamy analizę i poznajemy podstawowe wzorce projektowe.

W fazie trzeciej nowe wymagania (ooo projekt jest otwarty na rozbudowę - jak fajnie), nowe wzorce...

To tylko wyrywkowe zagadnienia - książka liczy 700 stron więc nie ma sensu jej streszczać.


Unified Process nie jest akademickim toczeniem kręgla. Ta metodyka jest ekstremalnie pragmatyczna. Nie tracimy czasu na produkowanie ton dokumentów, których nikt nie czyta!

Larman wskazuje nam, które artefakty (diagramy, dokumenty, kod, testy) są istotne i jasno tłumaczy DLACZEGO są istotne - nie pozostawia tu żadnych wątpliwości.

W skrócie: Larman prezentuje nam spojrzenie z różnych poziomów abstrakcji (przyznam, że mi jako programiście szeroko otworzyło to oczy)
- analityk biznesowy - zostawia po sobie dokument wizji, wymagania
- analityk systemowy - zostawia po sobie model domenowy, juzkejsy, sekwencje procesów biznesowych
- architekt - zostawia po sobie architekturę (niespodzianka) - w dużym skrócie styl projektowania
- projektant - zostawia po sobie diagramy: klas i oczywiście diagramy dynamiczne (tworzone na podstawie wzorców)
- programista - zostawia po sobie kod i testy
Artefakty wyjściowe z jednego poziomu abstrakcji są artefaktami wejściowymi do następnego.

heh... porównajmy sobie to ze znanym nam procesem "chałupniczo garażowym" gdzie mamy jedną warstwę abstrakcji:
- programista - zostawia po sobie bajzel:)

//=============================

Podsumowując chcę gorąco zachęć do lektury... Larman ma niesamowity umysł charakteryzujący się klarownością myśli i wypowiedzi - co widać w strukturze i stylu książki oraz posiada rzadką zdolność do syntetyzowania wiedzy z bardzo szerokiego zakresu. Osobiście to właśnie cenię najbardziej - raczej zdolność do syntezy niż analizy (chociaż ta też się przydaje;).