Domain specic languages for software requirements capture⋆ J. Guadalupe Ramos1 , Josep Silva2 , Heriberto Flores, Margarita Torres, Laura E. Mendoza, Juan C. Solorio DSIC, Universidad Politécnica de Valencia Camino de Vera s/n, E-46022 Valencia, Spain. 2 {jsilva@dsic.upv.es} Instituto Tecnológico de La Piedad Av. Tecnológico 2000, La Piedad, Mich., México. CP 59300 1 {guadalupe@dsic.upv.es} The task of requirements capture is a crucial step in the development software process. The accuracy of requirements identication is useful in order to ensure the success of a software development project. Regularly, requirements are materialized in particular documents expressed either as documents in natural language or technical diagramas like class diagrams or use cases. All of them are non executable documents. In this paper we propose the use of domain specic languages (DSL's) as a medium for requirements identication. Domain specic languages design implicitly involves the denition of concepts and their relations of the domain. For this, we introduce examples from dierent programming paradigms that model specic domain concepts. Finally, we suggest particular DSL's like an integration mechanism between Software Factories and Model Driven Architecture for the requirements model. Abstract. 1 Introduction Software requirements are those attributes that a software product should accomplish once a development phase has concluded. The satisfactory accomplishment of requirements allows that the aim which inspired the software development can be reached. Indeed, once a software system is developed, the rst judgement of success is the measure in which the system satises the purpose for what was built[1]. In this setting, the denition of software requirements that allow the unambiguous identication of the purpose in the software development project becomes a crucial task to be fullled in the beginning of the project. The signicance of this particular task has given raise to the topic so called: Requirements Engineering and the establishment of standards for its documentation [2, 3]. ⋆ This work has been partially supported by the Mexican Dirección cación Superior Tecnológica under grant 2369.09-P of CICT 2009. General de Edu- Identication and requirements capture is a step what is accomplished independently of the employed software development approach. Nowadays, Software Factories (SF) and the Model Driven Architecture (MDA) are two important trends in the software engineering eld. Both approaches have been proposed for developing software systems in a highly productive and cost-eective way [4]. Roughly speaking Software Factories [5] promotes the use of domain specic developing by employing domain specic languages (DSL) while MDA [6] focus on the practice of high-level abstract models for representing software concepts. Domain-Specic Modeling (DSM) can raise the level of abstraction by specifying programs directly using domain concepts. The nal products can then be generated from these high-level specications [7]. In this work, we discuss and propose domain specic languages for requirements capture such a practical strategy which is useful in both MDA and Software Factories. This can be done by designing DSL's (Example 3)from SF approachthat generate models of the requirements model of MDA. We introduce examples of current modern paradigms for DSL creation in order to show how it is possible discover elements and relations in a domain (a proper task of requirements capture). The rest of the paper is organized as follows. In Section 2, we overview the topic of SF and MDA and explain the possible relation between them by DSL's. In Section 3, we introduce examples of DSL's and describe how domain concepts are related to requirements capture. Finally, in Section 4 we conclude. 2 Requirements capture in MDA and Software Factories Software Factory is dened in [5] as follows: is a software product line that con- gures extensible tools, processes and content [...] to automate the development and maintenance of variants of an archetypical product by adapting, assembling and conguring framework-based components . Software Factories focus on the development of families of systems emphasizing the reuse by means of domain specic development, for instance domain specic languages. On the other hand, MDA is described in [6] as a set of OMG standards that enables the specication of models and their transformation into other models and complete systems. Thus, MDA focus on the use of high level abstraction models. In the software engineering practice MDA promotes the use of the UML (Unied Modeling Language) which is a general purpose modeling language for object oriented software. The requirements model with respect to Objectory methodology [8] is described by three particular models: behavior Based on use cases of UML. information Based on class diagram of UML. presentation Which is composed by a model of interfaces. Currently the requirements model is part of the Rational Unied Process [9]. Revisiting the Software Factories proposal, the software engineers develop one or many particular DSL's for the domain in order to specify the system or code which is pretended to develop. In this work we present toy examples of DSL's focused for specic domains, thus following the SF approach. By employing DSL's we intrinsically identify domain concepts, indeed, concepts and their relations are the vocabulary of the new DSL designed. I.e., designing a DSL (from SF) is similar to dene the information model of MDA. Furthermore by means of DSL's (from SF) we can produce the MDA presentation model by generating code for interfaces for instance in Java. 3 Domain specic languages A domain specic language (DSL) is a programming language tailored for a particular application domain. Domain specic languages research is fairly old, eorts devoted to standardize concepts and ideas data to [10]. The main purpose of DSL design is the correct abstraction of the domain Hudak [11]. This fact can be very useful in the software engineering eld. In the literature we can nd many examples for several domains, for instance for: robot programming [12, 13], music composition [14], graphics programming [15], multimedia programming [16], fuzzy and logic programming [17] and so on. All of the aforementioned DLS's correspond to internal (or embedded) languages, i.e., they require of a language (or a framework) host in order to be run. In the following section we present some examples of DSL's. The goal is to show that despite of dierent characteristics of hosting languages for DSL development, still is possible to model concepts of the domain and their relations. Identication of concepts and their relations from SF is similar to dene the model of information in MDA. 3.1 Formal DSL's with ANTLR ANTLR [18] is the more modern language tool that provides a framework for constructing compilers from grammatical descriptions. It is possible to dene actions for a variety of target languages. Example 1. book [18]. Let us considere the following example extracted from the ANTLR grammar Expr; prog : stat+ ; stat : expr NEWLINE | ID '=' expr NEWLINE | NEWLINE ; expr : multExpr (('+'|'-') multExpr)* ; multExpr : atom ('*' atom)* ; atom : INT | ID | '(' expr ')' ; ID : INT : WS : ('a'..'z'|'A'..'Z')+ ; '0'..'9'+ ; NEWLINE:'\r'? '\n' ; (' '|'\t'|'\n'|'\r')+ {skip();} ; The above code introduces a set of grammatical rules in lowercase and a set of lexical rules. Both rules dene the set of concepts of that domain. For instance, a program is composed by statements and a statement is composed by expressions which are formed from integers, white spaces and identiers. Relations between concepts are dened by sequences of compositions which are exploited when an expression is decomposed (derivated) following grammar rules. The example constitutes a too basic domain composed by arithmetic expressions. 3.2 DSL's in imperative languages Ruby is an objected oriented programming language very useful for DSL development [19]. Ruby is considered like a general purpose language due to incorporates many advantages useful for rapid writing of applications. Now, let us consider a domain relative to building (the DSL design is inspired by Fowler at [19]). Let us think in a system for calculating the costs implicit in the construction of a house. Typically a house is built from dierent segments for instance, oor, walls, windows, doors, etc. Creating a system for costing requires to determine the concepts to be taken into account. A segment of a house can be modeled as follows. Example 2. class Segment attr_reader :id def initialize id @id = id @requirements = [ ] end def addResource res @requirements << res end def scost tcost=0 @requirements.each do |r| tcost += r.cost end return tcost end def to_s "%s \n requires: \n %s\n requirements cost: %s" % [@id, @requirements.join(", \n "), scost] end end Roughly speaking a segment is a class composed by many requirements (an array), for example, to construct a wall we need bricks, labour, etc., they will be registered in the instance variable @requirements. class Bricks attr_accessor :type, :number def initialize @@costh = 2.5 @@costi = 2.0 end def cost if type==:industrial return @@costi * number elsif type==:handcrafted return @@costh * number end end def to_s "Brick requirements <<type: %s, quantity: %d, cost %.2f>>" % [@type,@number,cost] end end A brick is modeled in its corresponding class, let us observe class variables (@@costh, @@costi) that dene prices for all instances of Brick. Now we present a domain specic program. begBuilding segment(:wall1) requires(bricks) brickType(:industrial) brickNumber(500) requires(bricks) brickType(:handcrafted) brickNumber(1500) requires(labor) laborType(:wall) laborUnits(35) printCost In the above code we can observe a construction composed by a wall, an the wall has some requirements, e.g., industrial and handcrafted bricks and units of labor. When the domain user begins a program, a global variable (like [19]) is established for register the construction and all its segments. When a segment is declared, newly, a global variable dene de current segment. Variables predened with ":" are denominated symbols in Ruby, in that case they are associated to a new object. Fig. 1. Ruby DSL program running of Example 2. Again, DSL implies detection and programming of domain concepts (model of information in MDA). Ruby is a very expressive language, hence possibilities for representing domain relations are many. An execution of this DSL can be seen in the Figure 1. 3.3 Domain specic modeling languages Domain-Specic Modeling (DSM) Languages are DSL's that put models at the core of development, making it truly model-driven. Some frameworks for DSM development are: Eclipse EMF/GEF, MetaEdit+ (a comparison between them is in [20]) and DSL Tools [21]. By using DSL Tools we can build customized modeling tools, dene a modeling language and implement it, from models we can generate code for any target language. Regularly models describe concepts that are specic to how our organization models business processes. I.e., models are intrinsically related with the requirements of a specic domain. In these tools developing of a new DSML needs denition mainly of three phases: a) denition of an abstract syntax; b) denition of a concrete syntax and nally denition of c) code generators. Abstract syntax is associated to a metamodel that represents all possible models to be constructed from the metamodel. Concrete syntax is referred to visual gures which will be used when the domain user develop domain programs. In this example, we create a specialized language that describes a user interface. Then we can generate code from those visual descriptions. First let us observe the abstract syntax in Figure 2. It is basically a metamodel built from a class diagram. In the metamodel a window is composed by buttons, checkboxes, etc. In Figure 3 we observe a domain program. There, two windows contain buttons and checkboxes. Concrete syntax permits that a blue rounded rectangle represents the concept window. In Figure 4 we present a template for java code generation. Example 3. In the Example 3, domain concepts of visual interfaces like window, button or checkbox are part of the model of information. And also, from the code generator the interfaces model can be directly gotten. 4 Conclusion Basically, SF and MDA can have a common strategy for requirements capture. An appropriate design of the DSL in the SF approach can produce the presentation model of MDA by generating the code of the system interfaces. And also a DSL requires a particular vocabulary for the domain and mechanisms for relating the words of that specic vocabulary. Properly the model of information Fig. 2. Domain model of Example 3. Fig. 3. A DSL visual program from Example 3. <#@ output extension=".java"#> <# foreach(Ventana v in this.Interfaz.Ventanas) { #> public class <#=v.Name#> extends javax.swing.JFrame { public <#=v.Name#> () { setSize(300,200); setTitle("<#=v.Titulo#>"); initComponents(); } private void initComponents() { getContentPane().setLayout(new java.awt.GridLayout(5,1)); <# foreach(Casilla b in v.Casilla) { #> <#=b.Nombre#> = new javax.swing.JCheckBox(); <#=b.Nombre#>.setText("<#=b.Etiqueta#>"); getContentPane().add(<#=b.Nombre#>); <# } #> addWindowListener(new java.awt.event.WindowAdapter() { public void windowClosing(java.awt.event.WindowEvent evt) { exitForm(evt); } } ); } ... Fig. 4. A template for code generation of Example 3. contains the classes or concepts of the domain and relations between classes. Relations for DSL's can be modeled in dierent way according to the host paradigm for the DSL construction selected. Concluding, the advance of software paradigms makes possible the construction of executable requirements by means of DSL's that are useful for MDA and for SF approaches. References 1. B. Nuseibeh and S. M. Easterbrook. Requirements engineering: a roadmap. In ICSE - Future of SE Track, pages 3546, 2000. 2. Institute of Electrical and Electronics Engineers. IEEE Recommended Practice for Software Design Descriptions. volume IEEE Standard 1016-1998, 1998. 3. Institute of Electrical and Electronics Engineers. IEEE Recommended Practice for Software Requirements Specications. volume IEEE Standard 830-1998, 1998. 4. J. Muñoz and V. Pelechano. Building a software factory for pervasive systems development. In CAiSE, pages 342356, 2005. 5. Jack Greeneld, Keith Short, Steve Cook, and Stuart Kent. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. John Wiley & Sons, 2004. 6. A. Clark S. Mellor and T. Futagami. Guest editors' introduction: Model-driven development. IEEE Software, 20(5):1418, 2003. 7. J. Tolvanen and S. Kelly. Dening domain-specic modeling languages to automate product derivation: Collected experiences. In Proceedings of the 9th International Conference on Software Product Lines, SPLC 2005, pages 198209. Springer, 2005. Object-Oriented Soft- 8. I. Jacobson, M.Christerson, P. Jonsson, and G. Overgaard. . Addison-Wesley, 1992. 9. W. Scacchi. Process Models in Software Engineering. pages 9931005. Wiley, 2002. 10. Editor J. C. Ramming. USENIX Conference on Domain-Specic Languages. 1997. 11. P. Hudak. Modular Domain Specic Languages and Tools. In , page 134. IEEE Computer Society, 1998. 12. J. Peterson, G. Hager, and P. Hudak. A Language for Declarative Robotic Programming, 1999. 13. L. Huang and P. Hudak. Dance: A Declarative Language for the Control of Humanoid Robots. Technical Report YALEU/DCS/RR-1253, Yale University, August 2003. 14. P. Hudak, T. Makucevich, S. Gadde, and B. Whong. Haskore Music Notation - an Algebra of Music. , 6(3):465483, 1996. 15. C. Elliott and P. Hudak. Functional Reactive Animation. In , pages 263 273. ACM Press, 1997. 16. P. Hudak. . Cambridge University Press, New York, NY, USA, 2000. 17. P. Julián, G. Moreno, and J. Penabad. Operational/Interpretive Unfolding of Multi-adjoint Logic Programs. , 12(11):16791699, 2006. 18. T. Parr. . Pragmatic Bookshelf, 2007. 19. ThoughtWorks Inc. . Pragmatic Bookshelf, 2008. 20. S. Kelly. Comparison of eclipse emf/gef and metaedit+ for dsm. In , 2004. 21. S. Cook, G. Jones, S. Kent, and A. C. Wills. . Addison-Wesley Professional, 2007. ware Engineering  A Use Case Driven Approach Conf. on Software Reuse (ICSR '98) Proc. of the 5th Int'l Journal of Functional Programming Proc. of the 2nd. ACM SIGPLAN Int'l Conf. on Functional Programming (ICFP '97) The Haskell School of Expression: Learning Functional Programming through Multimedia Journal of Universal Computer Science The Denitive ANTLR Reference: Building Domain-Specic Languages The ThoughtWorks' Anthology, Essays on Software Technology and Innovation OOPSLA Domain-Specic Development with Visual Studio Dsl Tools