Login | Register   
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: Making Code Generation Complete : Page 2

Domain-specific modeling is most successful when the models let you generate complete working code, without the need for post-generation code modifications or additions. The examples and guidelines in this article show you how.


advertisement
Example 1: Generating XML
Defining generators to produce XML is often quite a straightforward process, especially if the modeling language maps well onto the XML schema. This is in fact normally the case, since both are designed to be a good way of describing the same domain. Where XML schemas have had to sacrifice understandability to cope with the limitations of XML, the modeling language can do things in a more natural way. In this case, the generator will do a little extra legwork to produce the verbosity and duplication required in XML.

This concrete example uses the Call Processing Language (CPL). CPL describes and controls Internet telephony services, in particular, specifying how a system routs calls. The structure of the CPL language maps closely to its behavior, so any CPL service developer can easily understand and validate the service from these graphical models (see sample in Figure 1). Figure 1 also helps show the benefit of models; even a non-CPL developer can largely understand the model, whereas deciphering the same model in XML would be considerably harder.

 
Figure 1. Redirecting Calls: A sample call redirecting service expressed in CPL.
The modeling language includes concepts such as proxy, location, and signaling actions, which are essential for specifying IP telephony servers. The generation process is very clear-cut, because the XML already defines the language concepts, and the property values of the modeling constructs are attributes of the XML elements. The task of the generator is to follow the nodes via their connections and create the corresponding CPL document structure in XML. The following code shows the generator output when producing XML from the specification illustrated in Figure 1.

01 <?xml version="1.0" encoding="UTF-8"?> 02 <!-- DOCTYPE call SYSTEM "cpl.dtd" --> 02 <!-- DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd" --> 03 <cpl> 04 <subaction id="voicemail"> 05 <location url="sip:jones@voicemail.example.com"> 06 <redirect /> 07 </location> 08 </subaction> 09 <incoming> 10 <address-switch field="origin" subfield="host"> 11 <address subdomain-of="example.com"> 12 <location url="sip:jones@example.com"> 13 <proxy timeout="10"> 14 <busy><sub ref="voicemail" /></busy> 15 <noanswer><sub ref="voicemail" /></noanswer> 16 <failure><sub ref="voicemail" /></failure> 17 </proxy> 18 </location> 19 </address> 20 <otherwise> 21 <sub ref="voicemail" /> 22 </otherwise> 23 </address-switch> 24 </incoming> 25 </cpl>

The generator starts by going through all the subactions of the service specification. This example contains only one subaction, the voicemail box at the right bottom corner of the model, for which the generator produces lines 4—8.

04 <subaction id="voicemail"> 05 <location url="sip:jones@voicemail.example.com"> 06 <redirect /> 07 </location> 08 </subaction>

This "voicemail" subaction defines a location element (line 5) as well as a redirect element (line 6), which activates the redirection automatically.

After producing subactions the generator starts to specify the main call processing actions. It goes through the service specification from a service start (the yellow "CPL" circle in Figure 1). The generator crawls the connections from the CPL circle through the "Incoming" relationship to the Address-switch object. It produces the properties of the Address-switch node as element attributes in the generated output (lines 10—11).



10 <address-switch field="origin" subfield="host"> 11 <address subdomain-of="example.com">

The generator continues to follow the main flow path arrow to the next object and produces the location definition (line 12).

12 <location url="sip:jones@example.com">

The path continues and the proxy handling is generated on lines 13—17, first the timeout attribute (line 13) followed by three alternate connections from the proxy element.

13 <proxy timeout="10"> 14 <busy><sub ref="voicemail" /></busy> 15 <noanswer><sub ref="voicemail" /></noanswer> 16 <failure><sub ref="voicemail" /></failure> 17 </proxy>

Finally, the generator produces lines 20—22 for the cases where the call origin has an address other than example.com.

20 <otherwise> 21 <sub ref="voicemail" /> 22 </otherwise>

The generated code forms a complete service whose validity has already been checked at the design stage. Because the modeling language contains the rules of the domain, service creators can create only valid and well-formed design models. The modeling language can also help service creators with consistency checks and guidelines, for example by informing them about missing information (such as the lack of a call redirect specification). These rules are highly domain-specific and thus be handled only with a domain-specific language.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap