UML for Java programmers

Tym razem książ­ka dla pro­gra­mi­stów (autor książ­ki jest zna­ny w sie­ci jako Uncle Bob). Długo się nad nią zasta­na­wia­łem ale w koń­cu kupi­łem i nie żału­ję mimo, że napi­sa­na ponad deka­dę temu. Po pierw­sze jako pro­jek­tant muszę (no powi­nie­nem ;)) znać ogra­ni­cze­nia oraz spe­cy­fi­kę narzę­dzia (Java). Po dru­gie jako ana­li­tyk, nie raz spra­wu­ją­cy nad­zór autor­ski nad deve­lo­pe­rem, muszę (no powi­nie­nem ;)) mieć z tymi ludź­mi wspól­ny język.

Książka dosko­na­le poka­zu­je to co zawsze mówię na szko­le­niach: UML jako nota­cja jest nad­mia­ro­wa i nie wol­no o tym zapo­mi­nać (cza­sem mam wra­że­nie, że auto­rzy wie­lu dia­gra­mów, jako zada­nie, posta­wi­li sobie uży­cie za wszel­ka cenę wszyst­kich sym­bo­li UML jakie są dostępne).

Jednym z naj­bar­dziej (po dia­gra­mie klas) nad­uży­wa­nym jest dia­gram przy­pad­ków uży­cia. Na każ­dym szko­le­niu zawsze mówię: to ma być pro­sty dia­gram, wszel­kie extends, inc­lu­de, dzie­dzi­cze­nie to dzi­siaj beł­kot UMLowy (te związ­ki powsta­ły w latach 90-tych, gdy dia­gram UC był samo­dziel­nym two­rem, nie zna­ją­cym dia­gra­mów klas czy komponentów… ).

Po dru­gie kolej­na waż­na rzecz: w toku pro­ce­su two­rze­nia opro­gra­mo­wa­nia powsta­ją mode­le poję­cio­we (tak con­cep­tu­al zna­czy poję­cio­wy a nie kon­cep­tu­al­ny czy kon­cep­cyj­ny!), spe­cy­fi­ka­cyj­ne i imple­men­ta­cyj­ne. Autor książ­ki opi­su­je dwa ostat­nie, w koń­cu to książ­ka dla pro­gra­mi­stów, ale nie zaka­za­na dla ana­li­ty­ków. Od sie­bie dodam, że w ramach ana­liz wyma­gań powsta­ją mode­le poję­cio­we i (nie raz uprosz­czo­ne) specyfikacyjne.

Po co modelować?

Gorąco pole­cam pro­gra­mi­stom, by w ogó­le zaczę­li korzy­stać z UML a ana­li­ty­kom, by wyle­czy­li się z wie­lu mitów o UML roz­po­wszech­nia­nych nie­ste­ty na wie­lu, nie zawsze tanich, szko­le­niach i w wie­lu kiep­skich ​„porad­ni­kach UML” (pisa­nych nie raz nawet przez uczel­nia­nych dok­to­rów i nie tyl­ko).…. Może wte­dy prze­sta­ną two­rzyć nie­przy­dat­ne deve­lo­pe­rom dokumentacje. 

Poniżej tak­że – o dzi­wo jest dostęp­na – wer­sja pdf do pobrania.

UML for Java Programmers, June 6, 2003 by Robert C. Martin (Author): papie­ro­we wyda­nie na Amazonie i do pobra­nia pdf (pobież­ne przej­rze­nie wer­sji pdf wska­zu­je że jest trosz­kę uboższa)

Inne artykuły na podobny temat

• Związki w UML czy­li abs­trak­cja vs rzeczywistość
• Obiektowy model systemu
• Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny systemu
• Związki mię­dzy ele­men­ta­mi w mode­lach sys­te­mów – zawie­ra­nie, dekom­po­zy­cja i zależności
• UML MDA czy­li od biz­ne­su do pro­jek­tu logi­ki systemu

Jarosław Żeliński

BIO: Od roku 1991 roku, nie­prze­rwa­nie, reali­zu­ję pro­jek­ty z zakre­su ana­liz i pro­jek­to­wa­nia sys­te­mów, dla urzę­dów, firm i orga­ni­za­cji. Od 1998 roku pro­wa­dzę tak­że samo­dziel­ne stu­dia i pra­ce badaw­cze z obsza­ru ana­li­zy sys­te­mo­wej i mode­lo­wa­nia (mode­le jako przed­miot badań: ORCID). Od 2005 roku, jako nie­eta­to­wy wykła­dow­ca aka­de­mic­ki, pro­wa­dzę wykła­dy i labo­ra­to­ria (onto­lo­gie i mode­lo­wa­nie sys­te­mów infor­ma­cyj­nych, aktu­al­nie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspi­cja­mi Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje bada­nia i publi­ka­cje nie mają finan­so­wa­nia z zewnątrz, jako ich autor dekla­ru­ję brak kon­flik­tu interesów.