UML MDA czyli od biznesu do projektu logiki systemu

(arty­kuł uzu­peł­nio­ny w 2019 r.) 

Kolejna god­na pole­ce­nia książ­ka na ryn­ku. Nie mia­łem cza­su by wcze­śniej ją opi­sać ale w koń­cu uda­ło się. Ale od począt­ku, wró­ci­my do niej.

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):

W czym pro­blem? Nauczyć się pra­co­wać na mode­lach (abs­trak­cje sys­te­mu) a nie od razu na kodzie (a raczej poprze­dzić kodo­wa­nie ana­li­zą i pro­jek­to­wa­niem), nauczyć się wzor­ców pro­jek­to­wych i przede wszyst­kim obiek­to­we­go myśle­nia (para­dyg­ma­tu) czy­li ana­li­zy i pro­jek­to­wa­nia. Wykonanie – imple­men­ta­cja na koń­cu a nie na począt­ku (podob­nie jak baza danych: w meto­dach obiek­to­wych pro­jek­tu­je­my utrwa­la­nie na koń­cu!). Po dru­gie, nie­ste­ty, nie raz sły­sza­łem o dostaw­ców: nie mamy inte­re­su w tym by pro­jekt trwał krót­ko”, to jed­nak tyl­ko argu­ment za tym by nie zle­cać im pro­jek­to­wa­nia a tyl­ko realizację.

MDA to trzy klu­czo­we eta­py: CIM, PIMPSM (szcze­gó­ło­wo opi­sa­łem w arty­ku­le o ana­li­zie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to ana­li­za biz­ne­so­wa, nie ma ona nic wspól­ne­go z opro­gra­mo­wa­niem, jej celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie tego co robią przy­szli użyt­kow­ni­cy sys­te­mu oraz wska­za­nie zakre­su pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia. Drugi to PIM czy­li opra­co­wa­nie mode­lu logi­ki sys­te­mu bez wzglę­du na to w jakiej tech­no­lo­gii powsta­nie, tu mil­czą­cym zało­że­niem jest, że będzie to tech­no­lo­gia obiek­to­wa jed­nak język pro­gra­mo­wa­nia może być dowolny.

Dużą zale­tą tego podej­ścia jest to, że opra­co­wa­nie mode­lu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgod­ne z PZP (Prawo Zamówień Publicznych) bo nie deter­mi­nu­je imple­men­ta­cji ale dokład­nie opi­su­je ocze­ki­wa­nia. Uważam, że jest to naj­lep­szy spo­sób two­rze­nia OPZ, bo nie pozo­sta­wia dowol­no­ści w kwe­stii funk­cjo­nal­no­ści roz­wią­za­nia. Jaki mamy tu pro­blem? Należy oddzie­lić pro­jek­to­wa­nie od reali­za­cji czy­li mamy dwa eta­py pro­jek­tu zamiast jed­ne­go, dwóch wyko­naw­ców (ana­li­za i pro­jek­to­wa­nie oraz reali­za­cja). Wady? Nie, korzy­ści bo wyko­naw­ca i tak musi jakiś pro­jekt opra­co­wać, po dru­gie wyce­na na bazie pro­jek­tu jest dale­ko mniej ryzy­kow­na niż wyce­na na bazie kon­cep­cji”, zresz­tą skut­ki wszy­scy obser­wu­je­my na ryn­ku. Ale wra­ca­my do tematu :).

Proces od analizy do projektu

Dwa pierw­sze (CIM i PIM) to pierw­sze eta­py pro­ce­su powsta­wa­nia opro­gra­mo­wa­nia: Analiza Biznesowa i jej pro­dukt oraz pro­jek­to­wa­nie roz­wią­za­nia i jego pro­dukt. Między nimi ma miej­sce okre­śle­nie zakre­su, któ­re­go pro­duk­tem jest model przy­pad­ków uży­cia (od 2015 roku w UML 2.5.x ten dia­gram jest mode­lem uzupełniającym) 

Analiza biznesowa

