Förslaget till specifikationsspråket SysML godkändes nyligen av OMG. Det innebär att det slutliga standardiseringsarbetet nu är igång på allvar. Alan Moore från Artisan Software Tools arbetade som specifikationsarkitekt under utvecklingsarbetet och han beskriver här språket och dess användningsområden.
Hela artikeln i PDF-format.
I början av april lämnade ”SysML Merge Team” (SMT) under ledning av Sanford Friedentahl från Lockheed Martin Corp in förslaget till SysML v1.0 till OMG (Object Management Group) för genomgång och godkännande. I slutet av april godkändes förslaget enhälligt av OMG.
Bakgrunden till SysML är en förfrågan (Request for Proposal9 från OMG och INCOSE (the International Council on Systems Engineering) om en specialversion av UML 2, anpassad för systemingenjörernas speciella behov.
Den SysML-specifikation som nu godkänts är ett resultat av ett mycket ovanligt samarbete mellan några av de största verktygstillverkarna, ledande användare, myndigheter och professionella organisationer. Att skapa SysML-specifikationen har varit ett gigantiskt arbete, där över 100 manårs arbete lagts ner.
SysML är ett visuellt modelleringsspråk som utvidgar UML 2.0 för att stödja specifikation, analys, konstruktion, verifiering och validering av komplexa system. Specifikationen skall kunna hantera hårdvara, mjukvara, data, personal, procedurer etc. SysML återanvänder ett subset av UML 2-koncept och diagram och lägger till en del nya diagram och uppställningar som lämpar sig för systemmodellering.
Ett av målen för SysML var att återanvända så mycket som möjligt av UML 2 och undvika ändringar, utom där det var helt nödvändigt. SMT definierade ett subset av UML 2 som kallades UML4SysML, där man plockade bort i sammanhanget onödiga delar ur UML. SysML-profilen använde sedan UML4SysML som referens-metamodell. I SysML återanvänds många UML-diagram, andra har modifierats och bara två diagram är helt nya (Requirement Diagram och Parametric Diagram). Den här artikeln kommer framför allt att fokusera de här två nya diagrammen och det nya strukturella konceptet ”Block”.
Krav i SysML
Ett av de två grundläggande tilläggen i SysML är stödet för krav. <>-stereotypen utvidgar en klass till att också specificera det textuella ”shall”-uttrycket och fånga den kravidentifikation (requirement Id) som ofta används för integration med externa kravhanteringssystem. UMLs ”containment relationship” används för att bryta ner ett krav till sina delkrav. Ett krav relateras till andra modelleringsartefakter via en uppsättning av stereotypade beroenden. Beroendena <> och <> beskriver hur krav härleds från andra krav och hur kraven tillfredsställs av respektive konstruktion. <> visar länken från ett testfall till det eller de krav som verifieras.
Två sena tillägg var UMLs beroende <>, som används för att indikera att ett modellelement i SysML är en förfining av ett textuellt krav, och <>, som används för att återanvända en del standardkrav inom den befintliga kravhierarkin.
Det generiska ”rationale”-konceptet kan användas av kravmodelleraren för att identifiera stödjande information som ger en bas för härledda krav, en ”design rationale” eller något annat modelleringsbeslut.
Bara ett kravs mest grundläggande attribut täcks av SysML-specifikationen. Mer specialiserade kravtyper kan anges genom att specialisera <>-stereotypen. Typiska exempel på det är operationella krav, funktionella krav, gränssnittskrav, styrkrav, prestandakrav, fysiska krav och lagringskrav.
Dessa stereotyper kan begränsa vilken typ av modellelement som kan tillfredsställa kravet. Till exempel kanske ett prestandakrav bara kan tillfredsställas av ett ”Constraint Block”, tillsammans med en associerad tolerans och/eller sannolikhetsdistribution. Ett funktionellt krav kanske kan tillfredsställas av en aktivitet eller en klassoperation. En (icke-normativ) uppsättning av sådana specialiserade stereotyper finns i appendix C i SysML-specifikationen.
Kravmodellen kan visas i en grafisk trädstruktur eller i tabulerat format. Det grafiska formatet kallas ”Requirements Diagram” och ett exempel på det visas i fig 1.
Vänstra sidan av fig 1 visar kravflödet nedåt för ett destillationssystem. Beroendet <> är gränssnittet från ett användarkrav (Produce Distilled Water) till ett systemkrav (Boil Water). ”Produce Distilled Water” spåras uppåt till ett originaldokument (Customer Brochure) och förfinas av användarfall (Distill Water), som innehåller mer detaljerade användarscenarier, kanske med sekvensdiagram.
”Boil Water” bryts ner i underkrav som visar andra relationer. Beroendet <> visar att kokaren (Boiler) förser systemet med den nödvändiga ”Boiler”-funktionaliteten. Beroendet <> från testfallet ”Boiler Test” används för att verifiera kravet ”Boiler Power”. Kravet ”Safety Cut Off” är en kopia av ett standardiserat säkerhetskrav. Varje krav har en unik ID, som visas vid id#-etiketten. Kravets ”shall-statement” visas i en avdelning med namnet ”txt” i den undre delen av klassboxen.
Det format som visas här är bara ett av ett antal möjligheter. ”Ergonomic Profiling” kan användas för att modifiera formatet så att det passar läsaren. De exakta möjligheterna för den typen av finess beror på vilket verktyg som används.
Block
Den viktigaste strukturella utvidgningen i SysML är ”Block”, vilket utvidgar ”UML Structured Class”. Det här är en generell hierarkisk struktureringsmekanism som abstraherar bort mycket av de mjukvaruspecifika detaljer som finns i UMLs strukturerade klasser.
Block kan representera valfri nivå av systemhierarkin, inklusive toppnivån, subsystem eller logiska eller fysiska komponenter av ett system eller dess omgivning. Ett ”Block” i SysML beskriver ett system som en uppsättning delar och förbindningar mellan dem som tillåter kommunikation och andra former av samband.
Portar (Ports) är en speciell typ av komponent som ger access till en intern struktur från utsidan av ett kompositobjekt. Det används när blocket används inom en större struktur. Dock kan i SysML, till skillnad från i UML, så kallade ”deep-nested”-förbindelser dras direkt till interna element om så behövs. Detta har visat sig vara nödvändigt för att beskriva fysiska system, som ofta inte bara beskrivs som svarta lådor. Det finns två typer av portar, ”Service Ports” som hanterar klient-server-kommunikationen och ”Flow Ports”, som definierar flödet in och ut från ett block.
Två diagram används för att beskriva förhållanden mellan block. ”Block Definition Diagram” (bdd) liknar ett vanligt klassdiagram och används för att beskriva förhållanden som existerar mellan block. ”Internal Block Diagram” (ibd) används för att beskriva de interna funktionerna hos ett block. Ett exempel på en ibd visas i fig 2.
Figuren visar den interna strukturen hos ”Distiller”-blocket. Blocket har två delar, hx, en värmeväxlare (Heat Exchanger) och bl, en kokare (Boiler). De bägge är sammankopplade för att tillåta material och energi att flyta mellan dem och (via anslutningen till sin ”parent”) till externa system. hx och bl har vardera ett antal flödesportar som beskriver vad som kan flöda in och ut. Dessa är anslutna till andra kompatibla portar för att möjliggöra de flöden som krävs i det här sammanhanget. Pilarna representerar poster, vilket visar de flöden som faktiskt uppträder i systemet och vilka egenskaper som kan användas i parametriska modeller (som visas i fig 3).
De olika avdelningarna i ”hx” och ”bl” visar värden för olika viktiga funktions- och prestandaparametrar i blocken.
Parametriska modeller
Parametriska modeller används för att beskriva systemegenskaper och deras förhållanden till varandra. För att stödja den här typen av modellering introducerades en ny strukturell egenskap kallad ”ConstraintBlock” i SysML. Ett ConstraintBlock definierar en uppsättning parametrar och ett eller fler uttryck som beskriver hur en förändring av en parameteters invärde påverkar värdet hos andra parametrar. Som standard är de här parametrarna icke-direktionella och har inget begrepp om kausalitet. Dessa ConstraintBlocks kopplas sedan via sina parametrar till systemegenskaper för att skapa systembegränsningar. Eftersom block är återanvändbara kan nya ConstraintBlock byggas genom att återanvända mera primitiva block, till exempel grundläggande matematiska operatorer.
SysML definierar också en modell med typvärden som kan hantera enheter och dimensioner. Dessa typvärden kan sedan användas för att skriva parametrar i parametriska modeller.
ConstraintBlocks kan användas för matematiska ekvationer, som t ex F=m*a=dv/dt’, eller statistiska värden.
Ett specialiserat diagram, ”Parametric Diagram”, introducerades för att underlätta en parametrisk utgångspunkt.
Det är en specialiserad version av ett internt blockdiagram som begränsar diagramelementen till att bara representera ConstraintBlocks, deras parametrar och blockegenskaperna som de kopplas till. Både parametrar och egenskaper kan representeras som små ”pin-liknande” lådor för att göra diagrammen mera skalbara.
Ett exempel på ett parametriskt diagram visas i fig 3. Här beskrivs begränsningarna i vätskeflöde genom destillatorblocket (Distiller). Noderna till höger representerar flödena i fig 2 och de fem begränsningarna visar hur parametrarna hos de olika generella och specifika ekvationerna kopplas till egenskaper hos flödena för att driva igenom flödesbegränsningarna. En del av ekvationerna visas som bifogade noter, men man kan också visa en ytterligare avdelning i begränsningens symbol. Observera att flödets egenskaper har typer med definierade enheter.
Kontinuerliga system
SysML har dessutom utvidgningar för att beskriva distribuerade flöden av material, energi eller information genom ett system. Dessa utvidgningar tillåter modelleraren att lägga in restriktioner om hur snabbt poster kan röra sig rund kanterna av en aktivitet eller in och ut ur beteendenas parametrar. Diskreta eller kontinuerliga flöden förenas under flödeshastighet, på samma sätt som man normalt sett gör i matematiska modeller av kontinuerliga förändringar.
Alan Moore, VP Product Strategy, Artisan Software Tools
11%
13%
42%
12%
22%
