Visual Paragim Agilian 11.0

Pojawiła się ocze­ki­wa­na wer­sja 11 pakie­tu CASE fir­my Visual-Paradigm. Przede wszyst­kim roz­wój pro­duk­tu idzie w kil­ku głów­nych kie­run­kach: wspar­cie dla wizu­al­ne­go pro­jek­to­wa­nia apli­ka­cji (mock-up’y, kolej­ne uła­twie­nia w two­rze­niu i inte­gro­wa­niu mode­li UML), sta­ły roz­wój wspar­cia dla archi­tek­tu­ry kor­po­ra­cyj­nej (to narzę­dzie pozwa­la two­rzyć mode­le powią­za­ne ze sobą, pozwa­la na pro­wa­dze­nie ana­liz wpły­wu i wie­lu innych, wspie­ra tak­że nota­cję ArchiMate) oraz na praw­dę bar­dzo sil­ne wspar­cie dla pra­cy gru­po­wej. Co dzi­siaj ogła­sza producent:

Visual Paradigm International Limited today [16.12.2013] anno­un­ced the rele­ase of Agilian (AG) 11.0, a Visual Modeling tool for Agile Modeler. In this rele­ase, Agilian intro­du­ces 49 new featu­res and enhan­ce usa­bi­li­ty of vario­us types of diagrams.

What’s new in Agilian 11.0?

  • Supported ArchiMate Viewpoint
  • Use Case List
  • Actor List
  • Requirement List
  • Use Case Notes
  • Web wire­fra­me
  • Android pho­ne wireframe
  • Android tablet wireframe
  • iPhone app wireframe
  • iPad app wireframe
  • Desktop appli­ca­tion wireframe
  • Plan and mana­ge deve­lop­ment acti­vi­ty with Tasifier

(New Releases and Feature Enhancements of Visual Paragim Products).

Nowe narzę­dzie wspie­ra­ją­ce pro­ces ana­li­zy wymagań:

W moich oczach to narzę­dzie wysu­wa się na czo­ło w tym seg­men­cie. Koszt vs. uży­tecz­ność zosta­wia w tyle zarów­no dro­gie pro­duk­ty IBM (Rational Rose) jak i mało przy­dat­ne (nie trzy­ma­nie stan­dar­dów) SPARX Enterprise Architect. Do tego pro­dukt VP jest w ok. 80% spo­lsz­czo­ny (pra­ce trwa­ją). pro­jek­ty Rational Rose mogą być impor­to­wa­ne, pro­jek­ty SPARX EA tyl­ko w czę­ści (EA nie respek­tu­je w peł­ni stan­dar­du UML/XMI).

Oprogramowanie Visual-Paradigm to tak­że wspar­cie dla gene­ro­wa­nia kodu, inży­nie­rii wstecz­nej (doku­men­to­wa­nie kodu ist­nie­ją­ce­go), pro­jek­to­wa­nia baz danych i mapo­wa­nia ORM, całe­go pro­ce­su ana­li­zy i rein­ży­nie­rii pro­ce­sów biz­ne­so­wych wraz z testo­wa­niem mode­li i symu­la­cja­mi procesów.

Modelowanie obiektowe, procesy biznesowe, inżynieria oprogramowania

CASE czyli komputerowe wspomagania analizy i projektowania systemów

Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć co mamy” czy opi­sać wyma­ga­nia na to cze­go jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Model warstw AK

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my wymy­śla­ne” w celu jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Przykładowy proces biznesowy

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przypadki użycia aplikacji

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Czynność_4 - Scenariusz

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Macierz Procesy na uslugi

Macierz Uslugi na kommponenty

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

Czynność_4 Analiza wpływu

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).

WYCIĘTE Z MEJLI (AD ABSURDUM): Rozumiem

Od jakie­goś cza­su śle­dzę blog WYCIĘTE Z MEJLI (AD ABSURDUM) (gorą­co pole­cam). Dzisiaj prze­czy­ta­łem to:

Ms-OfficeRozumiem, że lubi Pan pra­co­wać w pho­to­sho­pie, ale uwa­ża­my że ten pro­gram jest za mało uni­wer­sal­ny. Proszę pra­co­wać w MS Paint, będzie nam łatwiej edy­to­wać Pana pli­ki i wsta­wiać popraw­ki.” (za pomo­cą WYCIĘTE Z MEJLI (AD ABSURDUM): Rozumiem).