Zgodnie z zale­ce­nia­mi opra­co­wu­je­my model CIM czy­li two­rzy­my model tego jak dzia­ła biz­nes”. Produktem tego eta­pu są mode­le pro­ce­sów biz­ne­so­wych (raczej [[BPMN]] niż [[UML]]). Muszą się one jed­nak cecho­wać usta­lo­nym pozio­mem abs­trak­cji (nie powin­ny być zbyt szcze­gó­ło­we) i muszą uwzględ­niać roz­dział kom­pe­ten­cji pra­cow­ni­ków (ich nie kom­pu­te­ry­zu­je­my) od ich spe­cy­ficz­nych dla danej orga­ni­za­cji i pro­ce­su (te będą wspie­ra­ne przez nowe opro­gra­mo­wa­nie). Dobrą prak­ty­ką jest poprze­dza­nie tego eta­pu (uzu­peł­nie­nie go) o ana­li­zę i model archi­tek­tu­ry kor­po­ra­cyj­nej. To jest ostat­ni gwiz­dek na wpro­wa­dza­nie ewen­tu­al­nych ulep­szeń zarzą­dza­nia (rein­ży­nie­ria pro­ce­sów) w orga­ni­za­cji. Kolejny etap to

Opracowanie modelu przypadków użycia

Przypadki uży­cia, usłu­gi sys­te­mu dla użyt­kow­ni­ków, to celo­we inte­rak­cje użyt­kow­ni­ka z sys­te­mem. Ich cechą powin­na być kom­plet­ność, bo przy­pa­dek uży­cia to reali­za­cja kon­kret­ne­go celu biz­ne­so­we­go przez użyt­kow­ni­ka. Poprawnie opra­co­wa­ny taki model pozwa­la mapo­wać czyn­no­ści z mode­lu pro­ce­sów wprost na przy­pad­ki uży­cia (ale nie koniecz­nie jeden do jed­ne­go, przy­pad­ków uży­cia może być mniej, bo ta sama usłu­ga sys­te­mu może posłu­żyć do reali­za­cji kil­ku celów biz­ne­so­wych, np. utwo­rze­nia danych jak i ich pod­glą­du czy korek­ty, przy­kła­dem mogą być tak zwa­ne [[CRUD]]«y) (klik­nij tu by zoba­czyć to na przy­kła­dzie narzę­dzia jakie­go uży­wam).

Każda czyn­ność kan­dy­du­ją­ca na przy­pa­dek uży­cia powin­na być opi­sa­na sce­na­riu­szem jej reali­za­cji opi­su­ją­cym jak pla­nu­je­my tę usłu­gę zre­ali­zo­wać. Jest to tak zwa­ny dia­log użyt­kow­nik-sys­tem. Model przy­pad­ków uży­cia to tak­że defi­ni­cja zakre­su pro­jek­tu pro­gra­mi­stycz­ne­go (robi­my to i tyl­ko to).

Opracowanie modelu dziedziny

Specyfikacja usług sys­te­mu (przy­pad­ki uży­cia) to tak zwa­ne wyma­ga­nia funk­cjo­nal­ne. Jest to sta­now­czo za mało by cokol­wiek (w szcze­gól­no­ści opro­gra­mo­wa­nie) mogło powstać. Problem w tym, że samo stwier­dze­nie sys­tem ma wcią­gać śmie­ci” nijak się nie ma do kon­struk­cji urzą­dze­nia jakim jest odku­rzacz. Wymaganie poza­funk­cjo­nal­ne, że ma ich wcią­gać co naj­mniej 90%” tak­że nic nie mówi o tym co na praw­dę ma zostać wytwo­rzo­ne. Brakuje PROJEKTU.

Takim pro­jek­tem jest model dzie­dzi­ny, jed­nak nie jest to dia­gram klas na któ­rym poka­że­my, że np. ist­nie­je zwią­zek logicz­ny brud­ne­go dywa­nu z odku­rza­czem! bo to jest tyl­ko model poję­cio­wy (słow­nik pojęć). Model dzie­dzi­ny sys­te­mu to model dzie­dzi­no­wej logi­ki jaką nale­ży odwzo­ro­wać w opro­gra­mo­wa­niu. Owszem, jest to tak­że Diagram klas UML, ale zupeł­nie inny niż tak zwa­ny model kon­cep­tu­al­ny, któ­ry po pro­stu jest tyl­ko słow­ni­kiem (i czę­sto jest mylo­ny z mode­lem danych!).

