Swego cza­su w arty­ku­le o Wścipskim Analityku uza­sad­nia­łem potrze­bę pano­wa­nia nad wyma­ga­nia­mi od momen­tu poja­wie­nia się potrze­by biz­ne­so­wej aż do jej imple­men­ta­cji. Nie zna­czy to abso­lut­nie, że ana­li­tyk ma pro­gra­mo­wać, zna­czy to jed­nak, że ana­li­tyk powi­nien doku­men­to­wać to cze­go żąda w wyma­ga­niach a potem nad­zo­ro­wać realizację.

Developerzy uzur­pu­ją sobie pra­wa do wszyst­kie­go co wią­że się z imple­men­ta­cją. Z jed­nej stro­ny czę­sto żąda­ją szcze­gó­ło­wych danych np. o danych z dru­giej stro­ny sami chcą opi­sać ich logi­kę biz­ne­so­wą (tak, bo dane biz­ne­so­we to logi­ka biz­ne­so­wa a nie tech­no­lo­gia). Do tego bar­dzo wie­lu deve­lo­pe­rów sto­su­je meto­dy pra­cy rodem z przed kil­ku­na­stu lat… We wspo­mnia­nym wyżej arty­ku­le napi­sa­łem mię­dzy inny­mi o tak zwa­nym para­dyg­ma­cie obiek­to­wym i wie­dzy o nim u deve­lo­pe­rów, szu­kam hasła ana­li­za pro­ce­so­wa” i para­dyg­mat obiektowy”:

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne współ­pra­cu­ją­ce obiek­ty. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Logiki dzia­ła­nia i orga­ni­za­cji zamawiającego!

Tak wła­śnie jest: ana­li­za obiek­to­wa i mode­lo­wa­nie obiek­to­we to nie pro­gra­mo­wa­nie. Programowanie (wraz z pro­jek­to­wa­niem ele­men­tów czy­sto tech­nicz­nych) to imple­men­ta­cja modelu.

Jak moż­na radzić sobie z tym nie­do­pa­so­wa­niem”. Pomagają w tym zasa­dy SOLID (w szcze­gól­no­ści zasa­da otwar­to­ści na roz­sze­rze­nia i zamknię­cia na mody­fi­ka­cje oraz pro­jek­to­wa­nie zorien­to­wa­ne na zobo­wią­za­nia klas) oraz wzor­ce DDD w ana­li­zie i projektowaniu.

To co tu opi­szę nie jest pro­stym algo­ryt­mem mode­lo­wa­nia”, z pra­cy myślo­wej niko­go tu nie zwol­nię. Moim celem jest uzu­peł­nie­nie arty­ku­łu o sza­chow­ni­cy i arty­ku­łu o zbyt Niskim pozio­mie ana­li­zy o wska­za­nie, że model dzie­dzi­ny jest bar­dziej ele­men­tem ana­li­zy i mode­lo­wa­nia biz­ne­so­we­go niż pro­jek­to­wa­nia i imple­men­ta­cji. Model ten to jed­no z klu­czo­wych wyma­gań: sys­tem ma reali­zo­wać logi­kę opi­sa­ną w mode­lu dziedziny.

Jeżeli uzna­my, że moż­na (taki) model dzie­dzi­ny imple­men­to­wać to jego opra­co­wa­nie to tak­że pro­jek­to­wa­nie. Nadal uwa­żam, że nie jest to robo­ta dla pro­gra­mi­sty, bo na jakiej pod­sta­wie on miał by taki model opracować?

Jak wyglą­da więc pra­ca ana­li­ty­ka biz­ne­so­we­go zgod­nie z mode­lem kom­pe­ten­cyj­nym IIBA (IIBA com­pe­ten­cy model). Kluczowym ele­men­tem pra­cy Analityka Biznesowego (w kon­wen­cji IIBA) jest pro­wa­dze­nie (ana­li­za) wyma­gań od momen­tu okre­śle­nia potrze­by biz­ne­so­wej aż do imple­men­ta­cji uzy­ska­nia wła­ści­we­go roz­wią­za­nia. Jednak uzy­ska­nie to nie to samo co wła­sno­ręcz­ne wyko­na­nie. Znowu ana­lo­gia do budow­nic­twa: archi­tekt na bazie biz­ne­so­wych celów swo­je­go klien­ta opra­co­wu­je nie tyl­ko wizu­ali­za­cję budyn­ku ale tak­że jego kon­struk­cję, do takie­go pozio­mu by deve­lo­per miał jed­no­znacz­nie posta­wio­ne wyma­ga­nia, nie blo­ku­je to jed­nak deve­lo­pe­ro­wi reali­za­cji” wszel­kich poza-funk­cjo­nal­nych wymagań.