Dokładnie mie­siąc temu u jed­ne­go z klien­tów usły­sza­łem ana­lo­gicz­ny zarzut, któ­ry moż­na by parafrazować:

Rozumiem, że lubi Pan pra­co­wać w mode­le­rze” (mój CASE VP-Agilian), ale uwa­ża­my że ten pro­gram jest za mało uni­wer­sal­ny. Proszę pra­co­wać w MS PowerPoint, będzie nam łatwiej edy­to­wać Pana pli­ki i wsta­wiać poprawki.”

No i cały czar prysł… to była duża kor­po­ra­cja z wła­snym, dużym dzia­łem deve­lop­men­tu… narze­ka­ją na duże kosz­ty pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia… Nazywam to kul­tu­rą kor­po­ra­cyj­ną MSOffice”.

Na koniec deli­kat­nie przy­po­mnę, że powsta­ją­ca gra­fi­ka czy opra­co­wa­nie tek­sto­we, to dzie­ło jego auto­ra (Ustawa o pra­wach autor­skich), i nie moż­na zgła­szać uwag do cudze­go dzie­ła mody­fi­ku­jąc je… za to moż­na być auto­rem wła­snych uwag :).

Na zakoń­cze­nie: z tego powo­du tak­że nie uży­wam opro­gra­mo­wa­nia Enterprise Architect fir­my SPARX, jest nie­kom­pa­ty­bil­ny w 100% ze spe­cy­fi­ka­cja­mi OMG, jest sier­mięż­ny i pra­co­chłon­ny. wyma­ga wie­lu dar­mo­wych lub płat­nych plug-inów by spraw­nie z nie­go korzystać.

O narzędziach CASE – rzadko ale jednak piszę

Prawdę mówiąc zabra­niam” przy­no­sze­nia kom­pu­te­rów na moje szko­le­nia, wyma­gam papie­ru i ołów­ka. Powody są dwa:
  1. Narzędzia CASE poma­ga­ją tyl­ko wte­dy gdy dia­gra­mów jest wie­le i model jest zło­żo­ny, na szko­le­niach takich mode­li się nie robi.
  2. Narzędzia, w szcze­gól­no­ści nie­któ­re, pła­ta­ją figle i szko­le­nie np. z zakre­su ana­li­zy biz­ne­so­wej ewo­lu­uje w stro­nę szko­le­nia z obsłu­gi narzę­dzia.… do cze­go nie dopuszczam :).

Napisze tu kil­ka słów jed­nak o narzę­dziach, bo dobrze jest jed­nak znać dobre i złe cechy swo­je­go narzędzia.

Spotykam się nie raz z bar­dzo popu­lar­nym pakie­tem CASE (SPARX Enteprise Architect) na szko­le­niach (ma go wie­lu kur­san­tów i jest uży­wa­ny w wie­lu fir­mach) i u nie­któ­rych klien­tów. Pakiet ten jed­nak nie raz spra­wiał pew­ne kło­po­ty. Nie znam zbyt dobrze tego narzę­dzia w obec­nej wer­sji, wiem, że model prze­cho­wy­wa­ny jest w rela­cyj­nej bazie danych, ale nie­daw­no tra­fi­łem na coś, co wyja­śnia mi pew­ne przy­go­dy z pakie­tem Enterprise Architect”. Przytaczam cały aka­pit z tego opi­su, bo to w zasa­dzie jest to lista wad tego pakie­tu. Problemy z pro­jek­tem, a kon­kret­nie z jego inte­gral­no­ścią mogą poja­wić się…

…w nastę­pu­ją­cych sytuacjach:

Z mode­lu korzy­sta wie­lu użyt­kow­ni­ków, któ­rych połą­cze­nia sie­cio­we mogą być prze­ry­wa­ne. Wystarczy, że jest praw­do­po­do­bień­stwo, że ktoś bez zamy­ka­nia pro­jek­tu wypnie z sie­ci lap­top lub zosta­nie zerwa­ne połą­cze­nie VPN.

Model jest skon­fi­gu­ro­wa­ny z sys­te­mem kon­tro­li wer­sji. W takim przy­pad­ku mamy do czy­nie­nia z wie­lo­ma ope­ra­cji impor­tu pli­ków XMI. Zawartość takich pli­ków może pocho­dzić z inne­go mode­lu a połą­cze­nie takich danych może skut­ko­wać utra­tą inte­gral­no­ści na przy­kład w zakre­sie uży­tych ste­reo­ty­pów, czy rela­cji do ele­men­tów spo­za pli­ku XMI.