Model dzie­dzi­ny sys­te­mu to sed­no ana­li­zy obiek­to­wej. To model całej logi­ki biz­ne­so­wej apli­ka­cji: kla­sy, ich ope­ra­cje i atry­bu­ty. Nie powi­nien to być na pew­no tak zwa­ny [[ane­micz­ny model dzie­dzi­ny]] a nie­ste­ty takie wła­śnie są one w więk­szo­ści pro­jek­tów jakie widuję.

Na tym eta­pie, mode­lo­wa­nie dzie­dzi­ny sys­te­mu, powsta­ją suche” kla­sy, bez metod i atry­bu­tów (tak, bez atry­bu­tów!). W pro­jek­tach zło­żo­nych sys­te­mów, powsta­nie mode­lu dzie­dzi­no­we­go powin­no być poprze­dzo­ne powsta­niem mode­lu kom­po­nen­tów (tak­że sto­sow­ny dia­gram UML), któ­ry jest pośred­nią war­stwą abs­trak­cji w takich pro­jek­tach. W takim przy­pad­ku począt­ko­wo ope­ru­je­my prak­tycz­nie tyl­ko na kla­sach abs­trak­cyj­nych i ich inter­fej­sach (są to inter­fej­sy tych komponentów).

Projektowanie realizacji czyli testowanie modelu dziedziny

Mając model dzie­dzi­ny, czy­li listę spe­cja­li­zo­wa­nych wyko­naw­ców” kon­kret­nych prac, może­my przy­stą­pić do testów sce­na­riu­szy przy­pad­ków uży­cia. Takim testem jest pró­ba zre­ali­zo­wa­nia sce­na­riu­sza przy­pad­ku uży­cia z pomo­cą obiek­tów mode­lu dzie­dzi­ny. Na tym eta­pie powsta­je dia­gram sekwen­cji (lub ste­ro­wa­nia inte­rak­cją, prze­pły­wu inte­rak­cji) dla każ­de­go przy­pad­ku uży­cia. Dobrą prak­ty­ką jest sto­so­wa­nie tu dia­gra­mów prze­pły­wu inte­rak­cji. Służą one do mode­lo­wa­nie nie­try­wial­nych przy­pad­ków uży­cia, prze­pły­wu sce­na­riu­szy alter­na­tyw­nych, ekra­nów itp.

W trak­cie two­rze­nia dia­gra­mu sekwen­cji pro­jek­to­wa­ne są ope­ra­cje klas (meto­dy to ich reali­za­cje). Diagram sekwen­cji opi­su­je dia­log pomię­dzy obiek­ta­mi pro­wa­dzą­cy do zre­ali­zo­wa­nia zada­nia, jakim jest cel przy­pad­ku uży­cia (jego stan koń­co­wy). Dialog taki to nic inne­go jak wywo­ła­nia ope­ra­cji obiek­tów przez inne obiek­ty (lub wła­snych). Po opra­co­wa­niu dia­gra­mu sekwen­cji obiek­ty, któ­re bra­ły w niej udział wzbo­ga­cą” się w pro­jek­cie o swo­je ope­ra­cje. Na tym eta­pie może się oka­zać, że pew­ne obiek­ty zmie­nia­ją swo­je sta­ny. Dla ich klas pro­jek­tu­je­my dia­gra­my maszy­ny sta­no­wej. Jeżeli oka­że się, że jakiś obiekt wyko­nu­je nie­try­wial­ne zada­nia (obli­cze­nio­we, zło­żo­ny pro­ces itp.), jego ope­ra­cję, któ­ra za to odpo­wia­da, doku­men­tu­je­my z pomo­cą np. dia­gra­mu czyn­no­ści – taki algo­rytm to Metoda danej Operacji. Za każ­dym razem spraw­dza­my zgod­ność z ocze­ki­wa­nia­mi użyt­kow­ni­ka i uzu­peł­nia­my kla­sy o nie­zbęd­ne atry­bu­ty, w szcze­gól­no­ści, jeże­li repre­zen­tu­ją one doku­men­ty czy formularze.

Projekt wykonany

