Blogasek Javowy - zawsze smaczny i zdrowy

W ostatnim (lipcowym) numerze Świata Nauki ukazał się felieton z zakresu mojej ulubionej dziedziny nauki - neuropsychologii. Jessica Wapner w artykule pt "Zdrowo się wypisać" tak oto opisuje wyniki badań nad autorami blogów: "... pisarstwo ekspresyjne poprawia pamięć i sen, stymuluje układ odpornościowy (i zmniejsza ilość wirusów u osób chorych na aids), a nawet przyśpiesza gojenie się ran pooperacyjnych".
Badania z zastosowaniem metody czynnościowego rezonansu magnetycznego wykazuję, że mózg (a w szczególności układ limbiczny) "świeci" inaczej przed, a inaczej po sesji pisarskiej.


//======================
Zatem na zdrowie: http://lifebert.blogspot.com/

Twoja rola w zespole

Dr Meredith Belbin opracował ciekawy test, którego przeprowadzenie na sobie może doprowadzić do ciekawych przemyśleń na temat siebie i swej roli w zespole (programistycznym na ten przykład).

Oczywiście przy tak małych testach istnieje niebezpieczeństwo, że testowany odpowiada raczej - czy to świadomie, czy nieświadomie - tak jak chciałby by go postrzegano niż tak jak jest naprawdę.
Test Belbina może wygląda niezbyt profesjonalnie, ale w najbliższym czasie opiszę spojrzenie z perspektywy psychologii, która za tym stoi. Mianowicie wydaje mi się, że 7 typów wyróżnionych w zorientowanym na techniczny team podziale Belbina ma swoje "mapowanie" na ok 17 typów osobowości w jednej z teorii w psychologii.

Póki co zainteresowanym szczegółami tego co macie pod deklem polecam arcyciekawy artykuł poświęcony metaprogramom.


//===================================
Sam byłem już jakiś czas temu testowany 2 krotnie i...
okazało się, że mój główny typ (rola) to "Poszukiwacz źródeł" (idąc za terminologią z powyższej strony) czy "Analityk Poszukiwacza" albo "Resource Investigator" (trzymając się innych źródeł)

Jako typ "secondary" (czyli taki, który jest aktywowany gdy pierwszy nie może być realizowany) wyszedł "Kreator" (za belbin.pl) lub "Innowator" (za innymi źródłami).

Moja antyrola - czyli to w czym się kompletnie sie sprawdzam to "perfekcjonista" i "implementator"

Przejmowanie całkowitej kontroli nad światem

Znalazłem to przypadkiem i zamieszczam z sentymentem do ulubionej kreskówki...

Spring+Seam - integracja dla ubogich

Wczoraj opisałem dosyć ogólnie wszystkie warstwy. Teraz pora na obniżenie poziomu abstrakcji; zobaczmy jak to wszystko ze sobą skleić przy pomocy Springa.

Oczywiście można zadać pytanie: po co sie wydurniać? Czy używanie Springa to nie nakładanie gaci przez głowę? Przecież Seam wspiera injekcje, bijeckje, outjekcje...

Założenie jest takie, że nie chcemy widzieć Seama w warstwach niższych niż warstwa prezentacji aby nie wiązać się z nim zbyt mocno mając na uwadze ogromną skalę czasową projektu. Spring pozwala na eleganckie zarządzanie transakcjami i bezpieczeństwem (Spring Security - dawniej ACEGI). Wogóle... Spring to Spring:)
Poza tym kwestia nieszczęsnych adnotacji. Wg mnie używanie adnotacji w celu Dependency Injection to chromy pomysł - zdradza on chyba niezrozumienie idei DI. Prosty kontrprzykład: w celu zmiany wstrzykiwanej instancji muszę przekompilować kod. O ile da się z tym żyć, to niestety gdybym chciał wstrzykiwać przykładowo różnie strategie wyliczania podatków u różnych klientów to przydały by się chyba jakieś dyrektywy kompilacji w Javie hehehe. Natomiast trzymanie deklaracji wstrzykiwania w np XMLu pozwala na trzymanie jednej wersji kodu - systemy różnych klientów różnią się jedynie paroma XMLami. Że o konfiguracjach na potrzeby testów nie wspomnę...

