How to define interface patterns in model-based system engineering

Transcription

1 How to defie iterface patters i model-based system egieerig Idraja Elžbieta Germaaitė Departmet of Iformatio Systems Kauas Uiversity of Techology Kauas, Lithuaia idraja.germaaite@ktu.lt Prof. dr. Rimatas Butleris Cetre of Iformatio Systems Desig Techology Kauas Uiversity of Techology Kauas, Lithuaia rimatas.butleris@ktu.lt Abstract The Patters help system egieers to create efficiet ad more cosistet System Models faster. Thus the methodology of quickly defiig ad describig the Patters are eeded. The review of the existig methodology of defiig Iterface Patters is doe i this article. As a result, the eed for the ew or more detailed ideas cocerig the methodologies ad implemetatios of the Patters use could be idetified. Keywords Model-based System Egieerig; MBSE Patter; MBSE Framework; FAF; ; SysML I. INTRODUCTION The disciplie ad practice of Model-based System Egieerig (MBSE) follows the mai cocepts of the Systems Egieerig disciplie. The Systems Egieerig covers a wide rage of fudametal cocepts such as system thikig, system sciece, life cycle maagemet, system of systems, ad agile ad iterative methods [1]. System thikig captures ad exploits what is commo i a set of problems ad correspodig solutios i the forms of various types. Thus, a patter is a represetatio of similarities i a set of problems, solutios, or systems [1]. As already kow from the object-orieted programmig practice, the desig patters facilitate the reusig of successful desigs ad architectures, expressig prove techiques as patters ad makig them more accessible to developers of ew systems [2]. Patters help to choose desig alteratives that make a system reusable, to avoid alteratives that compromise reusability, ad to improve the documetatio ad maiteace of the existig systems [2]. The patters help the desiger (or the system egieer) get the desig (or the architecture) right faster. The term patter appears repeatedly i the history of desig, such as civil architecture, software desig, ad systems egieerig [3]. I the MBSE cotext, a patter could mea the whole framework that covers etire systems ad is used as a reusable, cofigurable model of whole domais or platform systems - whether formal platform maagemet is already recogized or ot - or oly as smaller-scale elemet desig patters withi them [3]. The aim of this article is to look ito the methodology of defiig ad describig subsystem or compoet patters. I this case, the review of Patter-Based Systems Egieerig methodology based o S*Models ad S*Patters ad dedicated to the complex systems is ot i the scope of this article. II. WHAT IS THE PATTERN IN MBSE? Joh Holt et al. give the full picture of what is the MBSE Patter ad describe the mai terms that are used for defiig ad describig the Patters i their book [4]. The Model abstracts the System ad is made of oe or more s that are the fudametal buildig blocks of the Model. The uses a Systems Modelig Laguage (SysML) diagram as a represetatio, ad is made of the Elemets that i tur use SysML elemets as a represetatio. The is the realizatio of a ad the ed product of the Patter. The MBSE Framework provides the basis for the structure of the Model ad defies a umber of s. The is a template for the Patter that forms the basis for the. I tur, the elemet is a template for the Elemet. The Otology is made up of oe or more Otology Elemets that defie the cotet of the. The mai etities that participate i Patter defiitio ad relatioships betwee those etities are show i Figure 1. Fig. 1. The relatioship betwee the System, the Model, The Framework, the Otology, ad the Patter (take ad modified from [4]). Joh Holt et al. [4] explai that a Patter is a special type of the Framework ad is made up of oe or more s, each of which comprises oe or more Elemets. The ad elemets are based o the Otology, providig cosistecy with the rest of the Model. The mai differece betwee a Framework ad a Patter is that a Framework has a sigle purpose ad sigle applicatio, while a patter has a sigle purpose but multiple applicatios. For example, the Iterface Patter may be used as part of several Frameworks, at differet level of abstractios, ad i differet Copyright 2017 held by the authors 54

2 aspects of the Model [4]. Thus, the Patter uses a template itself the - ad also serves as a template for the. I additio, the Patter could be uderstood as a Framework, but the Framework may also use may differet Patters for differet purposes. So, the itet is to create a iitial 'otology' of high-level Patter descriptios that provide a framework withi which Patter relatioships ca be discussed [5]. III. DEFINING PATTERNS Goig deeper ito the defiitio of a Patter, Joh Holt et al. [4] declare that the approach used to defie each Patter is the same as the approach used to defie the Framework, ad uses Framework for Architecture Frameworks (FAF). The FAF was defied to address the key questios through the MBSE approach based aroud the ideas of Otology, s, ad Framework, ad cosists of the Otology, six s, ad supportig processes [4]. The six s directly address oe of the six key questios that should be cosidered i order to approach the Patter defiitio i a cosistet ad repeatable way [4]. These key questios with the attached FAF s ad s are show i Table I. It should also be oted that the s may be visualized usig ay otatio, text, tables, or formal techiques, ad i ay way that is appropriate [4]. The SysML is selected as the MBSE Patterdefiig laguage that is importat ad useful for its graphical otatio. TABLE I. FAF KEY QUESTIONS (TAKEN AND MODIFIED FROM [4]) Key questio purpose of the Patter? What cocepts must the Patter support? What differet ways of cosiderig the idetified cocepts are required to fully uderstad those cocepts? purpose of each? defiitio of each i terms of the idetified cocepts? What rules costrai the use of the Patter? FAF used to aswer Architectur al Framework Otology Relatioshi ps Rules Architectural Framework Otology Relatioship s Rules Is derived from Architectura l Framework Otology Architectura l Framework SysML diagram used Use Case Defiitio Defiitio Use Case Defiitio Defiitio IV. THE INTERFACE DEFINITION PATTERN EXAMPLE Joh Holt et al. give may examples of MBSE Patters defied accordig to the FAF method i their book [4]. Oe of the most commo examples is the Iterface Patter chose to illustrate MBSE Patter defiitio i this article because it ca be used i both software ad hardware systems. More tha that, iterfaces form a itegral part of ay systems model ad defie a cotract betwee system elemets, whether those elemets are physical or are realized i software [4]. Thus, the key aim of the Iterfaces Patter is the idetificatio of iterfaces ad their relatio to the system elemets that use them ad the ports that expose them [4]. Accordig to the FAF method for describig the Iterface Patter, the mai aims of the Iterface Patter should be defied first. These aims are show i the Architectural Framework i the form of SysML Use Case i Figure 2. Fig. 2. Architectural Framework (take from [4]). Secod, the mai cocepts covered by the Iterface Patter should be defied i the Otology i the form of the SysML. Joh Holt et al. defie the mai Iterface Patter cocepts i their book [4]: a Iterface has a Directio, which may take the values i, out, ad iout. The Directio property shows the directio i which the Iterface operates from the poit of view of the Port, owed by a System Elemet, which exposes the Iterface [4]. Each Iterface is described by a Iterface that defies the operatios of a Service-Based Iterface ad the items trasferred by a Flow-Based Iterface [4]. A Port represets the iteractio poits betwee oe or more System Elemets ad may represet the cocept of a software Port or a physical Port, such as the coector for the fuel lie o a car egie fuel pump [4]. Ports are coected to each other via a Port Coectio. Ports ad Iterfaces may coform to oe or more Protocols that describe ad cotrol how the Port ad the Iterface behave [4]. Third, the s that make up the Iterface Patter should be described. This should be doe i the Relatioships i a form of the SysML. Types of Patter relatioships are itroduced as a mechaism to categorize ad stadardize basic relatioship types ad rage from iformal to formal [5]. The Iterface Patter provides three s that eable the idetificatio ad defiitio of Iterfaces to be specified i terms of the structural aspects of the Iterfaces: the 55

3 Iterface Idetificatio idetifies each Iterface, the Iterface Coectivity shows the coectio betwee Iterfaces, ad the Iterface defies what is trasferred across each Iterface [4]. The Patter also provides two s that eable the behavior of Iterfaces to be specified: the Iterface Behavior idetifies typical scearios showig how Iterfaces are used, ad the Protocol defies ay Protocols to which Iterfaces or Ports must coform [4]. These s will be described i more detail later i this article. Fourth, the Rules that apply to the Iterface Patter should be defied i the Rules i a form of the SysML. The example of such rule could be the statemet: Ay protocol-based Iterface or Port must have a correspodig Protocol defied [4]. V. THE VIEWPOINTS OF THE INTERFACE DEFINITION PATTERN Joh Holt et al. i their book provide a detailed descriptio of the s that make up the Iterface Patter [4]. The Iterface Patter cosists of five s that represet the structural or behavioral aspects of the Iterfaces. Each of these s cosists of the that defies the purpose of the each ad a that covers the defiitio of each. Oly the diagrams are preseted later i this article, ad s will be discussed i the text as they describe oly the aims of each. The first Iterface Idetificatio idetifies the System Elemets, the Ports that they ow, ad the Ports that expose the Iterfaces ad the Iterfaces that they expose [4]. By usig the Iterface Idetificatio, it is possible to defie both Service-Based ad Flow-Based Iterfaces. The examples of the Service-Based ad Flow-Based Iterface Idetificatio s are show i Figure 3 ad Figure 4, respectively. Fig. 4. Flow-Based Iterface Idetificatio (take from [4]) The secod Iterface Coectivity idetifies coectios betwee Ports ad the Iterface Coectios that take place across the Port Coectios. Agai, two examples of Service-Based ad Flow-Based Iterface Coectivity s are show i Figure 5 ad Figure 6, respectively. Fig. 5. Service-Based Iterface Coectivity (take from [4]) Fig. 6. Flow-Based Iterface Coectivity (take from [4]) The third Iterface defies the operatios or flows of data, material, eergy, persoel, etc. of the Iterfaces. A example show i Figure 7 demostrates the Service-Based Iterface (PumpIF), ad the Flow- Based Iterface (LiquidFS) i oe. Fig. 3. Service-Based Iterface Idetificatio (take from [4]) 56