Po wyko­na­niu powyż­sze­go, otrzy­ma­my kom­plet­ny model apli­ka­cji w nota­cji UML. Będzie to wła­śnie model PIM. Wszelkie nie­ja­sno­ści powin­ny zostać wyja­śnio­ne. Pozostaje reali­za­cja, model PSM, czy­li opa­ko­wa­nie pro­jek­tu tech­ni­ka­lia­mi” (w tym reali­za­cja wyma­gań poza­funk­cjo­na­lych) czy­li tym co dają nam np. fra­me­wor­ki MVC i podob­ne. Oczywiście nie jest to try­wial­ny pro­blem”, ale w takim pro­jek­cie deve­lo­per roz­wią­zu­je pro­ble­my jako­ści sys­te­mu a nie logi­ki biz­ne­so­wej sys­te­mu (podob­nie jak inży­nier budow­la­ny, któ­ry ma posta­wić moc­ny i bez­piecz­ny dom, bo jego funk­cjo­nal­ność to pro­blem miesz­kań­ca i zada­nie pro­jek­tan­ta architekta).

Poniżej pro­duk­ty takiej ana­li­zy i pro­jek­to­wa­nia w posta­ci dia­gra­mów (mode­li), pierw­szy to BPMN, pozo­sta­łe UML:

Aby zoba­czyć jak to zro­bić pakie­tem Agilian obej­rzyj Tutorial pakie­tu Visual-Paradigm Agilian

A teraz lektura Craig’a Larman’a

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]]), 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.

Larman’s UML Process

Use Cases
  • Define user inte­rac­tion with the system.
  • Underline nouns to iden­ti­fy con­cepts in the pro­blem domain.
Conceptual Model
  • Use the under­li­ned nouns from the use cases to cre­ate the con­cepts in the con­cep­tu­al model.
  • Some of the nouns, if they iden­ti­fy sim­ple data types, are used to cre­ate attri­bu­tes of the­se concepts.
  • Create asso­cia­tions betwe­en the concepts.
System Sequence Diagram
  • Create sys­tem sequ­en­ce dia­grams for each use case scenario.
  • Each sequ­en­ce event in the dia­gram cor­re­sponds to a user inte­rac­tion with the sys­tem spe­ci­fied by the expan­ded use case.
System Contracts
  • Specify post-con­di­tions for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Use the con­cep­tu­al model to iden­ti­fy objects cre­ated, asso­cia­tions for­med, and attri­bu­tes modified.
Collaboration Diagram
  • Create a col­la­bo­ra­tion (or sequ­en­ce) dia­gram for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Assign respon­si­bi­li­ties to clas­ses in the con­cep­tu­al model to ful­fill the post-con­di­tions in the contracts.
  • Use asso­cia­tions from the con­cep­tu­al model in con­junc­tion with pat­terns (Expert, Creator) to assign responsibilities.
Class Diagram
  • Add methods and addi­tio­nal attri­bu­tes which were disco­ve­red in the col­la­bo­ra­tion dia­grams to the clas­ses in the con­cep­tu­al model.
Code
  • Create clas­ses with the­ir names, attri­bu­tes and method signa­tu­res taken from the class diagram.
  • For each method on a class, use the col­la­bo­ra­tion dia­grams to find the sequ­en­ce of mes­sa­ges gene­ra­ted when the method is cal­led and cre­ate at least one line of code for each message.

(Based on Craig Larman’s Applying UML and Patterns -> Larman’s UML Process).

kon­wen­cje bar­dzo bli­ska powyż­szej (Larmana) opi­sa­no na stro­nach MSDN, tu wyciąg:

You can cre­ate seve­ral dif­fe­rent views of the users» requ­ire­ments. Each view pro­vi­des a par­ti­cu­lar type of infor­ma­tion. When you cre­ate the­se views, it is best to move fre­qu­en­tly from one to ano­ther. You can start from any view.

