The main reason Together was originally created is the technology called, LiveSource™ . This is the ability to use programming language source code files to store the relevant parts of the UML model. Today, over a decade later, Together 2007 still supports LiveSource™ through its Java Modeling, C++ Modeling and IDL Modeling projects (see figure 1 below).
Figure 1: Together 2007 New Project Wizard
Until Together arrived in the mid 1990's, most high-end UML modelling tools boasted some form of round-trip engineering. This is the combination of generating programming language code constructs from the UML models (called forward engineering), and because this generated code was rarely complete, generating model content from code (called reverse engineering) so that models could be updated after develoeprs had made changes to the source code.
Round-trip engineering was promoted as the solution to the thorny problem of keeping the UML design models for a system, application, service, or component in step with the source code that implements it. Unfortunately, in most cases, even if the reverse-engineering step was performed frequently, there were always some kinds of changes that failed to merge back into the existing model, resulting in many reverse-engineering actions being no more productive than a manual update to the existing model.
LiveSource™ is different because it uses programming language source code as its model storage mechanism for the relevant model elements like classes and interfaces. This means when a developer edits a source code file they are effectively editing the model too. Any changes they make are reflected in the model because the source code is the persisted form of the model. Conversely, designers create and modify source code as a by product of modelling, linking them in a much more concrete way to the implementation of their designs. Figure 2 shows the diagram and source code view of the same operation, isWithdrawn(), in a Together 2007 Java Modeling Project. Changes made in either pane updates the other.
Figure 2: Together 2007 Java Modelling Project
LiveSource™ also means that Together can very easily display UML class diagrams for existing code because it considers any source code files to be model files. To 'reverse engineer', you simply point Together at the existing source code files.
Where a modelling concept cannot be expressed in the underlying programming language being used, Javadoc (documentation) style comment tags are used. In addition to keeping all the design information in a single place, this has additional side-benefits:
- Programmers do not have spend as much time referring to design documents because more of what they need is in the source code comments
- Higher-level design documents can be generated from source code so that design documents are more easily kept up to date..
- Comments in source code become more structured than normal Javadoc comments due to the use of additional tags.
Objections to LiveSource™
LiveSource™ is a different way of doing things. Those who have worked extensively with more traditional tools like Rational Rose often find the approach disconcerting at first.
The idea of always producing source code even when you are just sketching class diagrams is the first source of complaint. The answer here is a change in mindset to treat the source code file format produced as no different than the proprietary file format used by other modeling tools. There is nothing in the Together product that forces a user to compile the source code files used to store model elements.
The second complaint is the issue of having to select a particular programming language in which to model. The often claimed necessity of programming language independent modeling is in many cases a myth. In practice, few development teams get very far into a project without a good idea of which programming language they will be using. Where a switch in language is required at some point, Together’s XMI export and import features can be used to force a change in the underlying programming language.
A slightly more valid complaint is the restrictions imposed on class diagram features such as multiple inheritance when the underlying programming language, e.g. Java, does not fully support it. However, the validity of using constructs in modelling that are not supported by the language being used by the developers is highly debatable because it requires the developers to translate from the unsupported concept to a supported concept.
LiveSource™ provides the opportunity for analysts, designers and developers to work much closer together. This can lead to problems at first. Analysts and designers used to working in isolation from developers complain that by using Live LiveSource™, developers are making changes to their carefully crafted models and designs.
The actual issue here is changes to the design made by developers become undeniably visible to the designers and analysts. Without LiveSource™ these changes can go unnoticed leading to problems much later when it is realized that the implementation is completely out of step with the analysis and design models. The real problem here is one of change control and, as always, the solution is the disciplined application of version control systems and configuration management.
What is more problematic, is designers making changes to the model that prevents the source code from compiling. In a traditional development team where designers work separately from developers this can cause significant issues. Again many of these can be resolved through appropriate use of version control systems and configuration management. Alternatively, where more modern agile approaches to software development are being adopted, Together can help bridge the gap between analysts, designers and developers by encouraging them to work much more collaboratively.