20 Examples on Domain-Specific Modeling

Let’s look examples of
Domain-Specific Modeling. I have picked 20 different cases each targeting different application
domain and generating different kind of code. The languages are used for different purposes
too, such as application development which
is the biggest category here but also for architecture design, testing, verification and validation,
service design, configuration and so forth. The languages described are also used for different purpose and by different people. Not only by programmers and developers
but also by test engineer, service creators, interaction specialists, and so forth. The first case deals with modeling financial constructs so the modelers is here non-programmer: An insurance expert. Using this modeling language he specifies
insurance products and financial contracts and generates full code. The modeling language you see here shows the structure of the system:
structure of the product. Modeling concepts in this language deal
with insurance concepts such as accidents, risks, bonuses, payments, damages. In other words, the concepts that insurance experts already know. From these designs a full code is
generated. Generated code is Java but actually the insurance expert doesn’t want
to see the code or change the code but rather wants to see how the product is them generated into a web application. This language has been used to specify
hundreds of different kind of products and the company noticed that the process
of building these is now three to five stars faster than it was earlier when done manually. The second case goes perhaps to another
extreme: the domain of these languages is developing
voice menus into a 8-bit microcontroller. So engineers are using the language or actually languages, since in this case there are
two integrated modeling languages. At the general level where we have the main structures
defined and one of these loudspeaker symbols
then is describing in detailed voice menu structure. And then code generator produces
from here the Assembler code that is optimized to the memory and size
requirements of the microcontroller. And again, there is no need to modify the
generated code – so it is complete. As you can see, the language raises
the level of abstraction closer to the voice menu away from the implementation, so the engineerdon’t need to
think the solution in terms of Assembler but can use already the domain
concepts. Let’s stay for a while in embedded
software development and look cases of PLC software development, so generating
code for programmable logic controllers. So far we have had separate languages
for structural parts like the insurance and behavior parts like
the voice menus. Domain-specific language you can also integrate
these views as done in this case of heating system. We have here modeling language describing the
structure: different kind of instruments and
how pipes are connecting them and the language also checks the rules here and does’t allow me to make illegal
designs or checks that’s … for example that some sensors or valves are not connected properly. If then I click one of these heating
system elements like this burner, I can see more details of the behavior
side. Now some of the same concepts I was using
in the structure part are also available here when I’m describing the behavior. From here it then generates the PLC
code – state machine basically – that can be executed in the distributed
heating system. These languages con then be also other kind of PLC software, like here a domain-specific language for
building fish farm automation systems. So here you can see different kind of bonds,
wiring, and how it takes care of feeding of the fishes, lights heat checks, that the water is in a good condition and so forth. From this kind of models the company is generating
not only the code, but also wiring plans, installation guidelines, server
data and even the user interface. Let’s next move to languages that target user interfaces and their application. Domain-Specific Languages are not only useful
for building the system and generating the code but also for
concept design. Here is a case of automotive systems. Most modern systems nowadays in a cars have more than one
thousand menus. So automotive manufacturer designs them, can generate prototype from here, and then can give the system for a
third-party supplier to implement it, or the supplier can use the same language to finalize the system for a certain target. Similar user interface design and actually interaction design can happen in other domains too than in
automotive. For example, in a mobile phone area. In this case we actually have two different views for the
system design. So we have a very detailed level design view which shows things like
localization, icons and so forth but we can also choose here use view and then we get a more simpler view for the system that hide
some of the details. Still here we can generate the
code and also integrate to the localization. This example deals with mostly
targeting plain code generation as all the user interface elements are fixed in
this language. The developer can use in the
models the realistic user interface elements, add there the navigation
between the widgets and then also how the services of the phone, like making calls,
sending SMSs, are made and then again we can generate the code. Rather than having this kind of
generic platform language you can also have dedicated domain-specific
languages that targets certain application types like here point of sale systems. So abstraction can be raised further like
here in this particular language for example the concept of ‘L’ means login and authentication. So when this is added to the model the code generator adds a lot of
things here to the final product but the modeler does not need to specify all
the details – just want to have a login and authentication with certain parameters. And again here the code can be generated and executed. Final example of UI application I have
here is one targeting sports computers. Again here we have different kind of
displays, menus and navigation been modeled and code can be generated. Usually in devices like various kind of
embedded devices UI applications can often be half of the
code needed. Domain-Specific Languages are also used to
describe different kind of processes and services. For example, here I have a language that targets
document engineering and describes different kind of states and
actually parallel states: what’s going in the process and what is the state of the document. Languages can also be used to describe
various kind of services. Here I have a those dealing with
call processing. Service engineers at telecom operator are
specifying call processes using concepts they already know: proxies, locations, redirecting and so forth. From the specification an XML based configuration can be produced to be
executed. Service engineers don’t need to
know and write XML but can use alredy known concepts in
visual model and then generate the required code. Domain-specific modeling is also applied for
service creation and providing service creation environments. This example shows how
operators specify various services to their customers like location based telephony service for routing. But it could be also presence
based routing, region based routing, time base routing and so forth. One key characteristic of a good domain-
specific language is that it mimics closely to the domain it addresses and then the domain should immediately look and be visible in the notation. This example shows a domain-specific language
for specifying interlocking of a railway systems. So the modeling concepts here deal with
tracks between line segments, controlling lights and so forth. Here we can then generate
interlocking code. The visualization can be also used
for other kind of important information. Like in this language targeting
configuration of a real-time operating system. We show clearly in diagram in which priorities different tasks may have. The language here uses concepts like
functions, timers, interrupts as main modeling constructs and then generates the configuration data. Let’s move next to testing. Web application modeling language here
is a languages that is used for testing web
applications. Now the language users is
test engineer. Test engineer can specify test cases using
already familiar domain concepts: pages, navigation between them, page contents, data available and so forth. The generators are used to
translate this model into test cases and in particular case here this model is translated to be used in a testing tool. Domain that testing targets can also be other than
web applications. It can also be very dedicated, like in this example testing
military voice-over-IP telephony and their networking. Here we have two different kind of test
models. Left one describes a single test case like device one makes a point-to-point
call to device three and after two seconds ends the call. The model here on the right describes test logic. So it doesn’t say which devices is
used but generator applies random logic so it goes through all the devices in the test and generates multiple test cases
from a single test logic. Designs made with a domain-specific modeling
languages can also be verified with defect analysis tools. In this
example domain-specific language is used for describing flow control and the data
is generated to testing environment, TVEC, in this example,
which analysis the models and then generates test vectors for every
logic path. The generated test suites are then run for
verification. Let’s move next to the architecture design and
automation domain. We have here an architecture design with
different type of components and their communication. For example, the communication
cam be input-output flow, client-server messaging, or power based. This architecture can then be also detailed
into lower level languages and can also be used to generate not only code but also other kind of models like here Simulink
which is applied in automotive. If we stay in automotive, the following language targets both functionality and hardware architectures and enables their co-design. Here you can actually see two different kind of
languages, one addressing the functionality and then another one describing the hardware
architecture. So there are usually different kind of people doing these. Rather than keeping the models
disconnected this domain-specific languages allows specifying mapping between
functions and hardware elements, like sensors, actuators power supplies, and other devices like ECUs (Electronic Control Unit) and here the mapping is provided as a matrix. It uses the same elements you see here in the diagrams and allows to trace between these design models. A bit different case of
allocation is the one dealing with printers and their data path
architectures. Here we have two languages, one language describes the steps that we took, and then we have also another language for
describing hardware architecture – alternative hardware architectures
which you can see here these boxes. If I click one box, I can
see one possible hardware architecture and also showing some of the
allocations. I can easily then choose between different allocations.
If I pick this one, this model becomes annotated so I can see where each step has been allocated. This information can then be generated by combining the allocation data and put it to some performance
analysis tool or other kind of simulation
or analysis tool. All these examples show the idea of
Domain-Specific Modeling: You create the model at a high-level
of abstraction and then generate different kind of artifacts. This works because the languages need to fit only a narrow area of interest. The modeling language is domain-specific, it operates at a higher level, does not
visualize the code and uses the concepts people are already familiar with. Also the code generators
are domain-specific, so they always generate full efficient
code. There is no need to change the code afterwards,
and no round-tripping or or isolation of the code and model problems. This works because if you find out
that your generated code is not efficient, you can change the generator. Thank you for watching this video on 20 different
cases of Domain-Specific Modeling. For more examples, case studies,
analyst reports, user testimonials, please visit Thank you for watching.

Leave a Reply

Your email address will not be published. Required fields are marked *