Diagram or document What it descri­bes in a requ­ire­ments model Section
Use case diagram Who uses the sys­tem and what they do with it. Describing how your sys­tem is used
Conceptual class diagram Glossary of types that are used to descri­be the requ­ire­ments; the types visi­ble at the sys­te­m’s interface. Defining terms used to descri­be requirements
Activity dia­gram Flow of work and infor­ma­tion betwe­en acti­vi­ties per­for­med by users and sys­tem or its parts. Showing work flow betwe­en users and your system
Sequence dia­gram Sequence of inte­rac­tions betwe­en users and sys­tem or its parts. An alter­na­ti­ve view to the acti­vi­ty diagram. Showing inte­rac­tions betwe­en users and your system
Additional docu­ments or work items Performance, secu­ri­ty, usa­bi­li­ty and relia­bi­li­ty criteria. Describing quali­ty of servi­ce requirements
Additional docu­ments or work items Constraints and rules not spe­ci­fic to a par­ti­cu­lar use case Showing busi­ness rules

Notice that most of the dia­gram types can be used for other pur­po­ses. For an ove­rview of dia­gram types, see Developing Models for Software Design. For basic infor­ma­tion abo­ut dra­wing dia­grams, seeHow to: Edit UML Models and Diagrams.

Na zakończenie

Powyżej opi­sa­ny pro­ces w cało­ści moż­na prze­ćwi­czyć wraz z pozna­niem wyma­ga­nych dia­gra­mów UML na warsz­ta­tach, któ­re pro­wa­dzę.

Serdecznie zapra­szam.

Inne artykuły na podobny temat