Więc po kolei, opracowujemy.

Model procesu biznesowego

Model procesuMamy tu pro­ces skła­da­ją­cy się z dwóch ele­men­tar­nych pro­ce­sów biz­ne­so­wych (czyn­no­ści). Każda czyn­no­ści, zgod­nie z defi­ni­cją pro­ce­su biz­ne­so­we­go, ma dane wej­ścio­we i dane wyj­ścio­we. Dokument 2 i Dokument 3 powsta­ją w tych pro­ce­sach. Mamy tak­że Procedury two­rze­nia doku­men­tów, czy­li jakąś logi­kę ich two­rze­nia. Pojawia się tak­że regu­ła biz­ne­so­wa. Jest to to ele­ment z poza nota­cji BPMN (nota­cja ta zawie­ra jed­nak moż­li­wość ozna­cza­nia czyn­no­ści wyma­ga­ją­cych uży­cia takiej regu­ły). Na dia­gra­mie poka­za­no, regu­łę biz­ne­so­wą oraz jej powią­za­nie z kon­kret­ną czynnością.

Czas zacząć ana­li­zo­wać czy­li pro­jek­to­wać nasz System. Założenie: wyma­ga­ne jest by System (opro­gra­mo­wa­nie) wspie­ra­ło oba pro­ce­sy: 1 i 2 (przy­po­mnę, że pro­ces biz­ne­so­wy to jed­na czyn­ność lub ich sekwen­cja, więc jed­ną czyn­ność mają­cą wej­ście i wyj­ście tak­że z defi­ni­cji, utoż­sa­mia­ny z pro­ce­sem biznesowym).

Usługi systemu

Usługi sys­te­mu to korzeń ana­li­zy obiek­to­wej. Stanowią szkie­let całe­go obiek­to­we­go pro­jek­tu. two­rzy­my bar­dzo waż­ny dia­gram: dia­gram przy­pad­ków użycia.

Usługi systemu

Często sły­szę, że ten dia­gram nic nie wno­si do pro­jek­tu. To nie praw­da. Wnosi klu­czo­wą infor­ma­cję: wyzna­cza gra­ni­ce Systemu i wska­zu­je ewen­tu­al­ne powią­za­nia z inny­mi sys­te­ma­mi. Ale też nie praw­dą jest, że słu­ży do poka­za­nia cze­go­kol­wiek ponad to, np. kolej­no­ści korzy­sta­nia z usług czy struk­tu­ry wewnętrz­nej. To ostat­nie robi­my w posta­ci mode­lu dziedziny.

Na powyż­szym dia­gra­mie udokumentowano:

  1. System ofe­ru­je użyt­kow­ni­ko­wi dwie usłu­gi (to wyma­ga­nie by Czynność 1 i Czynność 2 pro­ce­su były wspie­ra­ne przez System). 
  2. System będzie korzy­stał z danych inne­go opro­gra­mo­wa­nia (Zewnętrznego źró­dła danych), wyma­ga­na jest więc integracja.
  3. Usługa 2 jest reali­zo­wa­na w cało­ści przez inny, zewnętrz­ny sys­tem, wyma­ga­ne jest od sys­te­mu więc by obsłu­gi­wał prze­kie­ro­wa­nie na inny sys­tem (np. reali­za­cja płat­no­ści na stro­nie Banku).

Zakres pro­jek­tu to wyłącz­nie to co w środ­ku”, albo lepiej: wszyst­ko to co jest poza pro­sto­ką­tem System jest poza zakre­sem pro­jek­tu. Nie dostar­cza­my ani Zewnętrznego źró­dła danych ani Systemu Zewnętrznego usłu­go­daw­cy ale musi­my na liście wyma­gań zapi­sać, że inte­gra­cja z nimi jest wyma­ga­na i jaka ona ma być.

Logika działania Systemu – model dziedziny