4 Iterface s would be produced alog with the Iterface Behavior ad Protocol s [4]. The discussed s show that the cotext ad the scope of the that is used for the geeratio should be set: every must provide a template for aswerig some small set of core questios about the System for the customer stakeholders, which could ot be otherwise easily aswered [6]. The must idetify ad meet the eeds of the target audiece ad their specific cocers, ad must be well scoped ad make the geerated s easy to draw ifereces from [6]. Fig. 7. Service-Based ad Flow-Based Iterface (take from [4]) The fourth Iterface Behavior idetifies the typical scearios showig how Iterfaces are used [4]. A example of the Iterface Behavior is show i Figure 8. VI. THE USE OF THE MBSE PATTERNS The mai goal of the use of Patters, as stated by Joh Holt et al. [4], is to allow re-use, which brigs a umber of tagible beefits. Amog such beefits, Joh Holt et al. distiguish the shorteed developmet time, sice by workig to a set of predefied s, the structure ad the cotet of each has already bee decided, hece reducig the amout of time required to geerate the idividual s [4]. I additio, the improved cosistecy of the Model is emphasized because whe workig i accordace with the Patter s (ad Otology), the cosistecy betwee the resultat Patter is guarateed [4]. If systems modelers are educated ad traied i the use of Patters, they ca apply this kowledge i a variety of applicatios, thus shorteig the learig curve [4]. Joh Holt et al. [4] also metioed the beefit of icreased efficiecy through the use of the MBSE modelig tool for the implemetatio of Patters, as the s that describe the Patter may be implemeted i a modelig tool through the use of profiles. Whe discussig the realizatio of the MBSE Patters, Joh Holt et at. [4] stated that three aspects eed to be cosidered i order to realize MBSE Patters effectively ad efficietly: People, Process, ad Tools. For example, the MBSE Patters ca be used as part of the Competecy assessmet Process or to shorte the learig curve associated with MBSE [4]. The MBSE Frameworks may be costructed by re-usig ad tailorig the established Patters, ad if each Patter has its associated s defied, the the defiitio of the Framework becomes so much quicker ad easier as the structure ad cotets of each will already be defied [4]. Good MBSE modelig tools may be tailored to support a defied MBSE approach by defiig the profiles, ad thus the use of profiles allows the tool to be tailored to implemet a specific approach to MBSE [4]. Fig. 8. Iterface Behavior (take ad modified from [4]) The fifth Iterface Protocol defies ay protocols to which a iterface or port must coform [4]. The Iterface Protocol is represeted by the SysML State Machie. Whe usig the Iterface Patter, at least oe Iterface ad oe Iterface are eeded to specify Iterfaces, their associated Ports, ad the coectios betwee them [4]. I practice, however, multiple Iterface Idetificatio s, Iterface s, ad VII. CONCLUSIONS The review of the existig methodology for the defiitio ad descriptio of the MBSE Patter based o the book by Joh Holt et al. [4] showed that: 1. A cosistet MBSE Patter ca be defied with the help of the Otology ad the Framework, usig s ad s as their realizatio. 2. I order to defie the Patter i a completed way, the key questios about the cotext, purpose, defiitio, relatioships, 57

5 ad rules of the Patter should be aswered i the form of SysML diagrams. 3. The structural ad behavioral aspects of the Patters are preseted i five s, which serve as a basis for the creatio of s. 4. The use of Patters ot oly helps to shorte system developmet time, but also improves the cosistecy of the model, shortes the learig curve, ad icreases the efficiecy of MBSE modelig tools. 5. The MBSE methodology should be used together with the MBSE Patters that icreases the effectiveess ad efficiecy of modelig. REFERENCES [1] Icose, INCOSE Systems Egieerig Hadbook, WILEY [2] Gamma, E., Helm, R., Johso, R., Vlissides, J., Desig Patters. Addiso-Wesley Publishig Compay, [3] Peterso, T., Schidel, W. D., Hamilto, B. A., Model-based system patters for automated groud vehicle platforms, INCOSE iteratioal symposium, vol. 25, pp , [4] Holt, J., Perry, S., Browsword, M., Foudatios of model-based systems egieerig: From patters to models, Istitutio of Egieerig ad Techology. Iet Professioal Applicatios of Computig, [5] Simpso J., J., Simpso M., Foudatioal Systems Egieerig (SE) Patters for a SE Patter Laguage, INCOSE Iteratioal Symposium, vol. 16, pp , [6] Paredis, C. J. J., Bishop, C., Boder, D., Itroductio to Iformatio Visualizatio (IfoVis) techiques for Model-Based Systems Egieerig, Coferece o Systems Egieerig Research, vol. 16, pp ,