The Middleware Research era una compañia dedicada, entre otras cosas, a la investigación y evaluación de software. Para el 2004, todavía aparecía como parte de The Server Side, pero hoy, siguiendo el enlace de su artículo, lo que se encuentra es esto:
As of November, 2004, The Middleware Company and its Middleware Research business unit have been discontinued. TheServerSide.com, TheServerSide.NET and related conferences are continuing operation as part of the TechTarget network. The Torpedo O/R benchmark has been moved to: http://www.torpedo-group.org, and the SOA Blueprints initiative now lives at: http://www.soacenter.com
Para quien le interese, todavía puede encontrar materiales disponibles en sus nuevos alojamientos. En el caso del informe de productividad de MDA, luego de varios intentos, lo localicé en el sitio de Compuware. Compuware, que también sufrió cambios desde 2004, no lo menciona como un papel destacado, quizá porque no cuadre enteramente con su producto -OptimaJ- al día de hoy.
Cuá era el propósito del estudio:
In the spring of 2003 The Middleware Company performed and published a study testing whether development tools taking a Model-Driven Architecture (MDA) approach increased the productivity of developers building a new J2EE application. That study found that MDA increased productivity 35% over a traditional, code-centric approach.La herramienta medida fue OptimalJ, pero puedo asegurar que el esquema es válido con la mayor parte de los productos de su tipo, y allí reside el interés del estudio. El punto clave del estudio es su extensión al período de mantenimiento. Es aquí donde las ventajas de utilizar un esquema de desarrollo basado en modelado abstracto con generación automática de los resultados, se torna crecientemente productivo, tanto más cuanto más se expande el desarrollo en tamaño y tiempo. La condición es que la descripción del problema esté hecha en el nivel abstracto, y que existan herramientas que traduzcan en cada momento el modelo a código ejecutable.
This study extends the examination to the realm of application maintenance. Two teams performed a set of typical and diverse enhancements to an existing application. One used an MDA -based tool, while the other team used a code-centric approach with a traditional enterprise-caliber integrated development environment (IDE).
The team taking the MDA approach completed the five enhancements 37% faster than the traditional team, in 165 hours versus 260. These results are well in line with those of the first study. As a result of this case study, The Middleware Company reinforces its recommendation that development shops interested in increasing their productivity evaluate MDA -based development tools for use in their projects.
(...)
This whitepaper compares the productivity of two development teams maintaining and upgrading an identical J2EE application. One team used a Model-Driven Architecture (MDA) approach to J2EE development. The other team used a traditional, code-centric development approach. The original application was a version of the familiar J2EE PetStore application, defined by a rigorous functional specification. The upgrades, which represented a range of typical enhancements, were defined by another rigorous specification. Both specs were reviewed by industry experts.
Qué se comparaba:
(...) the basis for the specification used in this study is the well known PetStoreLa comparación desde el punto de vista de la arquitectura:
application4, a simple web-based J2EE e-commerce application. The baseline PetStore has the following functionality:
o User management and security. Users can sign into the system and manage their account.
o A Product catalog. Users can browse a catalog of pets on the web site (such as birds, fish or reptiles).
o Shopping cart functionality. Users can add pets to their shopping cart and manage their shopping cart in the usual ways.
o Order functionality. Users can place an order for the contents of their shopping carts.
o Web services. Users can query orders via a web service. We extended the PetStore to include this, since web services are an emerging area of interest.
From a technology perspective, the PetStore includes the following:
o A thin client HTML UI layer
o JSPs to generate HTML on the server
o JDBC SQL-based data access
o EJB middle tier components
o Ad-hoc database searching
o Database transactions
o Data caching
o User/Web session management
o Web Services
o Forms -based authentication
Our Maintainability Specification describes requirements for five major enhancements to the baseline application. Each focuses on a different combination of additions or changes, from new user features to business logic changes to integration with other applications.
The teams in this study implemented all of these enhancements :
1. Tracking pet maturation
2. Calculating shipping costs
3. Soliciting supplier bids for new inventory
4. Integrating with Amazon.com via its web service
5. Integrating with a mainframe application to track shipments
Since the development work performed in this study built on that of the original one, many of the critical design choices were already in place. As the previous study describes in detail, both teams used J2EE design patterns extensively in their original work. On the MDA side, these patterns resulted from the implementation templates that translate the Platform-Specific Model (PSM) into code. The MDA tool automatically generated high-quality pattern code from the model. On the traditional side, the patterns stemmed from deliberate design choices and (for the most part) explicit coding. In fact, the previous study found that the traditional team actually used several more patterns than the MDA team.La integración de código heredado:
Some of the design patterns used by both sides in the original application include:
o Session Façade
o Business Delegate
o Data Transfer Object (DTO)
o Model-View-Controller (MVC)
Additionally, the traditional team used these patterns in its original coding:
o Service Locator
o Data Access Objects (DAO)
o JDBC for Reading
In the current round, both teams expanded their use of patterns. On the MDA side, the newer version of OptimalJ incorporated patterns that the previous study’s version did not, particularly Service Locator and DAO. Since these additions resulted from changes to the implementation patterns, they stem from the MDA approach rather than this particular MDA tool. In fact the MDA team in the previous round could have added those patterns had they edited the templates themselves. On the other side, the traditional team used the EJB Command pattern in the legacy integration enhancement. All in all, in this round both teams used approximately the same set of design patterns.
In terms of overall design quality, the code produced this time compared favorably with that of the previous round. For new work that extended previous functionality, the two teams adhered to the same basic designs. The MDA models generated new code that was architecturally equivalent to the existing code.
And the traditional team continued their deliberate use of appropriate design patterns.
In terms of work that was substantially new – such as JMS, web service or legacy integration – the MDA approach continued to help keep architectural quality high. Two examples:
o When a web service or JCA integration was added to the model, the model generated not only the basic client stub classes, but also a stateless session bean and business façade wrapper to the stub.
o For writing a JMS producer, the MDA approach made it very easy to define a message data structure and tie it to the message-producing component, thus minimizing the amount of custom business logic actually required.
On the traditional side, the team had to consciously design and build the wrapper code for the various integration components . They did so with a level of quality comparable to that of the original application.
El equipo tradicional:
Receiving the stub classes for talking to the CICS application simplified the team’s task enormously. Without them, the team would have had to write that code by hand; lacking experience in COBOL programming or CICS connectivity, they undoubtedly would have found this experience arduous, time consuming and frustrating.El equipo MDA:
One problem hindering productivity had to do with the distribution of classes for deployment. Using a JCA adapter and accompanying RAR file encouraged the use of an EAR file for deployment. This caused several slowdowns as the team discovered that all non-EJB classes needed to be placed in a separate JAR
file from the EJB JAR and the WAR file so that they could be safely shared and correctly loaded by the class loader. This took considerable time to detect as crucial and then configure, however once accomplished, the deployment of changes was much swifter
Connecting to a mainframe application through a JCA adapter proved remarkably easy. The teams were given an adapter for CICS applications and a piece of COBOL code containing the required record structure, as well as basic information about the target application and some rudimentary documentation.En suma:
After the JCA adapter was installed (a simple process), setting up the JCA client was much like defining a web service client:
o OptimalJ parsed the COBOL file much like a WSDL document to create the correct data structure (a custom DTO). This process also created the appropriated elements in the integration tier of the application model.
o The team had the product create corresponding data structures in the domain and application models.
o Generating the code model (EJB and web code) from the application model was straightforward.
o The default application again proved handy for testing.
Overall, the process was extremely quick and did not require any knowledge of COBOL.
The challenge in this enhancement was much like the previous one: very little change to the data structures, some UI work, some business logic, but mostly integration. And the result was a comparably large difference between the two teams. Here the challenge centered almost exclusively on using JCA to send a query to a CICS application and get a result. The MDA team was able to add the JCA integration to their MDA model in almost exactly the same way as for a web service. This meant they could auto-generate the stub code without having to know anything about COBOL. And, as with the web services, they also auto-generated wrapper components. The entire effort was remarkably easy.La comparación desde el punto de vista cuantitativo:
The traditional team, by contrast, did not have the benefit of a wizard to generate their stub code, so to keep the study’s focus on the differing approaches the team was given those classes . The remainder of their work centered on installing the JCA adapter and integrating the provided code into the application.
To complete all five PetStore enhancements took the MDA team 164.8 hours of development time, compared with 260.5 hours for the traditional team. This comes to a 37% improvement in productivity for the team using MDA.La comparación es particularmente interesante al bajar al trabajo diario de los dos equipos, enfocando las tareas y tomando decisiones. Quizá en su análisis detallado se encuentre el material de mayor interés, y la motivación para estudiarlo. Invito a hacerlo.
This result is well in line with those of the previous study, which found a 35% productivity improvement for the MDA approach in building the PetStore application to the original baseline specification. The new result indicates that the MDA approach can offer similar productivity gains with respect to maintaining /
enhancing an existing application.
No hay comentarios.:
Publicar un comentario