Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development

Transcription

1 Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development Ahmet Demir Technische Universität München Department of Informatics Munich, Germany Abstract Model-Driven Development aims to leverage models to generate the specified software system. Two currently dominant approaches to Model-Driven Development are Model-Driven Architecture and Software Factories. The goal of this paper is to analyze the advantages, disadvantages and the applicability of these two approaches. A basis for the analysis provides a case study comparing Model- Driven Architecture and Software Factories. The comparison focuses on the development activities and challenges of both. The subsequent analysis covers their purposed modeling languages, expected benefits like higher productivity and higher efficiency, and the main objectives of both approaches. 1. Introduction Model-Driven Development (MDD) is a software engineering methodology with particular focus on models, automation and code generation. The difference to traditional software development is that MDD proposes to leverage models to generate the specified software system. Two currently dominant approaches to MDD are Model-Driven Architecture (MDA) [6] and Software Factories (SF) [4]. MDA, owned by the Object-Management Group (OMG) [8], proposes to apply the Unified-Modeling Language (UML) [10], also owned by the OMG. Due to aspects like platform independence and reusability, the software system is supposed to be modeled in three major steps, described further down. SF, as proposed by Microsoft, is an entire software development paradigm, which makes use of Domain- Specific Modeling (DSM) [3]. In this manner, SF and particularly its DSM part is the second considered MDD approach in the context of this paper. SF proposes to utilize Domain-Specific-Languages (DSLs) for modeling. In order to apply the two approaches, a web-based application named Bookstore Administration Center (BAC), an administration tool that shows, appends, edits or deletes books from a bookstore will be developed. The BAC is developed first applying MDA and then SF. Both variants are developed by on single person. The experiences made during the development phases are compared, analyzed and evaluated. It turns out that both approaches demonstrate strengths and weaknesses, but both are able to achieve the expected benefits. Important is that their intended purpose plays a decisive role in achieving the benefits. 2. Model-driven development Model-Driven Development (MDD) aims to leverage models for automatically generating applications with appropriate code generation techniques and templates. Models are already used to specify software systems, but unfortunately these models mostly serve only for the purpose of documentation and comprehending the system. Changing this fact by using these existent models to generate the application, software development can easily be automated. By automatic code generation, the quality of an application can be increased, due to the fact that code is produced according to a certain structure, scheme or rules. In this way the generated code will precisely match the models. Further on this road the evolution could lead to the fact that modeling languages replace the implementation languages, just like the way third-generation languages replaced the assembly languages through the introduction of compilers.

2 3. Model-Driven Architecture Impelled from the idea that models are vital and necessary to handle complexity in software development, Model-Driven Architecture (MDA) [6] specifies a process for creating models. 3.1 The Unified Modeling Language The Unified-Modeling Language (UML) [10] is the proposed modeling language for MDA. According to [9], UML s architecture is represented by a four layer hierarchy as shown in Figure 1. On the top of this hierarchy is the meta-metamodel layer (M3), also known as the Meta-Object Facility (MOF) [7] layer, followed by the metamodel layer (M2) representing the UML. The third layer is model layer (M1), where the actual modeling process takes place. The architectural hierarchy bottoms out at the data layer (M0), which contains the run-time instances of a model. system, continuing with the Platform Independent Model (PIM) encapsulating the entire software specification, apart from the any platform specific aspects, the modeling process finishes with the enhancement of the PIM to a Platform Specific Model (PSM). The PSM binds the software system to a specific platform. 3.3 Model transformation The focus at this point is on the last model transformation of MDA, which results in the application, expressed in a programming language. The result can also be in form of deployment descriptors or configuration files. The transformation can also be considered as mapping. Beyond the code generator, there is a need for rules describing the way how model-elements shall be mapped into code. Figure 2 illustrates the MDA process. The first transformation refers to the process where the PIM is transformed into a PSM. A PIM and a PSM can also be transformed into a more detailed version of itself. This is marked as refinement. The mapping into the desired programming language is called second transformation in Figure Software Factories Figure 1 - An example of UML s four-layer architecture [9] Furthermore, UML provides extension mechanisms (Stereotypes, Tagged Values and Constraints) to extend or specialize itself for specific purposes. A collection of Stereotypes, Tagged Values and Constraints is called a UML Profile. Profiles are necessary and needed in the context of MDA, because they facilitate code generation. 3.2 Basic concepts of MDA Platform independency is the primary goal of MDA. Particularly due to this aspect, the software system is supposed to be modeled in three major steps. Starting with the Computational Independent Model (CIM) to present a high-level overview of the software Microsoft introduces Software Factories (SF) [4] as a new software development paradigm. SF primarily focuses on Product Line Development, which copes with developing a set of similar but distinct products. In this context SF relies heavily on models and automation, which are basic concerns of MDD. This paper will focus on the MDD concerned aspects of SF. 4.1 Software Factory methodology Jack Greenfield and Keith Short define the methodology Software Factory [4] as followed: A Software Factory is a Software Product Line that configures extensible tools, processes, and content using a software factory template based in a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework based components. A Software Factory has two central elements, a Software Factory Schema and a Software Factory Template. A SF Schema defines, categorizes and summarizes the artifacts and assets required to build a

