Wzorce projektowe to przede wszystkim sposoby rozwiązywania typowych problemów architektonicznych i projektowych. Niewątpliwie nie zastąpią one projektantów ale są ogromną pomocą. Drugim, bardzo ważnym aspektem stosowania wzorców projektowych, jest ich rola komunikacyjna. Wystarczy jedno slowo: np. fabryka, a każdy wytrawny projektant czy architekt będzie wiedział o co chodzi. Jednak nie tylko projektanci powinni poznać wzorce projektowe, także dobry analityk powinien je znać, ot choćby po to by mieć wspólny język z wykonawcami aplikacji.

Wraz z rozwojem technologii i rosnącą złożonością oprogramowania każdy szanujący się analityk biznesowy jest także projektantem wstępnej architektury systemu. Wskazując możliwe rozwiązanie pozwala już na etapie analizy zastosować wiedzę pozyskaną od klienta i przekaząć ją wykonawcy oprogramowania. Coraz powszechniejsze stosowanie wzorca MVC (ang. Model-View-Controller) powoduje, że juz w procesie analizy powstaje zarys oprogramowania: analityk tworzy (powinien) model dziedziny systemu.

Książke tę, będącą niemalże elementerzem projektowania, polecam każdemu kto chce jako profesjonalista brać udział w procesie powstawania jakiegokolwiek oprogramowania obiektowego.

Naucz się zbierać wymagania od użytkowników systemu, zarządzaj zmianami w specyfikacji, przeprowadź analizę i wykonaj projekt. Tyle z okładki ksiązki...

Książka początkowo wydawała mi się dość dziwna bo opowiadała o analizie dziwnym "zorientowanym na kod" językiem ale po przeczytaniu całej uznałem, że nie byl to czas stracony.

Napisana przez programistów wnosi wiele w zrozumienie "myślenia programisty", który chyba zawsze będzie patrzyl na problem jak na kod i jego częsci. Dla mnie klasa to pojęcie z dziedziny problemu klienta, dla programisty jest to kawałek kodu.

Zaletą książki w moich oczach jest namawianie programistów by na projektowanie poświęcali nie mniej czasu niż na samo kodowanie (które czasami w kwestii rozwiązania problemu przypomna mi u niektórych programistow szczura w labiryncie). Pewną wadą jest preferowana, w książce metoda prototypowania polegająca na "dajmy klientowi cokolwiek byle się cieszył, naprawiać i ulepszać będziemy później". Coż, ot takie żale analityka.

Ma ta książka jedną ogromna zaletę: pokazuje praktykę! Ma także drugą: uczy analizy i projektowania obiektowego na przykładach i to ilustrowanych notacją UML. Uczy i notacji i analizy i kodowania i robią to jej autorzy z poczuciem humoru mimo więc, że temat trudny książka nie nudzi...

Książkę gorąco polecam w szczególności programistom, nawet tym, którym się wydaje, że już niczego poza kodem nie muszą czytać.... niejednego nauczy ona pokory.

Książka bardzo ciekawa bo opisuje całą, opracowaną i stosowaną przez jej autora, metodykę analizy. Każdy kto para się projektowaniem systemów business inteligencje wie, że dane czyli hurtownia danych i jej projekt to 100% sukcesu lub porażki takich projektów.

Książek o projektowaniu modeli danych dla hurtowni jest mało, chyba dlatego, że trudno opisać niealgorytmizowalny proces opisu "wymagań biznesowych". Tu podjęto próbę i na pewno warto się z nią zapoznać.

Książka może być przydatna analitykom, menedżerom nie koniecznie. Pewna szkoda, że autor używa swojej "dość dziwnej" notacji a nie np. diagramow ERD czy UML ale w analizie naważniejsza jest analiza. Tu przytoczę kolegę, szefa programistów który swoim podopiecznym mawia: "Ty się kolego ucz programować a nie języków programowania" jednak z drugiej strony używanie egzotycznego języka też nie jest najlepszym pomysłem....