Do rzeczy: załóżmy, że mamy klasę juzkejsu i chcemy zadeklarować ją w Springu:

<bean id="beanId" class="Klasa">
<property name="jakiesDAO"><ref bean="jakiesDAO"/></property>
</bean>

Teraz aby zrobić z naszego beana komponent Seamowy wystarczy do definicji beana dodać:
scope="prototype" - ponieważ Springowe singletony niezbyt nadają się na stanowe komponenty;)
<seam:component scope="CONVERSATION"/> - aby zadeklarować, że dany bean jest komponentem Seam o danym zasięgu.
Zatem całość wygląda tak:

<bean id="beanId" class="Klasa" scope="prototype">
<seam:component scope="CONVERSATION"/>
<property name="jakiesDAO"><ref bean="jakiesDAO"/></property>
</bean>


Oczywiście aby parser XML mógł zrozumieć co to znaczy seam:component potrzebujemy zmodyfikować plik konfiguracyjny Springa:


<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:seam="http://jboss.com/products/seam/spring-seam"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://jboss.com/products/seam/spring-seam
http://jboss.com/products/seam/spring-seam-2.0.xsd">
<!-- bean definitions -->
</bean>


Aby całość "zatrybiła", czyli aby nasze Springowe beany były widoczne w kontekście Seam i JSF musimy zadeklarować Resolvera w faces-config.xml:

<faces-config>
<application>
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver
</el-resolver>
</application>
</faces-config>


Od tej pory w warstwie prezentacji (Czy to adnotacje @In w backing beanach czy wyrażenia EL w faceletach) możemy posługiwać się identyfikatorem naszego beana.


Oczywiście nasz przykład możemy rozszerzyć o managera transakcji i Proxy, który opakowuje nasze obiekty UC w celu obsłużenia transakcji w transparentny sposób:


<bean id="beanId" scope="prototype" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean" >
<seam:component scope="CONVERSATION" class="Klasa"/>
<property name="proxyTargetClass" value="true"/>
<property name="transactionManager"><ref bean="txManager"/></property>
<property name="transactionAttributes">...</property>
<property name="target">
<bean id="beanId" class="Klasa" >
<property name="jakiesDAO"><ref bean="jakiesDAO"/></property>
</property>
</bean>


Jednak tym razem musimy dodać:
class do seam:component oraz paramter proxyTargetClass ponieważ wspaniały Seam nie obsługuje Dynamic Proxy:/
Niestety nie da się wyciągnąć transaction proxy jako abstrakcyjny bean w celu zmniejszenia ilości kodu ponieważ mamy wówczas paskudny wyjątek:/


Prawie gotowe. Prawie ponieważ aby zaznaczyć początek i koniec Seamowej konwersacji muszę uzyć adnotacji @Begin i @End. Mogę je dopisać w metodach backing beanów, które reagują na czynności użytkownika. Niestety zakładam, że wiele różnych kliknięć może rozpocząć konwersację (np odpalić metodę init z klasy juzkesju) - więc mamy bałagan. Lepiej byłby otagować dwie metody juzkejsu - wszystko jasno, czysta i porządnie. Niestety nie mogę sobie pozwolić na brudzenie corowych warstw jakimiś adnotacjami jakiegoś frameworka prezentacji. Póki co wymyśliłem takie oto rozwiązanie:
W warstwie prezentacji tworzę klasę wrappera dla klasy juzkejsu: wrapper implementuje tan sam interfejs co UC, wrapper ma wstrzykniętą implementację danego UC (tą zadeklarowaną w Springu). Wrapper służy tylko do tego aby to jego metody (a nie klasy UC) brudzić adnotacjami. Hmm gdy wymyślę coś lepszego to napiszę...