3 Figure 2 - MDA process software product line. It can be seen as a recipe listing ingredients, tools and the application process. A SF Template is based on the SF Schema and represents the implementation of the SF Schema that means that all defined assets and artifacts have to be built and made available. The implementation comprises among others developing DSLs. The SF Template can be seen as a bag of groceries containing the ingredients listed in the recipe (SF Schema). A core principle of the SF approach is to enable a high degree of reuse of existing assets and development of new reusable assets. The development of a specific member of a product family comprises reusing existing assets and developing variable assets for that specific member. The SF approach uses the concept of Domain-Specific Modeling (DSM), which utilizes Domain-Specific Languages (DSLs) for modeling. 5. Case study The architecture of a DSL is similar to UML s architecture, which is also represented by a four-layer hierarchy. The significant difference is that the metamodel layer (corresponding to UML s M2 layer) has to be defined, while UML s metamodel layer is already defined and can be extended by Profiles. The mapping of a DSL model into a programming language is conducted by an appropriate code generator, which must be designed and developed for a given DSL or at least be configurable to tailor its task to a specific domain. A DSL is mapped to a programming language, just as a programming language like Java is mapped into byte code. According to this analogy, the compiler would correspond to the code generator. The case study described in [2] comprises a product line with three similar but distinct web applications. 1. Bookstore Administration Center (BAC) - An administration tool that allows authorized users to show, edit, add or delete books from a bookstore. 2. Online Bookstore (OBS) - Users can browse and buy books and have them shipped. 3. Online Music Shop (OMS) - Users can browse, buy and download MP3 songs 4.2 Domain-specific modeling The purpose of DSM serves primarily for the creation of models for computation and secondarily for documentation. Models should be able to be processed by tools to generate source code out of them. DSM aims to bridge the gap between the problem domain and the solution domain by the means of abstraction. DSLs raise the level of abstraction by incorporating domain concepts. A DSL uses concepts and terms of the problem domain and provides specific graphical and textual notations to create models, thus it is very close to the problem domain. The more a DSL can be tailored to a specific domain or purpose the more efficient the DSL and the code generation will be. Figure 3 - Use case diagram for BAC The MDA approach will be applied by modeling the BAC. The SF approach will be applied by deriving a DSL according to the features of the entire product line. The expense of creating a DSL can only be compensated by using the DSL for modeling multiple