W kwestii jeszcze dyskusji o notacjach i językach zacytuję mojego stryja i jego opinie o poliglotach: "znajomość języków to nic, trzeba mieć najpierw cokolwiek do powiedzienia w którymkolwiek z nich, na początek w ojczystym" a w tym kontekście autor ma wiele do powiedzenia.

Książkę nabyłem z czystej ciekawości. Po protu podtytuł Schematy blokowe uznałem dla siebie za kolejna lekturę obowiązkową (w końcu jestem modelarzem ). Polecam w szczególności rozdziały o dokumentowaniu algorytmów za pomocą schematów blokowych (czyli ok. 3/4 książki). Użyta w książce notacja to pomysł jej autorów i nie ma nic w tym złego, jak już nie raz pisałem: uczmy się modelować a nie notacji i obrazków.

Książka przyda się każdemu kto chce za pomocą schematów blokowych modelować algorytmy i procedury oraz każdemu kto w notacji UML planuje dokumentować (i analizować) algorytmy czyli tu, w analizie obiektowej, będą to metody operacji (metoda to algorytm wykonania operacji w klasie).

Obawiałem się, że to kolejna nudna książka o UML i modelowaniu a tu miłe zaskoczenie. Stosunkowo cienka (170 str.) ale za to konkretna i pomocna. Stanowi sobą kompletne kompendium wiedzy o analizie i modelowaniu komponentów. Rozdział Systemy komponentowe opisuje idee podziału na komponenty. Proces tworzenia systemu to opis tego jak przebiega analiza i projektowanie. Zastosowanie UML to krótki kurs pracy z diagramami UML w tym: diagram klas i model dziedziny (model pojęciowy), przypadki użycia jako opis wymagań oraz użycie stereotypów, interfejsów a także definiowanie tak zwanych niezmienników. Następnie krótki "kurs" definiowania wymagań. Dalej to sedno sprawy czyli identyfikowanie komponentów, określanie ich interakcji oraz ich specyfikowanie.

Gorąco polecam każdmeu kto ma ambicje analizy i modelowania w kontekście architektury komponentowej. Na obecne czasy w zasadzie każdy nietrywialny system powinien być od samego początku, już od modelu analitycznego, projektowany jako system komponenetowy.

