While this thesis has demonstrated the potential of efficiently using MDE to implement a DSL for SES to facilitate the modeling of reactive behavior in MAS, many opportunities for extending the scope of this thesis remain. This section presents some of these directions, which include:
• The improvement of the meta-model to support other types of equation and formalisms to describe a given behavior. Although non-programmers might not be familiar with some formalisms such as logistic regression and differential equation, researchers would likely appreciate the possibility to describe MAS behaviors using other types of equations. Moreover, new types of formalisms (such as DEVS, CSP, Z, etc) could also be included in the meta-model, thus increasing the flexibility of code generation to MAS platforms (such as MIMOSa) that are based on such formalisms. Finally, with new elements that cover most of the MAS platforms, the meta-model
7.2. Future works 117 could be refined to support code generation to a third MAS plat-form, such as GAMA.
• The addition of other validation rules can help to ensure the validity of a model and could prevent the generation of erroneous codes. With the spe- cification of more complex behaviors, validation rules may provide some semantic checks even if the compiler does not find any compile-time er- rors. By using the quick fix mechanisms provided by Xtend, the user can easily make a suggestion to fix an error, reducing the possibility of syntax and semantic errors.
• The implementation of a graphic editor to represent some elements of acti- vity diagrams to improve the modeling process. With a graphical editor, behaviors expressed as activity behaviors or activity diagram behaviors would be easily expressed by non-programmers. However, certain as- pects (such as equations) are not as efficiently represented with graphical icons. But this could be easily overcome through the development of edi- tors combining both graphical and textual representation of behaviors. • Model point-of-view capabilities should be incorporate-rated to B-Reactive.
Although we provide a very limited code-generation of point-of-views during Cormas code generation, B-Reactive was not initially conceived to describe MAS point-of-views. Point-of-views are very useful and are an essential aspect of MAS M&S because they allow a user to choose what he wishes to observe during simulation (e.g. the value of an attribute or the population of an agent over time). Ideally, a new layer (abstract syntax) for point-of-view specification should be designed along with a concrete syntax to be incorporated to B-Reactive language.
• The realization of tests of our proposed DSL during participatory mo- deling workshops. Due to time limitations, we were not able to effectively test our language in a real-case scenario. Even though the B-reactive lan- guage is still a prototype, B-Reactive can be improved trough the feedback of domain experts. This feedback can be captured in such events as trai- ning sessions and workshops, where the needs of domain experts during model and simulation stages are more easily identified.
7.3
Conclusion
B-reactive is a prototype of DSL to model reactive behaviors on MAS. Built with MDE tools, the language aims at enhancing the level of participation of SES domain-experts with no programming skills. Additionally, the language was conceived by applying a meta-model approach that aimed to decrease MAS models’ dependence to different platforms. The meta-model served as an inter- operable layer from which model-to-text transformations can be easily applied to generate code for various MAS platforms. Meanwhile, B-Reactive represents the intent to look at a different direction for establishing a modeling environ- ment (starting with a language) that is truly suited to non-programmers, while , providing them at the same time the means to apply their own discourse during MAS modeling and simulation. While it is true that there is no silver bullet to overcome MAS model’s complexity, there is much theoretical work to be done tot address some of the complexities of SES and directly influences the way DSL are developed. One of these particularities is granularity. This requires the introduction of a new representation of formalisms and inference mechanisms such as aggregation and disaggregation. Hence, a large field of research still re- mains open to SES domain formalization. This work endeavours to be the first step toward a further understanding of these important issues.
119
Appendix A
SES axmodels in B-Reactive
language
A.1
Implementation of ECEC model in B-Reactive
language
1 Model Ecec { 2
3 Entity Plant {
4 Attributes { biomass: Float } 5 EquationBehaviour grow {
6 Parameters (k : Float,r : Float)
7 Equation {biomass = biomass + r*biomass * (1-biomass/k)}
8 }
9 } 10
11 Entity Forager {
12 Attributes {energy: Float}
13 ActivityBehavior ConsumeEnergy { 14 Parameters (catabolic_rate:Float) 15 Remove catabolic_rate from energy 16 }
17
18 ActivityDiagramBehavior ToMove {
19 let biomassOfPlant <- Plant.biomass of Plant from here 20 let aLocation <- max-one-of [ Plant.biomass,
select-location-from [ neighborhood ] such that (
neighborhood is NOT occupied by (any Forager here) )
21 Start -> Decide { if (biomassOfPlant >= ConsumeEnergy.
catabolic_rate) then Move to {aLocation} -> End else Move to
{one-of[ union-location(neighborhood,here) ]} -> End } 22 }
23
24 ActivityBehavior Eat {
25 Parameters ( harvest_rate: Float )
26 let aPlantBiomass <- Plant.biomass of one-of (Plant from
here )
27 Add harvest_rate * aPlantBiomass to Plant.biomass 28 Remove harvest_rate * aPlantBiomass from Plant.biomass 29 }
30
31 ActivityDiagramBehavior ToReproduce { 32 Parameters ( Fertility_Threshold: Float )
33 Start -> Decide { if ( energy >= Fertility_Threshold ) then
Reproduce(1) with energy (50) placed on one-of [neighborhood
] -> Remove 50 from energy -> End
34 }
35 } 36
37 ActivityDiagramBehavior ToDie {
38 Start -> Decide { if ( energy < 0 ) then Die -> End } 39 }
40 } 41
42 Run main as : ActivityDiagramBehavior Main {
43 Start -> Plant.grow ->Forager.ConsumeEnergy -> Forager.Eat -> Forager.ToMove -> Forager.ToReproduce -> Forager.ToDie ->
End 44 } 45 //---| 46 // INITIALIZATION | 47 //---| 48 //---Space init--- 49 Create Forager 10 as Restrained{
50 each Forager {
51 position = one-of [ grid of Plant ]
52 Forager.ConsumeEnergy.catabolic_rate := 2 53 Forager.Eat.harvest_rate := 0.5
A.1. Implementation of ECEC model in B-Reactive language 121
55 Forager.ToReproduce.Fertility_Threshold := 100 56 }
57 } 58
59 Create Forager 10 as Unrestrained { 60 each Forager {
61 position = one-of [ grid of Plant ]
62 Forager.ConsumeEnergy.catabolic_rate := 2 63 Forager.Eat.harvest_rate := 0.9 64 Forager.energy := 50 65 Forager.ToReproduce.Fertility_Threshold := 100 66 } 67 } 68 //---Entity init--- 69 Create grid of Plant (20,20) {
70 each Plant {
71 Plant.grow.k := 10 72 Plant.grow.r := 0.2
73 Plant.biomass := random-float (Plant.grow.k) 74 }
75 } 76 }