4 similar products. Therefore, the DSL is derived from, and created for a complete product line. In order to assure and demonstrate the SF methodology within this case study, the DSL is derived as assumed, but implemented including only the features of the BAC, since this is sufficient for the purpose of the comparison. The DSL can easily be extended to cover the entire product line. The functionality of the BAC is very simple and should be clear by the use case diagram in Figure MDA solution In order to apply the MDA approach, a MDA tool named ArcStyler [1] is utilized. ArcStyler provides several UML Profiles to develop software systems, amongst others a UML Profile for developing web applications. This Profile contains two stereotypes, one named Accessor and the other named Representer. The Accessor is used to model objects that are responsible for the graphical aspect of a web application, while the Representer is used for modeling objects that encapsulate behavior. The BAC is modeled with two Accessor objects for handling user requests and seven Representer objects for handling the graphical representation. Only the objects with the suffix Page do really display data. The others handle concerns like layout and menu. ArcStyler enables defining graphical elements (e.g. buttons, text fields, etc.) for a Representer object and mapping its class attributes to the graphical elements. Figure 4 illustrates the Class diagram of the BAC. The behavior of the application is still to be defined. This is realized by defining one Activity diagram for each Accessor class. Figure 5 shows the Activity diagram for the MainAccessor. The entire behavior of the application is encapsulated in the MainAccessor. Merely the authentication procedure is handled by the LoginAccessor. All states in Figure 5 are nested states within the base state application, which is active as long as the application is running. All states with the suffix View are mapped to the corresponding Representer object from the class diagram. For example, the application starts in the StartPageView state, which displays the StartPage object with its graphical elements. Within this state the user can select a book and request its details. That means that the transition to the DetailedPageView represents the response of the MainAccessor, sending the DetailedPage object, to the user. The transformation of the PIM into a PSM is determined by choosing the desired programming language and further not obvious for the ArcStyler user. In coherence with the utilized UML Profile, ArcStyler provides mapping rules for the built-in model interpreter to process the diagrams and generate the artifacts for the modeled application. For each Class from the class diagram is one Java file generated. Additionally for each Representer, a JSP file. After the generation process, the source code must be enhanced, which turns out to be a difficult task, because the generated source code is opaque and thus difficult to comprehend. Methods annotated in the diagrams as comments, are added to the LoginAccessor and the MainAccessor. 5.2 Software Factories solution Figure 4 Class diagram for BAC The SF approach assumes to create a Problem Domain Matrix (PDM) to show the highlevel features of the product line. A PDM lists all possible features of the products on the left and the product line members on the top (see Table 1). If a feature applies to a product, the according row and column will be marked with a x. In the

5 Producttype element further contains an element named Attribute for specifying its attributes (e.g. name, author, year, etc.). In this manner the DSL is build hierarchically. Furthermore, the DSL contains elements to display the data (e.g. Page, Button, Form, etc.), which actually appear as solution domain aspects, but in this case of problem domain they also represent problem domain aspects. The hierarchical structure is also applied for these elements, because the Page element contains Figure 5 - Activity Diagram for MainAccessor elements like Button, Textfield, Form, etc. The main functionality of web-applications is determined by processing user requests and sending responses to the users, particularly by manipulating data and providing the content for the graphical representation. Therefore the DSL includes a Controller element to capture this task, and a LoginController element to handle the authentication process. The Controller elements correspond to the Accessor objects in the MDA solution. The DSL additionally comprises associations between its elements, for example, a Page element needs to know what kind of data to display, therefore it can be associated with the Producttype or Store element. These connections can be more detailed by associating the elements within a Page (e.g. Textfield, Form, etc.) with the Attribute elements of a Producttype element. Although the amount of features that the DSL supports is fairly small, the DSL definition (metamodel) turned out to be complex, because the DSL is designed to model graphical, functional and data aspects. Developing a DSL is time-consuming and sophisticated. Highly skilled software engineers with problem domain experience should design DSLs. Once created, a DSL can be used by requirements engineers, by other domain experts and in general by people with less programming experience and even be understood and comprehended by the customer. next step, a Solution Domain Matrix (see Table 2) is derived from the PDM. Both have the same structure. The product features will be mapped to the solution domain, thus they become more detailed. The purpose of the matrices is to show commonalities and variabilities of the product line and to derive an appropriate DSL. In order to develop a DSL, a DSL tool named Generic Modeling Environment (GME) [5] is utilized. Among others, GME provides a meta-modeling language named MetaGME. It can be compared to OMG s MOF [7] and is used to develop the DSL. GME can then be used as an editor to apply the developed DSL Developing the DSL: The purpose of the DSL is to model web-applications like those mentioned above. The data that is processed by the applications plays a minor role in this case. The major role is assigned to the structure of such a web application. Thus, the problem domain can be set to web-applications and narrowed down to webapplications coping with one or two products (e.g. Books, MP3s, CDs). In this manner, the DSL contains elements for specifying the data objects, for example a Store element for modeling a Bookstore or a Music store. Since the elements of a store can be of different types, the DSL includes additionally an element named Producttype, for modeling Books, MP3s, etc. The

