Struktura projektu UML

V‑model i zarządzanie jakością

Ten arty­kuł to krót­ki wpis o tak zwa­nym V‑modelu. Jest to model wytwa­rza­nia opar­ty na pętli ana­li­zy, pro­jek­to­wa­nia, testo­wa­nia i prze­ka­za­nia do użyt­ku. Oparty jest połą­cze­niu dwóch cykli życia: pro­jek­to­wa­nia i wytwa­rza­nia. jest sto­so­wa­ny w sze­ro­ko poję­tej inży­nie­rii sys­te­mów, nie koniecz­nie oprogramowania. 

W bran­ży IT zna­na jego postać wyglą­da np. tak:

V‑Model is also refer­red to as the Verification and Validation Model. In this, each pha­se of SDLC must com­ple­te befo­re the next pha­se starts. It fol­lows a sequ­en­tial design pro­cess the same as the water­fall model. The testing of the devi­ce is plan­ned in paral­lel with a cor­re­spon­ding sta­ge of deve­lop­ment. (źr.: V‑model (Software Engineering) – javat­po­int).

Niedawno w innej wer­sji v‑model publi­ko­wa­łem, pisząc o tym czym jest mecha­tro­ni­ka :

Bardzo czę­sto auto­rzy piszą, że jest to skom­pro­mi­to­wa­ny, tak zwa­ny wodo­spa­do­wy (water­fall), sys­tem wytwa­rza­nia opro­gra­mo­wa­nia. Była by to praw­da, gdy zawsze cho­dzi­ło o hipo­te­tycz­ny cały sys­tem”. Jednak V‑model, jako meto­da, nie pre­cy­zu­je ska­li pro­jek­tu. W przy­pad­ku więk­szo­ści daw­nych kon­struk­cji mecha­nicz­nych była by to praw­da, jed­nak modu­ło­wość to od lat cecha każ­dej kon­struk­cji inży­nier­skiej. Model ten więc nie koniecz­nie musi być tym złym wodo­spa­dem”. Pojawiają się od cza­su do porów­na­nia mię­dzy wodo­spa­dem, v‑modelem a agi­le, jako meto­da­mi, jed­nak ich auto­rzy nie pre­cy­zu­ją tego, czy w danym przy­pad­ku cho­dzi o moduł czy o cały sys­tem . Model ten jest sta­le przed­mio­tem poszu­ki­wań popra­wy jako­ści i więk­szej zwin­no­ści” .

Myślę, że kla­sycz­ny wodo­spad, jako meto­da pro­wa­dze­nia powo­li odcho­dzi w nie­pa­mięć (powi­nien). Nie zapo­mi­naj­my jed­nak, że roz­po­czy­na­nie two­rze­nia opro­gra­mo­wa­nia od pro­jek­to­wa­nia wspól­ne­go (rela­cyj­ne­go) mode­lu danych to taki wła­śnie kla­sycz­ny struk­tu­ral­ny wodo­spad. Więc jak?

Modułowe sys­te­my to w zasa­dzie zagnież­dżo­ne dwa v‑modele. Najpierw pro­jek­tu­je­my archi­tek­tu­rę cało­ści: powsta­je model kom­po­nen­to­wy. Kolejne eta­py to ite­ra­cyj­ne dostar­cza­nie poszcze­gól­nych kom­po­nen­tów. W kon­struk­cjach elek­tro­me­cha­nicz­nych i tak musi­my cze­kać na ukoń­cze­nie cało­ści (samo­chód czy pral­ka albo jest w cało­ści, albo nie mamy cze­go uży­wać). W przy­pad­ku opro­gra­mo­wa­nia może­my sku­pić sie na poje­dyn­czych komponentach. 

Poprawnie zapro­jek­to­wa­ne opro­gra­mo­wa­nie to samo­dziel­ne usłu­gi apli­ka­cyj­ne. Złożone nie raz, apli­ka­cje powsta­ją jako zbio­ry takich usług, na ryn­ku widzi­my je jako goto­we wie­lo­mo­du­ło­we sys­te­my. Jednak dedy­ko­wa­ne pro­jek­ty nie mają rygo­ru odda­nia w cało­ści”. Usługi apli­ka­cyj­ne mogą być odda­wa­ne jed­na po dru­giej. Wtedy opi­sy­wa­ny tu v‑model to naj­pierw lewa stro­na: tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu”, a następ­nie ite­ra­cyj­no-przy­ro­sto­we reali­za­cje kolej­nych kom­po­nen­tów i usług. Każda kolej­na usłu­ga (kom­po­nent) to pro­jek­to­wa­nie, imple­men­ta­cja, testy i odda­nie do użytku.

Podejścia zna­ne jako Use Case 2.0 czy Microservice, to wła­śnie takie modułowe 

Jednak nadal na eta­pie ana­liz i pro­jek­to­wa­nia auto­rzy tych pro­jek­tów bar­dzo czę­sto nadal poprze­sta­ją na opi­su idei, czy­li pro­ce­su biz­ne­so­we­go i nazwa­nych usług, nie jest to jed­nak pro­jek­to­wa­nie sys­te­mu a co naj­wy­żej biz­ne­so­we wyma­ga­nia . V‑model opie­ra się na tym, że imple­men­ta­cja jest poprze­dza­na pro­jek­to­wa­niem, czy­li swo­istym stu­dium wyko­nal­no­ści. Jest to spraw­dzo­na meto­da z każ­dej innej inżynierii: 

zanim zaczniesz budo­wać, upew­nij się, że wiesz co powin­no powstać.

Tak więc v‑model wyglą­da na dobrą meto­dę-pro­ces. To czy jest to wodo­spad czy nie, zale­ży od archi­tek­tu­ry cało­ści (mono­lit czy nie mikro­ser­wi­sy) a nie od fak­tu poprze­dza­nia imple­men­ta­cji projektowaniem.

Źródła

Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V‑Model vs. Agile: A com­pa­ra­ti­ve stu­dy on SDLC. International Journal of Information Technology and Business Management, 2(1), 26 – 30.
Mathur, S., & Malik, S. (2010). Advancements in the V‑Model. International Journal of Computer Applications, 1(12), 29 – 34.
Friman, E. (2020). BUILDING AND ADAPTING SYSML BASED SYSTEM ARCHITECTURE FRAMEWORK FOR MECHATRTONIC SYSTEMS. 75.
Arroyo, J. C. T. (2020). Analysis and Design of Enterprise Resource Planning System for a Coffee Shop. International Journal of Advanced Trends in Computer Science and Engineering, 9(3), 2972 – 2980. https://​doi​.org/​1​0​.​3​0​5​3​4​/​i​j​a​t​c​s​e​/​2​0​2​0​/​7​4​9​3​2​020

Prawo autorskie w projektach IT

Ten arty­kuł to pew­ne­go rodza­ju kon­ty­nu­acja poprzed­nie­go: Vendor lock-in. Starałem się tu wyja­śnić czym jest pro­jekt i wska­zać, że pew­ne wywo­dy praw­ni­ków wyda­ją się nie mieć żad­ne­go uzasadnienia. 

Prawo autorskie

Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy. Prawo autor­skie stwo­rzo­no z myślą o twór­cach oraz odbior­cach. (źr.: Prawa autor­skie w pro­jek­tach IT. Głównie o róż­ni­cach mię­dzy prze­nie­sie­niem praw a licen­cja­mi)

Zaskakuje mnie taka teza, bo pra­wo autor­skie, jak sama nazwa wska­zu­je, stwo­rzo­no z myślą o auto­rach. To, że ta kon­kret­na usta­wa zawie­ra wie­le odnie­sień np. do muzy­ki nie zmie­nia fak­tu, że regu­lu­je wszel­kie prze­ja­wy twór­czej dzia­łal­no­ści o indy­wi­du­al­nym cha­rak­te­rze”. Ta usta­wa dosko­na­le sobie radzi z każ­dą inży­nie­rią, i uwa­żam, że inży­nie­ria opro­gra­mo­wa­nia nie jest tu żad­nym wyjąt­kiem. Być może Pan Maruta dzia­ła tu jako lob­by­sta edżaj­lo­wych pro­gra­mi­stów”, cze­mu chy­ba daje wyraz, np. tu:

Wdrożenia sys­te­mów infor­ma­tycz­nych to zde­cy­do­wa­nie jed­ne z naj­bar­dziej skom­pli­ko­wa­nych przed­się­wzięć w bran­ży IT. Ta oczy­wi­sta oczy­wi­stość znaj­du­je swo­je potwier­dze­nie cho­ciaż­by w kosz­tach zwią­za­nych z reali­za­cją wdro­żeń oraz ska­lą ryzy­ka wyni­ka­ją­cą z ewen­tu­al­ne­go nie­po­wo­dze­nia pro­jek­tów wdro­że­nio­wych. (źr.: Jak pisać umo­wy dla pro­jek­tów IT reali­zo­wa­nych w mode­lu Agile? Cz. I.)

