| Abstract: | V trenutnem tehnološko naprednem svetu se področje inženiringa pomika z veliko hitrostjo. Eno on najbolj pomembnih pristopov za snovanje in vzdrževanje velikih, kompleksnih sistemov je sistemski inženiring. S pomočjo definicije zahtev za naš sistem lahko oblikujemo pisno ali vizualno dokumentacijo, ki pripomore k lažjemu razumevanju sistema, ki ga snujemo. Proces sistemskega inženirstva lahko predstavimo s pomočjo V-modela. Snovanje sistema sodi na levi krak V-modela, sledi mu dolina, ki predstavlja implementacijo, in na desnem kraku modela je preizkušanje ustreznosti rešitev. Fokus te naloge bo drugi krak, bolj podrobno verifikacija in validacija sistemskega modela.
S pomočjo modelarskega jezika SysML je možno ustvariti dokumentacijo, ki definira celoten sistem s pomočjo vizualnih objektov, kot so diagrami. Ker je jezik SysML standardiziran s strani organizacije OMG (Object Management Group), se lahko uporablja v različnih programskih okoljih, kar pomeni da se metoda, omenjena v tej nalogi, ne navezuje samo na orodje PTC Winchill Modeler.
Na področju avtomatizacije postopkov sistemskega inženiringa je pri podjetju AVL že nekaj rešitev. Za izvoz in uvoz testnih primerov iz orodja Integirty Lifecycle Manager se uporablja skripta, ki zmanjša potreben čas in trud. Avtomatsko generira datoteke, ki se uporabljajo na testnih postajah, rezultat testov pa ponovno avtomatsko uvozi v programsko okolje.
V sklopu izboljšav je tudi skupek pristopov, ki izboljšajo efektivnost in zmanjšajo potreben čas. Eden izmed teh je polformalni zapis zahtev, ki ga lahko prebere tudi računalnik. Kot predhodnik trenutne naloge je bila programska rešitev, s katero se lahko izvozijo testni primeri, ampak samo iz sistemskega diagrama stanj.
Najprej je bilo treba definirati obseg dela, ki je zavzemal dva različna testna primera od predhodnega projekta. S pomočjo teh dveh primerov bo možno ustvariti program, ki bo lahko operiral z različnimi testnimi primeri. Ker je za avtomatsko generiranje potrebno več podatkov kot prejšnjič, je bilo treba raziskati nov pristop modeliranja. Pristop, ki je bil najbolj primeren, je bila uporaba sekvenčnega diagrama, ki je prikazal točen potek korakov in tudi zavzemal vse potrebne informacije signalov.
V diagram je bilo treba vključiti označbe, ki jih lahko program uporabi za pravilno formiranje testnih primerov. Testni primer je razdeljen na več delov: predpogoj, testni postopek, kriterij in sledeči pogoj. Prvi del je predpogoj, ki bo definiran v posebnem diagramu, saj v realni aplikaciji ne bo samo en testni primer v enem diagramu, kar bi povzročilo zmešnjavo. Predpogoji so označeni s komentarjem s posebno obliko in povezavo do diagrama predpogojev. Naslednje so označene dejavnosti testnega inženirja med testom ali druge stvari, ki delujejo na testni objekt. Te so označene s komentarji in zaporednimi števili. Testni kriterij pa določa, kaj dejansko se mora preveriti med tem testom. Teh kriterijev je lahko več, imajo tudi dva tipa, ki določata, kako bo program te kriterije izvozil.
Prvi tip je pogoj pravilnega zaporedja pošiljanja signalov, drugi pa je pogoj oblike določenega sporočila. Prvi tip je označen s komentarjem, drugi pa se avtomatsko prebere, če ima sporočilo besedilo. Glede na uspešnost testnega primera pa je v diagramu tudi odločitev, ki pove, kaj se zgodi, če je test uspešen ali neuspešen.
S pripravljenima primeroma je bilo možno napisati program, ki bo te informacije izvlekel. Ker je za modeliranje sistema uporabljen program Windchill Modeler, je bilo treba izbrati dostop do okolja, ki ga ponuja PTC za svoje programske pakete. Dostop je možen z vmesnikom, ki je bil vključen v program, sam program pa je bil napisan v jeziku C#.
Program se najprej poveže s programskim paketom Windchill Modeler, nato navigira do želenega diagrama, kar je trenutno fiksno napisano v kodi. Ko je pravi diagram najden, se preveri, ali sploh vsebuje testni primer; če ga ne, se to javi uporabniku in program se zaključi. |
|---|
