Waterfall versus incremental modeling Cycle


Three years ago, Omondo’s executive team made the decision to expand EclipseUML java code centric to an agile model driven tool.
Developing software in an environment where business processes are changing was one of the key challenges.
The new EclipseUML architecture based on native XMI (patented technology) allows better-faster-smarter and cheaper software delivery.
Traditional waterfall development methods do not connect business with IT, while the new agile modeling incrementally improve an organization’s performances. Many tools vendors are talking about iterative, incremental, agile etc....but no one has really successfully developed an advanced technology such as EclipseUML 2008 patented model merge using native incremental xmi synchronization technologies. Omondo is the leading new agile generation UML modeling tool:
In this section we will talk about :
  1. First iteration requirements
  2. Second iteration dilemma
1. First iteration requirements

This first level of iteration is covered by all good UML tools using standard GMF framework (e.g. R.., B....., Topcased, Papyrus, Eclipse Modeling Tools etc..).This is related to a Waterfall approach in which architects and modelers design the architecture and then give a blue print (e.g. documentation & generated code) to the integration team composed by developers.This waterfall approach is the traditional UML methodology used by all Eclipse tools generating XMI from the GMF framework. It allows modeling at a high level of abstraction with no code generation at this early stage, to use internal tool model then to map GEF to EMF inside the GMF framework and finally generate a standard XMI from the internal and graphical models. You can after the modeling stage generate your code using standard XMI transformation tools such as OpenArchitectware, Obeo, BlueAge, AndroMDA, ATL etc...
The architecture is as below:



This GMF framework using standard UML specification is a real improvement compared to proprietary UML solution and is totally integrated inside Eclipse.

2. Second iteration dilemma

This second iteration is used by either very advanced modeling projects which reuse generated code to remodel it and then generate code again or by agile, scrum projects. The first implementation stage of the requirements is based on the UML diagrams. It means that the developer team is coding inside the provided skeleton (e.g. package, class, interface, enum) by implementating business method rules. The current problem we are facing is that agile processes require the delivery of working code and the business user needs to quickly see if the manifestation of their “requirement” is really what meets their needs. Requirements are therefore flexible, not always defined at the first stage and depend on understanding the correlation with use cases. Usually after the first delivery the scope of the project is adapted in order to better fit the real needs.


Companies have now two choices. Either abandon UML modeling if a need arises for a second stage because it is impossible to merge XMI model with newly created java code once the project java code has been generated. Or use EclipseUML, immediately, or by migrating from R.., B....., Topcased, Eclipse Modeling to EclipseUML 2008 (see migration guide). Using a standard model (EMF, GMF, EclipseUML2) allows easy migration from one to another tool and recreation of your previous diagrams using dynamic navigation (see dynamic navigation tutorial). EclipseUML 2008 allows multiple iterations because of its incremental approach based on a patented new architecture using triple live model, UML Editor and java code synchronizations.
EclipseUML architecture is described below:


Conclusion

EclipseUML 2008 is more than just a "waterfall" UML tool because it is specially designed to:
  • reduce the cost of fixing bugs that make it too far downstream in the waterfall process
  • eliminate waste and rework
  • incrementally improve an organization’s performance and deliver tangible business value
  • reduce development costs
  • help an organization to adapt quickly and effectively
  • allow more predictable delivery schedules

© Omondo 2002-2008. All Rights Reserved.