Słowa oczy­wi­sta oczy­wi­stość” to czę­sty wybieg reto­rycz­ny praw­ni­ków, mówią­cy roz­mów­cy nawet nie pró­buj pod­wa­żać tego co powie­dzia­łem”. Otóż nie­ste­ty wiel­ko­ści budże­tów nie są jakieś spe­cjal­nie wiel­kie na tle innych inży­nie­rii (Pan Maruta stra­szy kil­ko­ma ewe­ne­men­ta­mi, rzecz w tym, że podał przy­kła­dy głów­nie złe­go zarzą­dza­nia zakre­sem pro­jek­tów), a ska­la ryzy­ka pro­jek­tów IT jest dale­ko mniej­sza, bo nie­po­wo­dze­nia pro­jek­tów IT nie powo­du­ją np. ofiar w ludziach jak w przy­pad­ku kata­strof budow­la­nych czy komu­ni­ka­cyj­nych. A więc nie jest to żad­na oczy­wi­sta oczywistość”. 

Teza Pana Maruty i jego wywo­dy o IT natych­miast przy­po­mnia­ły mi inny arty­kuł (pole­cam):

TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK (źr.: https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

Teza auto­ra (Marcin Maruta): Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy”, jest co naj­mniej nie­zro­zu­mia­ła, a sam autor jej nie uza­sad­nia. Autor wska­zu­je na rosną­cą kom­pli­ka­cje tego pra­wa, ale nie­ja­ko sam wska­zu­je źró­dło: lob­bing pra­co­daw­ców w celu zła­go­dze­nia ochro­ny twór­ców (auto­rów czy­li ich pra­cow­ni­ków: pro­gra­mi­stów, pro­jek­tan­tów, archi­tek­tów opro­gra­mo­wa­nia). Ten wątek pozo­sta­wię bez komentarza. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych , mówi mie­dzy innymi: 

Art. 1. 1. Przedmiotem pra­wa autor­skie­go jest każ­dy prze­jaw dzia­łal­no­ści
twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci,
nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (utwór).

To zna­czy, że istot­ny jest indy­wi­du­al­ny cha­rak­ter czy­li uni­kal­ność powsta­łej tre­ści, nie jest istot­ny spo­sób jej wyra­że­nia (tekst, rysun­ki, głos), istot­ny jest fakt jej utrwa­le­nia (usta­le­nie). Artykuł ten jest bar­dzo istot­ny, bo zapis ten cał­ko­wi­cie abs­tra­hu­je od bran­ży, zasto­so­wa­nia i przy­dat­no­ści utwo­ru. Coś jest utwo­rem bo jest uni­kal­ne i powsta­ło w wyni­ku twór­czej (a więc celo­wej) dzia­łal­no­ści czło­wie­ka (czło­wie­ka bo Prawo doty­czy ludzi). Ustawa mówi wprost: 

2. W szcze­gól­no­ści przed­mio­tem pra­wa autor­skie­go są utwo­ry:
1) wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi
(lite­rac­kie, publi­cy­stycz­ne, nauko­we, kar­to­gra­ficz­ne oraz pro­gra­my
kom­pu­te­ro­we);[…]

3. Utwór jest przed­mio­tem pra­wa autor­skie­go od chwi­li usta­le­nia, cho­ciaż­by miał postać nieukończoną

Jak widać for­ma (treść lite­rac­ka, sche­ma­ty, wzo­ry mate­ma­tycz­na, pro­gram kom­pu­te­ro­wy itp.) nie ma żad­ne­go zna­cze­nia, liczy się wyłącz­nie fakt zma­te­ria­li­zo­wa­nia się utwo­ru w jakiej­kol­wiek postaci. 

Art. 2. 1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie,
prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pier­wot­ne­go.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania

Tu waż­na uwa­ga: moż­na bez pro­ble­mu opra­co­wy­wać cudze utwo­ry do szu­fla­dy”, jed­nak jakie­kol­wiek roz­po­rzą­dza­nie takim opra­co­wa­niem (nawet publi­ka­cja), wyma­ga już zgo­dy auto­ra utwo­ru pier­wot­ne­go. To bar­dzo istot­ne, bo w inży­nie­rii reali­za­cje są opra­co­wa­niem ich pro­jek­tu. Tak jak budow­la jest reali­za­cją jej pro­jek­tu wyko­na­ne­go na desce kre­ślar­skiej, tak opro­gra­mo­wa­nie może być reali­za­cją (opra­co­wa­niem) pro­jek­tu logi­ki dzia­ła­nia i archi­tek­tu­ry opro­gra­mo­wa­nia wyra­żo­nych sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi” (parz tak­że ).

Innymi sło­wy jeże­li pro­gram powstał bez takie­go pro­jek­tu, jest on fak­tycz­nie samo­dziel­nym utwo­rem pro­gra­mi­sty (co zresz­tą bar­dzo czę­sto ma miej­sce). Jeżeli jed­nak pro­gram (opro­gra­mo­wa­nie, apli­ka­cja) powstał jako opra­co­wa­nie pro­jek­tu wyra­żo­ne­go w for­mie j.w. (sche­ma­ty blo­ko­we, wzo­ry, tabli­ce, algo­ryt­my itp. ) jest wyłącz­nie imple­men­ta­cją (efekt sta­ran­ne­go dzia­ła­nia), lub utwo­rem zależ­nym, jeże­li autor oddał pew­ną okre­ślo­ną swo­bo­dę pro­ga­mi­ście. To, że to jest to rzad­ka sytu­acja (ist­nie­nie pro­jek­tu), nie zmie­nia fak­tu, że jest pro­gram nie jest tu utwo­rem a wyko­na­niem utwo­ru .

Rzesze pro­gra­mi­stów (i ich praw­ni­ków) zwal­cza­ją tą tezę bo ude­rza ona w ich monopol. 

Uważam, że orzecz­nic­two jest jed­nak po stro­nie pro­jek­tan­tów i archi­tek­tów sys­te­mów, w tym opro­gra­mo­wa­nia. Więcej o tym zagad­nie­niu napi­sa­łem w arty­ku­le Ochrona know-how. Tu sku­pię się na pro­jek­cie opro­gra­mo­wa­nia jako samo­dziel­nym i peł­no­praw­nym utwo­rze będą­cym spe­cy­fi­ka­cją opro­gra­mo­wa­nia jakie ma powstać (pro­jekt jako wymaganie).

Projektowanie

Zacznijmy od pro­ste­go przy­kła­du i słyn­ne­go zara­zem wyna­laz­ku i paten­tu (w USA). Poniższy rysu­nek to model (spe­cy­fi­ka­cja) mecha­ni­zmu dzia­ła­nia regu­la­to­ra. Nie jest to nawet rysu­nek tech­nicz­ny wyko­naw­czy. Jest to utwór w rozu­mie­niu usta­wy, bo: sta­no­wi prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny zna­ka­mi gra­ficz­ny­mi. Nie mniej jed­nak sta­no­wi bar­dzo pre­cy­zyj­ny opis mecha­ni­zmu dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obrotów. 

PODSTAWY CYBERNETYKI REGULACJA PROCESÓW FIZJOLOGICZNYCH - ppt video online  pobierz

Poniższe zdję­cie to jed­na z wie­lu moż­li­wych imple­men­ta­cji (opra­co­wa­nia) powyż­sze­go mecha­ni­zmu. I co cie­ka­we, udo­wod­nie­nie, że jest to imple­men­ta­cja (utwór zależ­ny) mecha­ni­zmu opi­sa­ne­go powy­żej, nie zaj­mie żad­ne­mu sądo­wi zbyt wie­le czasu. 

Historia automatyki - Wikiwand

Tak więc jed­no jest tu pew­ne: kon­kret­na kon­struk­cja na zdję­ciu powy­żej jest opra­co­wa­niem utwo­ru jakim jest sche­mat opi­su­ją­cy mecha­nizm dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obro­tów Watta. I nie­za­leż­nie od tego ile wła­snej inwen­cji wło­żył w to inży­nier kon­struk­tor tego kon­kret­ne­go regu­la­to­ra, jest to – kon­struk­cja na zdję­ciu – utwór zależ­ny. Poniżej inna kon­struk­cja (imple­men­ta­cja) tego same­go mecha­ni­zmu, to tak­że jest utwór zależny. 

Regulator odśrodkowy obrotów silnika rozbryzgiwacz oleju Briggs 691968 -  skladczesci.pl

Pewną cie­ka­wost­ką jest sta­no­wi­sko pol­skie­go usta­wo­daw­cy, mówią­ce że: 

Art. 28 pkt. 5 usta­wy o wła­sno­ści prze­my­sło­wej sta­no­wi, iż za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?. Wynika z tego jasno, iż pro­gram kom­pu­te­ro­wy nie może być zatem zgło­szo­ny do wła­ści­we­go urzę­du paten­to­we­go celem jego reje­stra­cji i uzy­ska­nia sto­sow­ne­go paten­tu. Autorzy pro­gra­mu kom­pu­te­ro­we­go mogą pró­bo­wać jedy­nie opa­ten­to­wać wyna­la­zek, któ­ry wspo­ma­ga­ny jest pro­gra­mem kom­pu­te­ro­wym, nie­zbęd­nym do jego pra­wi­dło­we­go funk­cjo­no­wa­nia. (źr.: Ochrona praw­na pro­gra­mów kom­pu­te­ro­wych)

Absolutnie nie jestem zwo­len­ni­kiem paten­to­wa­nia opro­gra­mo­wa­nia, a nawet gene­ral­nie jestem prze­ciw­ni­kiem paten­tów, czy­li trwa­łych mono­po­li na wyna­laz­ki ludz­kie. Skąd teza mówią­ca, że za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?”?. Wydaje się ona nielogiczna.

Popatrzmy na to. Poniżej zdję­cie mecha­ni­zmu mecha­nicz­ne­go pro­gra­ma­to­ra pral­ki: zawie­ra sil­nik i tak zwa­ne krzyw­ki ste­ru­ją­ce sty­ka­mi sterownika. 

Mechaniczny pro­gra­ma­tor pralki

Identyczne funk­cje, jako mecha­nizm ste­ru­ją­cy, reali­zu­je poniż­szy nowo­cze­sny ste­row­nik będą­cy tak na praw­dę kom­pu­te­rem (mikro­kon­tro­ler)

Programator pralki Aquamatic AQUA 100 +blokada+ silnik Sosnowiec -  Sprzedajemy.pl
Mikrokontroler peł­nią­cy funk­cję pro­gra­ma­to­ra pral­ki automatycznej. 

W pew­nych obsza­rach mecha­nizm wyko­na­ny (opra­co­wa­ny, wyna­le­zio­ny) jako kon­struk­cja mecha­nicz­na (moż­li­wa do opa­ten­to­wa­nia) może być zre­ali­zo­wa­ny w 100% z uży­ciem kom­pu­te­ra: mecha­nicz­ny aryt­mo­metr został zastą­pio­ny elek­tro­nicz­nym kal­ku­la­to­rem (to jest kom­pu­ter), mecha­nicz­ny zegar tak­że pro­gra­mem kom­pu­te­ra (czy­taj tak­że Model czy abs­trak­cja). Ładnie to opi­su­je autor publi­ka­cji nauko­wej zaty­tu­ło­wa­nej Komputer jako uni­wer­sal­ny mecha­nizm . Innymi słowy: 

sko­ro kom­pu­ter to pro­ce­sor, pamięć i pro­gram, i sko­ro 100% reali­zo­wa­nych funk­cji kom­pu­te­ra reali­zu­je pro­gram, to zna­czy sam pro­gram, bez wzglę­du na for­mę jego wyra­zu, z zasa­dy jest tu kom­plet­nym opi­sem mecha­ni­zmu dzia­ła­nia, pod­le­ga­ją­cym poten­cjal­nie ochro­nie praw­no-autor­skiej i/lub know-how.

Dokładnie z tego same­go powo­du gar­nek nie jest inte­gral­ną czę­ścią chro­nio­ne­go prze­pi­su potra­wy kuli­nar­nej (a są one chro­nio­ne pra­wem np. jako pro­duk­ty spo­żyw­cze regio­nal­ne, np. takie jak oscypek). 

Od dekad mamy do czy­nie­nia z postę­pem tech­no­lo­gii gdzie jeden z obsza­rów inży­nie­rii: sze­ro­ko poję­te sys­te­my ste­ro­wa­nia, jest sys­te­ma­tycz­nie pochła­nia­ny przez kom­pu­te­ry. Mechaniczne kon­struk­cje takie jak sys­te­my zli­cza­ją­ce, cza­so­mie­rze, kal­ku­la­to­ry, ste­ro­wa­nie opar­te o cię­gna, sys­te­my auto­ma­ty­ki, sys­te­my zobra­zo­wa­nia (np. wska­zów­ko­we: moni­tor zamiast mecha­nicz­ne­go wskaź­ni­ka) itp. są zastę­po­wa­ne przez kom­pu­ter (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram). Kolejne kon­struk­cje, do nie­daw­na wyłącz­nie mecha­nicz­ne, są zastę­po­wa­ne kom­pu­te­rem (patrz tak­że nie­daw­ny arty­kuł: Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka). Proces ten postę­pu­je, powsta­ła nota­cja (roz­sze­rze­nie UML) pozwa­la­ją­ca na mode­lo­wa­nie (spe­cy­fi­ko­wa­nie) takich mie­sza­nych kon­struk­cji: SysML:

Wszystkie powyż­sze kon­struk­cje są chro­nio­ne pra­wem autor­skim, jako ich pro­jek­ty wyko­na­ne w posta­ci udo­ku­men­to­wa­nych (usta­lo­nych) opi­sów (spe­cy­fi­ka­cji) wyko­na­nych z uży­ciem sche­ma­tów blo­ko­wych, zapi­sów związ­ków logicz­nych i wzo­rów mate­ma­tycz­nych. Tak więc teza, jako­by opro­gra­mo­wa­nie wyma­ga­ło jakie­goś inne­go spe­cjal­ne­go podej­ścia, jest moim zda­niem nie do obro­ny: jeże­li kom­pu­ter (czy­li tak­że pro­gram) może być rów­no­praw­nym funk­cjo­nal­nie zamien­ni­kiem kon­struk­cji mecha­nicz­nej (co wyka­za­no powy­żej), to zna­czy że moż­na wobec nie­go i kon­struk­cji mecha­nicz­nych, sto­so­wać te same zapi­sy w prawie. 

Podsumowanie

Czy moż­li­we jest więc opra­co­wa­nie spe­cy­fi­ka­cji dla wyko­na­nia opro­gra­mo­wa­nia, ana­lo­gicz­nej jak dla urzą­dze­nia mecha­nicz­ne­go? Oczywiście! Powyższa pozy­cja lite­ra­tu­ry to jed­na z wie­lu tego typu. Na tym blo­gu jest wie­le przy­kła­dów takich spe­cy­fi­ka­cji. Stawianie tezy, że jedy­ną moż­li­wą for­mą usta­le­nia opro­gra­mo­wa­nia jest kod źró­dło­wy, nie ma żad­ne­go uza­sad­nie­nia w fak­tach: mamy na świe­cie ogrom­ną ilość doku­men­ta­cji sta­no­wią­cej pre­cy­zyj­ną spe­cy­fi­ka­cje opro­gra­mo­wa­nia jakie ma powstać. Oczywiście nie ma obo­wiąz­ku two­rze­nia takich doku­men­tów (meto­dy nazy­wa­ne agi­le) ale po pierw­sze jest to moż­li­we, po dru­gie jest to jed­nak nadal naj­sku­tecz­niej­sza meto­da zama­wia­nia opro­gra­mo­wa­nia. Panu Marucie, świet­ne­mu praw­ni­ko­wi, pole­cam jed­nak kon­fron­to­wa­nie poglą­dów pro­gra­mi­stów któ­rych repre­zen­tu­je, z dostęp­ną lite­ra­tu­rą i nauko­wą i popu­lar­ną z zakre­su inży­nie­rii opro­gra­mo­wa­nia oraz orzecz­nic­two w tym zakre­sie, np. poniższe: 