Mam na półce kilka książek o UML. Dzielę je na trzy grupy: mniej czy bardziej nieudolne podręczniki traktujące tylko o UML z ambicją jego nauczenia bez krzty wiedzy o analizie obiektowej mimo nie raz wielu przykładów użycia samej notacji (raczej odradzam), książki z dziedziny inżynierii oprogramowania, o analizie i modelowaniu gdzie elementy analizy są ilustrowane skomentowanymi diagramami UML (gorąco polecam do nauki inżynierii a przy okazji UML'a) oraz książka o UML autorstwa ... autorów UML, którzy w podsumowaniu piszą: 80% zadań da się wykonać za pomocą 20% UML.

Tę książkę powinien na półce posiadać każdy kto używa UML ale nie jako podręcznik. Tak jak każdy intelektualista ma na półce słowniki i encyklopedie, których nie czyta się "od dechy do dechy" tak każdy dobry analityk, architekt systemów czy programista powinien mieć na półce Podręcznik UML trzech amigos.

Książka jest napisana pozornie chaotycznie i do czytania (nauki ?) jest trudna. Jednak jako skorowidz haseł (diagramów i artefaktów na nich) jest nieoceniona. Rozdziały grupuja diagramy nie alfabetycznie czy kontekstowo ale zgodnie z procesem tworzenia złożonych systemów a więc kolejne części to: Wprowadzenie, Podstawowe modelowanie struktury, Złożone modelowanie struktury, Podstawowe modelowanie zachowania, Złożone modelowanie zachowania, Modelowanie architektury no i podsumowanie zawierające spis diagramów i symboli i opis krótki metodyki RUP (Rational Unified Process).

Dla kogo ta książka? Najpierw zacytuję autorów: "Zadziwia fakt, że wielu wytwórców oprogramowania pragnie wznosić drapacze chmur, ale przystępuje do tego jak do zbijania psiej budy". Ta książka jest dla tych pozostałych wytwórców ...

Tematyka książki obejmuje obszerne wprowadzenie do teorii sieci Petriego. Omówiono w niej dziewięć klas sieci, uwzględniając zarówno sieci najczęściej spotykane w literaturze (sieci uogólnione, sieci kolorowane), jak i te nowo proponowane (RTCP-sieci). Dla każdej z omówionych klas przedstawiono przykłady ich zastosowania do modelowania rozmaitych systemów oraz metody analizy ich najważniejszych własności.

Książka powstała na bazie doktoratu więc poza walorami poznwczymi ma także walor... formalny. W kazdym razie moim zdaniem warto przebrnąc gdyż modele w postaci diagramow blokowych, szczególnie modele procesow to tak zwane grafy skierowane i sieci Petriego.

Moim zdaniem przytłaczająca większość błędnych modeli to efekt tak zwanych "naiwnych metod modelowania" czyli wiary w to, że samo użycie symboli danej notacji już samo z siebie jest "modelowaniem". Nic bardziej błędnego... warto zrozumieć nie tylko modelowane zjawisko (w zasadzie poprawny model to efekt tego zrozumienia) ale także język modelowania a ty sieci petriego maja duzo do powiedzenia.

Jest to nowe wydanie - znacznie zmienione i rozszerzone - podręcznika wydanego przez Wydawnictwa Naukowo-Techniczne w 1998 roku. Książka jest poświęcona nowoczesnej technologii baz danych i tworzeniu systemów baz danych. Można ją zaliczyć do klasycznych pozycji podręcznikowych zarówno ze względu na układ, jak i treść.

Książka przeznaczona jest dla studentów informatyki, a także ludzi uczestniczących w przedsięwzięciach programistycznych, architektów systemów, projektantów, programistów, wdrożeniowców. Zawiera opis procesu powstawania oprogramowania od strony i teoretycznej i praktycznej.

Książka z grona "teoria i praktyka". Na mojej półce ma poczesne miejsce, gdyż poza praktycznymi wynurzeniami wyłącznie paktyków, zawiera sporo teorii i systemowych uzasadnień dla wielu elementów procesu powstawania oprogramowania. Nie jest to tylko kolejne tępe klepanie przypadków użycia, prostego UML'a i RUP'a ale rzetelne potraktowanie problemu jakości analizy i projektowania (bo kodowanie mamy chyba opanowane aż za dobrze).

Polecam każdemu analitykowi...

P.S. Dlaczego wielu ludziom w branży IT wydaje się, że mniejszych systemów (a co to znaczy?) nie trzeba projektować, można od razu kodować? Klient zapłaci za błędy, owszem, ciekawe jak długo tak będzie... Osobiście uważam, że nie istnieje pojęcie "mały system", systemy mają kluczowy lub nie wpływ na biznes zamawiającego i to jest argument (ryzyko dla zamawiającego) za tym by uznać projekt za ważny a nie to czy ma pięć czy pięć milionow linii kodu....

Do tego typu książek podchodzę sceptycznie. Nie dlatego, że nie dociera do mnie ich treść (choć może czasami...;)) ale dlatego, że ich autorzy poszukują Świętego Graala dla problemu, który opisują a ja niestety w Graala nie wierzę. Reklama książki żeruje na "powszechnym poszukiwaniu sukcesu w sprzedaży" co zaliczam do elementów taniej manipulacji nabywcą. Treść książki to zlepek prawd znanych każdemu kto choć kilka popracował w roli handlowca okraszonych elementami "sposobów" manipulowania ludźmi czego osobiście jestem zaciętym wrogiem.

Być może (tego nie wiem) autor jest (był) skutecznym sprzedawcą ale mam wrażenie, że jego wiedza to zebrane doświadczenie bez zrozumienia przyczyn i skutków podejmowanych działań i osiąganych sukcesów. Ot takie "skoro to się sprawdza to róbmy tak, nie musimy rozumieć dlaczego". Otóż obowiązku nie ma ale warto rozumieć, choćby dlatego by wyciągać wnioski z nieudanych transakcji. Niestety, właśnie o modelach biznesowych tu nic nie znajdziecie a książka to raczej zapisu szczura nauczonego w labiryncie.