Большинство разработчиков понимают производительность как создание максимально быстрого кода, потому что это их ежедневный опыт, возникающий из-за управления и давления со стороны клиентов. Поэтому многие разработчики считают, что UML-моделирование не сильно повысит их производительность. Они не совсем ошибаются: рисование диаграммы классов и заполнение атрибутов и сигнатур операций не быстрее, чем ввод той же информации в скелет класса. Рассмотрите модель на рисунке 1 и соответствующий ей код Java, и вы увидите, что нет свидетельств повышения производительности, особенно если разработчик Java уже использует IDE, такую как Eclipse .
Рисунок 1 — Самая простая модель класса в UML
package customerManagement;
import com.modeliosoft.modelio.javadesigner.annotations.objid;
public class Customer {
}
Модуль Java-дизайнера Modelio может создавать более сложный код в зависимости от модели. Например, ассоциации, как показано на рисунке 2, и полезный дополнительный код Java, такой как методы получения и установки, запрошенные для ассоциации:
Рисунок 2 — Ассоциация между двумя классами
package customerManagement;
import java.util.ArrayList;
import java.util.List;
import com.modeliosoft.modelio.javadesigner.annotations.objid;
public class Customer {
public List<Order> order = new ArrayList<Order> ();
public List<Order> getOrder() {
// programmers code to be entered
return this.order;
}
public void setOrder(final List<Order> value) {
// programmers code to be entered
this.order = value;
}
}
Однако даже с приведенным выше примером можно утверждать, что любая продвинутая IDE (например, Eclipse) может генерировать такие методы получения и установки. Так почему же разработчик должен беспокоиться о создании модели и использовании моделировщика, если простая IDE может выполнять такую автоматизацию?
Ценность подхода к моделированию можно увидеть, когда предыдущий пример расширен во времени. Представьте себе, что после нескольких итераций кода конец ассоциации перетаскивается в другой класс или что имя целевого класса изменяется (рисунок 3). Код, сгенерированный IDE, теперь устарел и будет оставаться таковым до тех пор, пока разработчик не запросит IDE повторно сгенерировать новые методы доступа для того, что кажется новым атрибутом в классе. Разработчик также должен будет очистить код, удалив устаревшие средства доступа, так как это не делается в среде IDE. Теперь разработчик быстро поймет, что автоматизация, обеспечиваемая IDE, на самом деле была всего лишь одним выстрелом.
Когда разработчик использует моделер, обновленный код обновляется соответствующим образом. Нет риска что-либо забыть, нет ошибок и нет проблем.
Рисунок 3 — Место назначения ассоциации было изменено (команда)
package customerManagement;
import java.util.ArrayList;
import java.util.List;
import com.modeliosoft.modelio.javadesigner.annotations.objid;
public class Customer {
public List<Command> command = new ArrayList<Command> ();
public List<Command> getCommand() {
// programmers code to be entered
return this.command;
}
public void setCommand(final List<Command> value) {
// programmers code to be entered
this.command = value;
}
}
Этот небольшой пример показывает, что производительность следует рассматривать не только для начального варианта использования «первого запуска», но и для реальных рабочих ситуаций с частыми изменениями в коде. Как известно любому разработчику, обновлять код с постепенными изменениями, безусловно, гораздо труднее, чем изначально. Однако на практике эти изменения происходят в каждом дереве кода, которое имеет большое количество классов. Без надлежащего инструмента моделирования трудно убедиться, что все синхронизировано и правильно обновлено.
В целом, написание кода — это небольшая часть (не более 30%) усилий по разработке программного обеспечения, которая включает в себя задачи анализа, проектирования, тестирования и проверки. И эти усилия по разработке сами по себе являются лишь частью глобальных усилий по обслуживанию, которые часто оцениваются в 15% от первоначальных усилий по разработке в год. Эти цифры необходимо учитывать для хорошо спроектированного программного обеспечения; ситуация явно хуже для плохо спроектированного программного обеспечения.
Сила моделирования абстракции
UML-моделирование дает свои лучшие преимущества на этапах анализа и проектирования.
Коммуникационная поддержка
Анализ, варианты использования, глобальная архитектура и шаблоны хорошо поддерживаются UML. Модели предоставляют обзор проблем и позволяют общаться между аналитиками, дизайнерами, разработчиками и любыми другими заинтересованными сторонами (на его уровне интересов). Модели также предоставляют дополнительную семантику, которой нет в языках программирования. Ассоциации, в качестве небольшого примера, несут семантику, которая теряется в коде Java, такую как количество элементов, композиция (если есть), связанные ограничения, информация о противоположном (не ориентированном) конце ассоциации и многое другое. Вы можете понять архитектуру, взглянув на изображение (диаграмму класса или пакета) на уровне UML, в то время как вам может потребоваться изучить тысячи строк кода, чтобы получить ту же информацию из кода Java.
абстракция
Используя возможности абстракции моделей, один класс UML может предложить гораздо более плотную информацию, чем класс Java. Например, давайте рассмотрим концептуальную модель объектов, управляемых приложением. Такая модель будет иметь высокую ценность для аналитиков, дизайнеров и разработчиков, обеспечивая общее понимание основных концепций приложения. Кроме того, в зависимости от технических решений и ограничений проекта, таких как хранение в реляционной базе данных, наличие графического интерфейса пользователя, применение к нему нескольких шаблонов, специфичных для фреймворка (например, J2EE, Spring, …), один класс UML модель может быть переведена в большое количество классов Java.
Уменьшение сложности
На практике преимущества использования моделей возрастают с увеличением размера и сложности программного обеспечения. Разработка программного продукта, содержащего 100 классов, не всегда является большой проблемой, но разработка приложения, использующего 10 000 классов, требует согласованной архитектуры и дизайна программного обеспечения на протяжении всего цикла разработки.
Архитектура является ключевым фактором качества для Java-кода. Разработчики знают, что хорошо спроектированные приложения легко программировать; для каждого изменения в функциональности существует не более одного места, где код должен быть изменен, и этот эффект виден во всем приложении. Моделирование помогает разработчикам сосредоточиться на общей картине и определить архитектуру, которая не связана с низкоуровневым кодом. Модели могут быть использованы для освоения архитектуры, для развития и для облегчения эволюции и изменений. Конечно, эти модели всегда должны быть синхронизированы, чтобы оставаться полезными.
Обслуживание
Следование модельно-ориентированному подходу помогает бороться с синдромом «разрушения архитектуры»: разработчики, выполняющие обновления обслуживания, часто являются не разработчиками, которые изначально занимались разработкой приложений, и не архитекторами, которые проектировали систему. Если они слишком быстро погружаются в код, они могут «перехватывать» код с места на место, чтобы исправлять ошибки или вносить изменения и исключения в принципы архитектуры, постепенно нарушая всю архитектуру приложения. Начиная с модели дает им глобальное представление и помогает предотвратить это возникновение.
Лучшие практики
Модель также может быть руководством для менее опытных разработчиков. Даже когда он используется в качестве средства рисования, он предлагает разработчикам подумать, прежде чем действовать, и определить модель, прежде чем погрузиться в программирование. Кроме того, диаграммы моделей могут быть частичными и показывать только определенные элементы, сохраняя конкретную концепцию или конструкторскую точку в стороне от других второстепенных задач. Эта способность фокусироваться на конкретных аспектах помогает разработчикам лучше понимать дизайн, а инструменты генерации кода предоставляют им среду, помогающую создавать совместимый со стандартами код.
Modelio Technologies для синхронизации модели / кода
To gain these benefits, code/model consistency is key. None of these benefits are possible if there isn’t a smooth and robust code/model synchronization process in the modeling tool. If Java developers find that they have to do the job twice — at the model level and the code level — and also have to manually make sure that both levels are in sync, they will leave aside the modeling work, and go right to the code with their favorite IDE. At best, there will remain an obsolete and dusty initial model that reflects only the initial design intention and nothing else.
That’s where Modelio comes in.
Modelio is based on the architecture of Objecteering, a modeling tool that’s been at the cutting edge of innovation and model-driven development for 20 years. Objecteering was initially very well known for its model driven development with C++ since 1991 and Java since 1996. Modelio has recently been released under an open source license. Licensed under the GPL v2, Modelio offers a complete open source modeling product, with support for both the UML and BPMN standards.
In addition, the new open source Modelio project has been given a modular architecture, with the key APIs (in Java) licensed under the more permissive Apache 2.0 open source license. This allows individual developers, communities and partner companies to develop both open source and proprietary add-on modules, providing new specialist functionality to the core product.
Modelio provides a roundtrip mechanism that minimizes the consistency maintenance effort by providing a close integration with the IDE (Eclipse) and by allowing changes in the code within operations (algorithms) or within structure definitions (classes, attributes, generalizations, …). Modelio keeps the abstraction level unchanged: the model is not rebuilt from the code, but updated by code changes. For example, associations are maintained even after a roundtrip session.
Let’s take a closer look at how Modelio manages code/model synchronization.
Three Levels of Modeling
Depending on the phase of the development cycle (analysis, design, or detailed design/coding), the model parts implemented are not identical.
- During the analysis phase, models are used to build the application’s dictionary, define its requirements, realize use cases, construct design models and use all of UML’s modeling capacities. Model construction and documentation generation are the main results of this phase.
- The design phase focuses on realization, by building productive models that concentrate on main architectural themes and essential system classes. Designers are encouraged by the fact that their models will have an immediate translation into Java code in the programming phase.
- The coding/detailed design phase completes the general design model in «round-trip» mode, by using the features of the Eclipse/Java environment and by permanently synchronizing the model.
Model-Driven and Round-Trip Code Generation
Figure 4 shows Modelio with one UML window in sync with one Java window. Most frequently, developers capture their Java code under Eclipse.
The model-driven approach must balance the advantages and disadvantages of model orientation or code orientation. Modeling everything before coding can be excessive in the case of small technical Java classes; however, a code-centric approach can result in the production of huge amounts of often badly constructed code.
For example, Eclipse is a great tool for productivity, with code «refactoring» features and handy completion mechanisms. However, completion (for example, when Java methods are called) transgresses all design rules, such as encapsulation principles, architectural layering or the avoidance of mutual dependencies, quickly resulting in a large amount of badly structured code.
Modelio enables users to choose between two model/code synchronization approaches: model-driven, or round-trip. In both cases, the same Java workspace is shared between Modelio and Eclipse. Figure 5 illustrates the differences in the generated code.
Model-Driven Generation
Under this approach, the model is developed and then the code is generated, with authorization to write method code only between markers in the Java code. Modelio is therefore in charge, with Eclipse being used to complete the skeleton of produced code. In theory, this is the recommended mode, since it guarantees that model-level design is respected. Below, we see the comments marking up the beginning and the end of code that can be changed by the programmer (procedural code).
public Product order(final String orderedProduct) {
//begin of modifiable zone(JavaCode)......C/3a0ca6e8-f99c-11e0-ad97-58946b108de1
...you can enter your application code between the markers
//end of modifiable zone(JavaCode)........E/3a0ca6e8-f99c-11e0-ad97-58946b108de1
//begin of modifiable zone(JavaReturned)..C/3a0ca6e8-f99c-11e0-ad97-58946b108de1
//end of modifiable zone(JavaReturned)....E/3a0ca6e8-f99c-11e0-ad97-58946b108de1
}
Обратите внимание, что в режиме на основе модели от разработчика не требуется вводить какой-либо дополнительный код за пределы маркеров, т. Е. Он или она не может добавлять какие-либо определения атрибутов или методов, импорт или классы, а также он или она не может изменять любую существующую сигнатуру метода. Это делает модельно-ориентированный подход очень безопасным, но ограниченным режимом.
Если этот режим хорошо адаптирован к этапам проектирования, когда код еще не является основной проблемой, он также полезен на этапах обслуживания, поскольку он гарантирует, что изменения в коде не приведут к нежелательным последствиям проектирования. Однако этот режим обычно слишком ограничен для фаз разработки, где требуется некоторая гибкость из-за многочисленных действий по рефакторингу, которые обычно происходят во время таких фаз.
Поколение туда и обратно
Under this approach, the code can be freely altered, and Modelio resynchronizes the model with the code by reversing it. In this case, Eclipse is in charge, with Modelio adapting the model to the code (Java reverse). This mode is popular among developers, since they are free to take full advantage of the Eclipse/Java power. We see below from the code that only one marker is generated to retrieve the operation by its identifier.
@objid ("3a0ca6e8-f99c-11e0-ad97-58946b108de1")
public Product order(final String orderedProduct) {
}
The round trip mode is obviously more flexible than the model-driven one. However, as more freedom is granted to developers, special care must be taken to ensure that the overall design is not damaged by ad-hoc modifications. In such situations, model reviews after reverse are important and worth considering.
Modes and Development Phases
The strict «model-driven» mode is typically used during the design phase. The design phase does not go into detail concerning highly specific Java classes, such as in the case of GUI construction. For example, an «ActionListener» class will not be modeled. The GUI is simply built using Eclipse features, possibly using specific complementary tools. However, the main dialog classes are modeled and then generated, along with the generic GUI classes, and the rest is carried out in Eclipse and then reversed in Modelio (using the «Update from source» command). However, the implementation phase uses the «round-trip» mode, which is more flexible for the programmer, while keeping design classes in model-driven mode.
Developers need to understand the benefits that they get from using modeling techniques. Using Modelio and UML to help with Java development still leaves all responsibilities to the developers. In the «round-trip» mode, they have the freedom to change any piece of code they want, but they have to know the model and respect the design intention, in order not to provoke any architectural decay. Giving developers responsibility is indeed the best way of getting them on board. In practice, developers using Modelio for Java development generally have two screens linked to their workstation : one screen is dedicated to development (Eclipse-Java), while the other is used for modeling (Modelio).
Other Useful Features
ANT File Generation
Modelio Java Designer also generates ANT files, compiles and produces executable code for Java, based on models similar to Figure 6. That is useful for complex applications where an application/packages mapping has to be modeled in order to produce the targeted binaries. The production scheme is thus modeled, and that simply drives the generation code.
Pattern Automation
Design Patterns can be modeled within Modelio, just by defining models and pattern parameters (Figure 7). Then, the pattern application will create instance models according to actual parameters and produce the corresponding Java code through the generation process. This automates systematic pattern development, a frequent task when using frameworks or libraries.
Profiles
Modelio can be extended by defining profiles. A profile helps to map a model to a specific target or framework. As an example, stereotypes defined in a profile can be used to specify that a class is «persistent», that an attribute is an «identifier», and so on.
Open API and Metamodel
Modelio provides a rich Java API and an open metamodel, that allows automation of any additional code generation or model exploitation tasks. Advanced examples such as generating code from state machines or mapping to frameworks can use this capability.
Community Modules
Modelio.org provides «modules» (Modelio packaged extensions) for different automation targets, such as Hybernate mapping. Due to Modelio’s Open Source nature, programmers can build their own modules for any modeling automation or code generation tasksand combine them with the existing Java module.
Conclusion
Productivity is more than generating lots of lines of code from a simple model. It can only be measured at the scale of a team working on a project during the entire development cycle.
A modeling tool is not a silver bullet: if you use a bulldozer without being able to drive it properly, you’re likely to end up doing more damage than good. But there are genuine advantages of following a model-driven development approach and they make it worthwhile to put in the effort and set up a proper model development approach within a team.
There is certainly a resistance to change that prevents developers from using a model driven approach. Expensive modeling tools that may not smoothly maintain code/model consistency throughout the development phase are a strong hurdle. Now, with Modelio Java Designer becoming open source, it is easier to improve development productivity and quality through model based tooling.
Useful Links
- The Modelio open source community, where Modelio can be downloaded.
- The original author of Modelio commercial solutions.
- The Modelio Store, where Modelio modules (extensions) such as «Java Designer» can be downloaded.
- Java language specification.
- Model driven technologies and standards.