//============================
Przedstawiona integracja jest wyjściem (aczkolwiek niewielkim) poza zakres "Poor man's integration" z rozdziału 15.2 doskonałej książki "Seam in Action" Dana Allena. Szczerze ją polecam wszystkim tym, którzy chcą zgłębić Seam trochę bardziej niż potrzeba do wyklikania formularzyków w apliakcji typu przeglądarka do bazy. Autor na prawdę rzetelnie opisuje poruszane zagadnienia. Szczególne wrażenie zrobił na mnie właśnie rozdział poświęcony integracji Springa z Seam. Oprócz gotowej do przepisania konfiguracji autor dokładnie omawia szczegóły architektoniczne obu frameworków i przyczyny dla których integracja wygląda tak a nie inaczej. Możecie się z niej dowiedzieć jak zintegrować frameworki na głębszym poziomie (wychodząc poza poor's man), tak aby wspólnie zarządzały persystencją i transakcjami. Mi niestety "nowoczesne" podejście do persystencji nie odpowiada z powodu drastycznych wymagań niefunckjonalnych...

Z pamiętnika zdomenowanego modelarza: #2 Architektura

- Ogry są... jak cebula!
- Śmierdzą?!
- Tak... nie! ... Ogry mają WARSTWY!

Jak już pisałem pracowałem ostatnio nad architekturą dla nowego systemu. Wymagania niefunkcjonalne sprawiły, że przybrała ona kształt niezbyt wyrafinowany, jednak z paroma ciekawymi smaczkami. Do tego jest ona zanurzona w Springu i przykryta Seamem (o integracji w następnym odcinku).

Architektura promowana przez Seam to w ogóle jakieś śmieszne nieporozumienie rodem z programów zaliczeniowych na studiach;)
Z tego powodu, jak i z innych, o których napiszę później Seam został potraktowany jako framework prezentacji dostarczający paru fajnych ficzerów; za obsługę persystencji dziękujemy.

Architektura nie jest jeszcze dopracowana w szczegółach i pewne rzeczy mogą się zmienić ale z grubsza wygląda to tak...
Oczywiście mamy warstwy:
- warstwa prezentacji - klasyczne backing beany przykryte JSF, właściwie to faceletami, właściwie to RichFaces. Seamowe akcje i model odpadają ponieważ zakładam bardzo rozbudowaną logikę prezentacji czyli modyfikowanie, przestawianie, przełączanie i zmienianie komponentów JSF. Zatem potrzebuję odrębnej warstwy na tego typu rzeźbę...
- warstwa logiki aplikacji - aplikacja będzie głównie "UseCase oriented" więc w tym miejscu pojawią się klasy odpowiadające konkretnym juzkejsom. Taki UC zazwyczaj składa się z wielu kroków (metod), zatem przydałoby się przechowywać jego stan w sesji. No ale zasięg sesji to obciach - lepiej nadaje się do tego Seamowy zasięg konwersacji (przynajmniej do czegoś przyda się ten badziewiasty framework;)
Oczywiście nie wszystko będzie juzkejsem. Pojawią się tu również usługi aplikacyjne, które z powodu niemocy twórczej tymczasowo nazwałem sobie Fasadami (chociaż nie podoba mi się ta nazwa).

Warstwa logiki aplikacji będzie stanowić granicę systemu - ponad nią znajduje się po prostu jakaś mniej lub bardziej wyrafinowana powłoka (oczywiście najważniejsza z punktu widzenia marketingowego - ludzie uwielbiają gówno w kolorowym papierku).
Oprócz logicznego podziału na kroki juzkejsów będzie ona zawierać całą logikę, którą nie zaliczamy do logiki biznesowej (bo ta jest piętro niżej). Zatem znajdą się tu wszelkiego rodzaju podsystemy powiadomień, interakcji z systemem i innymi systemami itp.

