Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Domain-specific Modeling: Welcome to the Next Generation of Software Modeling : Page 2

Domain-specific modeling promises to change the modeling landscape by providing a greater level of abstraction from code than UML, providing modeling constructs for developers that mimic the real-world objects more closely, and most importantly, providing complete code-generation capabilities, which together lead to a much more productive way for developers to model applications.


advertisement
A DSM Example
Figure 2 shows a relatively simple application specified in a DSM language. It is the design for a conference registration application that runs on a SmartPhone. The design is expressed in a language created specially for defining enterprise applications on SmartPhones. It includes modeling concepts such as notification, query, pop-up, and text message—the actual UI widgets and services you already find on a phone. With these and other similar modeling concepts, you can specify both the static structure of applications and their dynamic behavior.

 
Figure 2. Conference Registration Application: The model shows a conference registration application in a DSM language intended for enterprise applications on SmartPhones.
The design provides enough information to automatically generate full code for this application. After drawing the design, the developer can run the generator and execute it on the target. This sample language includes the design rules for phone application development and completely hides the implementation details. You don't see code concepts in the model.

To be able to design applications this way the developer naturally needs to understand the phone domain. Of course, this particular DSM language is only helpful for designing SmartPhone applications. It is useless for designing a CRM application, a patient monitoring device, or for business rule modeling. However, reducing the design space to just one single problem domain makes it easy to raise the level of abstraction and, as I will discuss in the next section, makes complete code generation possible. As the simple example model demonstrates, the DSM language is much more expressive for designing these specific types of applications than a generic language. The design models made with the DSM language are easier to read, understand, remember, and validate. Perhaps most importantly, it allows applications to be created significantly faster.

Full Code Generation
In my view we should aim at making model-based code generation full: we should be able to generate all the code for the application from the models, and not have to edit the generated code. This completeness has been the cornerstone of other successful shifts made with programming languages, such as compiling source code to Assembly. Ever seen anybody manually edit Assembly and try to keep their C code in synch with it?

Because DSM languages and the way developers write code tend to differ from domain to domain, DSM code generators also need to be specific to a domain. Contrary to the approach that most CASE tools follow in offering proprietary, fixed-code generators, DSM advocates the use of fully open and customizable generators for generating any type of output: code, test cases, documentation, configuration files, etc. The idea is for a company's expert to have the freedom to define these generators, supported of course in doing this task by the tools offered by DSM modeling environments. Experienced developers usually know better than other developers or tool vendors how best to write code in the company's problem domain. DSM offers the opportunity here for the rest of the development team to leverage the knowledge of the expert developer. By advocating open language and code generator definitions, DSM aims at letting companies implement changes internally, without being dependent on a tool vendor to make changes for them. The result is a much tighter fit between language, generator and the company's problem domain.

A Code Generation Example
The code below presents a simple example of a generator definition for a Note dialog like those shown in Figure 2 . The Note opens a dialog with information, like for example "Conference registration: Welcome." Lines 1 and 6 simply create a structure to hold the generator. Line 2 creates the function definition signature, and line 3 is a comment. Function naming is based on an internal name that the generator can produce if the developer does not want to give each symbol its own function name.

1 report '_Note' 2 'def '; subreport; '_Internal name'; run; '():'; newline; 3 '# Note '; :Text; newline; 4 ' appuifw.note(u"'; :Text; '", '''; :Note type; ''')'; newline; 5 subreport; '_next element'; run; 6 endreport

Listing 1: Code generator for Note dialog

Line 4 produces the call for the platform service. It uses the model data (underlined here for clarity), such as the value for the Text property of the Note UI element (in this case, "Conference registration: Welcome"). Similarly, the modeler chose the 'Note type' value in the model from a list of available notification types, like 'info' (here) or 'confirmation' (used in "Registration made" in Figure 2). The generated line 4 is thus (with modeling data underlined):

appuifw.note(u"Conference Registration: Welcome ", 'info')

Because the code generator automates the mapping from model to implementation, every developer makes the Note dialog call similarly: the way the experienced developer has defined it. Finally, line 5 calls another generator definition to follow the application flow to the next phone service or UI element. This generator, named _next element, is also used by other UI elements similar to Notes.

 
Figure 3. Leveraging Expertise: DSM lets experts leverage their knowledge to automate software production and make development tasks easier for the rest.
In some cases, you may generate all the code directly from the designs. Often, though, this would cause the generation of code with a fair amount of repetition—as you probably have in your existing hand-written code. Making the generator often helps to expose places where lines of code are repeated, maybe with small changes to parameters. You should abstract such code out into what we call the domain framework: utility code or components to make code generation easier. Such a framework forms a thin layer on top of the current platform of in-house and third party components and language libraries.

Figure 3 recaps what I have discussed so far: DSM offers company experts a way to encapsulate their expert knowledge in a new, higher-level modeling language that reflects the problem domain in which developers are working. The expert developers also distil their experience into a code generator that transforms the developers' designs into code that interfaces with a domain framework layer or software platform. Essentially, DSM lets organizations use the skills and expertise of a company's best developers to make things easier for the rest.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap