Предлагаю обсудить проблемы, возникающие при использовании PHP5 совместно с Enterprise Architect, а также возможные способы их решения.
Ниже постарался перечислить все обнаруженные мной баги и недостатки.
Некоторые из них уже озвучивались в других темах, они были включены в общий список.
Тестировалось на Win XP SP 3, EA Version 7.5.844, использовались стандартные диаграммы (язык заменялся на PHP 5).
1. Диаграмма классов: нет возможности показать значения параметров по умолчанию в методах.подробнеевариант исправления2. Кривая поддержка «Heredoc» синтаксисаПри попытке импортировать следующий файл:
<?php
$value = 'test';
$heredoc = <<<TEXT1
Text Text Text Text Text Text Text Text Text Text Text
TEXT1;
class Test {
public function __construct () {
$heredoc = <<<TEXT
Text Text Text Text Text Text Text Text Text Text Text
TEXT;
}
}
?>получаем:
В тоже время «Heredoc» прекрасно обрабатывается, если находиться внутри метода (т.е. если удалить
$heredoc = <<<TEXT1 ошибки не будет).
Кроме этого на официальном сайте наткнулся на
PHP Import, очень похоже что синтаксический анализ PHP реализован не полностью.
3. Нет поддержки типов (основная проблема)На данный момент полностью отсутствует понятие типов, вместо этого определен «левый» тип
var который используется для всего.
Такой подход в корне неверен, PHP определяет следующие
типы данных:
boolean,
integer,
float (floating-point number, aka
double),
string,
array,
object,
resource,
NULL,
mixed,
number,
callback.
Отсутствие типов порождает как минимум четыре проблемы:
3.1. Перечисленные типы приходиться добавлять для каждого проекта заново, а это неудобно и отнимает время. Можно использовать «Tools | Export Reference Data» («Tools | Import Reference Data»), но хотелось бы чтобы и этого не приходилось делать.
3.2. После ручного добавления типов и генерации кода получаем синтаксические ошибки. Вызвано это тем, что при генерации не учитывается тип параметров, в результате на выходе получаем:
public function test(boolean $a = true)
{
}На самом деле в качестве типа допустимо указывать ТОЛЬКО
array и название класса3.3. Неудобства при синхронизации модели с кодом
Предположим, что есть следующая диаграмма классов:
Выполняем генерацию класса
Class1 (выделяем класс и жмем «F11»):
.....
/**
*
* @param a
*/
public function test(boolean $a = true)
{
}
.....исправляем
.....
/**
*
* @param a
*/
public function test($a = true)
{
}
.....теперь пытаемся синхронизировать модель и код (выделяем класс и жмем «F7»):
Внимание: полностью потеряна информация о типе параметра в методе
Class1::test(). Диаграмма ИСПОРЧЕНА, великолепно!
3.4. Неудобства при обновлении кода
Берем диаграмму классов из предыдущего пункта. Выполняем генерацию кода, выделяем
Class1 и снова жмем F11 (т.е. считаем что модель изменилась и нужно обновить код):
В результате необходимо вручную задать соответствие между методами
test() в модели и в коде.
При больших классах это ОЧЕНЬ быстро и ОЧЕНЬ сильно надоедает.
4. Нет поддержки PHPDocСм. первый постТакже неплохо было бы добавить поддержку тегированного значения (tagged value)
throws также как это реализовано для Java, естественно, не забывать добавлять его в комментарии (@throws).
Да, можно написать все это вручную, НО при импорте все это не будет использоваться, более того это будет приводить к загрязнению комментариев, т.к. в них будут снова и снова будет добавляться определения параметров.
5. Неудобство создания финальных методовНепонятно, почему для создания финальных методов необходимо использовать тегированное значение (tagged value)
final? Почему не реализовать это также как в Java?
Точнее, почему галочка есть, но при генерации она не учитывается?
Кроме этого при проверке модели отсутствует проверка на переопределение финальных методов (относиться не только к PHP). Такое поведение мне кажется неправильным, т.к. может привести к грубым ошибкам в дальнейшем. Правильнее выдавать предупреждение при попытке переопределить финальный метод.
Кроме проверки также полезно будет как-то помечать финальные методы на диаграмме, без этого ей неудобно пользоваться - приходиться постоянно лазить в свойства метода, а после распечатки диаграммы эта информация становиться недоступной.
6. При генерации кода неправильно обрабатывается путь к пакетамНапример, есть проект:
Генерируем код для класса
Class1, при этом, если в шаблонах для генерации использовать:
%importPackagePath%
The package path with a '.' separator of the Class being imported.
%packagePath%
The string representing the hierarchy of packages, for the Class in scope.
Each package name is separated by a dot (.). В коде, вместо соответствующих переменных ВСЕГДА будет
System (т.е. имя главного пакета), а должно быть
System.Package1.
Из-за этого при генерации кода нельзя указать пакет, в котором находиться какой либо класс, а это чрезвычайно полезно при генерации документации.
Пример того что нужно получить:
<?php
/**
* @package System.Package1
**/
/**
* .....
*/
class Class1 {
}
?>7. Проверка диаграмм – почему бы не добавить проверку повторного определения методов?Если создать следующую диаграмму:
То, во-первых – она проходит валидацию, а во-вторых, на выходе получаем код с синтаксическими ошибками.
<?php
require_once ('Class3.php');
require_once ('Interface1.php');
require_once ('Class2.php');
/**
* @author sfdgdfgdfgdgdgdfgdfgdff
* @version 1.0
* @created 02-май-2009 21:30:32
*/
class Class1 extends Class2 implements Interface1
{
public $m_Class3;
function __construct()
{
}
function __destruct()
{
}
/**
*
* @param a
*/
public function test(boolean $a = true)
{
}
/**
*
* @param a
*/
public function test(boolean $a = true)
{
}
/**
*
* @param v
* @param a
*/
public function test($v, boolean $a = true)
{
}
}
?>Логичнее или запретить добавлять к классам одинаковые методы, или добавить возможность обнаружить их при проверке модели.
А вот и ответ службы поддержки:
The Class diagram: there is no possibility to show the Default Parameters Values in Methods.
Yes, we don't currently support this, and don't have any immediate plans to add it. It has however been recorded as a feature request.
Awkward Herodoc syntax support
Unfortunately, our parse is unable to deal with Heredoc syntax. We have logged this issue with ID: 07030622. It works in methods because EA doesn't need to parse expressions fully when inside methods. However, depending on the text in your heredoc it will fail inside methods too.
No types support
Yes, this is a limitation of EA's support of PHP. Both the code templates and synchronization rely on types only being 'var', and will cause errors. We do plan on adding some support for this, including PHPDoc support. At this stage we are unable to give a timeframe for this addition.
Final Methods Creation Inconveniences
The final keyword on an operation is set from the tagged value because it is a concept that doesn't exist in UML. (The const checkbox is for a constant return value.) This is the strategy that is taken for any language specific extensions. This is also the reason why it is not checked, however if you want to add that check you can add one. Please see http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/validation.html.
When generating the code - the package path is done incorrectly.
Although I can't see you templates, I suspect the problem is that you are using the packagePath macro, without using the namespace template to iterate into the child templates. At the file template, the packagePath macro will not be the full path.
The diagrams validation – why not adding the option of the Methods Second-Time Definition Check?
Adding a validation check for two methods with the same signature is a good suggestion, and I have logged it as a feature request.
Unfortunately, I can't promise a short term solution to any of the issues you are having. What I can say is that we do test EA. Most of what you have described was deemed as acceptable behavior. The exception being the lack of heredoc support. But even with this shortcoming, I believe that the PHP support in EA is worthwhile.
Возможно, что я не нашел или не понял как использовать существуюший функционал, буду рад если меня поправят.
Не стал создавать новую тему, вместо этого предлагаю модераторам переименовать эту на "Enterprise Architect + PHP5", т.к. это будет более точно соотвествовать её содержанию.
Эта же тема на официальном форуме
Enterprise Architect + PHP5