- warstwa logiki domenowej - tu mieszka Domain Driven Design czyli serce naszego systemu. Większość klas z tej warstwy modeluje naszą dziedzinę. Będzie tu na przykład Pacjent, Oddział, Lek, itp. W DDD mamy kilka rodzajów "artefaktów" biznesowych: Encje, ValueObjects, Servisy, Fabryki, Agregaty - długo by o tym pisać, dlatego ta warstwa będzie tematem następnego posta.

- warstwa DAO - tak, tak... oldskulowe DAO. Co prawda z jego funkcjonalnością będzie pretendować do miana Repozytorium, ale nie będziemy się wydurniać z tą nazwą.


Typowy przepływ wygląda tak:
1. Akcja użytkownika rozpoczyna use case
2. Use case jest inicjalizowany i umieszczany w konwersacji Seama.
3. Kolejne akcje użytkownika odpalają metody odpowiadające krokom UC, gdzie dla każdego kroku zazwyczaj:
4. UC używa DAO aby pobrać Encje (ewentualnie tworzy agregaty encji przy pomocy fabryk)
5. UC stymuluje;) encje do wchodzenia w reakcje między sobą oraz wykonywania logiki biznesowej
6. UC może ewentualnie posiłkować się servisami biznesowymi (ustawiając im DAO), które zazwyczaj produkują ValueObjects
7. UC zazwyczaj w ostatnim kroku dokonuje utrwalenia encji przy pomocy DAO
Ogólnie to Kolejne kroki UC zmieniają jego stan, który jest jakoś prezentowany na GUI.


Tak pokrótce wyglądają warstwy. Jak widać architektura różni się od klasycznej proceduralnej-quasi-obiektowej architektury jedynie paroma konwencjami, a jednak intuicja podpowiada mi, że będzie to lepiej pracować i odsunie o kilkanaście miesięcy moment zwiększenia entropii do poziomu popularnie zwanego syfem w kodzie.
Różnie cą następujące:
- Stan juzkejsu w jednym miejscu zamiast w wielu backing beanach.
- Logika nie jest rozsiana pomiędzy procedury.
- Model domenowy nie jest anemiczny - jego klasy posiadają odpowiedzialność, możemy zagrać w nim wzorcami projektowymi w celu zmniejszenia komplikacji (chyba, że ktoś ma pecha i nie zna wzorców - wówczas komplikacja pozornie rośnie;)
- Paczki procedur ograniczone do minimum - servisy biznesowe


//==============================
W kolejnych postach opiszę bardziej szczegółowo każdą warstwę wraz z przykładową implementacją oraz przesłanki, które doprowadziły do niektórych strategicznych decyzji - niektóre z decyzji są dosyć kontrowersyjne, np: rezygnacja z lazy loading, uzywanie detached objects.
Przedstawię też integrację Seam ze Spring

Z pamiętnika zdomenowanego modelarza: #1 Anemiczny model

Jak pisałem ostatnio, przeformatowywuję się na Domain Driven Design. Co prawda książka Evansa nie jest tak dobra jak się spodziewałem, ale mimo wszystko jest wystarczająca aby stymulować do zmiany podejścia.

Postanowiłem w paru (mam nadzieję, że uda się to szybko zrobić) kolejnych krokach przedstawić kilka kluczowych różnic pomiędzy DDD a dosyć popularnym i powszechnie stosowanym podejściem quasi obiektowym.

Dziś część pierwsza: anemiczny model - to nic innego jak rekordy z Pascala albo struct z C. A gdzie logika? Oczywiście w procedurach! A że mamy języki obiektowe, to procedury nie mogą walać się nam po pamięci, więc się je opakowuje w klasy i dumnie nazywa metodami!

