Hi dear devs, Yesterday I submitted a patch to review (http://saros-build.imp.fu-berlin.de/gerrit/#/c/1997/), which contains a single .chralx file. This file contains a description of layers written in a custom Xtext-DSL. A description of the semantics is to be found in the DSL itself.
This .chralx file is used during the Sonarqube analysis to see whether the actual source-code complies with the envisioned architecture described in the file. If it doesn't, then an issue called "Architecture Violation" is raised in Sonarqube, and subsequently in the comments for your current patch were you to break those rules. This is just the first iteration, where we can only define layers and constrain access between them. This is of course but one aspect of architecture, what I would like to achieve is to capture with this DSL the more important aspects of Saros' architecture. An example would be defining components which have to be thread-safe, or some sort of formalization of the triple dispatch we have. What I would like is to hear form the team which aspects be the most important to capture? If there architectural principles behind Saros, which are broken the most often, or which are most painful to see? Thanks in advance, Arsenij ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
