Embedded Systems Design Europe - April 2008 - (Page 22)

software tion. Consequently, companies that work on short term projects, unaware of the general requirements of the next customer, are unlikely to achieve much success with DSM. But for those organizations that make a range of similar products, or build applications on top of a common library or framework (e.g. companies with a product line), the beneﬁts of DSM are nothing short of astounding. MODELING LANGUAGE CREATION In this section we will walk through the process of creating a domain-speciﬁc modeling language with the latest release of MetaEdit+[7], an IP telephony service language as an example. This use case is particularly relevant today, as a fundamental change is now occurring in the telephone service arena. In the past, network-based services were only created by service providers due to the special knowledge required, use of proprietary tools, and lack of user-speciﬁc customization options. With the introduction of Internet based telephony, the rules have change, allowing a much wider group to deﬁne these services. One of the ﬁrst required activities when building a modeling language is to deﬁne the modeling language concepts. There are various sources for these concepts, with typical examples being: product components, architecture, characteristics, required output, etc. Speciﬁcally designed tools in MetaEdit+ for describing modeling languages make it easy to transform these concepts into elements of the modeling language. The language creation process should be agile, allowing the metamodeler to deﬁne the language incrementally and to test it at any time by creating speciﬁcations. For the IP telephony services language the modeling concepts are pure call processing concepts, e.g. signaling operations, switches, locations, and non-signaling actions. Service engineers are already familiar with all these, even if the ﬁnal service creation code has been done manually by programming. 22 Now with DSM, such implementation code can be generated form these highlevel service concepts. Once the modeling concepts are deﬁned, the modeling rules need to be established. These rules cover how the concepts can be used and connected with each other. MetaEdit+ provides a variety of predeﬁned rule templates to choose from to address a wide range of possible scenarios – however custom rule deﬁnition is also supported. The establishment of these policies at the language level assures that all developers adhere to the same domain rules – a situation that rarely occurs when relying on in-house standards manuals and documentations. In the use case language, the majority of the rules were able to be deﬁned directly in the metamodel. Examples of the rules established for the language are: there can only be one start element of each service, the root concept must be in only one relationship to start the call process, and the number of connections each object can have. A very useful aspect of DSM – also a visually appealing one – is the ability to utilize custom graphics within the models and modeling language. These symbols can either be drawn using the integrated drawing tools of MetaEdit+, or imported in vector or bitmap format. Using symbols that closely approximate the real world items they represent, makes development far easier for the modeler, and also produces models that can be understood by any stakeholder familiar with the domain concepts. The symbols also support dynamic graphical behavior by using conditional property values that can display values calculated by the generators. The ﬁnal step in building a DSM solution is the creation of the generators. As was the case with the modeling language, domain-speciﬁcity is also important here. These generators can be created to for a wide variety of purposes: reports to check the consistency of the models, produce metrics, analyze model linkages, create data dictionaries, produce documentation, generate code or conﬁguration information, and to export models to other programs (e.g. simulators, version control systems, etc.). The generator deﬁnition below produces the code needed to call other call processes that may be used as reusable actions within the main call process. In this way the generator becomes modular and easy to modify. The integrated Generator Editor included in MetaEdit+ helps in the speci- APRIL 2008 | embedded systems design europe | www.embedded.com/europe 020-021-022-023_ESDE.indd 22 10/04/08 15:42:50 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - April 2008

Embedded Systems Design Europe - April 2008 Contents Chip Industry Confronts 'Software' Gap Wind River's VxWorks OS Part of the nEUROn UCAV Demonstrator iSuppli Cuts Electronic Equipment Forecast Study Says GigE Vision Not Mature Chip Aids Wireless Health Monitoring Kontron Reports Strong Financial Growth Xilinx Completes Virtex-5 Line-Up French Project Builds Open Platform Home Automation Group Uses Enocean Radio Layer MIPs Adds Multi-Core Option to Portfolio Cover Feature: Next Gen Programmable Chips: Why Can't Hardware Be More Like Software? Improving Productivity & Quality With Domain-Specific Modeling Efficient CRC Calculation With Minimal Memory Footprint Do-It-Yourself Linux Embedded Development Tools Hardware/Software Verification Enters the Atomic Age New Products Advertising Contacts

Embedded Systems Design Europe - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.