(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, PIM i PSM (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.