No dobra, z wyższego poziomu abstrakcji to nic innego jak struktury danych. Analizując problem zamieniamy rzeczowniki na klasy, rysujemy sobie kreski obrazujące powiązania. Później (o zgrozo) projektujemy sobie bazkę. Teraz już tylko wystarczy puścić jakiś generator, który wygeneruje z niej klasy mapujące Hibernate (pascal roox) i prawie z dyni. Prawie, bo został drobny szczegół - procedury. Więc potrzeba jakiegoś kontenera na procedury, w języku OO nie ma wyjścia - klasa; nazywamy ją dumnie fasadą albo servisem i piszemy sobie... switche i kaskady ifów często się przydają...
Wygenerowane klaski encji są fajne, bo mają gettery i settery do wszystkiego co jest dookoła - a nóż-widelec przyda się dla użytkownika pobrać sto tysięcy produktów jakie zamówił - heh nigdy nie wiadomo, a tak to zawsze jesteśmy otwarci na nowe ficzery.




W DDD obiekty biznesowe mają przede wszystkim odpowiedzialność. To one enkapsulują logikę biznesową czyli główną wartość naszego systemu. To przecież w tym miejscu rodzą się wszelkie problemy: bagole logiczne, powielanie kodu sprawiające ból w pupie przy refaktoryzacji - skąd my to znamy;)
To z nich możemy budować biblioteki reużywalnych komponentów biznesowych.

W DDD ważne jest aby "mówić wspólnym językiem". Czyli słownictwo z danej dziedziny powinno być używane nie tylko przez ekspertów domenowych i analityków, ale również przez projektantów i programistów. Przełożenie pomiędzy analizą a projektem powinno być dosyć spójne.

Co więcej, przy podejściu DDD na poziomie projektu/implementacji obiekty biznesowe mogą delegować wykonanie czegoś np do strategii lub w ogólności posługiwać się trikami (wzorcami) OO.

Obiekty biznesowe mają swój stan, który możemy chcieć utrwalić - wówczas mapujemy niektóre ich pola na kolumny w tabelach.

W DDD obiekty biznesowe mają owszem referencje do swych zagregowanych wnętrzności. Ale nie koniecznie po wszystkich kluczach obcych i w obie strony! W DDD istnieje pojęcie agregatu. Jest to spójna logicznie paczka obiektów, która ma roota - główny obiekt. Do głównego obiektu wysyłamy sygnały (wołamy metodę) a ten ewentualnie w swej logice zmodyfikuje stan swych zagregowanych "dzeci".

Po co zatem inne klucze obce? Po to aby zamodelować inny agregat - swego rodzaju inną perspektywę z której możemy spojrzeć na grupę obiektów.

To podejście ma niestety jedną wadę: gdy propagujemy taki obiekt biznesowy do warstwy GUI wówczas łamiemy hermetyzację warstw - gdyż wówczas metody biznesowe są wystawione dla programistów formularzy. Swoją drogą... czy w JSF czy czymś podobnym nie dałoby się tak zmontować javascript czy parametry requesta w ogólności aby odpalić jakąś metodę biznesową, która nie jest zbindowana z buttonem?
Rozwiązaniem może być przepakowywanie danych w DTOsy na potrzeby GUI - tak, tak, wiem DTO to syf, ale jak to zrobić inaczej?


//================
Pamiętam jak ok 4 lata temu nieśmiało dodałem sobie małą metodkę do klasy encji Hibernate, która niestety zniknęła przy którymś tam z kolei generowaniu klas na podstawie świeżo zmienionej bazy i wspólnie doszliśmy do wniosku, że metody w tych klasach są złe i zakazane:)

Dysonans kognitywny

Normalny zdrowy i niewytrenowany umysł ma nie lada problem z jednoczesnym utrzymaniem się przy 2 ortogonalnych ideach. Nazywa się to dysonansem kognitywnym. Umysł ma tendencję do dorabiania sobie teorii i mitów aby tylko usprawiedliwić lenistwo intelektualne i trzymanie się tego co znane - wszystko w celu minimalizowania dysonansu. Wbudowane mechanizmy obronne chronią mózg przed przegrzaniem wybierając ideę bardziej znaną a inne odrzucając jako z gruntu złe.

