User Manual    [Previous]   [Next]   

Convincing Potential Adopters

Convincing yourself, your development team or your management to use Model-Oriented Programming with Umple

Here are some arguments to make to help convince you, your management and your colleagues to adopt model-oriented programming and Umple in particular:

1. Model-code duality: Umple means you no longer have to maintain models separately from the code. Your code and model become the same thing. Your models therefore don't get out of date and your volume of separately-maintained documentation becomes less. Model elements in the Umple code, along with their comments, become the design documentation.


2. Rapid application development: Models containing the essential structure of a system can be developed extremely fast, and modified extremely rapidly. This is because most people can edit Umple text faster than they can use a drawing tool. But the ability to use a drawing tool is not sacrificed, as you can still draw an Umple model as a diagram with UmpleOnline!


3. Less code to write: Code for UML constructs like associations, state machines and certain patterns is generated. Less code means fewer bugs. Developers can concentrate on the more interesting or critical parts of their code.


4. Fewer bugs: It is extremely difficult to consistently write bug-free code for complex constructs like state machines, or associations that maintain referential integrity and respect multiplicity constraints. Umple does this for you.


5. The full power of UML features: Unlike Umple, most other code generators do not generate code that enforces multiplicity in class diagrams, or allows unlimited levels of nesting of state machines. Umple has incorporated the research of several PhD and masters theses to deliver state-of-the-art code generation.


6. Text-diagram duality: Umple allows visualization of key aspects of your code with UmpleOnline. Furthermore the diagram can be edited to change the code, or the code can be edited to change the diagram. Both of these occur in real time.


7. Product-line and feature-oriented development: Umple brings mixin technology to Java and PhP, allowing you to easily build different versions of your software for different customers or hardware platforms. Umple code can also be organized on a feature-by-feature basis.


8. Aspect orientation to adapt generated code: You can inject your own code before and after any generated methods to enforce constraints or change semantics.


9. Generation for multiple languages: Umple allows development targeted to several different programming languages at the same time: All the developer has to do is to maintain language-independent files for the models, and link them to language-specific code for algorithms.


10. Incremental adoption: You can start with just one Umple statement in a million lines of code and gradually increase Umple usage. Your software will remain fully compilable and functional as you gradually increase your uptake of Umple.


11. Use just like a pre-processor: Programmers have been confidently using pre-processors for half a century.


12. Fully open source with a liberal license: If you don't like something about Umple you can fix it, and contribute to the community. Because it uses an MIT-style license, there are no restrictions on your use of Umple or its generated code.


13. Commitment to the future: The team at the University of Ottawa developing Umple plan to continue active development for the years to come. This will not become one of those research programs that comes to an end and is then abandoned. We recognize that ideas can take decades to percolate to the community. We plan to be right there supporting Umple as this happens.

Countering the counterarguments

Here are some common arguments against adopting a new software development technology, and how they don't apply in model-oriented programming:

1. Complexity: Adding a new technology might add more complexity to our project so might require more learning by our employees and might make our systems harder to understand:
   Not true for Umple, because:
   • Umple is just a set of small extensions to well-known languages like Java, PhP, Ruby and (coming soon) C++.
   • Umple acts just like a preprocessor: traditional code is still there either embedded in the Umple, or with Umple embedded in the traditional code.
   • Umple can be used incrementally. You can use just a few pieces of it here and there to gain substantial advantages.
   • There is an easy-to-access user manual, with examples for all constructs and messages.
   • Umple will save a lot of coding and maintenance of boilerplate code, code for patterns, and code for constructs such as state machines.
   • Studies have shown that code using Umple is actually easier to understand than traditional code, and people learn to be better modelers when using Umple. See here for a list of peer-reviewed publications.
   • Umple is deliberately simpler than UML and other modeling technologies.


2. Confidence: Our company would have no way to be confident about whether it works or not and we do not have the time or resources to do the needed due diligence:
   Not true for Umple, because:
   • You can adopt Umple in extremely small increments and increase your use of it as you gain confidence.
   • If you encounter a problem with a particular use of Umple you can easily avoid that case since Umple can be blended in any combination with traditional code.
   • When using Umple a large amount of your code will be generated using templates that have been extensively tested; this saves both coding and testing time.
   • Umple is developed using test-driven development at several levels. There are a large number of tests that are run during every build covering all the important use cases. If you encounter a problem we can fix the problem (or you can) and then we can add your case to the test suite to ensure it does not recur.
   • Large systems have been built using Umple, including the Umple compiler itself. Since Umple compiles itself any bugs are rapidly detected.
   • The developers of Umple use Umple in their daily development. This is not typically true of other modelling tools.


3. Support: If the technology stopped being supported, we would not be able to maintain our code base.
   Not true for Umple, because:
   • You will always have access to the generated code base. Even if Umple vanished, you would have access to the code that had been generated.
   • The generated code is designed to be easily understandable, even though it is not intended to be edited and does not need to be read in normal development situations.
   • Umple is open source, so you would always have access to it.


4. Process: Our testing and building processes are likely to only work for well-known technologies:
   Not true for Umple, because:
   • The Umple compiler works just like compilers of other languages and is tested and built in the same manner.


5. Compatibility: We use a lot of re-used, proprietary or legacy code that might be incompatible with the new technology:
   Not true for Umple, because:
   • Umple can work with any existing libraries in Java, PHP, Ruby etc. You can subclass existing classes even if you can"t see the source; you can write arbitrary code to call APIs of existing libraries, or you can convert existing code to Umple if you wish.
   • Umple is particularly good at helping incrementally re-engineer (i.e. umplifiy) legacy code: You can convert your legacy code little-by-little. But you also have the option to leave it unchanged and just use Umple for extensions or new code.