Komentarze

  1. Bartek Andrzejewski 26 marca 2012 at 14:19

    Opinie na temat zawar­to­ści mode­lu dzie­dzi­ny są rozbieżne 🙂 

    Pan stwier­dza:
    Model dzie­dzi­ny sys­te­mu to sed­no ana­li­zy obiek­to­wej. To model całej logi­ki biz­ne­so­wej apli­ka­cji: kla­sy, ich ope­ra­cje i atry­bu­ty. Nie powi­nien to być na pew­no tak zwa­ny ane­micz­ny model dzie­dzi­ny a nie­ste­ty takie wła­śnie są one w więk­szo­ści pro­jek­tów jakie widuję.”

    a ja wygrze­ba­łem na uml​.com​.pl coś takiego:
    W uję­ciu UML model dzie­dzi­ny jest to bar­dzo ogól­ny dia­gram klas, pozba­wio­ny atry­bu­tów i ope­ra­cji poszcze­gól­nych klas”. Oto link: 

    Konfrontują się?

    Pozdrawiam,
    Bartek

    • Jarek Żeliński 26 marca 2012 at 15:11

      Model dzie­dzi­ny sys­te­mu to model dzie­dzi­ny roz­wią­zy­wa­ne­go pro­ble­mu, a nie pro­sty model poję­cio­wy (bo wte­dy jest to model poję­cio­wy). Model dzie­dzi­ny to skład­nik mode­lu PIM (omg​.org/​mda) wzor­ca MVC. 

      Auror wska­za­ne­go arty­ku­łu, moim zda­niem, bar­dzo try­wia­li­zu­je ten model, w zasa­dzie przed­sta­wił tak zwa­ny model kon­cep­tu­al­ny (model poję­cio­wy, jest to model ope­ru­ją­cy na poję­ciach i ich defi­ni­cjach a nie na kla­sach w rozu­mie­niu OOA/OOP, dia­gram klas UML posłu­żył do jego zobrazowania). 

      Model dzie­dzi­ny to wstęp­ny pro­jekt, powi­nien pozwa­lać na utwo­rze­nie dia­gra­mu sekwen­cji czy­li ma co naj­mniej ope­ra­cje. Jeżeli moż­na się zgo­dzić co do tego, że może nie zawie­rać atry­bu­tów (nie licząc tych, któ­re mode­lu­ją część zacho­wać, np. sta­tus) to brak ope­ra­cji czy­ni nie przy­dat­nym do mode­lo­wa­nia zacho­wa­nia tego mode­lu. Projektując kla­sy war­to korzy­stać z meto­dy pro­jek­to­wa­nia poprzez odpo­wie­dzial­ność” a tę ostat­nia defi­niu­je inter­fejs klasy.

      Autor wska­za­ne­go arty­ku­łu powo­łu­je się na ICONIX był to rok 2006. Od tam­tej pory świat OOA bar­dzo poszedł do przo­du. W moich oczach popeł­nia tak­że błąd na dia­gra­mie Use Case zanie­dbu­jąc gra­ni­ce sys­te­mu oraz uży­wa­ją strza­łek na aso­cja­cjach aktor-UC. W moim subiek­tyw­nym odczu­ci nie pole­cał bym tego arty­ku­łu. Sugeruję na począ­tek książ­ke M.Fowlera UML w kropelce. 

      Powyższe moje uwa­gi bazu­ją na idei wzor­ca MVC będą­ce­go obec­nie stan­dar­dem de fac­to więk­szo­ści fra­me­wor­ków. Ze swo­jej stro­ny zamiast ICONIX suge­ru­je pozna­nie prak­tyk i wzor­ców DDD/MVC

    • Bartek Andrzejewski 26 marca 2012 at 15:40

      Dziękuję.
      Nie ukry­wam, że gdzieś w zana­drzu cza­iło się ziar­no pro­wo­ka­cji, bo ona nie­rzad­ko wydo­by­wa na wierzch waż­ne fak­ty. Tak też sta­ło się i tym razem.
      Fowler oczy­wi­ście – czap­ki z głów, choć sam spo­tka­łem się z kon­tro­wer­sja­mi na jego temat. Na temat jego podejść – nie mam na myśli tej kon­kret­nie książ­ki (choć nie pamię­tam już, gdzie czy­ta­łem te kontrowersje).

      Robustness dia­grams też karie­ry nie zro­bi­ły. Nie mia­łem oka­zji poznać niko­go, kto sto­so­wał­by je jako regu­lar­ne narzę­dzie pra­cy. Sam ich nie znam i pozna­wać nie zamie­rzam ? dużo bar­dziej odpo­wia­da­ją mi (i więk­szo­ści zna­nych mi ludzi z tzw. bran­ży”) dia­gra­my czyn­no­ści i dia­gra­my sekwencji.

      Powodzenia w dal­szym nie­sie­niu oświa­ty kagańca!

    • Jarek Żeliński 26 marca 2012 at 21:28

      Dla mnie głów­ną kon­tro­wer­sją Fowlera jest jego pod­pis pod Agile Manifesto (podob­no teraz żałuje ;))

  2. grzegorz 28 marca 2012 at 23:31

    Ja mam małą uwa­gę. Pan pisze cały czas o tym, że agi­le be i powin­no się naj­pierw zro­bić peł­ną ana­li­zę z peł­nym mode­lem a następ­nie dopie­ro jego implementację.

    Miałem przy­jem­ność prze­czy­tać książ­kę, któ­rą Pan opi­su­je i tam Craig Larman zachę­ca wręcz do zwin­ne­go projektowania/analizy/programowania. Można powie­dzieć, że odkry­wa on wyma­ga­nia w trak­cie jego projektowania/programowania. Kruszy je po kawał­ku zaczy­na­jąc od naj­waż­niej­szej logi­ki dokła­da­jąc stop­nio­wo kolej­ne funkcjonalności.

    • Jarek Żeliński 29 marca 2012 at 11:26

      Książkę Larmana pole­cam z uwa­gi na pro­ces i spo­sób pro­jek­to­wa­nia. Proszę zwró­cić uwa­gę, że Laramann odkry­wa wyma­ga­nia” na eta­pie ana­li­zy i pro­jek­to­wa­nia mode­lu dzie­dzi­ny, pra­cy z mode­la­mi a nie z kodem. Na tym to pole­ga: ana­li­za i pro­jek­to­wa­nie poprze­dza implementację. 

      Wadą pro­ce­su Larmana, w moich oczach, jest uzna­nie sce­na­riu­szy przy­pad­ków uży­cia za dobrą mone­tę” czy­li mate­riał wej­ścio­wy. Problem w tym, że przy­pad­ki uży­cia nie nio­są całe­go kon­tek­stu biz­ne­so­we­go a jedy­nie cel sys­te­mu”, nie raz bar­dzo subiek­tyw­ny jeże­li opar­ty np. na user sto­ry”. Larman, wyda­je mi się, wyka­zu­je podej­ście podob­ne do Cockbourna: uzna­je, że przy­pad­ki uży­cia są wystar­cza­ją­cym mate­ria­łem do pra­cy. Ja zaś jestem zwo­len­ni­kiem tezy, że klu­czem jest kon­tekst czy­li wynik ana­li­zy biz­ne­so­wej nie­za­leż­nej od sys­te­mu (model CIM z meto­dy­ki OMG/MDA/MDD).

      Tak więc model dzie­dzi­ny two­rzę, nie na bazie przy­pad­ków uży­cia, a na bazie mode­lu biz­ne­so­we­go, bo wte­dy ma peł­ną wie­dzę o kon­tek­ście a nie wie­dzę okro­jo­ną do przy­pad­ków uży­cia, któ­re są zawsze czę­ścią całości.

  3. grzegorz 29 marca 2012 at 11:45

    Tak ale po każ­dym eta­pie zebra­nia wyma­gań, zapro­jek­to­wa­nia przy­cho­dzi imple­men­ta­cja. Potem zno­wu etap powta­rza­ny: nowe wyma­ga­nia, dopra­co­wa­nie pro­jek­tu, implementacja.

    • Jarek Żeliński 1 kwietnia 2012 at 19:16

      nie rozu­miem co i po co powtarzamy?

  4. Adam Cieloch 19 lutego 2013 at 17:28

    W pro­jek­tach zło­żo­nych sys­te­mów, powsta­nie mode­lu dzie­dzi­no­we­go powin­no być poprze­dzo­ne powsta­niem mode­lu kom­po­nen­tów (tak­że sto­sow­ny dia­gram UML), któ­ry jest pośred­nią war­stwą abs­trak­cji w takich projektach.”

    Mógłby Pan to roz­wi­nąć chy­ba nie cho­dzi tutaj o stric­te o jeden z rodza­ju dia­gra­mu UML?
    Czy takie dzia­ła­nie jest jakąś for­mą gene­ra­li­za­cji tego co będzie znaj­do­wa­ło się w takim mode­lu z mode­lem dziedzinowym”?

    • Jarek Żeliński 19 lutego 2013 at 20:57

      Chodzi o dokład­nie dia­gram kom­po­nen­tów UML. Zależnie od zło­żo­no­ści pro­jek­tu kla­sa DaneOsoby to może być pro­sta kla­sa małe­go sys­te­mu zapa­mię­tu­ją­ce­go mię­dzy inny­mi pod­sta­wo­we dane zare­je­stro­wa­ne­go użyt­kow­ni­ka, może to być korzeń więk­sze­go agre­ga­tu opi­su­ją­ce­go dane oso­bo­we a może to być inter­fejs imple­men­tu­ją­cy duży kom­po­nent KadryPłace. Jeżeli pro­jekt jest na tyle duże, że zmu­szał by do pra­cy z mode­lem dzie­dzi­ny mają­cym np. 200 klas, powin­no się podzie­lić to na dzie­dzi­no­wo (meto­dy podzia­łu na kom­po­nen­ty to osob­na histo­ria ;)) na kil­ka, góra kil­ka­na­ście kom­po­nen­tów i ope­ro­wać na mode­lu dzie­dzi­ny na wyż­szym pozio­mie abs­trak­cji” z kil­ku­na­sto­ma kla­sa­mi inter­fej­sów, zamiast dzie­siąt­ka­mi klas konkretnych…

  5. Ewelina 27 listopada 2013 at 15:17

    Ten arty­kuł jest esen­cją całe­go pro­ce­su ana­li­zy, zna­cze­nie każ­de­go dia­gra­mu jest bar­dzo dobrze opi­sa­ne i co naj­waż­niej­sze, nastę­pu­je spój­na kom­ple­ta­cja wszyst­kich poprzed­nich ele­men­tów w jed­ną całość. Z UML‑a korzy­sta już coraz wię­cej osób, nato­miast cza­sem mam wra­że­nie, że nie do koń­ca wie­dzą co z tym zro­bić. A i jesz­cze to zrzu­to­wa­nie pro­ce­sów biz­ne­so­wych na UC, świet­ne i pro­ste podej­ście do połą­cze­nia dwóch nota­cji. Bardzo dzię­ku­ję za ten artykuł 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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