UML Requirements Modeling For Business Analysts

Mam w ręku kolejną książkę: This book provides you with a collection of best practices, guidelines, and tips for using the Unified Modeling Language (UML) for business analysis. The contents…

Czytaj dalej UML Requirements Modeling For Business Analysts

Jak identyfikować klasy?

Tytułowy problem ma chyba każdy początkujący . Jak słusznie zauważył autor poniższego tekstu: Eksperci od obiektowego podejścia do procesu tworzenia oprogramowania dzielą się na dwa obozy, w zależności od proponowanego…

Czytaj dalej Jak identyfikować klasy?

The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Niestety i w lite­ra­tu­rze i w mate­ria­łach szko­le­nio­wych, czy nawet dydak­tycz­nych na uczel­niach (o zgro­zo) moż­na się spo­tkać z taki­mi antyw­zor­ca­mi” jak wyżej. Jednym z naj­bar­dziej kurio­zal­nych jest obec­nie mode­lo­wa­nie danych z uży­ciem dia­gra­mu klas, nano­sząc na nie np. jesz­cze klu­cze głów­ne. Niestety bar­dzo czę­sto auto­rzy tych mate­ria­łów, wykła­dow­cy i tre­ne­rzy, zamiast korzy­stać ze źró­deł, prze­pi­su­ją jeden od dru­gie­go pogłę­bia­jąc marazm w tej dzie­dzi­nie, a pier­wo­wzo­rem wie­lu tych here­zji są nie­ste­ty mate­ria­ły publi­ko­wa­ne przez fir­mę SPARX (pro­du­cent opro­gra­mo­wa­nia Enterprise Architect) jak choć­by mój ulu­bie­niec: czas jako Aktor systemu 

Czytaj dalej The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

UML dla programistów Java

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. 

Czytaj dalej UML dla programistów Java

System Analysis And Design with UML 2.0

Książkę pole­cam przede wszyst­kim ana­li­ty­kom do nauki ale tak­że wyżar­tym” pro­gra­mi­stom, by sobie upo­rząd­ko­wa­li zdo­by­te doświad­cze­nie i moż­li­wie łagod­nie prze­cho­dzi­li od metod struk­tu­ral­nych do obiek­to­wych. Tu pew­nie nowin­ka dla nich: bazy danych pro­jek­tu­je­my na samym koń­cu, na eta­pie imple­men­ta­cji opra­co­wa­ne­go kom­plet­ne­go pro­jek­tu obiektowego. 

Czytaj dalej System Analysis And Design with UML 2.0

UML MDA czyli od biznesu do projektu logiki systemu

To co naj­czę­ściej wzbu­dza brak zaufa­nia to teza, że moż­na prze­pro­wa­dzić ana­li­zę i pro­jek­to­wa­nie opro­gra­mo­wa­nia na papie­rze”. Programiści w więk­szo­ści uwa­ża­ją, że to nie moż­li­we (rok temu na stro­nach tego blo­ga burz­li­wa dys­ku­sja z jed­nym z nich…). W więk­szo­ści przy­pad­ków pod­czas spo­tkań (kon­fe­ren­cje, pro­jek­ty itp.) z zespo­ła­mi pro­gra­mi­stów sły­szę: czy­ta­my wyma­ga­nia, kodu­je­my od razu i two­rzy­my kolej­ne wer­sje apli­ka­cji; ina­czej się nie da”. W przy­pad­ku szko­leń, ostat­nie­go dnia warsz­ta­tów naj­czę­ściej sły­szę: ooo, w cią­gu jed­ne­go dnia [teraz] powstał kom­plet­ny pro­jekt dzie­dzi­ny sys­te­mu [cho­dzi­ło o kom­po­nent], prze­te­sto­wa­ny i oczysz­czo­ny z wąt­pli­wo­ści, bra­ku logi­ki i nie­spój­no­ści, do tego łatwy w dal­szym roz­bu­do­wy­wa­niu; to co zro­bi­li­śmy teraz na dia­gra­mach UML w cią­gu dnia, jako zespół tra­dy­cyj­ną meto­dą robi­li­by­śmy co naj­mniej tydzień, bio­rąc pod uwa­gę kodo­wa­nie każ­de­go pomy­słu by go dać użyt­kow­ni­ko­wi do testów”. W zasa­dzie taki pro­ces ana­li­zy i pro­jek­to­wa­nia jest zna­ny od lat jako [[Model Driven Architecture]] (MDA). […] Larman w swo­jej książ­ce opi­su­je nie­mal­że iden­tycz­ne podej­ście (tabe­la poni­żej). Kluczową róż­ni­cą jest jed­nak źró­dło infor­ma­cji pier­wot­nej. U Larman’a jest to model przy­pad­ków uży­cia i ich sce­na­riu­sze. W porów­na­niu z mode­lem biz­ne­so­wym, pod­le­ga­ją­cym testo­wa­niu czy wali­da­cji, całe ryzy­ko pro­jek­tu spo­czy­wa na jako­ści mode­lu przy­pad­ków uży­cia. Jeżeli powsta­ły one jako efekt np. burzy mózgów, ankie­to­wa­nia pra­cow­ni­ków zama­wia­ją­ce­go czy tak zwa­nych sesji JAD (Joint Application Development) to jest bar­dzo praw­do­po­dob­ne, że całe ryzy­ko złej jako­ści takie­go mode­lu (a jest ono bar­dzo duże jak poka­zu­je prak­ty­ka) zosta­nie prze­nie­sio­ne na projekt.

To jest wła­śnie pro­blem nazy­wa­ny użyt­kow­nik nie wie cze­go chce”. Po to się robi ana­li­zy biz­ne­so­we by w koń­cu wie­dział. Nie zmie­nia to fak­tu, że książ­kę Larman’a gorą­co pole­cam każ­de­mu pro­jek­tan­to­wi i pro­gra­mi­ście z ambi­cja­mi na meto­dy obiek­to­we i wzor­ce projektowe.

Czytaj dalej UML MDA czyli od biznesu do projektu logiki systemu

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu. 

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je rozwiązań. 

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.

Czytaj dalej Udziałowcy projektu czyli który diagram UML …