Zabawa zaczy­na się tu: zamie­nia­my sce­na­riu­sze” na narzę­dzia i materiały”:

Model dziedziny

Celowo zacho­wa­łem nazwy tak by moż­li­we było śla­do­wa­nie” co z cze­go powsta­ło. Kilka komen­ta­rzy, czy­li dobre prak­ty­ki, wzor­ce i styl projektowania.

Każda usłu­ga ma swo­ją dedy­ko­wa­ną kla­sę, zmia­ny reali­za­cji jed­nej nie prze­nio­są się na inne. Usługi są więc od sie­bie nie­za­leż­ne. Oddzielono two­rze­nie doku­men­tów od ich prze­cho­wy­wa­nia, dzię­ki cze­mu łatwo w przy­szło­ści zmie­nić meto­dy ich two­rze­nia bez potrze­by inge­ren­cji w repo­zy­to­rium. Wszelkie regu­ły biz­ne­so­we (w tym vali­da­cji) są zamknię­te” w tak zwa­nych zło­żo­nych typach danych (valueObject, sytu­acja ide­al­na to cał­ko­wi­ty brak typów pro­stych (typy pro­ste, pri­mi­ti­ves) w pro­jek­cie, wyłącz­nie typy zło­żo­ne). W zasa­dzie zastą­pie­nie wszyst­kich typów pro­stych na zło­żo­ne w obsza­rze mode­lu dzie­dzi­ny, otwie­ra w przy­szło­ści dro­gę do ich roz­bu­do­wy bez potrze­by wpro­wa­dza­nia innych zmian w pro­gra­mie. Realnie pomię­dzy Aktorem a usłu­gą ist­nie­ją kla­sy wido­ku (GUI, View w MVC), tu nie umiesz­czo­ne, bo kla­sy te nie reali­zu­ją (nie powin­ny) żad­nej logi­ki biznesowej.

Powyższy model:

  1. Spełnia zasa­dy SOLID (w szcze­gól­no­ści System jest łatwy w roz­sze­rza­niu i nie wyma­ga w tym celu zmian)
  2. Jest zgod­ny z DDD czy­li struk­tu­ra mode­lu odwzo­ro­wu­je struk­tu­rę i poję­cia biznesowe.

Co zysku­je­my? Niskie kosz­ty dal­sze­go roz­wo­ju, łatwość wyce­ny pro­jek­tu przez deve­lo­pe­ra (zna archi­tek­tu­rę). Powstanie takie­go pro­jek­tu daje mi gwa­ran­cję, że panu­je nad nim. Owszem mogę zało­żyć, że deve­lo­per tak­że taki model opra­cu­je, jed­nak życie poka­zu­je, że pra­wie na pew­no nie…

Powyższe z oczy­wi­stych powo­dów (mało miej­sca i uogól­nie­nie) nie zawie­ra szcze­gó­łów, ale te nale­ży zawsze w pro­jek­cie odkła­dać na sam koniec. Dzięki temu może­my sku­pić się na rze­czach na praw­dę waż­nych (waż­ne jest by zro­zu­mieć cel two­rze­nia doku­men­tu a nie spi­sać jego zawar­tość, ta ostat­nia wyni­ka z tego do cze­go służy).

Ostatni wpis na blo­gu, o Niskim pozio­mie ana­li­zy zawie­ra akapit:

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Właśnie dla­te­go ana­li­za i wyma­ga­nia powin­ny zawie­rać model dzie­dzi­ny wraz z zale­ce­nia­mi co do imple­men­ta­cji. Nie jest to doku­ment (ten model) dla spon­so­ra pro­jek­tu (w rozu­mie­niu do czy­ta­nia). Jego rola (war­tość jaką wno­si do pro­jek­tu) to mini­ma­li­za­cja ryzy­ka, że deve­lo­per wyko­na coś cze­go nie chcemy.

A gdzie baza danych? Nie tu! Implementacja prze­cho­wy­wa­nia danych to pra­ca deve­lo­pe­ra, nie wol­no mu jedy­nie znor­ma­li­zo­wać powyż­sze­go mode­lu. Zaprojektowanie rela­cyj­ne­go mode­lu i uży­cie mapo­wa­nia obiek­to­wo-rela­cyj­ne­go znisz­czy wszyst­kie zale­ty tego pro­jek­tu a dodat­ko­wo strasz­nie skom­pli­ku­je całość.