6 Table 1- Problem Domain Matrix Table 2 - Solution Domain Matrix BAC OMS OBS BAC OMS OBS Data Model Req. Data Model Store X X X store name (String) X X X Product X X X Product string attributes X X X Business Logic Rq. Business Logic Use cases X X X Use cases list all products X X X list all products X X X list product details X X X list product details X X X edit product X edit product X delete product X delete product X add product X add product X buy product X X buy product X X download product X download product X read online X read online X payment X X payment X X Authentication X X X Authentication Mapping login validation Registration X X Registration X X X registration validation X X User interface Req. User interface www pages JSP pages menu X X X menu (JSP fragment) X X X menu item X X X menu item (button) X X X transition element X X X transition element HTML link X X X HTML button X X X content element X X X content element header X X X static textfield X X X HTML table user input element X X X user input element editable textfield X X X HTML forms X X X Common style X X X Common style X X X Authentication login mask X X X Registration registration mask X X Applying the DSL: Figure 6 shows the DSLbased model of the BAC. Instead of describing the entire model, only the important elements will be addressed briefly. In order to model the data objects of the BAC, the Store element is used to specify a BookStore object and the Producttype element to specify a Book object. The attributes (e.g. author, title, price, etc.) of a book are modeled by using the Attribute element of the Book object. Furthermore, the BAC consists of several web pages with different content. For example the StartPage is modeled using a Page element. Since it displays all books of the bookstore, it is associated with the BookStore object. However, the DetailedPage object specifies the web page displaying the details of a previously selected book. In this case it requires an association to the Book object and the contained elements (e.g. Button, Form, Textfield) require additionally associations to the Attribute elements of the Book, particularly in order to specify which attributes of the book to display. The other Page objects (LoginPage, DetailedPage, etc.) are modeled analogously. Beside the web pages, two Controller objects are defined. The LoginController supports the Login process and the MainController handles all other user requests. All Page objects have to be associated with a

7 Controller object, because a Controller has to know which Page sends the request and which Page is to be sent to the user. A request can be started by an action object (Form, Button or ContentList). In order to know which Page to request, an action object has to be associated with the requested Page object, for example, the EditButton within the DetailedPage object is associated with the EditPage object, specifying that, this is the page to request by pushing this button. Figure 6 - DSL based BAC model Developing the code generator: The experiences made during the case study showed that it is necessary to consider the issue of code generation while creating the DSL. The development of the code generator seems to be a subsequent task to the development of the DSL. In fact they are closely related and constrained by the capabilities of the code generator to map model elements to code constructs. Thus, it is highly recommended to consider this task already during the development of the DSL, because it happened that the code generator required model information, which could not be retrieved due to a missing association in the metamodel of the DSL. Thus, the DSL metamodel had to be enhanced. GME provides a framework, the Builder Object Network, to develop code generators for MetaGMEbased modeling languages. This framework exposes the entire DSL model including its objects and associations as a set of Java objects. This set can then be used to generate appropriate code for each modeled object. Convenient methods to access the objects properties, attributes and associations allow to navigate within this set. The functionality of the code generator is basically separated into three components, the Invoker component, the Handler component and the Generator component. The Invoker component is composed of one single class providing the above mentioned set of Java objects. The Handler component contains classes for retrieving and gathering information from the objects, while the Generator component is composed of classes for generating source code. Each DSL element on the top level (e.g. Page, Controller, Store, Producttype) has an own Handler and Generator class. The Generator classes comprise predefined source code, which is enhanced with the information gathered by the Handler classes and then written in files. The data objects (Book, Bookstore) are mapped into simple Java classes. The Controller objects are mapped into Java Servlets and the Page objects are mapped into JSP pages. The MainController is build upon a if else structure, distinguishing on the requested page. The MainControllerHandler navigates through all associations the MainController holds with Page objects. In this way the Controller knows all pages that can be requested, and builds the if-else structure upon these associations. Before the MainController sends the requested page, it has to provide data for the requested Page object (JSP page). Therefore, the MainControllerHandler searches for associations, the current navigated Page object holds with a data object. For example, if there is an association between that Page and the Book object, the MainControllerGenerator produces a code fragment for passing the current selected Book object to the requested Page. In this manner an association between a Page and a data object is mapped into a code fragment for passing data. In order to show how a Page object and its associations are mapped into a JSP file, the generation of such a file will also be addressed briefly. A PageHandler analyzes a Page object and gathers information, for example about its associations. A Page can hold an association to a Book object, specifying that this page displays information about a