Model bywa aktu­ali­zo­wa­ny w opar­ciu o pli­ki XMI przy uży­ciu funk­cji Import Package from XMI lub Batch XMI Import. Sytuacja jest ana­lo­gicz­na do powyższej.

Model jest zin­te­gro­wa­ny z inny­mi aplikacjami/systemami, taki­mi jak HP Quality Center, Mantis itp.

Model jest wyko­rzy­sty­wa­ny przez jed­ne­go użyt­kow­ni­ka w posta­ci lokal­ne­go pli­ku EAP, jed­nak­że pod­czas wyko­ny­wa­nia jakiejś ope­ra­cji pro­gram EA lub sys­tem ope­ra­cyj­ny uległ awarii.

Z powyż­sze­go opi­su wyni­ka, że z funk­cji tej (kon­tro­la inte­gral­no­ści pro­jek­tu) nale­ży korzy­stać przede wszyst­kim w przy­pad­ku, gdy mamy do czy­nie­nia ze współ­dzie­lo­nym mode­lem, jak i w przy­pad­ku lokal­ne­go pro­jek­tu opra­co­wy­wa­ne­go przez jed­ną oso­bę. Może tyl­ko z tą róż­ni­cą, że praw­do­po­do­bień­stwo wystą­pie­nia nie­spój­no­ści jest wyż­sze w tym pierw­szym przypadku.

(Enterprise Architect Blog: Project Integrity Check od środ­ka).

Wszystkie powyż­sze sytu­acje to efekt tego, że EA do pra­cy w gru­pie (samo­dziel­nie tak­że) musi pra­co­wać na rela­cyj­nej bazie, na któ­rej pra­ca ta odby­wa się siła rze­czy on-line. Po dru­gie nie ma on narzę­dzia kon­tro­li spój­no­ści pro­jek­tu (danych w tej bazie) w locie” więc moż­na two­rzyć zły model” nie wie­dząc o tym…

Dlaczego o tym pisze? Używam pakie­tu Visual-Paradigm (wię­cej o nim na koń­cu). Pakiet ten nie ma żad­nej z tych wad, pra­cu­je zawsze off-line na pli­ku XML i znisz­cze­nie pro­jek­tu jest mało praw­do­po­dob­ne. Jeżeli zda­rza się utra­ta inte­gral­no­ści to raczej w sytu­acji gdy użyt­kow­nik usu­wa wybra­ne ele­men­ty mode­lu i zigno­ru­je ostrze­że­nie o powią­za­niach tych ele­men­tów z inny­mi usu­wa­ją je ręcz­nie bez wbu­do­wa­nej kon­tro­li. Pakiet VP ma moż­li­wość pra­cy z tak zwa­ną kon­tro­lą skład­ni w locie” więc w zasa­dzie nie moż­li­we jest two­rze­nie złe­go” modelu.

W przy­pad­ku pra­cy gru­po­wej (z ser­we­rem dedy­ko­wa­nym VP Teamwork Server lub Subversion, Perforce, ClearCase czy CVS.) uszko­dze­nie pro­jek­tu tak­że jest nie­mal­że nie­moż­li­we, bo tu tak­że pra­ca odby­wa się off-line, a upda­te pro­jek­tu jest nie tyl­ko trans­ak­cją, ale jak tyl­ko zosta­ną wykry­te kon­flik­ty pomię­dzy aktu­al­nym pro­jek­tem na ser­we­rze a pro­jek­tem łado­wa­nym na ser­wer (robi to ser­wer lub klient VP z dokład­no­ścią do obiek­tu na mode­lach) poka­zy­wa­na jest lista kon­flik­tów (nie­roz­strzy­gal­nych auto­ma­tycz­nie) z proś­bą o reakcję.

Tak więc jeże­li ktoś z Państwa nie doko­nał wybo­ru narzę­dzia CASE a pla­nu­je taki, war­to prze­te­sto­wać dostęp­ne na ryn­ku pro­duk­ty w warun­kach nie­co cięż­szych” niż kil­ka dia­gra­mów… Poniżej klu­czo­we korzy­ści ze sto­so­wa­nia narzę­dzi CASE:

Make a pie. Estimate the % time you are spen­ding on the­se five requ­ire­ments acti­vi­ties: plan­ning, eli­ci­ting, ana­ly­zing, docu­men­ting and revie­wing. Does it look like this?

Źródło: Business Analyst | 2 Requirements Tasks You’re Probably Spending Too Much Time On

Więcej o narzę­dziach Visual-Paradigm

Projekt wykonany – co było robione

Ostatni arty­kuł o pro­ce­sie ana­li­zy i pro­jek­to­wa­nia koń­czył się tak:

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 archi­tek­ta). (UML Process czy­li od biz­ne­su do pro­jek­tu logi­ki sys­te­mu).

Często dosta­ję pyta­nia o ogól­ną, poglą­do­wą mapę takie­go pro­jek­tu by łatwo było oce­nić czym jest opi­sy­wa­ne śla­do­wa­nie, jaka jest kolej­ność pra­cy i jakie mode­le powsta­ją. Podjąłem pró­bę poka­za­nia tego:

Kolejność pra­cy (klik­nij by powiększyć):

  1. Określenie celu biz­ne­so­we­go, powsta­je doku­ment wyja­śnia­ją­cy jakie biz­ne­so­we” korzy­ści chce­my (orga­ni­za­cja) osią­gnąć, nie powin­no być celem samym w sobie kupie­nie cze­goś (np. sys­te­mu ERP), korzy­ści te powin­ny być wyra­żo­ne osta­tecz­nie w pie­nią­dzu (potrzeb­ne do ana­li­zy ren­tow­no­ści projektu).
  2. Kolejny etap to opra­co­wa­nie mode­lu moty­wa­cji biz­ne­so­wej, będzie to mate­riał do wypra­co­wa­nia Wymagań Biznesowych. Model ten zawie­ra prze­ło­że­nie celu biz­ne­so­we­go na wyma­ga­ne dzia­ła­nia: tak­ty­kę i stra­te­gię jego osią­gnię­cia: raz jest to reor­ga­ni­za­cja a raz nowy sys­tem ERP. Tu poja­wia­ją się takie ele­men­ty jak ana­li­za SWOT czy oddzia­ły­wa­nia, ana­li­za wyko­ny­wal­no­ści i oce­ny wpły­wu oto­cze­nia na pro­jekt. Powstają Wymagania Biznesowe (źró­dłem są stra­te­gia i tak­ty­ka osią­ga­nia celu biz­ne­so­we­go).
  3. Następnie kolej na opra­co­wa­nie mode­lu pro­ce­sów biz­ne­so­wych dla całej orga­ni­za­cji na pozio­mie opi­su­ją­cym klu­czo­we pro­duk­ty (doku­men­ty i fak­ty). Zaczyna powsta­wać słow­nik pojęć i reguł biznesowych.
  4. Kolejny etap to dekom­po­no­wa­nie pro­ce­sów biz­ne­so­wych odpo­wie­dzial­nych” (powią­za­nych) za reali­za­cje Wymagań Biznesowych, te pro­ce­sy dekom­po­nu­je­my (uszcze­gó­ło­wio­ne mode­le) do pozio­mu czyn­no­ści two­rzą­cych i zmie­nia­ją­cych doku­men­ty i fak­ty. Dodajemy kolej­ne ziden­ty­fi­ko­wa­ne poję­cia i regu­ły. Na tym eta­pie moż­li­wa jest opty­ma­li­za­cja procesów.
  5. Jeżeli opty­ma­li­za­cja reali­zu­je wyma­ga­nia biz­ne­so­we pro­jekt się koń­czy. Jeżeli oka­zu­je się, że wyma­ga­nia biz­ne­so­we wyma­ga­ją np. tech­no­lo­gii IT, pro­jekt ma dal­szy ciąg.
  6. Określenie wyma­gań na opro­gra­mo­wa­nie to wska­za­nie tych czyn­no­ści w pro­ce­sach, któ­rych wspar­cie tą tech­no­lo­gią pomo­że zre­ali­zo­wać wyma­ga­nia biz­ne­so­we. Po ana­li­zie powsta­je na jej pod­sta­wie lista ocze­ki­wa­nych usług opro­gra­mo­wa­nia, są to tak zwa­ne przy­pad­ki uży­cia sys­te­mu. Każdy przy­pa­dek uży­cia ma okre­ślo­ny stan począt­ko­wy, koń­co­wy (ewen­tu­al­nie doku­ment jaki ma powstać), cel biz­ne­so­wy (uza­sad­nie­nie) oraz akto­ra czy­li wska­za­nie użyt­kow­ni­ka (a kon­kret­nie roli jaką peł­ni w orga­ni­za­cji). Powstaje spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (jako­ścio­wych, np. takich jak wydaj­ność czy nie­za­wod­ność). Na tym eta­pie dys­po­nu­je­my spe­cy­fi­ka­cją pozwa­la­ją­cą na szu­ka­nie goto­we­go opro­gra­mo­wa­nia na ryn­ku ofe­ru­ją­ce­go tak opi­sa­ne funk­cjo­nal­no­ści. Elementem spe­cy­fi­ka­cji wyma­gań jest słow­nik pojęć i reguł biz­ne­so­wych. Można dołą­czyć mode­le procesów.
  7. Jeżeli nie znaj­du­je­my pro­duk­tu speł­nia­ją­ce­go wszyst­kie wyma­ga­nia w 100%, decy­du­je­my, któ­re bra­ku­ją­ce wyma­ga­nia funk­cjo­nal­ne jeste­śmy goto­wi wytwo­rzyć spe­cjal­nie dla nas. Wymaga to utwo­rze­nia dla każ­dej takiej funk­cjo­nal­no­ści (przy­pad­ku uży­cia, PU) spe­cy­fi­ka­cji w posta­ci opi­su jej reali­za­cji. Jest to pro­jekt (doku­ment) zawie­ra­ją­cy tak zwa­ny model dzie­dzi­ny sys­te­mu czy­li obiek­ty biz­ne­so­we i logi­kę ich współ­dzia­ła­nia. Dla każ­de­go PU powsta­je dia­gram opi­su­ją­cy jak obiek­ty mode­lu dzie­dzi­ny reali­zu­ją” (współ­dzia­ła­nie) każ­dy przy­pa­dek uży­cia (dia­gra­my sekwencji).