Osobniki unikające myślenia krytycznego (myślenia nad tym co się myśli) mają łatwiej - są w stanie bez skrupułów odrzucić niewygodny pogląd i przy okazji stwierdzić, że osoba go głosząca "nie zna sie, jest gupia i filozuje". Wszyscy inni aby doraźnie zdusić to dręczące i nieprzyjemne uczucie napięcia psychicznego towarzyszące dysonansowi uciekają się do trików typu wysiłek fizyczny lub upojenie alkoholowe;)

Magicy od NLP zalecają strategię pytań w celu przebicia się przez mur uprzedzeń. Twierdzą oni, że nie da się kogoś przekonać do innych poglądów jedynie próbując je artykułować. Natrafiamy wówczas na opór wywołany dysonansem kognitywnym, który spowoduje jedynie mocniejsze utwierdzenia w przekonaniach - pomóc tu mogą jedynie elektrowstrząsy;)
Zamiast tego lepiej jest wczuć się w rolę osobnika którego chcemy przekonać, zacząć mówić jego językiem a później zacząć zadawać pytania. Pytania mają ogromną siłę zdolną rozbić mur uprzedzeń. Siła ta polega tym, że na pytanie zawsze zostanie udzielona odpowiedź - nie koniecznie jawnie, ale przynajmniej w środku, w Czesiu.


W poprzednim poście zachwalałem książkę, która wywarła ogromy wpływ na moje rozumienie procesu powstawania oprogramowania i myślenie o poziomach abstrakcji. Niedawno zainspirowany gorącą dyskusją o DDD na forum Springa i z polecania Rafała Barszczewskiego zacząłem czytać "Domain-Driven Design: Tackling Complexity in the Heart of Software" Erica Evansa.

Co prawda przeczytałem dopiero pierwszą (z 4) część ale już widzę, że zapowiada się dzieło na miarę Larmana. Evans dzieli się głębokimi i trafiającymi w sedno przemyśleniami o przyczynach niepowodzeń projektów (nawet tych, które w pierwszym roku wyglądały na wspaniały sukces), sięga do natury developerów i opisuje ich błędy od strony psychologicznej.

Póki co z lektury pierwszej części Okazuje się, że należy jednak utrzymywać jeden model łącząc poziom analizy i projektu - inaczej niż u Larmana.

Do nasilenia mojego osobistego dysonansu przyczynia się również praca nad architekturą nowego systemu. Z jednej strony chciało by się zaprojektować go inaczej niż do tej pory, uniknąć pułapek i bałaganu do którego w sposób nieunikniony prowadzą dotychczasowe doświadczenia. Może zastosować podejście Evansa... Z drugiej strony wymagania niefunkcjonalne takie jak integracja ze starymi systemami czy modularyzacja posunięta do granic absurdu uniemożliwiająca wypracowanie eleganckiej i prostej architektury - po prostu nakładanie gaci przez głowę.

Mało tego... okazuje się, że wspaniałe frameworki niezbyt wspierają DDD. Raczej anemiczny model domenowy. Springowcy coś ściemniają. Seam to wogóle szczyt prostactwa architektonicznego. Hibernate - diabeł tkwi w szczegółach i rozwala OO:/

Co więcej... potwierdzają się odczucia mojej kobiecej intuicji iż lansowana dotychczas architektura (czy to Springowa czy EJB) to po prostu proceduralne badziewie. Może to okaże się jakąś namiastką: Real Object Oriented.

Zachęcam do dyskusji... Czy macie jakieś doświadczenia z Domain Driven Deveopment? A może ktoś zechciałby podzielić się nimi w formie prezentacji na JUG?

//==============
W najbliższym czasie obiecuję recenzję książki Evansa. W nieco dalszej przyszłości spróbuję opublikować wyniki pracy nad opracowywaną architekturą.

5km biegu nie pomogło; może jutro low-level format w sprzyjających okolicznościach przyrody jeziora...

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;).