Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

SPEM

Autorzy spe­cy­fi­ka­cji piszą, że celem SPEM jest:

przed­sta­wie­nie wyczer­pu­ją­cej defi­ni­cji Meta-Modelu Inżynierii Procesów Oprogramowania i Systemów […]. Metamodel wyko­rzy­stu­je UML jako nota­cję i przyj­mu­je podej­ście zorien­to­wa­ne obiektowo.

Specyfikacja ta ope­ru­je na bar­dzo dużym pozio­mie ogól­no­ści (meta­mo­del), ale mimo to pre­cy­zyj­nie opi­su­je upo­rząd­ko­wa­ne podej­ście do pro­ce­su wytworzenia/dostarczenia opro­gra­mo­wa­nia. Stanowi for­mę stan­da­ry­za­cji tego pro­ce­su (inży­nie­rii oprogramowania).

Etapy procesu tworzenia systemu

Autorzy wyróż­nia­ją: etap ana­li­zy biz­ne­so­wej, któ­re­go celem jest oce­na moż­li­wo­ści, rodzaj stu­dium wyko­nal­no­ści (OE) oraz etap opra­co­wa­nia i dostar­cze­nia roz­wią­za­nia (PA, A, DC, I). W tym dru­gim wydzie­lo­no trze­cią fazę: pro­jek­to­wa­nia i wyko­na­nia imple­men­ta­cji (DC i I). Taki podział jest zgod­ny z trze­ma typa­mi mode­li MDA (Model Driven Architecture) odpo­wied­nio: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model). Wydzielenie samo­dziel­ne­go trze­cie­go eta­pu ma fun­da­men­tal­ne zna­cze­nie: oddziel­nie pro­jek­to­wa­nia roz­wią­za­nia od jego dostar­cze­nia. Powodem jest od daw­na sta­wia­na teza, że to rynek powi­nien decy­do­wać o wybo­rze tech­no­lo­gii wyko­na­nia i dawać szan­sę na wyko­rzy­sta­nie dostęp­ne­go już na ryn­ku roz­wią­za­nia zgod­ne­go z opi­sem wyma­ga­nej logi­ki dzia­ła­nia. Innymi sło­wy decy­zja o tym, że roz­wią­za­nie (apli­ka­cja) jest dedy­ko­wa­ne, powin­na zapa­dać nie na począt­ku a dopie­ro po opra­co­wa­nie pro­jek­tu i upew­nie­niu się, że żad­ne ist­nie­ją­ce już na ryn­ku roz­wią­za­nie do nie­go nie pasuje.

Iteracyjny proces wytwarzania

Autorzy zwra­ca­ją uwa­gę, że pro­ces ten nie jest tak zwa­nym wodo­spa­dem. Na eta­pie PA (powyż­szy dia­gram) powsta­je tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu i przy­pad­ki uży­cia (te są wywo­dzo­ne z eta­pu OE). Kolejne pro­duk­ty do mode­le i ich imple­men­ta­cje. Kolejne ite­ra­cje to roz­wój dostar­czo­ne­go rozwiązania: 

Struktura procesu

Ciekawą for­mę poka­za­nia tego zapro­po­no­wa­li auto­rzy specyfikacji:

MOF – poziomy abstrakcji

Modele powsta­ją­ce w wyżej opi­sa­nym pro­ce­sie zosta­ły tak­że ​„nało­żo­ne” na spe­cy­fi­ka­cję MOF (Meta Object Facility): 

W dużym skró­cie: M3 to wspól­ny meta­mo­del nota­cji w OMG. Poziom M2 to meta-mode­lo­wa­nie (kla­sy obiek­tów), to obszar reali­za­cji ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo, to tu defi­nio­wa­ny jest SPEM. M1 to fra­me­wor­ki i ich pro­duk­ty. Pokazano to na przy­kła­dzie poniżej:

Role i produkty

Z per­spek­ty­wy ana­li­zy i pro­jek­to­wa­nia istot­ne są role i głów­ne tak zwa­ne artefakty:

Jak widać klu­czo­wa jed­nost­ką pra­cy (work bre­ak­down struc­tu­re) jest przy­pa­dek uży­cia. Nie ma tu ana­li­ty­ka Biznesowego :). 

Przypadki użycia i ich statusy

Zależnie od podej­ścia («High Ceremony» lub «Low Ceremony») zarzą­dza­my sied­mio­ma lub trze­ma sta­tu­sa­mi przy­pad­ków uży­cia (ja oso­bi­ście sto­su­ję wer­sje z trzema).

Opisałem tu po krót­ce klu­czo­we ele­men­ty SPEM, zain­te­re­so­wa­nym deta­la­mi pole­cam zapo­zna­nie się z oryginałem.

Podsumowanie

Podsumowując moż­na to przed­sta­wić tak:

Powyższy dia­gram pokazuje: 

• Wymagania (cele) biz­ne­so­we jako cele kon­kret­ne­go pro­jek­tu (okre­ślo­ny pro­blem jaki orga­ni­za­cja ma do rozwiązania),
• Analiza i projektowanie:
  • Audyt i analiza
    • Model moty­wa­cji biz­ne­so­wej (jako test spój­no­ści wizji projektu), 
    • Dziedzinowe tek­sty czy­li ​„pro­za” i for­mu­la­rze sto­so­wa­ne w organizacji,
    • Na bazie tek­stów dzie­dzi­no­wych budo­wa­na jest onto­lo­gia (słow­nic­two i związ­ki poję­cio­we, jakie zosta­ną uży­te w modelach)
    • Na bazie mode­lu Motywacji biz­ne­so­wej powsta­ją Modele pro­ce­sów biz­ne­so­wych, te korzy­sta­ją z Ontologii,
  • Projektowanie roz­wią­za­nia
    • Przypadki uży­cia wywo­dzo­ne z pro­ce­sów biznesowych,
    • Struktury doku­men­tów wywo­dzo­ne z pro­ce­sów biz­ne­so­wych (ich pro­duk­ty), odwo­łu­ją się do Przypadków Użycia i są ich czę­ścią (imple­men­ta­cja usług),
    • Architektura wywo­dzo­na z tre­ści dokumentów, 
    • Każdy przy­pa­dek ma wła­sną imple­men­ta­cję zbu­do­wa­ną jako sce­na­riu­sze komu­ni­ka­cji mię­dzy kom­po­nen­ta­mi (archi­tek­tu­ra).
• Przypadki uży­cia i ich archi­tek­tu­ra imple­men­ta­cji są bazą dla wyko­na­nia tej imple­men­ta­cji czy­li dzia­ła­ją­ce­go oprogramowania.

Na zakończenie

Czy to trud­ne? No nie jest to łatwe z uwa­gi na war­stwę abs­trak­cyj­ną sta­no­wią­cą fun­da­ment cało­ści pro­jek­tu: trze­ba ją rozu­mieć. Czy to wodo­spad? Nie. Pierwsze dwa eta­py to od kwar­ta­łu do poło­wy roku, zależ­nie od ska­li pro­jek­tu, gdzie w przy­pad­ku więk­sze­go pro­jek­tu ite­ra­cyj­ne imple­men­ta­cje usług mogą zostać roz­po­czę­te w toku prac nad projektem.

Czy świat tak reali­zu­je pro­jek­tu? Owszem, np. tak: Use Case 2.0.

Pytania?

Piszcie tu pod artykułem. 

Źródła