Projekt ma trzy klu­czo­we eta­py: audyt orga­ni­za­cji czy­li jej pozna­nie i opra­co­wa­nie mode­lu dzia­ła­nia. Kolejny to Specyfikowanie wyma­gań na opro­gra­mo­wa­nie. Ostatni etap ana­li­zy i pro­jek­to­wa­nia to opra­co­wa­nie mode­lu logi­ki jaką ma reali­zo­wać zama­wia­ne opro­gra­mo­wa­nie. Cała ta doku­men­ta­cja zawie­ra know-how orga­ni­za­cji war­ty ochrony.

Na dia­gra­mie poka­za­no tak zwa­ne śla­do­wa­nie” czy­li kolej­ne wywo­dze­nie ele­men­tów mode­li z poprze­dza­ją­cych je ogól­niej­szych eta­pów ana­li­zy. Taka doku­men­ta­cja pozwa­la unik­nąć kosz­tow­ne­go odkry­wa­nia potrzeb­nych funk­cjo­nal­no­ści pod­czas dostar­cza­nia kolej­nych wer­sji opro­gra­mo­wa­nia i prze­pro­jek­to­wy­wa­nia go. Specyfikacja logi­ki sys­te­mu pozwa­la dokład­nie spre­cy­zo­wać jakie opro­gra­mo­wa­nie jest zama­wia­ne (co ma ono reali­zo­wać i jak). Całość to opis know-how, któ­ry nadal zosta­je przy zama­wia­ją­cym (jest posia­da­czem praw do tej doku­men­ta­cji bo wyko­nał ja sam lub zle­cił nie­za­leż­ne­mu ana­li­ty­ko­wi a nie dostaw­cy oprogramowania).

Skąd się bio­rą problemy

Przytłaczająca więk­szość pro­jek­tów to roz­po­czę­cie pra­cy od pró­by zebra­nia wyma­gam funk­cjo­nal­nych z pomi­nię­ciem całej ana­li­zy biz­ne­so­wej. Jedynym więc ich źró­dłem są przy­szli użyt­kow­ni­cy, Ci jed­nak po pierw­sze nie mają wie­dzy o kon­tek­ście zaś ich cele są inne niż spon­so­ra pro­jek­tu. Nie mamy żad­ne­go narzę­dzia pozwa­la­ją­ce­go spraw­dzić zasad­ność każ­de­go z tak zebra­nych wyma­gań ani tego czy są spój­ne i kom­plet­ne”. W efek­cie nie­spój­no­ści i bra­ku­ją­ce wyma­ga­nia odkry­wa­ny dopie­ro w trak­cie projektu.