8 book and not about the store. Analogue to the mapping above, this association is also mapped into a code fragment, but this fragment is contained in the JSP file and has the purpose of retrieving the passed data from the MainController. Furthermore, the PageHandler gathers information about the contained elements (e.g. Textfield, ContentList, etc.) of a Page. These elements can also hold associations, for example to the Attribute elements of a Book object. These associations determine which element (e.g. TextField) within a Page displays which attribute of the retrieved Book object. All these information is passed to the PageGenerator, which produces the actual JSP file. Nevertheless it is also necessary to enhance parts of the generated source code afterwards due to the same reasons as in the case of MDA; methods have to be implemented manually. 6. Conclusion This paper illustrates the development of a software system applying two of the current dominant approaches to MDD. In the following the experiences made during the development phases will be analyzed, compared and evaluated. Though, both approaches were applied by one single developer, but the degree of reused knowledge from the first development was low, because the development of the MDA solution has not provided much knowledge for developing the DSL and the code generator. The MDA solution shows that productivity can be increased by applying the MDA approach. Certainly, the utilized tool plays an important role, but a better productivity can be achieved particularly due to the omission of the implementation phase. A disadvantage in this case is that the learning phase for the MDA tool is due to its complexity and individuality very timeconsuming. Nevertheless, the modelling process can be started immediately, since the modelling language (UML) is already provided, apart from the fact that specific UML Profiles are needed and not granted by the MDA tool. The SF solution shows that the SF methodology can increase productivity as well, basically for the same reason as in the case of MDA, the implementation part is omitted. But, before reaching this point, the expense for the SF approach is much higher, because the DSL has to be developed first, which is time-consuming and sophisticated, and requires expert knowledge about the problem and the solution domain. This fact delays the start of the modeling process. Once a DSL is created, a better efficiency can be achieved, because a DSL comprises domain concepts and thus it is closer to the problem domain. This fact facilitates involving business stake holders into the specification process to avoid misinterpretation and confusion. This is an advantage for DSLs, since the comprehension of UML models require UML experts. Quality and reliability of a software system can be improved as well in both approaches, particularly due to the reason that the generated code is less errorprone, because of its generation according to a scheme, rules or code-templates. Provided that the model interpreter works properly, the generated code is more reliable than handcrafted code that usually contains bugs, because a developer tends to make mistakes. Furthermore, the generated applications exactly meet their specification in form of models, since they are generated according to them. Certainly, MDA and SF apply similar methods and techniques for modeling and mapping, but they have distinct objectives. Due to the high expense of developing a DSL and a code generator, the SF approach is only recommendable for developing Product Lines, because this expense has to be compensated somehow. However, once a DSL and the code generator are developed, the costs for generating the product line members are very low due to their similarity. The overall costs of a product line development can then be distributed on the amount of all members, which makes the SF approach productive. Otherwise, for One-Off development, the SF approach would be expensive in terms of time, budget and resources. MDA on the contrary can be used for One- Off Development and Product Line development, since there is no additional expense to compensate. Product Line development with the MDA approach would even increase the regular expected degree of productivity, because the first model could be reused for the other product line members. Fact is that MDA is a pure MDD approach and focuses on platform independence, while SF is an entire software development methodology and focuses on product line development. UML as the standard modeling language for MDA is a general purpose language, which has to be specialized and constrained with Profiles to be appropriate for MDD. A DSL in contrary is supposed to be developed for a specific domain from beginning, without specializing and constraining afterwards, in this manner DSLs can be very efficient within that domain, but also very useless in other domains. On the whole, both approaches have their strengths and weaknesses; none of them is clearly in advance. Depending on the purpose they are applied for, they demonstrate different strengths and weaknesses. An appropriate problem domain, professional developers, a suitable tool and a precise idea of the intended

9 products or product family, can guarantee each approach s benefits. 7. References [1] Interactive Objects: ArcStyler 4.0, released 2003, [2] DEMIR, Ahmet: Comparison of UML 2.0 and DSLs in the context of MDD, Diploma Thesis, Technische Universität München, 2005 [3] DSM Forum, Homepage, www page: [4] Greenfield, Jack and Short, Keith: Software Factories. Wiley Publishing, ISBN [6] OMG: MDA Guide V1.0.1., document: omg/ Jishnu Mukerji, Joaquin Miller, 2003, [7] OMG: Meta Object Facility 1.4 (MOF), OMG Document: formal/ , www page: [8] OMG: Object Management Group, www page: [9] OMG: UML 2.0 Infrastructure Final Adopted Specification. OMG Adopted Specification, document: ptc/ ), [10] OMG: UML Unified Modeling Language, www page: [5] Vanderbilt University.: Generic Modeling Environment (GME) 4.0, released 2004, www page: