CC BY
25
LO CD
O >
PRIMENA SysML NA POJEDNOSTAVLJEN MODEL OSMATRACKOG RADARA
Milos D. Jevtic3, Sinisa R. Marinkovicb, Ivica B. Marjanovicc
q^ a Univerzitet u Beogradu, Elektrotehnicki fakultet, Beograd, Republika Srbija,
^ e-mail: [email protected],
3 ORCID iD: http://orcid.org/0000-0002-2358-0074,
0 b Univerzitet u Beogradu, Institut „Mihajlo Pupin", Beograd, Republika Srbija, ^ e-mail: [email protected], ^ ORCID iD: http://orcid.org/0000-0002-3952-5432,
1 c Ministarstvo odbrane Republike Srbije, Vojna kontrola kvaliteta, lu Beograd, Republika Srbija,
e-mail: [email protected], ^ ORCID iD: http://orcid.org/0000-0001-6945-7533
DOI: 10.5937/vojtehg65-8697
OBLAST: informatika VRSTA CLANKA: strucni clanak < JEZIK CLANKA: srpski
CD
2 Sazetak: C
Systems Modeling Language (SysML) jeste profil Unified Modeling Language (UML) namenjen za upotrebu u sistemskom inzenjerstvu. Ovaj ¡5 tekst inspirisan je manjkom literature o SysML-u na srpskom jeziku, a ima
za cilj upoznavanje inzenjerske i akademske zajednice sa ovim
o interesantnim jezikom za modelovanje, pri cemu su posebno naglasene
razlike u odnosu na UML. Opis je dat kroz konkretan originalan primer -pojednostavljen model osmatrackog radara. Ukratko su analizirani prakticni aspekti SysML-a - koliko je prihvacen, kakva je perspektiva njegove dalje primene, itd. Moze se zakljuciti da je SysML koristan, prihvacen i perspektivan jezik za modelovanje.
Kljucne reci: sistemsko inzenjerstvo zasnovano na modelima, osmatracki radar, SysML, UML.
Uvod
Sistemsko inzenjerstvo zasnovano na modelima (eng. Model Based Systems Engineering) savremen je pristup u sistemskom inzenjerstvu koji
ACKNOWLEDGEMENT: Rad je finansijski potpomoglo Ministarstvo prosvete, nauke i tehnoloskog razvoja Republike Srbije (Ugovor TR32051).
bi trebalo da zameni tradicionalan pristup zasnovan na dokumentima £
(Friedenthal, et al., 2008). Jedan od kljucnih elemenata koji omogucuju primenu sistemskog inzenjerstva zasnovanog na modelima je standardizovan i robustan jezik za modelovanje (Friedenthal, et al., 2008). Systems Modeling Language (SysML) jeste jezik za modelovanje opste namene koji podrzava specificiranje, analizu, projektovanje i verifikaciju sistema, a stvoren je kao odgovor na prethodno pomenute potrebe. SysML je prosirenje jezika za modelovanje Unified Modeling Language (UML) (Friedenthal, et al., 2008), (Weilkiens, 2007).
Cilj ovog clanka, za cije razumevanje je potrebno dobro poznavanje UML-a, jeste da se ukratko predstavi SysML i da se ispita njegova upotrebljivost u sadasnjoj i buducoj praksi. U sledecem odeljku navedene su osnovne informacije o sistemskom inzenjerstvu (zasnovanom na modelima) i nastanku SysML-a. U trecem odeljku nalazi se kratak prikaz SysML-a sa tezistem na razlikama u odnosu na UML, na primeru pojednostavljenog modela osmatrackog radara. Pomenuti primer nije preuzet iz postojece js literature vec je namenski smisljen za potrebe ovog clanka. U trecem odeljku § predstavljen je kratak osvrt na prakticne aspekte koriscenja SysML-a, na osnovu tudih, ali i licnih iskustava autora, dok je zakljucak naveden u cetvrtom odeljku.
Sistemsko inzenjerstvo
ro
T3 2 O)
E
tf> >
<u
<u
<u
Sistemsko inzenjerstvo (eng. systems engineering) jeste e „interdisciplinarni pristup i sredstvo koje omogucuje realizaciju uspesnih sistema" (iNCOSE, 2004). Ovu definiciju preporucuje Medunarodni savet ® za sistemsko inzenjerstvo (eng. International Council on Systems Engineering (INCOSE)). Slicno tome, Friedenthal i ostali definisu sistemsko inzenjerstvo kao „multidisciplinar^ pristup kojim se skup potreba zainteresovanih strana transformise u balansirano sistemsko resenje koje zadovoljava date potrebe" (Friedenthal, et al., 2008).
Sistemsko inzenjerstvo je skoncentrisano na definisanje i dokumentovanje zahteva, projektovanje sistema i verifikaciju sistema u smislu saobraznosti sa zahtevima (Weilkiens, 2007). Ono uzima u obzir celokupni zivotni ciklus sistema (ukljucujuci faze koje nastupaju nakon isporuke sistema, kao sto su obuka, podrska i eventualno povlacenje sistema iz upotrebe) (Weilkiens, 2007). Projektovanje i implementacija pojedinacnih komponenti nije predmet sistemskog inzenjerstva vec drugih inzenjerskih disciplina (softversko inzenjerstvo, elektrotehnika, masinstvo itd.). Sistemsko inzenjerstvo, medutim, mora definisati zahteve koje date komponente moraju zadovoljavati (bilo da se razvijaju ili kupuju kao gotovi proizvodi), nacin na koji se komponente integrisu u sistem, te procedure za
o
o >
O CM
D¿ UJ
a.
Z) O O
_l <
o
X
o
LU
H >-
a. <
H
<
CD >o
X LU H O
O >
verifikaciju ispunjenosti sistemskih zahteva. Drugim recima, sistemsko inzenjerstvo je metadisciplina (Weilkiens, 2007), koja funkcionise na visem nivou apstrakcije u odnosu na druge inzenjerske discipline.
Sistemsko inzenjerstvo zasnovano na modelima
Tradicionalan pristup u sistemskom inzenjerstvu zasnovan je na dokumentima. Ovaj pristup moze se okarakterisati stvaranjem specifikacija i projektnih dokumenata, koji se zatim razmenjuju medu zainteresovanim stranama (eng. stakeholders). Sistemski zahtevi i projektne informacije su u ovim dokumentima izrazeni u obliku teksta i crteza. Kod sistemskog inzenjerstva zasnovanog na dokumentima, teziste je na upravljanju dokumentacijom i osiguravanju da su dokumenti validni, kompletni i konzistentni, te da je razvijeni sistem saobrazan dokumentaciji (Friedenthal, et al., 2008). Iako rigorozan, pristup zasnovan na dokumentima ima fundamentalna ogranicenja. Artefakti razvojnog procesa (zahtevi, projekat, rezultati analize, informacije vezane za testiranje, itd.) rasejani su na nekoliko dokumenata, sto otezava procenu kompletnosti i konzistentnosti dokumentacije, kao i shvatanje odnosa medu pomenutim artefaktima, sto nadalje stvara poteskoce u razumevanju pojedinih aspekata sistema i postizanju sledljivosti (eng. traceability). Takode, otezani su odrzavanje i ponovna upotreba sistemskih zahteva i projektnih informacija (Friedenthal, et al., 2008).
Termin inzenjerstvo zasnovano na modelima (eng. model-based engineering) odnosi se na pristup u kojem centralnu ulogu u definisanju specifikacija, projektovanju, integraciji, validaciji i operativnoj upotrebi sistema imaju modeli (Estefan, 2008). Pristup zasnovan na modelima odavno je postao standardna praksa u masinstvu i elektrotehnici, a postaje sve sire prihvacen i u softverskom inzenjerstvu, narocito nakon pojave UML-a (Friedenthal, et al., 2008). Ocekuje se da ce pristup zasnovan na modelima postati standardna praksa i u sistemskom inzenjerstvu, na slican nacin kao u pomenutim disciplinama (Friedenthal, et al., 2008).
Prema (Friedenthal, et al., 2008) i njihovim referencama, sistemsko inzenjerstvo zasnovano na modelima (SIZM) jeste „formalizovana primena modelovanja kao podrske aktivnostima definisanja sistemskih zahteva, projektovanja, analize, verifikacije i validacije, pocevsi od faze idejnog projekta i nastavljajuci se tokom razvoja i kasnijih faza zivotnog ciklusa". Potencijalne koristi od primene SIZM su poboljsanja u: komunikaciji medu zainteresovanim stranama, preciznosti izrazavanja specifikacija i projekta, integraciji projekta i ponovnoj upotrebi artefakata razvojnog procesa.
Pomenuta poboljsanja trebalo bi da poprave kvalitet i produktivnost, te da &
smanje rizike (Friedenthal, et al., 2008). Kod SIZM teziste je na upravljanju koherentnim modelom sistema i na koriscenju tog modela za specificiranje i projektovanje sistema (Friedenthal, et al., 2008). Model sistema evoluira i inkrementalno raste tokom vremena (Friedenthal, et al., 2008), (Estefan, 2008).
O nastanku SysML-a
o CD
cp cp
CO T3 2 O) O
>o ro
Inzenjerstvo zasnovano na modelima podrazumeva postojanje jezika za modelovanje. Uprkos brojnim inicijativama za standardizaciju procesa u sistemskom inzenjerstvu, do 2001. godine nije doslo do pojave jedinstvenog jezika za modelovanje (Weilkiens, 2007). Ovakva situacija e dovela je do znatnih problema u interdisciplinarnim projektima (Weilkiens, 2007). U meduvremenu, UML je postao dominantan jezik za modelovanje u softverskom inzenjerstvu (Weilkiens, 2007), a 1997. godine prihvacen je kao standard od medunarodnog konzorcijuma za standardizaciju Object Management Group (OMG) (Tartalja, 2011). °
Pocetkom 2001. godine INCOSE je doneo stratesku odluku da se <5 UML prilagodi za primenu u sistemskom inzenjerstvu. Zajednickim naporima INCOSE i OMG postavljeni su zahtevi za novi jezik za modelovanje, koji su objavljeni u dokumentu „UML for Systems Engineering Request for Proposal (UML for SE RFP)", 2003. godine (OMG, 2012). SysML je jezik za modelovanje koji je nastao kao odgovor na pomenute zahteve. Verzija 1.0 SysML-a (zasnovana na verziji 2.1.1. UML-a) usvojena je kao zvanicni OMG standard 2007. godine (Weilkiens, 2007). Nakon toga SysML je doziveo nekoliko revizija, a verzija 1.3 (zasnovana na verziji 2.4.1. UML-a), koja je opisana u ovom clanku, usvojena je kao standard 2012. godine (OMG, 2012). |
Postoji vise razloga zbog kojih je SysML zasnovan na UML-u. Naime, UML je popularan jezik koji je u sirokoj upotrebi, moze se prilagoditi specificnim potrebama (zahvaljujuci svojim mehanizmima za prosirivanje), a postoji i veliki broj raspolozivih alata za modelovanje, kao i organizacija koje pruzaju obuku ili savetovanje (Weilkiens, 2007). Takode, sistemski inzenjeri koji koriste SysML i softverski inzenjeri koji koriste UML moci ce da saraduju na modelima softverski intenzivnih sistema. Zahvaljujuci tome, poboljsace se komunikacija medu zainteresovanim stranama koje ucestvuju u razvojnom procesu i promovisace se interoperabilnost medu alatima za modelovanje (OMG, 2012).
Moze se postaviti pitanje da li je stvaranje novog jezika za modelovanje bilo zaista neophodno i opravdano, ili zasto UML u postojecoj
formi nije mogao biti upotrebljen u sistemskom inzenjerstvu? lako je UML veoma ekspresivan jezik, nedostaju mu neki elementi koji su bitni za ® sistemsko inzenjerstvo, kao sto je modelovanje zahteva (Weilkiens, 2007). > Pored toga, UML je usmeren na modelovanje softverskih sistema i jako je povezan sa objektnim modelom razvoja (Weilkiens, 2007). Sa druge strane, od jezika za modelovanje u sistemskom inzenjerstvu ocekuje se da podrzi interdisciplinarno modelovanje (Weilkiens, 2007) i da bude E agnostican u odnosu na primenjenu metodologiju (OMG, 2012).
О
о <
о
Kratak prikaz SysML-a
g SysML ponovo upotrebljava (eng. reuse) podskup UML-a i dodaje
ш prosirenja koja su neophodna da bi se ispunili zahtevi iz „UML for SE RFP" £ (OMG, 2012). Veza izmedu UML-a i SysML-a prikazana je Venovim < dijagramom na slici 1, po uzoru na (OMG, 2012). Krugovi oznaceni sa „UML" i „SysML" oznacavaju skupove jezickih konstrukcija koje cine UML i SysML, respektivno. Presek ova dva skupa, oznacen sa „UML4SysML" predstavlja deo UML-a koji je ponovo upotrebljen u SysML-u. Region w oznacen sa „SysML profil" predstavlja nove jezicke konstrukcije definisane ^ u SysML-u, a koje ili ne postoje u UML-u ili menjaju odgovarajuce UML 2 konstrukcije. Region oznacen sa „UML - UML4SysML" odnosi se na deo UML-a koji nije potreban za implementaciju SysML-a.
i Ш I—
О
z —>
О >
Slika 1 - Veza izmedu UML-a i SysML-a Рис. 1 - Связь между UML и SysML Figure 1 - Relation between UML and SysML
Klasifikacija SysML dijagrama prikazana je na slici 2, po uzoru na (OMG, 2012). Dijagram sekvence (eng. sequence diagram), dijagram masine stanja (eng. state machine diagram), dijagram slucajeva koriscenja
(eng. use case diagram) i dijagram paketa (eng. package diagram) jesu ponovo upotrebljeni iz UML-a, bez izmena (OMG, 2012). Dijagrami koji su nastali modifikacijom odgovarajucih UML dijagrama su: dijagram aktivnosti (eng. activity diagram), dijagram definicije blokova (eng. block definition diagram) koji je zapravo modifikacija UML dijagrama klasa (eng. class diagram) i unutrasnji blok-dijagram (eng. internal block diagram) koji je, u stvari, modifikacija UML dijagrama slozene strukture (eng. composite structure diagram) (OMG, 2012).
Slika 2 - Klasifikacija SysML dijagrama Рис. 2 - Диаграмма классификации SysML Figure 2 - SysML diagram classification
SysML uvodi dve nove vrste dijagrama. Dijagram zahteva (eng. requirement diagram) namenjen je modelovanju zahteva predstavljenih u tekstualnom obliku, ukljucujuci veze sa drugim elementima modela koji date zahteve zadovoljavaju ili definisu nacin njihove verifikacije (OMG, 2012). Parametarski dijagram (eng. parametric diagram) opisuje ogranicenja (eng. constraint) koja postoje medu svojstvima (eng. property) blokova (OMG, 2012) (blok je modifikovana UML klasa, o cemu ce vise reci biti kasnije). Parametarski dijagram uveden je radi integracije modela strukture i ponasanja sa analitickim modelima, kao sto su model performansi ili model pouzdanosti (OMG, 2012).
Pojedini UML dijagrami se ne koriste u SysML-u. Dijagram rasporedivanja (eng. deployment diagram) iskljucen je iz SysML-a, jer se rasporedivanje softvera na hardverske resurse moze predstaviti pomocu unutrasnjeg blok-dijagrama (OMG, 2012). Pored toga, smatralo se da su
SysML dijagrami ponasanja, prikazani na slici 2, sasvim adekvatni i dovoljni za predstavljanje ponasanja, te su dijagram komunikacije ® (eng. communication diagram) i dijagram pregleda interakcije (eng. > interaction overview diagram) iskljuceni iz SysML specifikacije (OMG, 2012). Vremenski dijagram (eng. timing diagram) nije nasao mesto u SysML-u, jer je u pitanju relativno nova vrsta UML dijagrama koja jos nije do kraja razvijena, a postoji i pitanje da li je ova vrsta E dijagrama prikladna za potrebe sistemskog inzenjerstva (OMG, o 2012). Ipak, recenica iz (OMG, 2012) koja glasi: „Iako UML 2 " vremenski dijagram nije ukljucen u ovu verziju SysML-a, on moze da dopuni SysML dijagrame ponasanja ..." ukazuje na potencijalno
LO
X
ukljucivanje vremenskog dijagrama u buduce specifikacije SysML-a. Ô Dijagram profila (eng. profile diagram) nije ukljucen u SysML, jer se definicije profila mogu predstaviti i na dijagramu paketa (OMG, oë 2012). Konacno, dijagram objekata (eng. object diagram) i dijagram ^ komponenata (eng. component diagram) ne postoje u SysML-u.
Svaki SysML dijagram mora imati okvir (eng. frame), za razliku od UML-a gde su okviri dijagrama opcioni (OMG, 2012). Okvir je pravougaonik ciji je veci deo povrsine predviden za prikaz sadrzaja < dijagrama, dok je manji deo povrsine u gornjem levom uglu d rezervisan za zaglavlje (eng. heading). Zaglavlje je niska sa g sintaksom vrstaDijagrama [tipElementaModela] imeElementaModela [imeDijagrama].
w Vrsta dijagrama i ime elementa modela su obavezni u zaglavlju.
o Ime elementa modela ukazuje na element modela koji je ^ podrazumevani prostor imena (eng. namespace) za elemente > modela prikazane unutar okvira. Elementi modela koji ne pripadaju podrazumevanom prostoru imena moraju biti prikazani sa kvalifikovanim imenima. Vrsta dijagrama je jedna od skracenica iz sledece liste: act (dijagram aktivnosti), bdd (dijagram definicije blokova), ibd (unutrasnji blok-dijagram), pkg (dijagram paketa), par (parametarski dijagram), req (dijagram zahteva), sd (dijagram sekvence), stm (dijagram masine stanja), uc (dijagram slucajeva koriscenja).
Primer okvira dijagrama moze se videti na slici 2 (koja je zapravo SysML dijagram definicije blokova). U nastavku ovog odeljka bice detaljnije opisani elementi SysML profila. Dijagrami i jezicke konstrukcije koji cine SysML bice ilustrovani na konkretnom primeru veoma pojednostavljenog modela osmatrackog radara.
Dijagram definicije blokova i unutrasnji blok-dijagram
LO
oo
o CD
Cp CP
U SysML-u blok (eng. block) podrazumeva modularnu jedinicu opisa sistema. On definise skup karakteristika (eng. features) koje opisuju sistem ili neki drugi znacajan element. Formalno, blok je UML klasa sa stereotipom «block» (OMG, 2012).
Dijagram definicije blokova zasnovan je na UML dijagramu klasa uz odredena prosirenja i ogranicenja. Namenjen je za definisanje | karakteristika blokova i relacija medu blokovima (OMG, 2012). Karakteristike blokova ukljucuju svojstva i operacije. Svojstva su strukturne karakteristike, npr. delovi i portovi poznati iz UML-a, ali i nove vrste | svojstava o kojima ce biti reci kasnije. Operacije su karakteristike bloka koje se odnose na ponasanje. Medu blokovima mogu postojati svi tipovi Jj relacija koji mogu postojati izmedu UML klasa: zavisnost, asocijacija, § agregacija, kompozicija, generalizacija i ugnjezdivanje. Dijagrami definicije blokova uglavnom se koriste za prikaz hijerarhijske dekompozicije nekog elementa na podelemente („je deo" hijerarhija) ili za prikaz stabla klasifikacije elemenata („je vrsta" hijerarhija). Zbog toga su na ovim dijagramima najzastupljenije relacije kompozicije i generalizacije.
Unutrasnji blok-dijagram zasnovan je na UML dijagramu slozene strukture uz odredena prosirenja i ogranicenja. Na ovom dijagramu prikazuje se unutrasnja struktura bloka pomocu svojstava koja su povezana konektorima (OMG, 2012). Dok se dijagram slozene strukture povezuje sa naprednim koriscenjem UML-a, unutrasnji blok-dijagram je esencijalni element strukturnog modelovanja u SysML-u.
Sledi ilustracija specificnosti dijagrama definicije blokova i unutrasnjeg blok-dijagrama na ranije pomenutom primeru osmatrackog radara. Na | slikama 3, 4 i 5, dati su SysML dijagrami koji opisuju domen problema, tj. domen radarskog osmatranja. Unutrasnji blok-dijagram na slici 3 prikazuje delove domena radarskog osmatranja (radar, pokretne objekte, posluzioca i operativni centar) i nacin na koji su oni povezani. Radar emituje elektromagnetne talase (EMT) putem antene. EMT se odbijaju od pokretnih objekata nazad prema radaru koji ih prima putem antene. Obradom primljenih signala formira se slika vazdusne situacije koja se prezentira posluziocu putem pokazivaca. Primenom tehnika automatske detekcije i pracenja (ADP) generisu se tragovi koji se putem modema salju operativnom centru (OC). Od OC se putem modema dobijaju tragovi generisani na drugim radarima ili dobijeni tehnikama fuzije podataka u samom OC.
ro
T3 2 O)
o >o
ro
T3 <D
cT p
ro
ю CD
О >
0
01
ОС ш
0£ ZD О
о <
о
X
о ш
н
>-
Q1 <
(Л <
-J
О ■О
X ш н
о
о >
Na osnovu zaglavlja dijagrama na slici 3 vidi se da se dati unutrasnji blok-dijagram odnosi na blok Domen radarskog osmatranja. Ovaj blok i njegova dekompozicija na delove definisani su pomocu dijagrama definicije blokova na slici 4. Ovde su iskorisceni oznaceni odeljci (eng. labeled compartments) za grupisanje karakteristika iste vrste, sto je dozvoljeno (ali ne i obavezno) u SysML-u. SysML definise odredene standardne odeljke, a dozvoljeno je da korisnici definisu dodatne.
Slika 3 - Domen radarskog osmatranja Рис. 3 - Диапозон радиолокационного наблюдения Figure 3 - Radar surveillance domain
Dijagram definicije blokova na slici 5 definise tipove portova i stavki (eng. items) u domenu radarskog osmatranja. Jedno od novih vrsta svojstava koja uvodi SysML je svojstvo toka (eng. flow property). Svojstva toka specificiraju vrste stavki koje mogu „teci" (tj. razmenjivati se) izmedu bloka i njegove okoline (OMG, 2012). Stavke mogu biti podaci, ali i materijalni objekti ili energija. Jedno svojstvo toka specificira jednu vrstu stavki koja moze teci u blok ili iz bloka. Smer toka se specificira prefiksom koji moze imati vrednost in, out ili inout. Blok Antena na slici 5 ima dva svojstva toka. Svojstvo toka izraceniTalas je tipa EMT i ima prefiks out, sto znaci da iz bloka Antena mogu izlaziti stavke tipa EMT. Svojstvo toka reflektovaniTalas definise da u blok Antena mogu ulaziti stavke tipa EMT.
Slika 4 - Dekompozicija domena radarskog osmatranja Рис. 4 - Декомпозиция поля радиолокационного наблюдения Figure 4 - Radar surveillance domain decomposition
Port ciji je tip blok koji ima svojstva toka moze unutar svog grafickog simbola imati strelicu koja ukazuje na smer svojstava toka u odnosu na blok koji je vlasnik porta (OMG, 2012). Tip porta pokazivac bloka Osmatracki radar je blok VizuelnilzlazniÜredaj koji ima jedno svojstvo toka sa smerom out. Zato na slici 3 port pokazivac ima strelicu ciji je smer od bloka Osmatracki radar ka spoljasnjosti. Ukoliko je tip porta blok koji ima svojstva toka sa razlicitim smerovima ili svojstva toka sa smerom inout, strelica unutar grafickog simbola porta ima oblik kao kod portova modem i antena na slici З.
Tok stavki (eng. item flow) specificira stavke koje se prenose preko konektora ili asocijacije (OMG, 2012). Formalno, tok stavki je stereotip ««ItemFlow» toka informacija (eng. information flow) iz UML-a. Notacija za tok stavki je slicna kao za tok informacija: na konektor se dodaje popunjeni vrh strelice u smeru toka pored kojeg stoji ime tipa stavke koja se prenosi (slika 3). Dok svojstva toka definisu sta moze da tece u blok ili iz bloka, tokovi stavki definisu sta zaista tece izmedu blokova u konkretnom kontekstu (OMG, 2012). Iz definicije bloka Modem (slika б) sledi da u port modem (koji je tipa Modem) mogu ulaziti i iz njega izlaziti stavke tipa Telegram. Medutim, tok stavki na konektoru koji spaja port modem i deo oC (slika 3) specificira da u port modem ulaze i iz njega izlaze stavke tipa TelTraga, koji predstavljaju jednu specijalizovanu vrstu telegrama.
Ю 00
о CD
p p
a d
ra g
o k
Ю
ra tr
a m s o
le d o m
v a t s o n d je
jo p
w (Л
e m
a t e
v e
ю CD
О >
О
см ОС
УУ 0£ ZD
о
о _|
< о
X
о ш
н
>-
СС <
(Л <
-J
О ■О
X ш н
о
о >
Slika 5 - Portovi i stavke u domenu radarskog osmatranja Рис. 5 - Порт и запись в зоне радиолокационного наблюдения Figure 5 - Ports and items within the radar surveillance domain
Pored standardnih portova koji su preuzeti iz UML-a, u SysML-u postoje jos dve vrste portova: potpun port (eng. full port) i port zastupnik (eng. proxy port). Port zastupnik identifikuje karakteristike bloka koji je vlasnik porta (ili karakteristike unutrasnjih delova tog bloka), a koje su raspolozive spoljasnjim blokovima. Akcija nad portom zastupnikom ekvivalentna je akciji nad blokom ili delom koji taj port zastupa. Tip porta zastupnika mora biti interfejs-blok (eng. interface block). Interfejs-blok je posebna vrsta bloka koja ne moze imati ponasanje i unutrasnje delove. Sa druge strane, potpun port predstavlja zaseban deo sistema koji moze imati svoje ponasanje i unutrasnje delove. Koriscenje pomenutih specijalizovanih vrsta portova nije obavezujuce. Korisnik moze izabrati da li ce na nekom mestu koristiti potpun port, port zastupnik ili „obican" port, u zavisnosti od primenjene metodologije (OMG, 2012). Notacija za potpune portove i portove zastupnike moze se videti na slikama 3 i 4, dok se na slici 5 moze videti notacija za interfejs-blokove.
Na slikama 6 i 7 predstavljeni su dijagrami koji prikazuju dekompoziciju, i unutrasnju strukturu bloka Osmatracki radar, respektivno. Treba napomenuti da ovde nije bio cilj da se radar modelira potpuno tacno i sa svim detaljima vec da se ilustruje SysML notacija.
Stereotip «block» uvodi atribut isEncapsulated tipa Boolean. Ako za neki blok ovaj atribut ima vrednost true, dati blok je kapsuliran (eng. encapsulated) i posmatra se kao crna kutija - veza sa ovim blokom moze se ostvariti iskljucivo putem njegovih portova ili direktno sa njegovom spoljnom ivicom. Ako pomenuti atribut ima vrednost false ili vrednost uopste nije definisana, blok nije kapsuliran i mogu se ostvarivati veze i sa njegovim unutrasnjim delovima (OMG, 2012). Na slici 6 blokovi
Sinhronizator, Duplekser, Predajnik, Prijemnik i Podsistem za akviziciju obradu razmenu i prikaz (AORP) kapsulirani su (uociti notaciju), dok ostali blokovi nisu kapsulirani. Na slici 7 moze se videti kako su delovi dup i aorp povezani konektorima sa unutrasnjim delovima dela ant ciji je tip blok Antenski podsistem koji nije kapsuliran.
Vezivni konektor (eng. binding connector) jeste konektor koji specificira da svojstva na njegovim krajevima imaju istu vrednost. Ukoliko su tipovi tih svojstava blokovi, vezivni konektor oznacava da se instance ovih svojstava odnose na istu instancu bloka (OMG, 2012). Vezivni konektor prikazuje se kao konektor sa kljucnom reci «equal». Tako se, na primer, na slici 7 instance porta zastupnika antena i instance dela ant.antena odnose na istu instancu, cime je zapravo definisano da port antena zastupa deo ant.antena (sve njegove karakteristike stavlja na raspolaganje spoljasnjim blokovima). Isto vazi za port zastupnik pokazivac i port aorp.mon.
Tip vrednosti (eng. value type) jeste tip koji se moze koristiti za izrazavanje informacija o sistemu, ali cije vrednosti nemaju identitet (osim same vrednosti) i ne moze im se pristupati putem reference (OMG, 2012). Formalno, tip vrednosti je stereotip «ValueType» tipa podatka (eng. data type) iz UML-a. Specifikacija SysML definise osnovne tipove vrednosti u paketu PrimitiveValueTypes. Tip vrednosti omogucava da se vrednosti pridruze vrsta velicine (eng. quantity kind) i jedinica (eng. unit). U paketu Tipovi, ciji je sadrzaj prikazan na slici 8, definisani su tipovi vrednosti korisceni u modelu osmatrackog radara. U ugnjezdenom paketu Fizicke velicine definisane su vrste velicina, a u ugnjezdenom paketu Jedinice definisane su jedinice mere vezane za ove velicine. Za svaki od definisanih tipova vrednosti specificirana je jedinica (pomocu atributa unit), dok vrste velicina nisu eksplicitno navedene, jer se implicitno mogu izvesti iz jedinica. Primera radi, vrednosti ciji je tip Brz odnose se na brzinu izrazenu u metrima u sekundi. Vrednosno svojstvo (eng. value property) jeste jedna od novih vrsta svojstava koje uvodi SysML. Tip vrednosnog svojstva mora biti tip vrednosti. Vrednosna svojstva blokova svrstavaju se u standardni odeljak values (slike 4 i 6).
LO
oo
o CD
£± Ci
<0
<0 T3 2 O) O
>o 2 <o E
tn o
ID
T3
o E
gj
1> <o tn o a T3 CD
cT
Ci <0
tn
CO c <1> E
CL
CO <1>
•O <1>
ю CD
О >
О
см ОС
УУ 0£ ZD О
о <
о
X
о ш
I—
>-
Q1 <
(Л <
-J
О >о
X ш I—
о
о >
Slika 6 - Dekompozicija bloka Osmatracki radar Рис. 6 - Декомпозиция блока радиолокационной станции кругового обзора Figure 6 - Decomposition of the Osmatracki radar (surveillance radar) block
Parametarski dijagram
U SysML-u, ogranicavajuci blok (eng. constraint block) jeste vrsta bloka koja predstavlja osnovu za integraciju analitickih modela (npr. model performansi ili pouzdanosti) sa drugim vrstama modela. Ogranicavajuci blok ukljucuje ogranicenje (matematicki ili logicki izraz proizvoljne slozenosti) i parametre ogranicenja (tj. parametre koji se koriste u pomenutom izrazu), a koristi se radi ogranicavanja svojstava drugih blokova (OMG, 2012). Pod uslovom da je dovoljno uopsten, dati ogranicavajuci blok moze se ponovo upotrebiti u mnogim razlicitim kontekstima.
Slika 7- Unutrasnja struktura bloka Osmatracki radar Рис. 7 - Внутренняя структура радиолокационной станции кругового обзора Figure 7 - Osmatracki radar (surveillance radar) block internal structure
Parametarski dijagram specificira kako se ogranicavajuci blokovi koriste da ogranice svojstva nekog bloka. Pod tim se podrazumeva povezivanje parametara ogranicavajucih blokova sa specificnim svojstvima datog bloka, pomocu vezivnih konektora. Sudeci po nekoliko primera parametarskih dijagrama iz (OMG, 2012), kljucna rec «equal» moze se izostaviti sa ovih konektora.
Na slici 9 definisani su osnovni elementi jednostavnog analitickog modela. U pitanju je jedan deo modela performansi osmatrackog radara koji se odnosi na analizu maksimalnog dometa otkrivanja pokretnih objekata. Kod ogranicavajucih blokova ogranicenja se svrstavaju u standardni odeljak constraints, a ostala
Ю
oo
о CD
cp
a d ra
D)
o k c ra tr
a
m
e d o m
v a t s o n d je jo
Ci
a
(Л >-
Ю
e m
a t e
vt e
ю CD
О >
0
01
ОС ш
0£ ZD О
о <
о
X
о ш
I—
>-
Q1 <
(Л <
-J
О >о
X ш I—
о
о >
svojstva u standardni odeljak parameters. Ogranicavajuce svojstvo (eng. constraint property) jeste svojstvo ciji je tip ogranicavajuci blok. Ogranicavajuca svojstva bloka svrstavaju se u standardni odeljak constraints. Blok KontekstMaksimalnogDometa predstavlja kontekst za pomenutu analizu maksimalnog dometa. Ovaj blok sadrzi dva ogranicavajuca bloka: blok RadarskaJednacina koji definise zavisnost snage primljenog signala od snage predajnog signala i razlicitih parametara radarskog sistema i osmatranog objekta i blok JednacinaTalasneDuzine koji definise medusobnu zavisnost talasne duzine, ucestanosti i brzine prostiranja talasa. Blok KontekstMaksimalnogDometa ima i referencu na blok Domen radarskog osmatranja.
Slika 8 - Tipovi vrednosti u domenu radarskog osmatranja Рис. 8 - Типы значений в зоне радиолокационного наблюдения Figure 8 - Value types in the radar surveillance domain
Na slici 10 prikazan je parametarski dijagram koji se odnosi na blok KontekstMaksimalnogDometa. Ovde se vidi kako su parametri ogranicavajucih blokova povezani sa svojstvima bloka KontekstMaksimalnogDometa i ugnjezdenim svojstvima blokova u „je deo" hijerarhiji bloka Domen radarskog osmatranja, radi modelovanja matematickih relacija koje postoje izmedu maksimalne daljine otkrivanja pokretnog objekta (dro.pokObj.daljina) i drugih relevantnih parametara.
ю оо
о CD
го тз го
О)
о
>о го
+J
го Е
ф
тз о Е
> го
-ь-' (Л
о с
тз ф
сТ го
(Л >-
ю
ф Е
го ф
■О ф
Slika 9 - Definicija konteksta za analizu maksimalnog dometa radara Рис. 9 - Определение контекста для анализа максимального диапозона радиолокационного наблюдения Figure 9 - Maximal range analysis context
Dijagram aktivnosti
U UML-u aktivnosti su klase cije su instance izvrsenja aktivnosti (OMG, 2012). Samim tim, aktivnosti se mogu pojaviti na dijagramima definicije blokova i mogu ucestvovati u relacijama generalizacije i asocijacije. SysML uvodi pojasnjenje semantike kompozicije izmedu dve aktivnosti i izmedu aktivnosti i tipa objektnog cvora. Kreiranjem instance aktivnosti zapocinje se izvrsavanje aktivnosti, a unistavanjem instance aktivnosti izvrsavanje se zaustavlja. Ako jedna aktivnost poziva drugu aktivnost onda ove dve aktivnosti mogu biti povezane relacijom kompozicije, pri cemu je pozivajuca aktivnost na strani celine, a pozivana aktivnost na strani dela. Gornja granica multiplikativnosti na strani dela ogranicava broj konkurentnih izvrsavanja pozivane aktivnosti. Donja granica multiplikativnosti na strani dela uvek je nula, jer tokom izvrsavanja pozivajuce aktivnosti postoji vremenski interval u kojem se pozivana aktivnost ne izvrsava. Na slici 11 prikazan je dijagram definicije blokova koji prikazuje relacije izmedu aktivnosti Osmatranje i njenih podaktivnosti. Ovakav prikaz podseca na klasicnu funkcionalnu dekompoziciju.
Na slici 11 prikazane su i relacije izmedu aktivnosti Osmatranje klasifikatora koji su tipovi objektnih cvorova u ovoj aktivnosti (prikazan ruzicastom bojom). Relacija kompozicije ukazuje na to da objektni cvorovi ne mogu postojati nakon zavrsetka izvrsavanja aktivnosti. Gornja granica multiplikativnosti na strani dela (tj. objektnog cvora) ogranicava broj instanci koje istovremeno mogu postojati u objektnom cvoru. Donja
ю CD
О >
0
01
ОС уу
0£ ZD О
о <
о
X
о ш
I—
>-
Q1 <
(Л <
-J
О >о
X ш I—
о
о >
granica multiplikativnosti na strani dela uvek je nula, posto tokom izvrsavanja aktivnosti postoje intervali u kojima je objektni cvor prazan.
Slika 10 - Matematicke relacije vazane za analizu maksimalnog dometa radara Рис. 10 - Математические отношения, связанные с анализом максимального диапозона радиолокационного наблюдения Figure 10 - Mathematical relations for the maximal range analysis
Na slici 12 prikazan je dijagram aktivnosti za aktivnost Osmatranje. Ovde najpre treba uociti da su imena akcija pozivanja ponasanja (eng. call behavior action) ista kao imena uloga pozivanih aktivnosti na slici 11. To je primer primene jednog od pravila konzistentnosti koja uvodi SysML.
Takode, treba uociti (iako nije u pitanju specificnost SysML-a) da u aktivnosti Osmatranje postoji nekoliko paralelnih tokova kontrole cije se
izvrsavanje moze prekinuti jedino izlaskom iz prekidljivog regiona aktivnosti (eng. interruptible activity region) pojavom signala Iskljucenje.
bdd [Package] Osmatranje [Osmatranje]
Ю CO
о
CD
ГО T3 ГО
О) О
>o
ГО
ч—<
ГО
E
<л о
"03
T3
о E
> го
Ч—'
<л о с тз 0) 'с?
СО >-
СО
«activity» Prijem VF eho signala
«activity» Generisanje VF predajnog signala
«activity» Demodulisanje VF eho signala
«activity» Emitovanje VF predajnog signala
«activity» 0..1 «activity» VFSignal VFSignal
Akvizicija videa i azimuta Automatska detekcija i «block» «block»
pracenje VFPredajniSignal VFEhoSignal
«block»
VideoLinija
values
«property) azimut : Real
«property) odbirciVidea : Integer
Slika 11 - Dekompozicija aktivnosti Osmatranje Рис. 11 - Декомпозиция деятельности Наблюдения Figure 11 - Decomposition of the Osmatranje (surveillance) activity
Stereotip «rate» moze se primeniti na granu ili na parametar i omogucava da se pomocu njegovog atributa rate specificira brzina toka (eng. rate of flow), tj. broj objekata ili vrednosti koje prelaze preko grane, odnosno teku u/iz parametra u jedinici vremena (OMG, 2012). Tok moze biti diskretan ili kontinualan. Stereotip «discrete» je specijalizacija stereotipa «rate» i sluzi za oznacavanje diskretnih tokova (vremenski interval izmedu prolazaka stavki koje teku je razlicit od nule). Stereotip «continuous» takode je specijalizacija stereotipa «rate», a namenjen je za predstavljanje kontinualnih tokova kao sto su signali kontinualni u vremenu ili kontinualni tok energije. Na slici 12 prikazano je kako se pomocu kontinualnih tokova moze modelovati tok kontinualnih signala (VFPredajniSignal, VFEhoSignal i VideoSignal) izmedu aktivnosti. Tok vrednosti azimuta antene modelovan je diskretnim tokom, posto se azimut najcesce odreduje pomocu optickog enkodera (u ovom slucaju navedena je brzina toka 819.2 Hz, sto odgovara slucaju kada se koristi 13-bitni enkoder, a perioda obrtanja antene je 10 sekundi). Paketski prenos video linija i tragova takode je modelovan diskretnim tokom.
U UML-u, ako je token koji pristize u objektni cvor odbijen od izlazne grane (ili akcije kojoj je objektni cvor ulazni pin), token se zadrzava u cvoru sve dok se ne steknu uslovi za njegov odlazak. SysML uvodi stereotip «noBuffer» koji, ako se primeni na objektni cvor, menja prethodno opisano ponasanje, tako da se token koji ne moze da napusti
o
o >
O CM
D¿ UJ
a.
Z) O O
_l <
o
X
o
LU
H >-
OU <
H
<
CD >o
X LU H O
O >
cvor odbacuje. Jedna od tipicnih primena ovog stereotipa javlja se kod modelovanja elektricnih signala (OMG, 2012), sto je primenjeno i na slici 12.
SysML uvodi i stereotip «overwrite». Kada token pristigne na pun objektni cvor na koji je primenjen ovaj stereotip (pun objektni cvor sadrzi maksimalan dozvoljen broj tokena), dati token zamenice jedan od tokena koji su vec u cvoru. Na slici 12 objektni cvor tipa Azimut ima stereotip «overwrite», sto uzevsi u obzir da je gornja granica multiplikativnosti za ovaj cvor 1 (slika 11), osigurava da ce se u ovom cvoru cuvati samo vrednost azimuta koja je poslednja pristigla.
Na slici 12 prikazano je kako se na dijagramu aktivnosti moze oznaciti alokacija ponasanja (eng. behavior allocation) pomocu stereotipa «allocateActivityPartition» primenjenog na pregradu aktivnosti (eng. activity partition). Alokacija je termin koji se u sistemskom inzenjerstvu koristi za oznacavanje organizovane asocijacije ili mapiranja medu elementima koji pripadaju razlicitim strukturama ili hijerarhijama u modelu (OMG, 2012). Alokacija ponasanja je jedna od tipicnih vrsta alokacije u sistemskom inzenjerstvu, a odnosi se na mapiranje izmedu elemenata funkcionalnog i strukturnog modela. Tako je, na primer, na slici 12 ponasanje opisano aktivnoscu Demodulisanje VF eho signala asocirano sa strukturnim elementom (svojstvom) prij tipa Prijemnik, itd.
Dijagram zahteva
U SysML-u zahtev (eng. requirement) jeste stereotip klase namenjen za modelovanje zahteva predstavljenih u tekstualnom obliku. Osnovni atributi koje uvodi ovaj stereotip su id (jedinstveni identifikator zahteva) i text (tekst zahteva). Dijagram zahteva namenjen je za prikaz zahteva i njihovih relacija sa drugim elementima modela. Zahtevi se mogu pojavljivati i na drugim dijagramima radi prikazivanja njihovih relacija sa drugim elementima. Na slici 13 prikazan je dijagram zahteva koji prikazuje deo specifikacije radara koji se odnosi na uslove okoline prilikom upotrebe.
Stereotip «deriveReqt», primenjen na relaciju zavisnosti izmedu dva zahteva, oznacava da je zahtev na klijentskoj strani relacije izveden iz drugog zahteva, npr. zahtev na nizem nivou apstrakcije koji je izveden iz sistemskog zahteva (OMG, 2012). Na slici 13, iz zahteva Podsistemi unutar kabine -uslovi okoline (upotreba), koji predstavlja sistemski zahtev vezan za uslove okoline, izveden je zahtev Prijemnik - uslovi okoline (upotreba) koji definise uslove okoline za jedan konkretan podsistem. Pored same klase uslova okoline, standard EN 300 019 definise i specifikaciju testova kojima se proverava da li neki uredaj zadovoljava zahtev za funkcionisanjem u uslovima okoline opisanim datom klasom. Ovde je to modelirano izvodenjem zahteva
Prijemnik - specifikacija testova uslova okoline (upotreba) iz zahteva Prijemnik- uslovi okoline (upotreba).
Ю
oo
о CD
CP CP
ro
T3 2 O)
о
>o
2
ro E
<u
T3
о E
> ro
4—'
(Л
о с тз CD
cT
Ci
го
(Л >-
ю
<u E
го <u
■О
<u
Slika 12 - Aktivnost Osmatranje Рис. 12 - Действия Наблюдения Figure 12 - Osmatranje (surveillance) activity
ю CD
О >
0
01
ОС уу
0£ ZD О
о <
о
X
о ш
I—
>-
Q1 <
(Л <
-J
О >о
X ш I—
о
о >
Stereotip «copy» moze se primeniti na relaciju zavisnosti izmedu dva zahteva kako bi oznacio da je tekst zahteva na klijentskoj strani relacije nepromenljiva (eng. read-only) kopija teksta drugog zahteva. Svrha ove relacije jeste da omoguci ponovnu upotrebu zahteva u razlicitim kontekstima. Sa slike 13 se vidi da je zahtev Prijemnik - specifikacija testova uslova okoline (upotreba) zapravo kopija zahteva T3.1 -Temperature-controlled locations, koji pripada modelu EN 300 019.
Slika 13 - Relacije vezane za zahteve Рис. 13 - Связь между установленными требованиями Figure 13 - Relations which pertain to requirements
Zahtev T3.1 - Temperature-controlled locations moze se ponovno &
upotrebiti u drugim projektima, jer predstavlja univerzalnu specifikaciju primenljivu na bilo koji uredaj. Sa slike 13 takode se vidi kako se slozen zahtev moze razloziti na jednostavnije, koriscenjem relacije ugnjezdivanja.
Slucaj testiranja (eng. test case) oznacava metod kojim se proverava da li je zahtev zadovoljen (OMG, 2012). Relacija zavisnosti sa stereotipom «verify» moze postojati izmedu zahteva i slucaja testiranja ili drugog % elementa modela koji moze da odredi da li sistem zadovoljava zahtev (OMG, 2012). Na slici 13 je pomocu ove relacije oznaceno da se zahtev T3.1 Low air temperature moze proveriti pomocu slucaja testiranja T3.1 § Low air temperature test. Formalno, slucaj testiranja je stereotip «testCase» operacije ili ponasanja, pa se moze modelovati pomocu dijagrama ponasanja.
Relacijom zavisnosti na koju je primenjen stereotip «satisfy» moze se oznaciti element modela koji ispunjava neki zahtev. Ovom relacijom je na b slici 13 oznaceno da blok Prijemnik ispunjava zahtev Prijemnik - uslovi okoline (upotreba) (prijemnik je projektovan tako da zadovolji zahtev za funkcionisanjem u odredenim uslovima okoline).
SysML u praksi
Sistemski inzenjer, suocen sa dilemom da li da uvede SysML u svoju praksu, najverovatnije bi postavio i sledeca dva pitanja: 1) da li je SysML „zaziveo", tj. kako ga je prihvatila strucna i naucna zajednica i kakva je perspektiva njegove primene i 2) kakvi alati za SysML modelovanje su raspolozivi? U ovom odeljku pokusacemo odgovoriti na ta pitanja.
Prihvacenost i perspektiva SysML-a
Godine 2009. OMG je sproveo onlajn anketu sa ciljem da se korisnicima SysML-a i proizvodacima alata omoguci da daju povratne informacije koje ce pomoci da se unaprede buduce verzije SysML-a. Detaljni rezultati ankete navedeni su u (Cloutier, Bone, 2010.), dok su kljucne informacije sumirane u (Bone, Cloutier, 2010.). Anketa je bila otvorenog tipa, a u njoj je ucestvovalo 128 ispitanika iz 45 organizacija iz 16 zemalja (Bone, Cloutier, 2010.). Medu anketiranima najvise je bilo sistemskih inzenjera (Bone, Cloutier, 2010.). Anketa je pruzila puno informacija o tekucem statusu SysML-a i SIZM (Bone, Cloutier, 2010.). Jedno od pitanja odnosilo se na to u kojoj meri se u organizacijama anketiranih lica planira upotreba SysML-a u buducnosti. Vise od dve
ro
>
T3 <D
cT
CP
ro
tf> >
<u E
ro <u
-5
<u
trecine anketiranih (71,3%) odgovorilo je da njihova organizacija vec koristi SysML ili planira da ga uvede u svoju praksu (Bone, Cloutier, 2010.). To ® pokazuje da je strucna zajednica dobro prihvatila SysML i da on > predstavlja perspektivan jezik za modelovanje.
Sa druge strane, relativno kratkom pretragom nama dostupnih indeksnih baza uspeli smo da pronademo preko 40 radova koji se u nekoj o¿ meri doticu SysML-a. U mnogim od ovih radova „SysML" se pojavljuje u
UJ
E naslovu ili u listi kljucnih reci. Pregled pomenutih radova prevazilazi obim o ovog teksta, ali samo njihovo postojanje ukazuje na to da SysML ima
o <
o
X
o
LU
znacajan uticaj i u akademskim okvirima.
SysML alati
£ Alati za SysML modelovanje sa komercijalnom licencom ukljucuju:
< IBM Rational Rhapsody, NoMagic MagicDraw, Sparx Systems Enterprise Architect, Artisan Studio i IBM Rational Tau. Treba napomenuti da se kod pojedinih komercijalnih alata podrska za SysML modelovanje dobija ili kupovinom posebnog dodatka ili kupovinom specijalne verzije alata w („systems engineering edition" i sl.). Besplatni SysML alati ukljucuju: ^ TOPCASED i Papyrus forSysML. Postoji i alat Modelio, koji ima i 2 komercijalnu i besplatnu verziju. Verzija Modelio-a otvorenog koda ne ^ podrzava modelovanje zahteva.
x Tokom upoznavanja sa SysML-om testirali smo jedan besplatan
(TOPCASED) i jedan komercijalan (Sparx Systems Enterprise Architect) alat. Besplatan alat je u verziji koju smo koristili imao gresku koju nije bilo o moguce prevazici (nije bilo moguce prikazati relaciju ugnjezdivanja na dijagramu zahteva). Kod komercijalnog alata, pomocu kojeg su izradeni modeli i dijagrami korisceni u ovom tekstu, takode su postojali propusti, koji su ili bili superficijalni ili ih je bilo moguce prevazici. Ako uzmemo u obzir i prethodno pomenutu nemogucnost modelovanja zahteva u drugom besplatnom alatu (Modelio), stice se utisak da besplatni SysML alati jos uvek nisu dostigli nivo zrelosti komercijalnih konkurenata. Nadamo se da ce se to u buducnosti promeniti.
Zakljucak
Jezik za modelovanje SysML je, pre svega, namenjen za primenu u SIZM, ali je generalno primenljiv svuda gde je potrebno modelovati slozene sisteme. Glavne razlike u odnosu na UML odnose se na dve nove vrste dijagrama koji omogucuju modelovanje tekstualnih zahteva i
integraciju analitickih modela sa drugim vrstama modela, kao i na brojne izmene u strukturnim dijagramima i u dijagramu aktivnosti. Te izmene omogucavaju modelovanje najrazlicitijih sistema ili elemenata sistema, kao sto su elektronski ili mehanicki sistemi/elementi, postrojenja, organizacije, itd. U ovom clanku SysML je ilustrovan na tipicnom primeru slozenog sistema ciji razvoj bi zahtevao interdisciplinarni pristup - primeru osmatrackog radara. Ovaj primer nije preuzet iz postojece literature vec je smisljen za potrebe ovog clanka.
U praksi je SysML dobro prihvacen, kako od strucnjaka - sistemskih inzenjera, tako i od naucne zajednice. Mnoge organizacije vec primenjuju SysML ili planiraju njegovu primenu u buducnosti. Na raspolaganju su i brojni alati za SysML modelovanje, kako komercijalni, tako i besplatni.
Na osnovu svega sto je receno, kao i na osnovu licnog iskustva, moze se zakljuciti da je SysML ekspresivan, koristan i perspektivan jezik za modelovanje, cija bi primena mogla pospesiti komunikaciju medu zainteresovanim stranama u interdisciplinarnim projektima i unaprediti proces razvoja slozenih sistema.
Literatura
Bone, M., & Cloutier, R. 2010. The Current State of Model Based Systems Engineering: Results from the OMG SysML Request for Information 2009. . In: 8th Conference on Systems Engineering Research CSER, Hoboken, NJ., pp.225-232
Cloutier, R., & Bone, M. 2010. Compilation of SysML RFI - Final Report.Stevens Institute of Technology, School of Systems & Enterprises.
Estefan, J.A. 2008. Survey of Model-Based Systems Engineering (MBSE) Methodologies, Rev. B.INCOSE MBSE Initiative.
Friedenthal, S., Moore, A., & Steiner, R. 2008. A Practical Guide to SysML: The Systems Modeling Language. Burlington, MA: Morgan Kaufmann Publishers.
INCOSE. 2004. Systems Engineering Handbook, Version 2a.
OMG. 2012. Systems Modeling Language (OMG SysML) Version 1.3.
Tartalja, I. 2011. Skripta za predmet Projektovanje softvera.Beograd: Elektrotehnicki fakultet Univerziteta u Beogradu, Katedra za racunarsku tehniku i informatiku.
Weilkiens, T. 2007. Systems Engineering with SysML/UML: Modeling, Analysis, Design.Burlington, MA: Morgan Kaufmann Publishers.
LO
oo
o CD
£± cp
coro
T3 2 O)
o >o 2 CO
E
tn o
ID
T3
o E
.CD
1>
CO +-1
tn o c T3 CD
cT cp CO
tn
CO c CD
E
CL
CO CD
•o CD
ю- ПРИМЕНЕНИЕ ЯЗЫКА SYSML НА УПРОЩЕННОЙ МОДЕЛИ
со
о >
о
РАДИОЛОКАЦИОННОГО НАБЛЮДЕНИЯ
Милош Д. Евтича, Синиша Р. Маринкович6, Ивица Б. Марьянович
см Университет в Белграде, Электротехнический факультет, г. Белград,
^ Республика Сербия
Е б Университет в Белграде, Институт «Михайло Пупин», г. Белград, 0 Республика Сербия
° в Министерство обороны Республики Сербия, Военный контроль < качества, г. Белград, Республика Сербия
I ОБЛАСТЬ: информатика
ВИД СТАТЬИ: профессио ЯЗЫК СТАТЬИ: сербский
ш ВИД СТАТЬИ: профессиональная статья
ОН
< Резюме:
Systems Modeling Language (SysML) представляет собой профиль Unified Modeling Language (UML), предназначенный для применения в системной инженерии. Недостаток литературы о S SysML на сербском языке подтолкнул автора данной статьи к ее
^ написанию, с целью представления этого интересного языка
^ моделирования инженерному и академическому сообществу, при
о этом подчеркиваются различия между языками SysML и UML.
Описание профиля приведено на основании конкретного примера -ш упрощенной модели радиолокационного наблюдения. Проведен
о краткий анализ практических аспектов SysML о его внедрении,
перспективах дальнейшего применения и пр. В заключении приведены выводы о полезности применения языка SysML, его употребляемости и благоприятных перспективах в связи с его внедрением.
Ключевые слова: системная инженерия основанная на моделях, радиолокационное наблюдение, SysML, ими
в
APPLICATION OF SYSML ON A SIMPLIFIED MODEL OF AN AIR SURVEILLANCE RADAR
Milos D. Jevtica, Sinisa R. Marinkovicb, Ivica B. Marjanovicc a University of Belgrade, School of Electrical Engineering, Belgrade, Republic of Serbia,
b University of Belgrade, Institute „Mihajlo Pupin", Belgrade, Republic of Serbia,
c Ministry of Defence of the Republic of Serbia, Military Quality Control, Belgrade, Republic of Serbia
FIELD: IT
ARTICLE TYPE: Professional Paper ARTICLE LANGUAGE: Serbian
Summary:
Systems Modeling Language (SysML) is a Unified Modeling Language (UML) profile intended for application in systems engineering. This text is inspired by lack of literature on SysML in Serbian language. Its goal is to introduce this interesting modeling language to the engineering and academic community, with a special emphasis on the differences from UML. An overview is given, using an original example - a simplified model of an air surveillance radar. A short analysis of practical aspects of SysML is made - its scope of acceptance, the prospects of its further application, etc. We concluded that SysML is a useful, accepted and promising modeling language.
Key words: Model-based systems engineering, Airsurveillance radar, SysML, UML.
Datum prijema clanka / Дата получения работы / Paper received on: 13. 07. 2015. Datum dostavljanja ispravki rukopisa / Дата получения исправленной версии работы / Manuscript corrections submitted on: 06. 11. 2015.
Datum konacnog prihvatanja clanka za objavljivanje / Дата окончательного согласования работы / Paper accepted for publishing on: 08. 11. 2015.
© 2017 Autori. Objavio Vojnotehnicki glasnik / Military Technical Courier (www.vtg.mod.gov.rs, vtg.mo.upr.srb). Ovo je clanak otvorenog pristupa i distribuira se u skladu sa Creative Commons licencom (http://creativecommons.org/licenses/by/3.0/rs/).
© 2017 Авторы. Опубликовано в «Военно-технический вестник / Vojnotehnicki glasnik / Military Technical Courier» (www.vtg.mod.gov.rs, втг.мо.упр.срб). Данная статья в открытом доступе и распространяется в соответствии с лицензией «Creative Commons» (http://creativecommons.org/licenses/by/3.0/rs/).
© 2017 The Authors. Published by Vojnotehnicki glasnik / Military Technical Courier (www.vtg.mod.gov.rs, втг.мо.упр.срб). This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/rs/).
LO
oo
о CD
p. p
<0
ar
d
ra g
o k c ra tr
a m s o
le d o m
je vl
a t s o n d je
jo p
a
tn
CO с CD
E
CL
CO
t
CD
■o CD