Dokumentacja i inne mate­ria­ły doty­czą­ce pro­jek­to­wa­nia pro­gra­mu kom­pu­te­ro­we­go nale­ży trak­to­wać jako pro­gram kom­pu­te­ro­wy (imple­men­ta­cja dyrek­ty­wy Parlamentu Europejskiego i Rady 2009/24/WE dnia 23 kwiet­nia 2009 (wer­sja ujed­no­li­co­na dyrek­ty­wy Rady Wspólnoty Europejskich nr 91/250 z dnia 14 maja 1991): ?dla celów niniej­szej dyrek­ty­wy poję­cie ?pro­gram kom­pu­te­ro­wy? obej­mu­je rów­nież przy­go­to­waw­cze pra­ce pro­jek­to­we i mate­riał projektowy?.

Co potwier­dza­ją tak­że auto­rzy naj­now­szych publi­ka­cji nauko­wych, np. 

Programming is not sole­ly abo­ut con­struc­ting software?programming is abo­ut desi­gning softwa­re”. .

Podsumowując: moż­li­we jest opra­co­wa­nie doku­men­ta­cji opro­gra­mo­wa­nia opi­su­ją­cej (wyma­ga­ny) mecha­nizm jego dzia­ła­nia i archi­tek­tu­rę. Oprogramowanie powsta­łe na bazie takiej doku­men­ta­cji to imple­men­ta­cja pro­jek­tu i sta­no­wi ono utwór zależ­ny w sto­sun­ku do utwo­ru jakim jest pier­wot­na spe­cy­fi­ka­cja. Prawo autor­skie jest tu wręcz dosko­na­łym mecha­ni­zmem kon­tro­l­nym nad wyko­naw­cą opro­gra­mo­wa­nia: mając pra­wa mająt­ko­we do pro­jek­tu tech­nicz­ne­go, z zasa­dy dys­po­nu­je­my w peł­ni opro­gra­mo­wa­niem wyko­na­nym na nasze zamó­wie­nie i na pod­sta­wie takiej doku­men­ta­cji. Jeżeli dostaw­ca stwo­rzy zamó­wio­ne opro­gra­mo­wa­nie ina­czej bo po swo­je­mu, to zna­czy tyl­ko tyle, nie zre­ali­zo­wał zawar­tej umo­wy i nie nale­ży mu płacić. 

Tak zwa­ne pro­jek­ty «agi­le» to cał­ko­wi­ty brak kon­tro­li nad wyko­naw­cą i nad wła­snym know-how. Trudno się więc dzi­wić, że jest to meto­da for­so­wa­na przez dostaw­ców opro­gra­mo­wa­nia i ich prawników. 

(pole­cam tak­że ana­lo­gicz­ny pra­wo­moc­ny wyrok doty­czą­cy muzy­ków gra­ją­cych z nut pod dyk­tan­do dyry­gen­ta)

Źródła

Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Friedenthal, S., Moore, A., & Steiner, R. (2009). OMG Systems Modeling Language (OMG SysMLTM) Tutorial September, 2009. 132.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049

SysML – co warto przeczytać i mieć na półce

Miesiąc temu pisałem: 

Mechatronika i nota­cja SysML ma swo­je począt­ki w latach 90-tych. Modele w tej nota­cji powsta­wa­ły już w fir­mie Boeing (Herrold, 2016). Od tam­tej pory powsta­ło wie­le publi­ka­cji na ten temat, w tym tak­że opi­sy dobrych prak­tyk jaki­mi są wzor­ce pro­jek­to­we (Barbieri, Kernschmidt, Fantuzzi & Vogel-Heuser, 2014). Można spo­tkać coraz czę­ściej publi­ka­cje na temat sto­so­wa­nia metod pro­jek­to­wa­nia opar­tych na SysML (Van Noten, Gadeyne & Witters, 2017).Moim celem było tu zwró­ce­nie uwa­gi na tę w sumie nową dzie­dzi­nę inży­nie­rii, waż­ne by nie utoż­sa­miać jej jedy­nie z robo­ty­ką, bo było by to ogrom­ne uprosz­cze­nie, co mam nadzie­ję poka­za­łem powyż­szy­mi przy­kła­da­mi. (źr.: Inteligentna pral­ka czy­li czym jest mechatronika)

Dzisiaj kon­ty­nu­acja: kil­ka słów o zasto­so­wa­niach i pole­ca­na literatura.

To co nazy­wa­my inży­nie­rią sys­te­mów, to mul­ti­dy­scy­pli­nar­na dzie­dzi­na wie­dzy. Założeniem pod­sta­wo­wym jest uzna­nie, że na eta­pie ana­li­zy i pro­jek­to­wa­nia sys­tem (jego model) jest abs­trak­cją jakiejś imple­men­ta­cji, któ­ra nie jest zna­na. Wiemy tak­że, że obec­nie kom­po­nen­ty wszel­kich urzą­dzeń to albo ele­men­ty mecha­nicz­ne (mate­rial­ne) albo reali­zu­ją­ce ich funk­cje opro­gra­mo­wa­nie (a kon­kret­nie kom­pu­ter czy­li pro­ce­sor i pamięć oraz pro­gram). Komputer jest tu czę­sto postrze­ga­ny jako «uni­we­ral­ny mecha­nizm» (patrz tak­że ww. arty­kuł o pral­ce: pro­gra­ma­tor mecha­nicz­ny vs. elektroniczny).

Ogólnie pro­ces two­rze­nia sys­te­mu moż­na zobra­zo­wać tak:

Składa się on z trzech klu­czo­wych faz: spe­cy­fi­ko­wa­nie, pro­jek­to­wa­nie i wyko­na­nie kom­po­nen­tów, zesta­wie­nie cało­ści i odda­nie do użyt­ku. Inżynieria sys­te­mów, na eta­pie pro­jek­to­wa­nia, cał­ko­wi­cie abs­tra­hu­je od imple­men­ta­cji i jej szcze­gó­łów. Potrzeba ta poja­wi­ła się wraz ze wzro­stem zło­żo­no­ści takich kon­struk­cji jak np. samo­lo­ty. Cykl życia pro­jek­tu sys­te­mu i jego same­go (np. samo­lot lub pociąg), gdy skła­da się on z setek tysię­cy deta­li, jest nie­moż­li­wy do zarzą­dza­nia bez opra­co­wa­nia jego abs­trak­cyj­nej uogól­nio­nej posta­ci. Warto zwró­cić uwa­gę, że takim zło­żo­nym sys­te­mem jest tak­że np. nowo­cze­sna fabryka. 

W latach 90-tych opra­co­wa­no (na począt­ku lat 2000 opu­bli­ko­wa­ło OMG​.org) nota­cję SysML (roz­sze­rze­nie UML) pozwa­la­ją­ca opi­sać dowol­ny sys­tem na pozio­mie kom­po­nen­tów i związ­ków mię­dzy nimi, w cał­ko­wi­tym ode­rwa­niu od ich imple­men­ta­cji .

Filozofia SysML ope­ra się na dwóch klu­czo­wym struk­tu­rach: jest to drze­wia­sta struk­tu­ra defi­niu­ją­ca typy kom­po­nen­tów i ich zależ­no­ści całość-część (block defi­ni­tion dia­gram) oraz struk­tu­ra obra­zu­ją­ca współ­dzia­ła­nie kon­kret­nych kom­po­nen­tów okre­ślo­nych typów (inter­nal block dia­gram). Poniżej obra­zo­wy przy­kład tych dwóch struk­tur dla samochodu: 

SysML, jako meto­da mode­lo­wa­nia, ma swo­ją pozy­cję i kon­tekst wśród innych:

Standard MBSE (Model-based Systems Engineering) to podej­ście do inży­nie­rii opar­te na mode­lo­wa­niu (Prezentacja SysML). Jest to nie­ja­ko kon­ty­nu­acja abs­trak­cji w górę” począw­szy od metod takich jak CAD/CAM czy­li metod pro­jek­to­wa­nia opar­tych na rysun­ku tech­nicz­nym i mode­lach 3D. Jak wspo­mnia­łem, prak­tycz­nie każ­de urzą­dze­nie moż­na skon­stru­ować jako zespół kom­po­nen­tów mecha­nicz­nych i będą­cych kom­pu­te­rem. Jeżeli wznie­sie­my” się na wyż­szy poziom abs­trak­cji, będzie na pozio­mie nota­cji SyML. Schematycznie moż­na to poka­zać tak:

Powyższe ilu­stra­cje zaczerp­ną­łem z książ­ki A Practical Guide to SysML The System Modeling Language” . Książka zwię­zły opis nota­cji SysML oraz przy­kła­dy, dla­te­go jej walo­ry edu­ka­cyj­ne są nie do prze­ce­nie­nia. Autorzy bar­dzo dokład­nie, na wie­lu przy­kła­dach, opi­sa­li jak pro­wa­dzić cały pro­ces mode­lo­wa­nia i jak orga­ni­zo­wać mode­le np. z pomo­cą w sys­te­mów CASE. Książka tak­że krót­ki, cie­ka­wy roz­dział o tym, jak wdro­żyć w orga­ni­za­cji inży­nier­skiej kul­tu­rę mode­lo­wa­nia i tę notację. 

Teraźniejszość uczy, że mono­dzie­dzi­no­wość” pro­jek­tów powo­li odcho­dzi do lamu­sa. Prawdę mówić kom­pu­ter, jaki każ­dy kto to teraz czy­ta ma przed ocza­mi, to urzą­dze­nie mecha­tro­nicz­ne. Każdy robot prze­my­sło­wy w szcze­gól­no­ści tak­że nim jest.

Druga książ­ka, któ­rą chciał­bym pole­cić to SysML for Systems Engineering”. Autorzy tej książ­ki sku­pi­li sie na samej nota­cji, tu przy­kła­dy (w prze­ci­wień­stwie do poprzed­niej) są na dru­gim pla­nie, dla­te­go ta pozy­cja to raczej podręcznik.

Druga książ­ka, któ­rą chciał­bym pole­cić to SysML for Systems Engineering” . Autorzy tej książ­ki sku­pi­li sie na samej nota­cji, tu przy­kła­dy (w prze­ci­wień­stwie do poprzed­niej) są na dru­gim pla­nie, dla­te­go ta pozy­cja to raczej podręcznik.

Sformalizowane gra­ficz­ne (albo pik­to­rial­ne) języ­ki wyra­zu, są stan­dar­dem w każ­dej inży­nie­rii. Szybko rosną­ca zło­żo­ność ele­men­tów nasze­go oto­cze­nia, powo­du­ją, że inży­nie­ria jako taka, szyb­ko sta­je się dzie­dzi­ną wie­dzy sku­pio­na wokół pro­jek­to­wa­nia sys­te­mów. Ich fizycz­na imple­men­ta­cja to rze­mio­sło (ang. cra­ft­sman­ship), co abso­lut­nie nie zna­czy, że rze­mieśl­nik jest kimś złym. Podział taki – pro­jek­to­wa­nie i wyko­na­nie – funk­cjo­nu­je od setek lat, wszedł już nawet na dobre do inży­nie­rii oprogramowania. 

Trzecia to Systems Engineering with SysML/UML. Modeling, Analysis, Design .

UML, był pierw­szym języ­kiem opi­su i mode­lo­wa­nia zapro­jek­to­wa­nym w celu speł­nie­nia wymo­gu uni­wer­sal­no­ści”. Jest postrze­ga­ny jako język spe­cy­ficz­ny dla opro­gra­mo­wa­nia i nie wspie­ra potrzeb inży­nie­rów pro­jek­tu­ją­cych z szer­szej per­spek­ty­wy sys­te­mo­wej. W kon­se­kwen­cji powstał SysML. Stale zysku­je on na popu­lar­no­ści, a wie­le firm, zwłasz­cza z sil­nie regu­lo­wa­nych branż: Defense, Automotive, Aerospace, Medical Device i Telecomms, uży­wa SysML. Na ryn­ku nadal dostęp­nych jest nie­wie­le infor­ma­cji na temat SysML. Jego uży­cie jest dopie­ro na pro­gu upo­wszech­nie­nia się, dla­te­go tysią­ce inży­nie­rów opro­gra­mo­wa­nia zaczy­na poszu­ki­wać szko­leń i zaso­bów. Ta książ­ka będzie słu­żyć jako kom­plek­so­wy, osta­tecz­ny prze­wod­nik, któ­ry zapew­ni wpro­wa­dze­nie do SysML i instruk­cje, jak go wdro­żyć, dla wszyst­kich tych nowych użyt­kow­ni­ków. (na pod­sta­wie wstępu).

Pozycje te dosko­na­le sie uzu­peł­nia­ją. Oczywiście zawsze war­to pamię­tać, że źró­dło jest na stro­nie OMG​.org .

Dla prze­ra­żo­nych nową wie­dzą do pozy­ska­nia (pierw­sza książ­ka 600 stron, dru­ga 300, nie­ste­ty obie tyl­ko import), być może dobrą na począ­tek będzie cie­niut­ka pozy­cja Język inży­nie­rii sys­te­mów SysML: archi­tek­tu­ra i zasto­so­wa­nia : pro­fi­le UML 2.x w prak­ty­ce” , jed­nak uprze­dzam, że to tyl­ko krót­ki opis samej notacji. 

Czy to dzia­ła? jeden z czo­ło­wych dostaw­ców sys­te­mów CAD/CAM pisze (źr. pod cyta­tem, nie mam żad­nej umo­wy z fir­mą Siemens): 

W cza­sach gdy nowo­cze­sne pro­duk­ty mogą zawie­rać ele­men­ty mecha­nicz­ne, elek­tro­nicz­ne, elek­trycz­ne i opro­gra­mo­wa­nie, trud­no jest sobie wyobra­zić uży­cie narzę­dzia do mode­lo­wa­nia, któ­re może uwzględ­nić tyl­ko ogra­ni­czo­ny dzie­dzi­no­wo zestaw sche­ma­tów blo­ko­wych (np. tyl­ko mecha­nicz­ne). Zwłaszcza, że każ­da z tych dzie­dzin będzie praw­do­po­dob­nie zawie­rać wie­le wła­snych pod­sys­te­mów, któ­re inte­gru­ją się w więk­szy sys­tem sys­te­mów. Nasze [Siemens, mój przy­pis] zaan­ga­żo­wa­nie w SysML v.2. ma klu­czo­we zna­cze­nie dla przy­szło­ści roz­wo­ju pro­jek­to­wa­nia – kom­plek­so­we mode­lo­wa­nie MBSE zapew­nia szyb­sze podej­mo­wa­nie lep­szych decy­zji. Eliminuje ryzy­ko i popra­wia jakość pro­jek­tów poprzez opty­ma­li­za­cję i wery­fi­ka­cję sze­rzej poj­mo­wa­nej defi­ni­cji archi­tek­tu­ry pro­duk­tu. Przełamuje gra­ni­ce pomię­dzy dzie­dzi­no­wy­mi dzia­ła­mi roz­wo­jo­wy­mi, aby osią­gnąć inte­ro­pe­ra­cyj­ność i wymia­nę wie­dzy w całym łań­cu­chu war­to­ści. Będziemy kon­ty­nu­ować naszą pra­cę jako aktyw­ny part­ner w opra­co­wy­wa­niu stan­dar­du języ­ka mode­lo­wa­nia następ­nej gene­ra­cji oraz zgod­ne­go z nim roz­wią­za­nia MBSE, aby zre­wo­lu­cjo­ni­zo­wać spo­sób, w jaki fir­my two­rzą, udo­stęp­nia­ją i opty­ma­li­zu­ją sys­te­my w całym przedsiębiorstwie.

Polecam tak­że to:

Źródła

OMG​.org. (2017, December 8). Systems Modeling Language (SysML). http://​www​.omg​sy​sml​.org/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Hause, M. (2006). The SysML model­ling lan­gu­age. Fifteenth European Systems Engineering Conference, 9, 1 – 12.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml
Holt, J., & Perry, S. (2008). SysML for sys­tems engi­ne­ering. The Institution of Engineering and Technology.
Wrycza, S., & Marcinkowski, B. (2010). Język inży­nie­rii sys­te­mów SysML: archi­tek­tu­ra i zasto­so­wa­nia : pro­fi­le UML 2.x w prak­ty­ce. Helion.

Studium wykonalności c.d. czyli analiza systemowa rozwiązania

Wprowadzenie

?Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? . ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.?

W roku 2014 w arty­ku­le Studium wyko­nal­no­ści pro­duk­tu – czym napraw­dę jest napi­sa­łem na zakończenie:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wiedzy.

Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak najwłaściwszą.

Warto jed­nak zwró­cić uwa­gę, że wyko­nal­ność tech­nicz­na a zdol­ność do sfi­nan­so­wa­nia to nie to samo? Studium wyko­nal­no­ści tech­no­lo­gicz­nej doty­czy pro­duk­tu pro­jek­tu lub efek­tu orga­ni­za­cyj­ne­go jakie­go ocze­ku­je­my. Ocena tego czy pozy­ska­my finan­so­wa­nie to nie wyko­nal­ność a zdol­ność do sfi­nan­so­wa­nia (stu­dium wyko­nal­no­ści finan­so­wo-eko­no­micz­nej). To są róż­ne analizy.

To był arty­kuł o ogól­nych zasa­dach reali­za­cji ana­li­zy jaką jest stu­dium wyko­nal­no­ści. Tym razem o tym, czym kon­kret­nie jest etap czę­sto nazy­wa­ny Identyfikacją pro­jek­tu i czym zaj­mu­je się jako ana­li­tyk w takich pro­jek­tach.

Struktura analizy

Kontynuując wątek stu­dium wyko­nal­no­ści, opra­co­wa­nie takie moż­na zobra­zo­wać tak:

Każda inwe­sty­cja ma cha­rak­ter mate­rial­ny i finan­so­wy. Materialny doty­czy przed­mio­tu inwe­sty­cji (nowy lub zmie­nia­ny sys­tem) zaś finan­so­wy doty­czy kosz­tu jego pozy­ska­nia lub zmiany. 

Moja pra­ca to opra­co­wa­nie Modelu sys­te­mu. Potrzebuję do tego eks­per­ta dzie­dzi­no­we­go. Analiza finan­so­wa i opis finan­so­wa­nia, powsta­ją na pod­sta­wie Modelu. Całość dopie­ro sta­no­wi sobą Studium Wykonalności (nie licząc oczy­wi­ście same­go wnio­sku, któ­ry opra­co­wu­je wnioskujący).

Wymagania formalne

Instrukcje dla wnio­sko­daw­ców (np. Instrukcja spo­rzą­dza­nia Studium Wykonalności Inwestycji (Projektu) dla wnio­sko­daw­ców ubie­ga­ją­cych się o wspar­cie z Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Świętokrzyskiego na lata 2014 – 2020, dalej Instrukcja) zawie­ra­ją mię­dzy inny­mi takie zalecenia: 

Identyfikacja pro­jek­tu powin­na dostar­czyć zwię­złej i jed­no­znacz­nej infor­ma­cji na temat jego cało­ścio­wej kon­cep­cji i logicz­nych ram. Projekt powi­nien sta­no­wić samo­dziel­ną (pod kątem ope­ra­cyj­no­ści) jed­nost­kę ana­li­zy. Oznacza to, że powi­nien on obej­mo­wać wszyst­kie zada­nia inwe­sty­cyj­ne, któ­re spra­wia­ją, że efek­tem reali­za­cji pro­jek­tu jest stwo­rze­nie w peł­ni funk­cjo­nal­nej i ope­ra­cyj­nej infra­struk­tu­ry, bez koniecz­no­ści reali­za­cji dodat­ko­wych zadań inwe­sty­cyj­nych nie uwzględ­nio­nych w tym projekcie.

To ozna­cza, że musi powstać pro­jekt cało­ści roz­wią­za­nia. Studium wyko­nal­no­ści to opra­co­wa­nie poka­zu­ją­ce tak­że model roz­wią­za­nia będą­ce­go przed­mio­tem ana­li­zy, jego wewnętrz­ną struk­tu­rę i mecha­nizm działania. 

Podstawowym celem stu­dium wyko­nal­no­ści tech­nicz­nej jest uwia­ry­god­nie­nie tego, że sys­tem będą­cy przed­mio­tem wnio­sku, może powstać i speł­ni swo­ją rolę, tego że cel pro­jek­tu zosta­nie osią­gnię­ty. Celem pro­jek­tu nie może być samo tyl­ko pozy­ska­nie dotacji. 

Jak to uwia­ry­god­nić? Należy wyka­zać nie tyl­ko to, że posia­da się środ­ki na sfi­nan­so­wa­nie przed­się­wzię­cia, nale­ży przede wszyst­kim uwia­ry­god­nić to, że sys­tem powsta­nie i osią­gnię­te zosta­ną cele zapo­wia­da­ne efek­ty. Jak? Po pro­stu nale­ży opra­co­wać model sys­te­mu, nie raz wręcz od zera go zapro­jek­to­wać, i poka­zać, że rozu­mie­my to co chce­my wytwo­rzyć lub zmienić.

Studium wyko­nal­no­ści to naj­czę­ściej żąda­nie inwe­sto­ra, czy­li pod­mio­tu finan­su­ją­ce­go przed­się­wzię­cie. Celem inwe­sto­ra zaś nie jest samo tyl­ko wyda­wa­nie pie­nię­dzy. Jak już pisa­łem w arty­ku­le Studium wyko­nal­no­ści pro­duk­tu – czym napraw­dę jest, stu­dium wyko­nal­no­ści powin­no zawie­rać opis sta­nu przed­mio­tu ana­li­zy obec­ne­go i planowanego. 

Wymieniona na począt­ku Instrukcja jasno precyzuje: 

Opis sta­nu aktu­al­ne­go (przed reali­za­cją)
Elementem wyj­ścio­wym w popraw­nie spo­rzą­dzo­nej ana­li­zie jest rze­tel­ny i dokład­ny opis sta­nu aktu­al­ne­go inwe­sty­cji pla­no­wa­nej do reali­za­cji. Jasno i czy­tel­nie opi­sa­ny aktu­al­ny stan pozwa­la w spo­sób przej­rzy­sty przejść do iden­ty­fi­ka­cji ist­nie­ją­cych pro­ble­mów oraz potrzeb, a tym samym do uza­sad­nie­nia potrze­by reali­za­cji pro­jek­tu. Celem opi­su sta­nu obec­ne­go jest odda­nie peł­ne­go obra­zu sta­nu ist­nie­ją­ce­go i przed­sta­wie­nie oto­cze­nia, w któ­rym będzie reali­zo­wa­ny pro­jekt. Opis sta­nu obec­ne­go jest rów­nież pod­sta­wą oce­ny potrze­by reali­za­cji pro­jek­tu. […] Na tym eta­pie powin­ny być wska­za­ne obec­ne pro­ble­my wyni­ka­ją­ce ze sta­nu aktualnego.

Kolejna część opra­co­wa­nia powin­na zawierać:

Opis sta­nu pro­jek­to­wa­ne­go
Wymagane jest szcze­gó­ło­we dopre­cy­zo­wa­nie i uza­sad­nie­nie zakre­su rze­czo­we­go pro­jek­tu, pre­zen­tu­jąc jego cel, kwe­stie któ­rych będzie doty­czył, infra­struk­tu­rę jaka ma zostać stwo­rzo­na, itp. […] Dodatkowo, nale­ży prze­pro­wa­dzić ana­li­zę pro­jek­tu w kon­tek­ście całe­go ukła­du infra­struk­tu­ry, tj. funk­cjo­nal­ne i rze­czo­we powią­za­nia mię­dzy danym pro­jek­tem, a ist­nie­ją­cą infrastrukturą.

Zwieńczeniem cało­ści tej czę­ści Studium Wykonalności powin­na być: 

Definicja celów pro­jek­tu
Zdefiniowanie celów jest nie­zbęd­nym eta­pem słu­żą­cym iden­ty­fi­ka­cji i ana­li­zie pro­jek­tu. Stanowi ono punkt wyj­ścia do prze­pro­wa­dze­nia jakiej­kol­wiek oce­ny inwestycji.

oraz

Wskaźniki reali­za­cji celów pro­jek­tu
Realizacja celu musi być mie­rzo­na za pomo­cą przy­naj­mniej jed­ne­go wskaź­ni­ka rezultatu.

Zależnie od nabo­ru istot­ne są deta­le doty­czą­ce celów spon­so­ra, jed­nak co do zasa­dy stu­dium wyko­nal­no­ści to nie tyl­ko ana­li­za finan­so­wa. Kluczem jest wyka­za­nie, że otrzy­ma­ne środ­ki finan­so­we przy­nio­są ocze­ki­wa­ne efekty: 

Zgodnie z cyto­wa­na instruk­cją Wniosek o finan­so­wa­nie to opi­su okre­ślo­ne­go eta­pu roz­wo­ju orga­ni­za­cji (sys­te­mu): pomię­dzy Stanem aktu­al­nym a Stanem pla­no­wa­nym (patrz wykres powy­żej). Całość to nic inne­go jak stan­dar­do­wa pro­ce­du­ra tak zwa­nej ogól­nej ana­li­zy sys­te­mo­wej (któ­rej nie nale­ży utoż­sa­miać tyl­ko z sys­te­ma­mi informatycznymi):

Najpierw dowiedz­my się ?jak jest i dla­cze­go jest tak jak jest? a potem napisz­my ?jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powin­no? .

W dal­szej czę­ści opi­szę pokrót­ce jak sfor­ma­li­zo­wa­ny­mi meto­da­mi i narzę­dzia­mi moż­na wyko­nać powyż­szą analizę.

Sformalizowane modelowanie systemów 

Nie tak daw­no, w arty­ku­le o mecha­tro­ni­ce (Inteligentna pral­ka) pre­zen­to­wa­łem meto­dę pro­jek­to­wa­nia sys­te­mów wyma­ga­ją­cych inter­dy­scy­pli­nar­nej wie­dzy. Prosty dia­gram poni­żej poka­zu­je struk­tu­rę opi­sa­ne­go tam systemu: 

Struktura taka jak ta, poka­zu­je ele­men­ty z jakich skła­da się roz­wią­za­nie i to jak owa całość jest skon­stru­owa­na, jak współ­dzia­ła­ją jej poszcze­gól­ne ele­men­ty. Taki model jest pierw­szym testem poka­zu­ją­cym, że to będzie dzia­ła­ło”. Modele takie moż­na testo­wać, bo ich two­rze­nie to sfor­ma­li­zo­wa­ny pro­ces. Wśród wie­lu cech ele­men­tów mode­lu jest (może być) tak­że koszt jego pozy­ska­nia. Dlatego model taki nie tyl­ko peł­ni rolę pro­jek­tu, peł­ni tak­że role szkie­le­tu wyce­ny: każ­dy ele­ment nale­ży wyce­nić czy­li podać koszt wytwo­rze­nia lub zaku­pu kom­po­nen­tów, koszt pra­cy zwią­za­nej z jego mon­ta­żem, koszt uru­cho­mie­nia całości. 

Najczęściej w doku­men­tach tego typu spo­ty­ka­my sche­ma­ty blo­ko­we, opra­co­wa­ne jako nie­for­mal­ne struk­tu­ry, np. takie jak poniższa: 

Zaletą takiej for­my pre­zen­ta­cji jest rela­tyw­na łatwość ich opra­co­wa­nia, pew­ne walo­ry este­tycz­ne, wadą zaś tej for­my jest to, że nie ist­nie­je żad­na moż­li­wość wali­da­cji takich dia­gra­mów (wery­fi­ka­cji popraw­no­ści, spój­no­ści i kom­plet­no­ści). Jako model są prak­tycz­nie nie­przy­dat­ne do innych celów niż nie­for­mal­na ilu­stra­cja. Niestety nie nada­ją się jako mate­riał badaw­czy do stu­dium wykonalności. 

Aby uzy­skać model do celów ana­li­zy, nale­ży sche­mat blo­ko­wy sfor­ma­li­zo­wać. Standardowym narzę­dziem for­ma­li­za­cji w inży­nie­rii są rysun­ki tech­nicz­ne, jed­nak te pozwa­la­ją jedy­nie na udo­ku­men­to­wa­nie struk­tu­ry konstrukcyjnej. 

W obec­nych cza­sach coraz wię­cej kon­struk­cji to wła­śnie kon­struk­cje mecha­tro­nicz­ne, czy­li struk­tu­ry skła­da­ją­ce się ele­men­tów nie tyl­ko mecha­nicz­nych. Elementy tych struk­tur nie tyl­ko są z sobą połą­czo­ne”, one na sie­bie oddzia­łu­ją, i to nie raz w bar­dzo wyra­fi­no­wa­ny spo­sób: wymie­nia­ją sygna­ły ste­ru­ją­ce. System grzew­czy – nie­for­mal­ny dia­gram – poka­za­ny powy­żej, w wer­sji sfor­ma­li­zo­wa­nej będzie wyglą­dał mniej wię­cej tak jak sche­mat poni­żej (to nie jest ten sam sys­tem, to wyłącz­nie przy­kła­dy dokumentów):

Formalizm tych sche­ma­tów pole­ga na pre­cy­zyj­nym opi­sie (mode­lo­wa­niu) nie tyl­ko samej kon­struk­cji, zawie­ra tak­że peł­ny opis mecha­ni­zmu działania. 

diagram_aspects_new.png
(https://​docs​.noma​gic​.com/​d​i​s​p​l​a​y​/​S​Y​S​M​L​P​1​9​0​/​D​i​a​g​r​a​m​+​a​s​p​e​cts)

Jak widać, szcze­gó­ło­wość opi­su moż­na dosto­so­wać do potrzeb: celu two­rze­nia modelu. 

Modele two­rzo­ne do celów stu­diów wyko­nal­no­ści cha­rak­te­ry­zu­ją się mniej­szą licz­ba szcze­gó­łów. Celem ich two­rze­nia jest raczej inwen­ta­ry­za­cja kom­po­nen­tów sys­te­mu, pozwa­la to łatwo uzu­peł­nić cechy kom­po­nen­tów np. o ich koszt pozy­ska­nia i pra­co­chłon­ność uru­cho­mie­nia (koszt pra­cy). Wtedy struk­tu­ra mode­lu ma postać np. jak poni­żej :

(https://​www​.scien​ce​di​rect​.com/​t​o​p​i​c​s​/​c​o​m​p​u​t​e​r​-​s​c​i​e​n​c​e​/​i​n​t​e​r​n​a​l​-​b​l​o​c​k​-​d​i​a​g​ram)

Podsumowanie

Korzystanie z ana­li­zy sys­te­mo­wej jako narzę­dzia i two­rze­nie sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, na uży­tek ana­liz wyko­nal­no­ści, to nie tyko uwia­ry­god­nie­nie samej analizy. 

Studium wyko­nal­no­ści sta­no­wi sobą pre-pro­jek­to­wa­nie sys­te­mu będą­ce­go przed­mio­tem ana­li­zy. To począ­tek opra­co­wy­wa­nia rozwiązania.

,

To tak­że obni­że­nie ryzy­ka pro­jek­tu, gdyż mode­le sys­te­mo­we pozwa­la­ją na wery­fi­ka­cję pro­jek­tu już na eta­pie jego doku­men­to­wa­nia. Dodatkowo, uzu­peł­nia­jąc mode­le o kosz­ty kom­po­nen­tów, uwia­ry­gad­nia­my tak­że wyce­nę: mamy pew­ność, że nicze­go nie pomi­nę­li­śmy. .

Oferta

Osoby zain­te­re­so­wa­ne wyce­ną takiej usłu­gi (zawsze Analiza Biznesowa, cza­sa­mi tak­że Projekt Techniczny Rozwiązana) zapra­szam na stro­nę Regulamin świad­cze­nia usług.

Źródła

Arantes, M., Bonnard, R., Mattei, A. P., & de Saqui-Sannes, P. (2018). General archi­tec­tu­re for data ana­ly­sis in indu­stry 4.0 using SysML and model based sys­tem engi­ne­ering. 2018 Annual IEEE International Systems Conference (SysCon), 1 – 6. https://​doi​.org/​1​0​.​1​1​0​9​/​S​Y​S​C​O​N​.​2​0​1​8​.​8​3​6​9​574
Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: the sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml
Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a gene­ral the­ory of plan­ning. Policy Sciences, 4(2), 155 – 169. https://​doi​.org/​1​0​.​1​0​0​7​/​B​F​0​1​4​0​5​730
Coffey, B. (2017). Unpacking the impli­ca­tions of label­ling envi­ron­men­tal issu­es as wic­ked pro­blems.’ 16.
Camillus, J. C. (2008). Strategy as a Wicked Problem. Harvard Business Review, 11.
Mattei, A. P., Loures, L., de Saqui-Sannes, P., & Escudier, B. (2017). Feasibility stu­dy of a mul­ti­spec­tral came­ra with auto­ma­tic pro­ces­sing onbo­ard a 27U satel­li­te using model based spa­ce sys­tem engi­ne­ering. 2017 Annual IEEE International Systems Conference (SysCon), 1 – 8. https://​doi​.org/​1​0​.​1​1​0​9​/​S​Y​S​C​O​N​.​2​0​1​7​.​7​9​3​4​725
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Herrold, J. (2016). System Architecture using SysML – Despite the GAPS! 37.
Steimer, C., Fischer, J., & Aurich, J. C. (2017). Model-based Design Process for the Early Phases of Manufacturing System Planning using SysML. Procedia CIRP, 60, 163 – 168. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​p​r​o​c​i​r​.​2​0​1​7​.​0​1​.​036
Thramboulidis, K. (2013). Overcoming Mechatronic Design Challenges: the 3+1 SysML-view Model. 1, 10.
Ireland, C., & Bowers, D. (2015). Exposing the Myth: Object-Relational Impedance Mismatch is a Wicked Problem. 6. http://oro.open.ac.uk/43318/1/download.php_articleid%3Ddbkda_2015_2_10_50020
Mili, S., Nguyen, N., & Chelouah, R. (n.d.). Connected Systems Modeling and Validation. 5.

Inteligentna pralka czyli czym jest mechatronika

Wstęp

Dzisiaj nie­co o czym innym, ale nie aż tak innym :). Po raz kolej­ny odkry­wam, że od lat pisze prozą ;). 

Nie raz publi­ko­wa­łem tu róż­ne rodza­je dia­gra­mów przy­pad­ków uży­cia, któ­re opi­su­ją opro­gra­mo­wa­nie, ale tym razem «akto­rem» nie jest ani czło­wiek ani inna apli­ka­cja, dzi­siaj akto­rem jest urzą­dze­nie elek­tro­me­cha­nicz­ne. Otóż od cza­su do cza­su mie­wam pro­jek­ty gdzie «akto­rem» jest żela­stwo”. Najczęściej są to pro­jek­ty zwią­za­ne z zaawan­so­wa­ny­mi sys­te­ma­mi ste­ro­wa­nia pro­duk­cją, jed­nak to nie jedy­ne takie miejsce. 

Coraz czę­ściej czy­ta­my o Internecie Rzeczy” (ang. IoT, Internet of Things) a to nic inne­go jak mecha­tro­ni­ka, a czym jest mecha­tro­ni­ka? Jedna z uczel­ni ame­ry­kań­skich (przy­pad­kiem wysko­czy­ła jako na począt­ku listy w google) poda­je na swo­jej stronie:

Mechatronics is a mul­ti­di­sci­pli­na­ry field that com­bi­nes seve­ral types of engineering?electrical, com­pu­ter, and mechanical?and refers to the skill sets needed in the con­tem­po­ra­ry, advan­ced auto­ma­ted manu­fac­tu­ring indu­stry. At the inter­sec­tion of mecha­nics, elec­tro­nics, and com­pu­ting, mecha­tro­nics spe­cia­li­sts cre­ate sim­pler, smar­ter sys­tems. Mechatronics is an essen­tial foun­da­tion for the expec­ted growth in auto­ma­tion and manufacturing.Mechatronics is an indu­stry buz­zword syno­ny­mo­us with robo­tics and elec­tro­me­cha­ni­cal engi­ne­ering. Robotics, con­trol sys­tems, and elec­tro-mecha­ni­cal sys­tems fall under mecha­tro­nics. (What is Mechatronics? | Michigan Technological University)

W uprosz­cze­niu jest to inter­dy­scy­pli­nar­na dzia­łal­ność, któ­ra łączy kil­ka rodza­jów inży­nie­rii: elek­trycz­nej, kom­pu­te­ro­wej i mecha­nicz­nej. W tym obsza­rze powsta­ją prost­sze, inte­li­gent­niej­sze sys­te­my, gdyż wie­le urzą­dzeń mecha­nicz­nych moż­na zastą­pić prost­szy­mi kon­struk­cyj­nie pod­sys­te­ma­mi kom­pu­te­ro­wy­mi (kom­pu­ter to pro­ce­sor, pamięć i pro­gram wraz z inter­fej­sa­mi, auto­rzy z obsza­ru filo­zo­fii infor­ma­ty­ki uży­wa­ją okre­śle­nia: kom­pu­ter jako uni­wer­sal­ny mecha­nizm ). Mechatronika to jed­nak ostat­nio głów­nie mod­ne hasło bran­żo­we (ang. buz­zword), będą­ce syno­ni­mem robo­ty­ki i inży­nie­rii elektromechanicznej.

(źr. What is Mechatronics? | Michigan Technological University)

Wielu auto­rów publi­ku­ją­cych w obsza­rze mecha­tro­ni­ki pisze we wstę­pach i stresz­cze­niach: Systemy mecha­tro­nicz­ne cha­rak­te­ry­zu­ją się syner­gicz­ną inte­rak­cją mię­dzy ich ele­men­ta­mi pocho­dzą­cy­mi z róż­nych dzie­dzin tech­no­lo­gii. Te inte­rak­cje umoż­li­wia­ją sys­te­mo­wi osią­gnię­cie więk­szej licz­by funk­cji niż suma funk­cji cechy jego skład­ni­ków roz­pa­try­wa­ne nie­za­leż­nie. Interdyscyplinarność mecha­tro­ni­ki moż­na przed­sta­wić tak:

Autor powyż­sze­go tak poka­zu­je róż­ni­cę pomię­dzy tra­dy­cyj­nym a mecha­tro­nicz­nym podej­ście do projektowania:

Tradycyjne meto­dy pro­jek­to­wa­nia są już nie­wy­star­cza­ją­ce. Dlatego coraz wię­cej inży­nie­rów korzy­sta z roz­sze­rze­nia języ­ka UML do celów sze­rzej rozu­mia­nej inży­nie­rii, jakim jest język SysML , .

Ogólnie cykl wytwa­rza­nia urzą­dzeń mecha­tro­nicz­nych jest opi­sy­wa­ny np. tak :

V‑Model – model wytwa­rza­nia systemu

Jak widać, cały cykl pro­jek­to­wy jest pro­ce­sem interdyscyplinarnym. 

Mechatronika i nota­cja SysML ma swo­je począt­ki w latach 90-tych. Modele w tej nota­cji powsta­wa­ły już w fir­mie Boeing . Od tam­tej pory powsta­ło wie­le publi­ka­cji na ten temat, w tym tak­że opi­sy dobrych prak­tyk jaki­mi są wzor­ce pro­jek­to­we . Można spo­tkać coraz czę­ściej publi­ka­cje na temat sto­so­wa­nia metod pro­jek­to­wa­nia opar­tych na SysML .

Moim celem było tu zwró­ce­nie uwa­gi na tę w sumie nową dzie­dzi­nę inży­nie­rii, waż­ne by nie utoż­sa­miać jej jedy­nie z robo­ty­ką, bo było by to ogrom­ne uprosz­cze­nie, co mam nadzie­ję poka­za­łem powyż­szy­mi przy­kła­da­mi. Po dru­gie rosną­ca zło­żo­ność pro­duk­tów zmu­sza do sto­so­wa­nia metod ogra­ni­cza­ją­cych licz­bę ana­li­zo­wa­nych deta­li na wcze­snych eta­pach opra­co­wa­nia pro­duk­tów i pro­jek­to­wa­nia .

Prosty przykład

Na zakoń­cze­nie, pro­sty dia­gram opi­su­ją­cy pralkę: 

Schemat blo­ko­wy pral­ki, nota­cja SysML.

Na powyż­szym dia­gra­mie poka­za­no sche­mat blo­ko­wy hipo­te­tycz­nej pral­ki, ze wska­za­niem, któ­re jej ele­men­ty będą reali­zo­wa­ne przez kom­po­nent będą­cy kom­pu­te­rem. Można sobie wyobra­zić, że pro­gra­ma­tor mecha­nicz­ny zastą­pio­no kom­pu­te­rem (jest to już dość powszech­ne). Ale moż­na też sobie wyobra­zić, że pral­ka sama komu­ni­ku­je nam stan pra­cy, kolej­ne fazy pra­nia i ewen­tu­al­nie pro­si o reak­cję w przy­pad­ku nie­stan­dar­do­wej sytu­acji. Schematy takie powsta­ją, by już na tym eta­pie pro­jek­to­wa­nia moż­li­we było okre­śle­nie wyma­gań na to opro­gra­mo­wa­nie. Zrozumienie dzia­ła­nia cało­ści tego sys­te­mu to klucz do sku­tecz­ne­go pro­jek­to­wa­nia i testo­wa­nia opro­gra­mo­wa­nia zanim jesz­cze powsta­nie samo urzą­dze­nie. Oczywiście pro­jek­to­wa­nie pral­ki jakie jako takie ma głę­bo­ki sens. 

Warto wie­dzieć i rozu­mieć jak są budo­wa­ne inter­fej­sy pomię­dzy kom­pu­te­rem a mecha­nicz­ny­mi ele­men­ta­mi takie­go sys­te­mu (np. ter­mo­stat): inter­fej­sy dostar­cza­ją pro­du­cen­ci pod­ze­spo­łów, kom­pu­ter widzi” inne urzą­dze­nia jako obsza­ry pamięci. 

SLIM (Systems LIfecycle Management)

Polecam też arty­kuł na temat inte­gra­cji opi­sa­nych wyżej metod i narzę­dzi do mode­lo­wa­nia takich jak nota­cja SysML i pakiet CASE (np. Visual Paradigm, któ­ry posłu­żył mi tu wyko­na­nia modeli):

SLIM (Systems LIfecycle Management) jest śro­do­wi­skiem dla zin­te­gro­wa­nej inży­nie­rii sys­te­mów opar­tej na mode­lach, nota­cji SysML (OMG Systems Modeling Language) i pro­duk­tach PLM (Product Lifecycle Management). Dzięki temu podej­ściu inży­nie­ro­wie zło­żo­nych sys­te­mów mogą opra­co­wy­wać i zarzą­dzać wyso­ko­po­zio­mo­wą archi­tek­tu­rą systemu/produktu w SysML i jed­no­cze­śnie łączyć się, komu­ni­ko­wać i syn­chro­ni­zo­wać ze szcze­gó­ło­wy­mi wyma­ga­nia­mi, czę­ścia­mi (zesta­wie­nia mate­ria­łów i CAD), mode­la­mi symu­la­cyj­ny­mi (MATLAB/Simulink, Mathematica, CAE) i zło­żo­ny­mi struk­tu­ra­mi danych, któ­re są wer­sjo­no­wa­ne i kon­tro­lo­wa­ne w sys­te­mach PLM kla­sy kor­po­ra­cyj­nej (takich jak Teamcenter i Windchill) oraz obiek­to­wych / rela­cyj­nych bazach danych (takich jak MySQL).

(źr.: Enabling MBSE by inte­gra­ting SysML with PLM, CAD/CAE, Databases)

Źródła

Van Noten, J., Gadeyne, K., & Witters, M. (2017). Model-based Systems Engineering of Discrete Production Lines Using SysML: An Experience Report. Procedia CIRP, 60, 157 – 162. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​p​r​o​c​i​r​.​2​0​1​7​.​0​1​.​018
Mhenni, F., Choley, J.-Y., Penas, O., Plateaux, R., & Hammadi, M. (2014). A SysML-based metho­do­lo­gy for mecha­tro­nic sys­tems archi­tec­tu­ral design. Advanced Engineering Informatics, 28(3), 218 – 231. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​a​e​i​.​2​0​1​4​.​0​3​.​006
OMG​.org. (2017, December 8). Systems Modeling Language (SysML). http://​www​.omg​sy​sml​.org/
Isermann, R. (2005). Mechatronic sys­tems: fun­da­men­tals. Springer.
Herrold, J. (2016). System Architecture using SysML – Despite the GAPS! 37.
Steimer, C., Fischer, J., & Aurich, J. C. (2017). Model-based Design Process for the Early Phases of Manufacturing System Planning using SysML. Procedia CIRP, 60, 163 – 168. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​p​r​o​c​i​r​.​2​0​1​7​.​0​1​.​036
Barbieri, G., Kernschmidt, K., Fantuzzi, C., & Vogel-Heuser, B. (2014). A SysML based design pat­tern for the high-level deve­lop­ment of mecha­tro­nic sys­tems to enhan­ce re-usa­bi­li­ty. IFAC Proceedings Volumes, 47(3), 3431 – 3437. https://​doi​.org/​1​0​.​3​1​8​2​/​2​0​1​4​0​824 – 6‑ZA-1003.00615

Co nowego w Visual Paradigm 15.2

26 Listopada zosta­ła opu­bli­ko­wa­na wer­sja 15.2 pakie­tu CASE Visual-Paradigm (VP) ofe­ro­wa­ne­go przez fir­mę o tej samej nazwie. (źr.: What’s New in Visual Paradigm?).

Numer wer­sji zmie­nił się po prze­cin­ku” więc rewo­lu­cji nie ma ale poja­wi­ły się rozszerzenia:

  1. Business Process Reengineering Canvas – sza­blon dla pro­jek­tów rein­ży­nie­rii pro­ce­sów. Szablony pro­jek­to­we w VP to kom­plet­ne zesta­wy pro­ce­sów biz­ne­so­wych, meto­dy­ki, wzo­ry doku­men­tów. Co praw­da uży­wa­ne są rzad­ko ale każ­dy ele­ment sza­blo­nu może być wyko­rzy­sta­ny samo­dziel­nie wedle uzna­nia użyt­kow­ni­ka, dla­te­go te sza­blo­ny speł­nia­ją rolę stan­da­ry­za­cji pra­cy (co poma­ga i to bardzo).
  2. Rozszerzona sza­blo­ny dla meto­dy­ki SCRUM, zwo­len­ni­cy tej meto­dy­ki znaj­dą wie­le pomoc­nych opcji.
  3. Poszerzono sza­blo­ny dla meto­dyk two­rze­nia Architektury Korporacyjnej opar­tych o TOGAF.
  4. Wireflow Diagram – A wire­fra­me-based flow­chart – poja­wi­ły się kolej­ne roz­sze­rze­nia dla funk­cji pro­jek­to­wa­nia i pre­zen­to­wa­nia makiet ekra­nów i ani­mo­wa­nych scenariuszy.
  5. UX Prototyping tool – nowe narzę­dzie do pro­to­ty­po­wa­nia sza­ty gra­ficz­nej i inte­rak­cji apli­ka­cji webowych.
  6. Bi-Directional ERD syn­chro­ni­za­tion – roz­sze­rzo­no wspar­cie dla pro­jek­tan­tów rela­cyj­nych baz danych.
  7. Enhanced SysML 1.5 sup­port – posze­rzo­ne i zak­tu­ali­zo­wa­ne wspar­cie dla SysML.
  8. Poszerzone wspar­cie dla pro­jek­to­wa­nia API i zesta­wów webserwisów.
  9. Process Map Designer – posze­rzo­ne wspar­cie dla pro­jek­to­wa­nia map pro­ce­sów wyso­kie­go poziomu.
  10. Wiele nowych sza­blo­nów dia­gra­mów biz­ne­so­wych i info­gra­fi­ki biznesowej.

Tak więc opro­gra­mo­wa­nie Visual-Paradigm sta­je się peł­nym zesta­wem narzę­dzi dla pro­jek­tów archi­tek­tu­ry biz­ne­so­wej, pro­jek­to­wa­nia sys­te­mów, w szcze­gól­no­ści infor­ma­tycz­nych. Ogromny nacisk fir­my Visual-Paradigm na jakość for­ma­li­za­cji i jej zgod­ność ze spe­cy­fi­ka­cja­mi OMG czy­ni z tego narzę­dzia dosko­na­łe wspar­cie dla prac nauko­wych bazu­ją­cych na for­ma­li­za­cjach ikonicznych.

Polecam testy pakietu 🙂 …