(prze­druk uka­zał się w ERP-View)

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 9 komentarzy

  1. Przewagę DDD widać gołym okiem, gdy porów­nu­je­my oba podej­ścia na tym samym przy­kłą­dzie pod kątem pre­cy­zji mode­lu i cza­su pracy.

    Gdy pró­bu­je­my ana­li­zo­wać po powierzch­ni” czy­li z per­spek­ty­wy pro­ce­sów, to ilość moż­li­wych kom­bi­na­cji powo­du­je paraliż.

    Wyjście od dome­ny pozwa­la na wyło­nie­nie bazo­wych reguł biz­ne­so­wych i sku­pie­nie się na nich. Dopiero póź­niej pra­cu­je­my nad war­stwą apli­ka­cji, któ­ra orkie­stru­je buil­ding blocks domenowe.

    To tro­chę tak jak mode­lo­wa­nie gry w sno­oke­ra. Możemy wyjść od warian­tów roz­bić, albo od bazo­wej fizy­ki” (np. kąt pada­nia rów­na się kąt odbi­cia). W dru­gim przy­pad­ku mam do czy­nie­nia z mniej­szą ilo­ścią kom­bi­na­cji stanów.

    Dotykamy tutaj kolej­nej kwe­stii: ogra­ni­cze­nia kogni­tyw­ne ludz­kie­go mózgu. Przy nie­try­wial­nym sys­te­mie ana­li­za po powierzch­ni” daje nam stycz­ność z pro­ble­mem o zło­żo­no­ści nie­moż­li­wej do ogarnięcia.

    1. Jarek Żeliński

      Ano, ja to nazy­wam ana­li­za jako krę­ce­nie fil­mu”, a wyj­ściem z sytu­acji jest jak naj­szyb­sze dotar­cie do reguł biz­ne­so­wych i tego czym zarzą­dza­ją. Dlatego pro­ce­sy biz­ne­so­we do ana­li­zy wyma­gań powin­ny być na dość wyso­kim pozio­mie, szcze­gó­ły i tak będą opi­sa­ne w przy­pad­kach uży­cia. Mapy pro­ce­sów na set­ki stron, szcze­gó­ło­wość na pozio­mie prze­ka­za­nie doku­men­tu prze­ło­żo­ne­mu” to masa­kra projektowa.…

  2. Krzysztof Sadowski

    Czytam twój blog od jakiś kil­ku mie­się­cy i pod­su­mo­wu­jąc krót­ko to napraw­dę dużo bym dał żeby mieć kie­dyś szan­se na współ­pra­cę z ana­li­ty­kiem two­je­go kali­bru 🙂 Niestety więk­szość mode­li” z któ­ry­mi zetkną­łem się w swo­jej karie­rze to były poema­ty na 1000 stron w wor­dzie albo dia­gra­my podob­ne do tego któ­ry zamie­ści­łeś w tym arty­ku­le. Wynika to chy­ba z bra­ku zna­jo­mo­ści pod­staw modelowania/projektowania obiek­to­we­go. Niestety doty­czy to rów­nież więk­szo­ści deve­lo­pe­rów, któ­rzy sto­su­ją meto­dy struk­tu­ral­ne, twier­dzą upar­cie że pro­gra­mu­ją obiek­to­wo. Wiele razy widu­ję w pro­jek­tach model dzie­dzi­ny”, któ­ry w kodzie wyglą­da mniej wię­cej tak:

    public class Employee
    {
    public string Name {get; set;}
    public string Surname {get; set;}
    public Company WorkingPlace {get; set;}
    }

    Oczywiście cała logi­ka i imple­men­ta­cja reguł jest roz­sma­ro­wa­na obok, po całej solu­cji. Zastanawiam się z cze­go to się bie­rze. Jest masa mate­ria­łów, trak­tu­ją­cych o projektowaniu/modelowaniu/programowaniu obiek­to­wym, z któ­rych napraw­dę moż­na wynieść dużą wie­dzę przy mini­mum wysiłku. 

    PS. Jedna mała tech­nicz­na uwa­ga: wyda­je mi się że to co ozna­czy­łeś na dia­gra­mie z mode­lem dzie­dzi­ny jako <> nie jest ser­wi­sem dome­no­wym (w sen­sie DDD) lecz raczej ser­wi­sem apli­ka­cyj­nym speł­nia­ją­cym rolę kon­tro­le­ra. Serwis dome­no­wym powi­nien odzwier­cie­dlać jakąś kon­cep­cję z mode­lu i moim zda­niem jak naj­bar­dziej zali­cza się do tej rela­tyw­nie wol­no zmien­nej czę­ści dzie­dzi­no­wej systemu”.

    1. Jarek Żeliński

      Co do lite­ra­tu­ry to jest, i jak się chce to się ma, fak­tem jest nie­ste­ty, że ginie ona w masie beł­ko­tu (nawet dru­kiem, mój ulu­bio­ny: książ­ka pod­ręcz­nik aka­de­mic­ki z dia­gra­ma­mi klas zawie­ra­ją­cy­mi klu­cze głów­ne i obce, masa­kra). Co do ostat­nie­go zda­nia, defi­ni­cje” usłu­gi (ser­wi­su) są róż­ne ale jak na razie prze­ma­wia do mnie naj­bar­dziej ta z DDD, któ­ra po pro­tu uzna­je za ser­wis każ­da logi­kę dzia­ła­nia” (ja to nazy­wam, umie­jęt­ność pra­cy z inny­mi obiek­ta­mi”). Jako ele­men­ty dome­no­we trak­tu­ję wszyst­ko to co doty­czy biz­ne­su”. W kom­po­nen­cie Model nie mam podzia­łu na apli­ka­cja i inne”. Bardzo faj­nie taka kon­wen­cja” opi­sa­na w ksiąz­ke Tools & mate­rials…” gdzie model dzie­dzi­ny opi­sa­no jako meta­fo­rę narzę­dzia i mate­ria­ły” (narzę­dzie to tak­że auto­ma­ty czy­li kla­sa reali­zu­ją­ca sama jaką usłu­gę). Ale jestem otwar­ty na dys­ku­sje :), ale poru­szy­łeś waż­ną rzecz: coraz czę­ściej badam” wzo­rzec MVVM/MVC, i byś może fak­tycz­nie usłu­ga w czę­ści «szyb­ko­zmien­nej” jest «poza dome­ną” ale z dru­giej stro­ny to nadal logi­ka biz­ne­so­wa bo imple­men­tu­je (i nad­zo­ru­je) sce­na­riusz przy­pad­ku użycia. 

  3. Krzysztof Sadowski

    Dyskutować moż­na rze­czy­wi­ście dużo i dłu­go bo poję­cie ser­wi­su jest dosyć czę­sto (nad)używane, co tym samym powo­du­je jego spo­re prze­ła­do­wa­nie. Ja wyróż­niam dwa rodza­je ser­wi­sów: apli­ka­cyj­ne i dome­no­we. Domenowe to te, któ­re sta­no­wią nie­od­łącz­ną cześć dome­ny, zawie­ra­jąc logi­kę któ­ra nie pasu­je” do żad­nej z encji/VO lub innych bytów. Serwis apli­ka­cyj­ny to nato­miast fasa­da dla nasze­go mode­lu, któ­ra orkie­stru­je ope­ra­cje wyko­ny­wa­ne na pod­sta­wo­wych skła­do­wych mode­lu dome­ny (encje, ser­wi­sy dome­no­we itd.), nad­zo­ru­jąc ich uży­cie w celu speł­nie­nia kon­kret­ne­go przy­pad­ku uży­cia. Temat został dobrze roz­wi­nię­ty w nastę­pu­ją­cych postach:
    http://​loste​chies​.com/​j​i​m​m​y​b​o​g​a​r​d​/​2​0​0​8​/​0​8​/​2​1​/​s​e​r​v​i​c​e​s​-​i​n​-​d​o​m​a​i​n​-​d​r​i​v​e​n​-​d​e​s​i​gn/

    http://​goro​din​ski​.com/​b​l​o​g​/​2​0​1​2​/​0​4​/​1​4​/​s​e​r​v​i​c​e​s​-​i​n​-​d​o​m​a​i​n​-​d​r​i​v​e​n​-​d​e​s​i​g​n​-​d​dd/

    1. Jarek Żeliński

      Najpierw małe wyja­śnie­nie: nie umie­ści­łem na mode­lu ele­men­tów View, real­nie pomię­dzy Aktorem a ser­wi­sem” odpo­wie­dzial­nym za reali­za­cję przy­pad­ku uży­cia, jest część obsłu­gu­ją­ca «ekran”, jed­nak nie ma w war­stwie View żad­nej logi­ki dla­te­go zosta­ła pomię­ta na mode­lu (popra­wię to). Ja w pro­jek­tach przy­ją­łem zasa­dę rodem z TDD: kom­po­nent Model dzie­dzi­ny (MVC) reali­zu­je 100% wyma­gań funk­cjo­nal­nych (prze­cho­dzi wszyst­kie testy funk­cjo­nal­ne). Taka kla­sy­fi­ka­cja jasno wska­zu­je co jest a co nie jest ele­men­tem dzie­dzi­ny sys­te­mu. W efek­cie 100% wyma­gań poza-funk­cjo­nal­nych reali­zu­ją pozo­sta­łe kom­po­nen­ty i infrastruktura.

      Bardzo faj­ne lin­ki, ale poja­wi­ło się coś cze­go tu nie wiem: co jest apli­ka­cją” a nie jest ele­men­tem dzie­dzi­ny? Bo ja po lek­tu­rze Evansa trak­tu­ję Model z MVC jako 100% logi­ki biz­ne­so­wej, View i Controler to ele­men­ty reali­zu­ją­ce poza­biz­ne­so­we funk­cje (np. ergo­no­mię GUI, AJAX, kodo­wa­nie trans­mi­sji, webser­wi­sy itp.)

  4. Siedzę sobie na kon­fe­ren­cji o sys­te­mach ERP i pew­na fir­ma IT, usta­mi swo­jej zło­to­ustej sprze­daw­czy­ni, mło­dej ład­nej dziew­czy­ny (pano­wie sze­fo­wie IT wpa­trze­ni jak w obra­zek), zachwa­la swój pro­dukt: rela­cyj­na baza danych jako plat­for­ma i jej język 4GL jako narzę­dzie w jakim powstał ich nowo­cze­sny” sys­tem ERP. Tak więc tech­no­lo­gia rodem z póź­nych lat 80-tych! Skąd się tacy biorą????

    1. Krzysztof Sadowski

      Sporo ana­li­ty­ków któ­rych ja spo­tka­łem mia­ło bar­dzo duży back­gro­und z baz danych. Tym samym czę­sto pró­bu­ją prze­no­sić to doświad­cze­nie na pole ana­li­zy i mode­lo­wa­nia sys­te­mów. Efektem są oczy­wi­ście mode­lu uwzględ­nia­ją­ce głów­nie struk­tu­rę danych, co pośred­nio prze­kła­da się na tech­no­lo­gię, w któ­rej reali­zo­wa­ny jest projekt.

      Apropos podzia­łu na ser­wi­sy dome­no­we i apli­ka­cyj­ne to po głęb­szym zasta­no­wie­niu wyda­je mi się że jest on bliż­szy samej imple­men­ta­cji. Z per­spek­ty­wy mode­lo­wa­nia biz­ne­so­we­go «ser­wis» to to coś reali­zu­je przy­pa­dek uży­cia poprzez orkie­stra­cje ele­men­tów z mode­lu dome­ny. Dla mnie (z per­spek­ty­wy imple­men­ta­cji) ser­wis apli­ka­cyj­ny to adap­ter w rozu­mie­niu archi­tek­tu­ry ports&adapters.

      http://​c2​.com/​c​g​i​/​w​i​k​i​?​P​o​r​t​s​A​n​d​A​d​a​p​t​e​r​s​A​r​c​h​i​t​e​c​t​ure

    2. Jarek Żeliński

      Ja patrze na model dzie­dzi­ny sys­te­mu jak na obiek­to­wy model dane­go biz­ne­su”, inny­mi sło­wy jest to w 100% ode­rwa­ne od imple­men­ta­cji, jak na razie się spraw­dza ;), czy to ide­ał… nie wiem 😉

      A w kwe­stii tych ana­li­ty­ków” to po pro­stu robią kla­sycz­ną struk­tu­ral­ną ana­li­zę z uży­ciem UML, któ­ra z meto­da­mi obiek­to­wy­mi nie ma nic wspól­ne­go, gorzej bo upie­ra­ją się, że to dia­gram klas UML więc jest OK”. 

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.