webgme-bip: a design studio for modeling systems with...
TRANSCRIPT
Anastasia Mavridou, Joseph Sifakis, and Janos Sztipanovits
WebGME-BIP: A Design Studio for
Modeling Systems with BIP
A. Mavridou for HCSS, May 2017
Why BIP?• A language and tool-set for component-based system design
‣ formal semantics ‣ high expressiveness with small number of notions ‣ code generation, simulation and verification tools
• BIP allows to compositionally ‣ analyze existing applications ‣ develop correct-by-construction applications
• Developed and maintained ‣ by Verimag and RiSD, EPFL ‣ directed by Joseph Sifakis
A. Basu, S. Bensalem, M. Bozga, J. Combaz, M. Jaber, T.-H. Nguyen, and J. Sifakis, “Rigorous component-based system design using the BIP framework,” Software, IEEE,
vol. 28, no. 3, pp. 41–48, 2011. 2
A. Mavridou for HCSS, May 2017
BIP applications• Development of current-by-construction satellite software
‣ 49 safety properties enforced by construction ‣ Compositional verification of deadlock-freedom with D-Finder
- State space size: - Verification time: minutes
• Development of the Dala robot controller ‣ > 500,000 lines of code ‣ Example results of deadlock-freedom analysis with D-Finder:
3A. Mavridou for HCSS, May 2017
BIP applications• Development of current-by-construction satellite software
‣ 50 safety properties enforced by construction ‣ Compositional verification of deadlock-freedom with D-Finder
• Development of the Dala robot controller ‣ > 500,000 lines of code ‣ Example results of deadlock-freedom analysis with D-Finder:
3
MAY/JUNE 2011 | IEEE SOFTWARE 47
force the safety constraints on module interactions. The BIP model inherently enforced these constraints by connec-tors and priorities.
As an example, consider a require-ment for the robot to navigate using the NDD module’s GoTo service only if services Init, SetParams, and SetSpeed have already executed successfully. BIP enforces this requirement by adding a connector be-tween the GoTo service’s request port and the other ports’ getStatus ports. The status values guard and may prevent the trig-gering of the GoTo service.
Finally, we ran experiments on the code generated automatically from the Dala rover’s BIP model, using fault in-jections to demonstrate that the BIP engine successfully stops the robot from reaching undesired or unsafe states.
B IP’s rigorous semantics and expressive power are unique among component frame-
works and associated system design flows. In contrast to other formalisms, BIP’s mathematical foundation on a minimal concept set and structuring principles doesn’t hamper its effec-tive use for modeling complex real-life systems. In contrast to less expressive frameworks, it models various syn-chronization types in a natural and di-
rect manner. BIP directly encompasses multiparty interaction between compo-nents, avoiding the complexities nec-essary in frameworks supporting only point-to-point interactions. In contrast to object-oriented software, BIP mod-els are easy to understand and analyze as compositions of integrated features. Furthermore, their explicit use of au-tomata in behavior ensures module ro-bustness by enforcing the right execu-tion order of functions independently of their use context.
Progressively refining the applica-tion software model by applying cor-rectness-preserving source-to-source transformations takes hardware archi-tecture constraints into account as well as coordination mechanisms between processors in a distributed implemen-tation. Essential properties are verified as early as possible in the design flow in an incremental, compositional veri-fication process that avoids complex-ity limitations. When the validity of a property is established for a model, the property holds for all the models ob-tained by transformation. Transforma-tion complexity is linear with the size of the transformed models.
As a unifying modeling framework, BIP can maintain a design flow’s over-all coherency by comparing different architectural solutions and their prop-
erties. This differs significantly from approaches that decouple code genera-tion and deployment from validation and use many different, semantically unrelated formalisms for program-ming, hardware description, and simulation.
AcknowledgmentsThe research leading to these results received funding from the European Community’s Seventh Framework Programme under grant agreement 248776 and from the Artemis Joint Undertaking grant agreement 2009-1-100230.
References 1. N. Halbwachs,
, Kluwer Academic Publish-ers, 1993.
2. A. Burns and A. Welling, , 3rd ed.,
Addison-Wesley, 2001. 3. S. Bliudze and J. Sifakis, “A Notion of Glue
Expressiveness for Component-Based Sys-tems,” Theory (CONCUR 08), LNCS 5201, Springer, pp. 508–522.
4. S. Bliudze and J. Sifakis, “Causal Semantics for the Algebra of Connectors,” -
, vol. 36, no. 2, 2010, pp. 167–194.
5. S. Bensalem et al., “Compositional Verifica-tion for Component-Based Systems and Ap-plication,”
(ATVA 08), LNCS 5311, Springer, 2008, pp. 64–79.
6. S. Bensalem et al., “Incremental Component-
TAB
LE
1 Deadlock-freedom-checking results for Dala robot controller modules.
ModuleAtomic
componentsControl
locations Connectors BIP LoC C/C++ LoCEstimated state
space sizeVerification
time (minutes)
LaserRF 43 213 202 5,343 51,653 220 × 329 × 34 1:22
Aspect 29 160 117 3,029 30,204 217 × 323 0:39
NDD 27 152 117 4,013 32,600 222 × 314 × 5 8:16
Rflex 56 308 227 8,244 57,442 234 × 335 × 1045 9:39
Antenna 20 97 73 1,645 16,501 212 × 39 × 13 0:14
Battery 30 176 138 3,898 21,527 222 × 317 × 5 0:26
Heating 26 149 116 2,453 18,380 217 × 314 × 145 0:17
Platine 37 174 151 8,669 51,511 219 × 322 × 35 0:59
MAY/JUNE 2011 | IEEE SOFTWARE 47
force the safety constraints on module interactions. The BIP model inherently enforced these constraints by connec-tors and priorities.
As an example, consider a require-ment for the robot to navigate using the NDD module’s GoTo service only if services Init, SetParams, and SetSpeed have already executed successfully. BIP enforces this requirement by adding a connector be-tween the GoTo service’s request port and the other ports’ getStatus ports. The status values guard and may prevent the trig-gering of the GoTo service.
Finally, we ran experiments on the code generated automatically from the Dala rover’s BIP model, using fault in-jections to demonstrate that the BIP engine successfully stops the robot from reaching undesired or unsafe states.
B IP’s rigorous semantics and expressive power are unique among component frame-
works and associated system design flows. In contrast to other formalisms, BIP’s mathematical foundation on a minimal concept set and structuring principles doesn’t hamper its effec-tive use for modeling complex real-life systems. In contrast to less expressive frameworks, it models various syn-chronization types in a natural and di-
rect manner. BIP directly encompasses multiparty interaction between compo-nents, avoiding the complexities nec-essary in frameworks supporting only point-to-point interactions. In contrast to object-oriented software, BIP mod-els are easy to understand and analyze as compositions of integrated features. Furthermore, their explicit use of au-tomata in behavior ensures module ro-bustness by enforcing the right execu-tion order of functions independently of their use context.
Progressively refining the applica-tion software model by applying cor-rectness-preserving source-to-source transformations takes hardware archi-tecture constraints into account as well as coordination mechanisms between processors in a distributed implemen-tation. Essential properties are verified as early as possible in the design flow in an incremental, compositional veri-fication process that avoids complex-ity limitations. When the validity of a property is established for a model, the property holds for all the models ob-tained by transformation. Transforma-tion complexity is linear with the size of the transformed models.
As a unifying modeling framework, BIP can maintain a design flow’s over-all coherency by comparing different architectural solutions and their prop-
erties. This differs significantly from approaches that decouple code genera-tion and deployment from validation and use many different, semantically unrelated formalisms for program-ming, hardware description, and simulation.
AcknowledgmentsThe research leading to these results received funding from the European Community’s Seventh Framework Programme under grant agreement 248776 and from the Artemis Joint Undertaking grant agreement 2009-1-100230.
References 1. N. Halbwachs,
, Kluwer Academic Publish-ers, 1993.
2. A. Burns and A. Welling, , 3rd ed.,
Addison-Wesley, 2001. 3. S. Bliudze and J. Sifakis, “A Notion of Glue
Expressiveness for Component-Based Sys-tems,” Theory (CONCUR 08), LNCS 5201, Springer, pp. 508–522.
4. S. Bliudze and J. Sifakis, “Causal Semantics for the Algebra of Connectors,” -
, vol. 36, no. 2, 2010, pp. 167–194.
5. S. Bensalem et al., “Compositional Verifica-tion for Component-Based Systems and Ap-plication,”
(ATVA 08), LNCS 5311, Springer, 2008, pp. 64–79.
6. S. Bensalem et al., “Incremental Component-
TAB
LE
1 Deadlock-freedom-checking results for Dala robot controller modules.
ModuleAtomic
componentsControl
locations Connectors BIP LoC C/C++ LoCEstimated state
space sizeVerification
time (minutes)
LaserRF 43 213 202 5,343 51,653 220 × 329 × 34 1:22
Aspect 29 160 117 3,029 30,204 217 × 323 0:39
NDD 27 152 117 4,013 32,600 222 × 314 × 5 8:16
Rflex 56 308 227 8,244 57,442 234 × 335 × 1045 9:39
Antenna 20 97 73 1,645 16,501 212 × 39 × 13 0:14
Battery 30 176 138 3,898 21,527 222 × 317 × 5 0:26
Heating 26 149 116 2,453 18,380 217 × 314 × 145 0:17
Platine 37 174 151 8,669 51,511 219 × 322 × 35 0:59
A. Mavridou for HCSS, May 2017
BIP applications• Development of current-by-construction satellite software
‣ 50 safety properties enforced by construction ‣ Compositional verification of deadlock-freedom with D-Finder
• Development of the Dala robot controller ‣ > 500,000 lines of code ‣ Example results of deadlock-freedom analysis with D-Finder:
3
MAY/JUNE 2011 | IEEE SOFTWARE 47
force the safety constraints on module interactions. The BIP model inherently enforced these constraints by connec-tors and priorities.
As an example, consider a require-ment for the robot to navigate using the NDD module’s GoTo service only if services Init, SetParams, and SetSpeed have already executed successfully. BIP enforces this requirement by adding a connector be-tween the GoTo service’s request port and the other ports’ getStatus ports. The status values guard and may prevent the trig-gering of the GoTo service.
Finally, we ran experiments on the code generated automatically from the Dala rover’s BIP model, using fault in-jections to demonstrate that the BIP engine successfully stops the robot from reaching undesired or unsafe states.
B IP’s rigorous semantics and expressive power are unique among component frame-
works and associated system design flows. In contrast to other formalisms, BIP’s mathematical foundation on a minimal concept set and structuring principles doesn’t hamper its effec-tive use for modeling complex real-life systems. In contrast to less expressive frameworks, it models various syn-chronization types in a natural and di-
rect manner. BIP directly encompasses multiparty interaction between compo-nents, avoiding the complexities nec-essary in frameworks supporting only point-to-point interactions. In contrast to object-oriented software, BIP mod-els are easy to understand and analyze as compositions of integrated features. Furthermore, their explicit use of au-tomata in behavior ensures module ro-bustness by enforcing the right execu-tion order of functions independently of their use context.
Progressively refining the applica-tion software model by applying cor-rectness-preserving source-to-source transformations takes hardware archi-tecture constraints into account as well as coordination mechanisms between processors in a distributed implemen-tation. Essential properties are verified as early as possible in the design flow in an incremental, compositional veri-fication process that avoids complex-ity limitations. When the validity of a property is established for a model, the property holds for all the models ob-tained by transformation. Transforma-tion complexity is linear with the size of the transformed models.
As a unifying modeling framework, BIP can maintain a design flow’s over-all coherency by comparing different architectural solutions and their prop-
erties. This differs significantly from approaches that decouple code genera-tion and deployment from validation and use many different, semantically unrelated formalisms for program-ming, hardware description, and simulation.
AcknowledgmentsThe research leading to these results received funding from the European Community’s Seventh Framework Programme under grant agreement 248776 and from the Artemis Joint Undertaking grant agreement 2009-1-100230.
References 1. N. Halbwachs,
, Kluwer Academic Publish-ers, 1993.
2. A. Burns and A. Welling, , 3rd ed.,
Addison-Wesley, 2001. 3. S. Bliudze and J. Sifakis, “A Notion of Glue
Expressiveness for Component-Based Sys-tems,” Theory (CONCUR 08), LNCS 5201, Springer, pp. 508–522.
4. S. Bliudze and J. Sifakis, “Causal Semantics for the Algebra of Connectors,” -
, vol. 36, no. 2, 2010, pp. 167–194.
5. S. Bensalem et al., “Compositional Verifica-tion for Component-Based Systems and Ap-plication,”
(ATVA 08), LNCS 5311, Springer, 2008, pp. 64–79.
6. S. Bensalem et al., “Incremental Component-
TAB
LE
1 Deadlock-freedom-checking results for Dala robot controller modules.
ModuleAtomic
componentsControl
locations Connectors BIP LoC C/C++ LoCEstimated state
space sizeVerification
time (minutes)
LaserRF 43 213 202 5,343 51,653 220 × 329 × 34 1:22
Aspect 29 160 117 3,029 30,204 217 × 323 0:39
NDD 27 152 117 4,013 32,600 222 × 314 × 5 8:16
Rflex 56 308 227 8,244 57,442 234 × 335 × 1045 9:39
Antenna 20 97 73 1,645 16,501 212 × 39 × 13 0:14
Battery 30 176 138 3,898 21,527 222 × 317 × 5 0:26
Heating 26 149 116 2,453 18,380 217 × 314 × 145 0:17
Platine 37 174 151 8,669 51,511 219 × 322 × 35 0:59
MAY/JUNE 2011 | IEEE SOFTWARE 47
force the safety constraints on module interactions. The BIP model inherently enforced these constraints by connec-tors and priorities.
As an example, consider a require-ment for the robot to navigate using the NDD module’s GoTo service only if services Init, SetParams, and SetSpeed have already executed successfully. BIP enforces this requirement by adding a connector be-tween the GoTo service’s request port and the other ports’ getStatus ports. The status values guard and may prevent the trig-gering of the GoTo service.
Finally, we ran experiments on the code generated automatically from the Dala rover’s BIP model, using fault in-jections to demonstrate that the BIP engine successfully stops the robot from reaching undesired or unsafe states.
B IP’s rigorous semantics and expressive power are unique among component frame-
works and associated system design flows. In contrast to other formalisms, BIP’s mathematical foundation on a minimal concept set and structuring principles doesn’t hamper its effec-tive use for modeling complex real-life systems. In contrast to less expressive frameworks, it models various syn-chronization types in a natural and di-
rect manner. BIP directly encompasses multiparty interaction between compo-nents, avoiding the complexities nec-essary in frameworks supporting only point-to-point interactions. In contrast to object-oriented software, BIP mod-els are easy to understand and analyze as compositions of integrated features. Furthermore, their explicit use of au-tomata in behavior ensures module ro-bustness by enforcing the right execu-tion order of functions independently of their use context.
Progressively refining the applica-tion software model by applying cor-rectness-preserving source-to-source transformations takes hardware archi-tecture constraints into account as well as coordination mechanisms between processors in a distributed implemen-tation. Essential properties are verified as early as possible in the design flow in an incremental, compositional veri-fication process that avoids complex-ity limitations. When the validity of a property is established for a model, the property holds for all the models ob-tained by transformation. Transforma-tion complexity is linear with the size of the transformed models.
As a unifying modeling framework, BIP can maintain a design flow’s over-all coherency by comparing different architectural solutions and their prop-
erties. This differs significantly from approaches that decouple code genera-tion and deployment from validation and use many different, semantically unrelated formalisms for program-ming, hardware description, and simulation.
AcknowledgmentsThe research leading to these results received funding from the European Community’s Seventh Framework Programme under grant agreement 248776 and from the Artemis Joint Undertaking grant agreement 2009-1-100230.
References 1. N. Halbwachs,
, Kluwer Academic Publish-ers, 1993.
2. A. Burns and A. Welling, , 3rd ed.,
Addison-Wesley, 2001. 3. S. Bliudze and J. Sifakis, “A Notion of Glue
Expressiveness for Component-Based Sys-tems,” Theory (CONCUR 08), LNCS 5201, Springer, pp. 508–522.
4. S. Bliudze and J. Sifakis, “Causal Semantics for the Algebra of Connectors,” -
, vol. 36, no. 2, 2010, pp. 167–194.
5. S. Bensalem et al., “Compositional Verifica-tion for Component-Based Systems and Ap-plication,”
(ATVA 08), LNCS 5311, Springer, 2008, pp. 64–79.
6. S. Bensalem et al., “Incremental Component-
TAB
LE
1 Deadlock-freedom-checking results for Dala robot controller modules.
ModuleAtomic
componentsControl
locations Connectors BIP LoC C/C++ LoCEstimated state
space sizeVerification
time (minutes)
LaserRF 43 213 202 5,343 51,653 220 × 329 × 34 1:22
Aspect 29 160 117 3,029 30,204 217 × 323 0:39
NDD 27 152 117 4,013 32,600 222 × 314 × 5 8:16
Rflex 56 308 227 8,244 57,442 234 × 335 × 1045 9:39
Antenna 20 97 73 1,645 16,501 212 × 39 × 13 0:14
Battery 30 176 138 3,898 21,527 222 × 317 × 5 0:26
Heating 26 149 116 2,453 18,380 217 × 314 × 145 0:17
Platine 37 174 151 8,669 51,511 219 × 322 × 35 0:59
> 310 ⇥ 4
< 2
A. Mavridou for HCSS, May 2017
BIP by exampleMutual exclusion example
work
sleep
work
sleep
{b1 � f2, b2 � f1}
{b1, f1, b2, f2}b2
f2
B2
f2
b2
b1
f1
B1
f1
b1
work sleep
sleep work
sleep sleep
work work
f1b2
b1f2
f2
b1
f1
b2
f2
b2 b1
f1
b1b2
f1f2
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2
b2 b1
f1
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2 f1
E. Baranov Architectures in BIP Fortiss 2016 11 / 54
4
No restrictions Restrictions from the interaction model
Restrictions from the priority model
A. Mavridou for HCSS, May 2017
BIP by exampleMutual exclusion example
work
sleep
work
sleep
{b1 � f2, b2 � f1}
{b1, f1, b2, f2}b2
f2
B2
f2
b2
b1
f1
B1
f1
b1
work sleep
sleep work
sleep sleep
work work
f1b2
b1f2
f2
b1
f1
b2
f2
b2 b1
f1
b1b2
f1f2
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2
b2 b1
f1
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2 f1
E. Baranov Architectures in BIP Fortiss 2016 11 / 54
5
No restrictions Restrictions from the interaction model
Restrictions from the priority model
A. Mavridou for HCSS, May 2017
BIP by exampleMutual exclusion example
work
sleep
work
sleep
{b1 � f2, b2 � f1}
{b1, f1, b2, f2}b2
f2
B2
f2
b2
b1
f1
B1
f1
b1
work sleep
sleep work
sleep sleep
work work
f1b2
b1f2
f2
b1
f1
b2
f2
b2 b1
f1
b1b2
f1f2
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2
b2 b1
f1
work sleep
sleep work
sleep sleep
work work
f2
b1
f1
b2
f2 f1
E. Baranov Architectures in BIP Fortiss 2016 11 / 54
6
No restrictions Restrictions from the interaction model
Restrictions from the priority model
A. Mavridou for HCSS, May 2017
BIP Connectors
• Connectors are tree-like structures ‣ ports as leaves and nodes of two types
- Triggers (diamonds) — nodes that can “initiate” an interaction - Synchrons (bullets) — nodes that can only “join” an interaction
initiated by others
7
tick1 tick2 tick3
p + pq + pr + pqr
tick1
p q r
tick2 tick3
A. Mavridou for HCSS, May 2017
Connector examples
8
Strong synchronization: pqr
Broadcast: p + pq + pr + pqr
Atomic broadcast: p + pqr
Causal chain: p + pq + pqr + pqrs
p q r
p q r
pq r
pq
r s
connector type Broadcast(HelloPort_t p, HelloPort_t q, HelloPort_t r) define p' q r on p q r on p q on p r
on p
(q =) p)^
(r =) q)^
(p =) true)
p Requires �p Accepts q, r
q Requires p
q Accepts p, r
r Requires p
r Accepts p, q
Enumerative BIP specification Symbolic BIP specification
A. Mavridou for HCSS, May 2017
Architecture diagrams
T1n1
T2mp:dp qpn2
mq:dq
9
• An architecture diagram consists of: - component types
• port types - cardinality - connector motifs
• degree • multiplicity
A. Mavridou, E. Baranov, S. Bliudze, and J. Sifakis, “Architecture diagrams: A graphical language for architecture style specification,” 9th Interaction and Concurrency Experience, 2016.
A. Mavridou, E. Stachtiari, S. Bliudze, A. Ivanov, P. Katsaros, and J. Sifakis. "Architecture-Based Design: A Satellite On-Board Software Case Study." 13th Formal Aspects of Component Software, 2016.
A. Mavridou for HCSS, May 2017
Architecture diagrams
T1n1
T2mp:dp qpn2
mq:dq
10
• An architecture diagram consists of: - component types
• port types - cardinality - connector motifs
• degree • multiplicity
A. Mavridou for HCSS, May 2017
Architecture diagrams
T1n1
T2mp:dp qpn2
mq:dq
11
• An architecture diagram consists of: - component types
• port types - cardinality - connector motifs
• degree • multiplicity
A. Mavridou for HCSS, May 2017
Architecture diagrams
T1n1
T2mp:dp qpn2
mq:dq
12
• An architecture diagram consists of: - component types
• port types - cardinality - connector motifs
• degree • multiplicity
A. Mavridou for HCSS, May 2017
Architecture diagrams
T1n1
T2mp:dp qpn2
mq:dq
13
• An architecture diagram consists of: - component types
• port types - cardinality - connector motifs
• degree • multiplicity
A. Mavridou for HCSS, May 2017
Degree constraint
Degree constraints the number of connectors attached to any instance of the port type
q1
q2
q3
T3
m:1q
q1
q2
q3
T3
m:2q
14
A. Mavridou for HCSS, May 2017
Multiplicity constraintMultiplicity constraints the number of instances of the port type that must participate in a connector
q1
q2
q3
T3
1:1q
q1
q2
q3
T3
3:1q
15
A. Mavridou for HCSS, May 2017
Engine-based execution
16
Priorities
Interactions
B E H A V I O U R1. Components notify the Engine about enabled transitions.
2. The Engine picks an interaction and instructs the components.
A. Mavridou for HCSS, May 2017
BIP summary• Compositional approach
‣ allows modeling complex, hierarchical components - atomic components - interaction and priority composition operators
• Execution is orchestrated by the BIP engine • Expressiveness • Small number of notions • Separation of concerns between behavior and interaction • Architecture diagrams in BIP
‣ reusability ‣ allow to deal with model complexity and size
17
A. Mavridou for HCSS, May 2017
Why WebGME?• WebGME allows: ‣ Web-based ‣ Collaborative ‣ Versioned model editing ‣ Formalized metamodeling process ‣ with FORMULA
webgme.org
M. Maroti, T. Kecskes, R. Kereskenyi, B. Broll, P. Volgyesi, L. Juracz, T. Levendovszky, and A. Ledeczi, “Next generation (meta) modeling: Web-and cloud-based collaborative tool
infrastructure.” in MPM@ MoDELS, 2014, pp. 41–60. 18
formula.codeplex.com
A. Mavridou for HCSS, May 2017
The design studio
BIP in WebGME
19
Semantic integration
Tool integration
Specification of the modeling language
Model transformations
Active Specification Analysis tools
Run-time execution
Tool integration
Simulation and analysis
Semantic integration
Specification of themodeling language
Model transformation
Design guidance
Accessibility
Design studioWebGME-BIP
JavaBIP metamodel in UML class diagrams
WebGME plugin for encoding checking
WebGME code generator plugins: 1. FSM to Java 2. Architecture to XML
JavaBIP engine Web interface
Service Integration
Model repositories1. Architecture styles 2. Component types
Simulated executionSimulation of JavaBIP engine output
Semantic integration
Tool integration
Specification of the modeling language
Model transformations
Active Specification Analysis tools
Run-time execution
Tool integration
Simulation and analysis
Semantic integration
Specification of themodeling language
Model transformation
Design guidance
Accessibility
Design studioWebGME-BIP
JavaBIP metamodel in UML class diagrams
WebGME plugin for encoding checking
WebGME code generator plugins: 1. FSM to Java 2. Architecture to XML
JavaBIP engine Web interface
Service Integration
Model repositories1. Architecture styles 2. Component types
Simulated executionSimulation of JavaBIP engine output
Semantic integration
Tool integration
Specification of the modeling language
Model transformations
Active Specification Analysis tools
Run-time execution
Tool integration
Simulation and analysis
Semantic integration
Specification of themodeling language
Model transformation
Design guidance
Accessibility
Design studioWebGME-BIP
JavaBIP metamodel in UML class diagrams
WebGME plugin for encoding checking
WebGME code generator plugins: 1. FSM to Java 2. Architecture to XML
JavaBIP engine Web interface
Service Integration
Model repositories1. Architecture styles 2. Component types
Simulated executionSimulation of JavaBIP engine output
A. Mavridou for HCSS, May 2017
Hands-on WebGME-BIP
20
• Camel Routes case study • Many independent routes share memory
‣ We have to control the memory usage ‣ e.g., by limiting to only a safe number of routes simultaneously
A. Mavridou for HCSS, May 2017
Conclusion• The WebGME-BIP design studio
‣ can be easily accessed through a web interface ‣ is open-source
- https://github.com/anmavrid/webgme-bip, https://webgme.org/ ‣ allows reusability of component types and parameterized models ‣ allows coping with modeling complexity and size
- component types, connector motifs ‣ has formal semantics
- allows connection with checkers and analysis tools ‣ includes
- dedicated editors for code, interaction, and behavior editing - code generator plugins - consistency checking plugin - integration with the JavaBIP engine and visualization of its output
21
Thank you for your attention