Metody zwa­ne zwin­ny­mi idą jesz­cze dalej: pra­ce dewe­lo­per­skie są roz­po­czy­na­ne są zanim powsta­nie kom­plet­na spe­cy­fi­ka­cja, poja­wia­ją­ce się wyma­ga­nia są natych­miast, z pomi­nię­ciem ich mode­lo­wa­nia i wery­fi­ka­cji pomy­słu, imple­men­to­wa­ne (kod to pierw­szy model i wery­fi­ka­cja). Ryzyko, że nowe, odkry­wa­ne w trak­cie tego pro­ce­su, wyma­ga­nia i meto­dy ich imple­men­ta­cji będą nie­spój­ne czy wręcz sprzecz­ne jest ogrom­ne co poka­zu­je prak­ty­ka: meto­dy zwin­ne dają pro­duk­ty nie raz po bar­dzo wie­lu ite­ra­cjach i naj­czę­ściej są kon­trak­to­wa­ne umo­wa­mi czas i mate­riał”, bo w zasa­dzie ina­czej się tym wypad­ku nie da. Deklarowanie ter­mi­nów i budże­tu wyma­ga­ło by ogrom­nych narzu­tów na nie­wie­dzę w momen­cie roz­po­czy­na­nia pra­cy (co jest tak­że powszech­na praktyką).

Na zakoń­cze­nie

Opisany pro­ces jest zgod­ny z zale­ce­nia­mi OMG​.org (http://​www​.omg​.org/​mda). Audyt to etap CIM (stan­dar­do­wo [[nota­cja BPMN]], sys­tem pojęć i [[nota­cja BMM]], hie­rar­chia struk­tu­ry orga­ni­za­cyj­nej, słow­nik reguł i pojęć) a pro­jek­to­wa­nie przy­pad­ków uży­ci i mode­lu dzie­dzi­ny to etap PIM (Platform Independent Model, [[nota­cja UML]]).

Wykonanie takiej ana­li­zy jest pra­co­chłon­ne i wyma­ga duże­go doświad­cze­nia, umie­jęt­no­ści ana­li­zy pro­ce­sów biz­ne­so­wych, pro­jek­to­wa­nia obiek­to­we­go i dobre­go narzę­dzia CASE, jed­nak mode­le te pozwa­la­ją tak­że prze­pro­wa­dzić ana­li­zy wpły­wu (zależ­no­ści pomię­dzy pro­ce­sa­mi, skut­ki i podat­ność na awa­rie opro­gra­mo­wa­nia itp.) oraz zre­du­ko­wać do mini­mum praw­do­po­do­bień­stwo prze­kro­cze­nia ter­mi­nu i kosz­tów (sta­ty­sty­ki wska­zu­ją na śred­nie prze­kro­cze­nie kosz­tów o 60% i ter­mi­nów o 200% pro­jek­tów z niskiej jako­ści spe­cy­fi­ka­cji wymagań).

Praktyka auto­ra wska­zu­je, że war­to taką ana­li­zę prze­pro­wa­dzić dla pro­jek­tów, któ­rych budżet prze­kra­cza 50 – 70 tys, zł i więk­szych, jej koszt jest zawsze znacz­nie niż­szy niż ryzy­ko­wa­ne 60% budże­tu. Paradoksalnie, w tych więk­szych pro­jek­tach, zbie­ra­nie wyma­gań i zarzą­dza­nie nimi meto­da­mi warsz­ta­tów i ankiet wyma­ga zaan­ga­żo­wa­nia wie­lu pra­cow­ni­ków po stro­nie zarów­no klien­ta jak i dostaw­cy (np. [[sesje JAD]]), z regu­ły jest to więk­szy koszt niż jeden ana­li­tyk z opi­sa­ny­mi kom­pe­ten­cja­mi i narzę­dzia­mi pra­cy, a otrzy­ma­ny pro­dukt – spe­cy­fi­ka­cja wyma­gań – niż­szej jako­ści (pro­ble­my spój­no­ści i kompletności).

(autor uży­wa pakie­tu CASE ana­li­tycz­no-pro­jek­to­we­go Agilian fir­my Visual Paradigm)

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