12.3 The Tools

What are the consequences of applying the MDA on the software development tools? Again, looking at the difference between the traditional development process and the MDA development process, we find three groups of people who will need new or better tools, and one group who will not need any tools, because it will not be involved in the MDA process.

The last group is the group of code writers. When the MDA approach has matured, this group will not be needed anymore. Current code writing tools, like IDEs specific to a certain programming language, will cease to be relevant in the development process. The trend is already noticeable. Currently, many IDE vendors are progressing their environments to integrate a modeling tool as well. Figure 12-3 shows how in the future the functionality supporting activities concerning code will be less important. Instead, new functionality will be demanded on the high end of the software factory pipeline.

Figure 12-3. Functionality in a future MDA development environment


A new kind of IDE will be demanded by the transformation definition developers. They will need specialized environments to create, edit, and test their transformation definitions. Because the aim is to reuse transformation definitions, the group of transformation definition developers will not be very large. Therefore, it is likely that there will not be a large choice of transformation definition IDEs.

The group of PSM creators will work with transformation tools. The desired functionality for these tools will include the following:

  • The ability to choose between different implementation platforms

  • The flexibility to switch within one platform between different implementation strategies, application architectures, and coding patterns

  • Openness to plug-in multiple modeling languages, transformation definitions

  • Support for standard domain specific models or blue prints

  • Integration with other tools that automate software development and maintenance (code maintenance, version control, requirement management, workflow automation, testing tools, performance tuning tools, and so on)

Most likely the different tools used in the MDA process will need to interoperate or perhaps even integrate. For instance, a PSM creator may want to make a small change in the transformation definition he is using in order to produce a more efficient system. Another example is a transformation definition developer who needs to test his definition. How will he do that? The obvious choice is to use a transformation tool. Therefore, it is important that all tools operate in a standard way. Looking back at Figure 3-1 from Chapter 3, we can say that these tools must at least be able to use the same standard interchange format for models and transformation definitions.

The PIM analysts are the group that is served already. There is a large number of modeling tools available, most of which are able to read and write the standard interchange format for UML models. Still, the PIM analysts will need better modeling tools; tools that provide more support on checking the model and on the integration of the model parts . For example, the flow of information between the various UML diagrams should be supported. But most of all the PIM analyst needs better modeling languages.

MDA Explained. The Model Driven Architecture(c) Practice and Promise 2003
Project Leadership (The Project Management Essential Library)
EAN: 2147483647
Year: 2004
Pages: 118

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net