Czy da się wyspe­cy­fi­ko­wać wyma­ga­nia na duże mia­sto? Poproście kil­ka­na­ście osób o wypi­sa­nie tego jakich funk­cji ocze­ku­ją od swo­je­go mia­sta. Dostaniecie dłu­gą listę wyobra­żeń zawie­ra­ją­cych prze­mie­sza­ne moż­li­wo­ści, ich jakość i wydaj­ność. Otóż zło­żo­ne­go sys­te­mu nie da ​„sen­sow­nie” opi­sać z pomo­cą zwy­kłej listy ocze­ki­wań. Będzie bar­dzo duża i zdez­ak­tu­ali­zu­je się toku trwa­nia pro­jek­tu, któ­ry pla­nu­je się raczej na lata niż niż tygodnie.

Książka zawie­ra opis szkie­le­tu (fra­me­work) mode­lo­wa­nia sys­te­mu infor­ma­cyj­ne­go opar­te­go na czte­rech pod­sta­wo­wych obsza­rach: inter­fejs użyt­kow­ni­ka, wej­ście i wyj­ście, klu­czo­wej oraz wspo­ma­ga­ją­cej logi­ki. Główny trzon szkie­le­tu to wej­ście, prze­twa­rza­nie i wyj­ście, czy­li ​„pro­ces”. Autorzy budu­ją sys­tem poję­cio­wy opar­ty na ana­li­zie od ogó­łu do szcze­gó­łu, abs­trak­cji, tak­że obiek­to­wym para­dyg­ma­cie (auto­rzy ope­ru­ją związ­ka­mi całość cześć, dzie­dzi­cze­niem, związ­kiem usłu­go­bior­ca – usłu­go­daw­ca). Złożony sys­tem dzie­lo­ny jest na kom­po­nen­ty, całość jed­nak utrzy­ma­na w duchu biz­ne­so­wych sche­ma­tów blokowych.

W czę­ści opi­su­ją­cej wyma­ga­nia, poja­wia się bar­dzo waż­ne i przy­dat­ne zało­że­nie: wyma­ga­nia są defi­nio­wa­ne nie­za­leż­nie od tech­no­lo­gii. Druga waż­na rzecz: wyma­ga­nia to słow­nik (zesta­wie­nie) cech: moż­li­wo­ści sys­te­mu oraz – tych moż­li­wo­ści (funk­cje) – cechy jako­ścio­we i wydaj­no­ścio­we. Szkielet (abs­trak­cja) sys­te­mu to trzy typy ele­men­tów (w książ­ce trzy per­spek­ty­wy): pamięć (enti­ty model) czy­li miej­sca prze­cho­wy­wa­nia infor­ma­cji (repo­zy­to­ria). Dalej pro­ce­sy – tu, funk­cje prze­twa­rza­ją­ce dane prze­cho­wy­wa­ne w pamię­ci oraz ste­row­nie (spra­wo­wa­nie kon­tro­li) nad całością.

Całość sta­no­wi pew­ne prze­mie­sza­nie ana­li­zy obiek­to­wej (model abs­trak­cji od ogó­łu do szcze­gó­łu z dzie­dzi­cze­niem, kom­po­nen­ty) i struk­tu­ral­nej (mode­le danych i prze­pły­wu danych). Całość jest ​„opa­ko­wa­na” wyma­ga­nia­mi w rozu­mie­niu słow­ni­ka cech systemu.

Z opi­su moż­na wysnuć wnio­sek, że auto­rzy nie wprost (nie powo­łu­ją się na ten model) nawią­zu­ją do obiek­to­we­go mode­lu BCE (opi­sa­łem go w arty­ku­le Wzorzec ana­li­tycz­ny BCE). Korzystają z dia­gra­mu klas UML (jaw­nie o nim pisze) jako mode­lu poję­cio­we­go. Jednak model pro­ce­sów to już model DFD zna­ny z ana­li­zy struk­tu­ral­nej (De Marco). W obsza­rze defi­nio­wa­nia pro­ce­sów (w tej książ­ce funk­cje prze­twa­rza­ją­ce) przy­wo­łu­ją tak­że tabli­ce decy­zyj­ne (tabli­ce decy­zyj­ne).

Warto tę książ­kę prze­czy­tać, by poznać dobrze opi­sa­ną, spój­ną, zorien­to­wa­ną na mode­le, kon­cep­cję ana­li­zy i mode­lo­wa­nia sys­te­mów biz­ne­so­wych. Dla kogoś mają­ce­go przy­wią­za­nie do ana­li­zy struk­tu­ral­nej, opi­sa­ny szkie­let będzie zapew­ne dobrym narzę­dziem pra­cy. Przyznam jed­nak, że nadal koja­rzy mi się to z lata­mi 90-tymi i pierw­szy­mi narzę­dzia­mi typu EJB ([[Enterprise Java Bean]]) i ane­micz­nym mode­lem dzie­dzi­ny. Autorzy przy­wo­łu­ją meto­dy obiek­to­we jako ​„sze­ro­ko obec­nie rekla­mo­wa­ne”, jed­nak mam wra­że­nie, że nie mają prze­ko­na­nia do tego mode­lu, uzna­ją­ce­go ści­sły zwią­zek danych i pro­ce­sów prze­twa­rza­nia w posta­ci obiek­tów. Co cie­ka­we jed­nak widzą zale­ty tego na ​„wyż­szych pozio­mach abs­trak­cji”, a tak się skła­da, że obiek­to­wy para­dyg­mat zakła­da imple­men­ta­cję wła­śnie tej abs­trak­cji – obiek­to­we­go mode­lu – w takiej posta­ci jaka powsta­je na eta­pie ana­li­zy i pro­jek­to­wa­nia (mode­lo­wa­nia) sys­te­mu (prze­czy­taj arty­kuł o DDD).

Dalsza część książ­ki to opis pro­ce­su wytwa­rza­nia apli­ka­cji co tu pomi­nę, tak­że dla­te­go, że nie jest moim celem stresz­cza­nie tu tej książ­ki. Opisałem ją bo (pomi­ja­jąc struk­tu­ral­nie zorien­to­wa­ną meto­dę ana­li­zy i pro­jek­to­wa­nia) bar­dzo dobrze opi­su­je war­tość doda­ną same­go pro­ce­su ana­li­zy opar­tej na mode­lo­wa­niu. Porządkuje to wie­dzą o sys­te­mie, mode­le sta­no­wią też doku­men­ta­cję sys­te­mu, są ​„mapo­wa­ne” na wymagania.

Na koniec war­to pod­kre­ślić jed­ną rzecz: ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań, zakła­da­jąc abs­tra­ho­wa­nie wyma­gań od tech­no­lo­gii, dosko­na­le nada­je się do pro­jek­tów zakła­da­ją­cych zakup goto­we­go opro­gra­mo­wa­nia. Autor nad­mie­nia na począt­ku, iż zakła­da­nie że będzie to od razu jeden mono­li­tycz­ny sys­tem, że taki jest lep­szy, jest moc­no nacią­ga­ne. Nawiązując do meta­fo­ry z budo­wa­niem mia­sta: powsta­je ono w cza­sie, będzie ono raczej zło­że­niem kom­po­nen­tów ([[COTS]]) niż monolitem.

Trzeba tę mieć jed­nak świa­do­mość tego, że książ­kę pierw­szy raz wyda­no w 2000 roku, jej napi­sa­nie mogło trwać ok. roku, może dwóch, a to zna­czy, że opi­su­je ona doświad­cze­nia auto­rów z lat 80 i 90 tych (cze­go auto­rzy nie ukry­wa­ją). To były cza­sy, gdy meto­dy obiek­to­we racz­ko­wa­ły a struk­tu­ral­ne prze­ży­wa­ły jesz­cze szczy­ty popularności.

Co cie­ka­we auto­rzy, w dodat­ku na koń­cu książ­ki, przy­zna­ją, że model zorien­to­wa­ny obiek­to­wo jest bar­dzo dobrą abs­trak­cją sys­te­mu, jed­nak uzna­ją, że na potrze­by imple­men­ta­cji waż­ny jest model struk­tu­ral­ny. Myślę, że to efekt przy­zwy­cza­je­nia auto­rów do trak­to­wa­nia wyma­gań jako prze­pi­su na pisa­nie kodu pro­gra­mu, pisa­nie meto­da­mi i narzę­dzia­mi strukturalnymi…

Tak więc czy­ta­jąc takie książ­ki, nadal popu­lar­ne, nie zapo­mi­naj­my o tym z jakiej epo­ki się wywo­dzą. Nie zapo­mi­naj­my, że meto­dy struk­tu­ral­ne to dro­ga do mono­li­tycz­nych sys­te­mów, któ­rych ​„zwin­ność” jest porów­ny­wal­na raczej do wiel­kie­go traw­le­ra prze­twór­ni na Bałtyku, a dzi­siaj są potrzeb­ne małe, szyb­kie, dedy­ko­wa­ne kutry rybac­kie, któ­re w moż­na bar­dzo w ilo­ści i spe­cja­li­za­cji, łatwo dobrać do panu­ją­cych warun­ków na ryn­ku i zmie­niać w razie potrzeby.

Tytuł: Process for System Architecture and Requirements Engineering
Autor: Derek Hatley, Peter Hruschka, Imtiaz Pirbhai0
Wyd.: Published August 2^nd 2013 by Addison-Wesley Professional (Goodreads | Process for System Architecture and Requirements Engineering Dorset House eBooks by Derek Hatley ? Reviews, Discussion, Bookclubs, Lists).