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