Форум Сообщества Аналитиков

×


Enterprise Architect + PHP5(Прочитано 21272 раз)
Enterprise Architect + PHP5 : 29 Декабря 2008, 20:49:51
Занимаюсь reverse engeneering'ом проекта, написанного на PHP. Столкнулся с проблемой, что EA не парсит комментарии в стиле PHPDoc (в частности мне нужно получить типы переменных), иначе много времени уходит на ручное редактирование классов. Существует ли возможность настроить определение типов по документации? Сам искал - безрезультатно.

Полный список проблем и частично их решение далее по ветке.
« Последнее редактирование: 12 Мая 2009, 00:46:28 от bas »



Re: Enterprise Architect + PHP Doc. Ответ #1 : 29 Декабря 2008, 21:52:35
Мне думается с этим вопрос Вамлучше обратится на форум самого продукта. Посоветовать можно только:
1. настроить схему трансформации с учетом этих самых PHPDoc (кстати это что? heredoc имеется в виду или нет?)
2/ воспользоваться возможностями Automation Interface и создать в какой-то студии хороший парсер для php кода

Насчет PHPDoc посмотрел. Может имеет смысл посмотреть а КАК ЕА конвертит JavaDoc, если успешно - сделать по аналогии
« Последнее редактирование: 29 Декабря 2008, 21:55:20 от Galogen »



Re: Enterprise Architect + PHP Doc. Ответ #2 : 29 Декабря 2008, 22:33:50
Понимаете, я только начинаю разбираться с данным продуктом. Но по всем категориям он мне понравился. Проблема именно в том, что он разбирает JavaDoc, корневое отличие которого от PHPDoc в том, что там не указываются типы переменных (по понятным причинам). С другой стороны это очень важно для языка с динамической типизацией, как PHP.

>> Может имеет смысл посмотреть а КАК ЕА конвертит JavaDoc, если успешно - сделать по аналогии
Вы не подскажите где я могу посмотреть про это? Я чувствую, что вы подсказываете правильное решение. Я видел шаблоны для генерации кода, а для парсинга пока не нашёл.



Re: Enterprise Architect + PHP Doc. Ответ #3 : 30 Декабря 2008, 22:14:51
Кукарача, извините, но это очень частный вопрос. Ни чем определенным помочь не могу. Все -таки советую постараться задать влвпрос на самом форуме ЕА



Re: Enterprise Architect + PHP Doc. Ответ #4 : 13 Января 2009, 11:03:54
Спасибо. Написал на официальный форум.



Re: Enterprise Architect + PHP Doc. Ответ #5 : 31 Марта 2009, 18:34:34
К сожалению это невозможно. (если честно - хз зачем нужна такая однобокая поддержка PHP - вроде и есть, а на деле сделано через, простите, жопу :( )

> Может имеет смысл посмотреть а КАК ЕА конвертит JavaDoc, если успешно - сделать по аналогии

Бесполезно - используется встроенная функция, которая никак не связана с обратным процессом (разбором комментариев).

> воспользоваться возможностями Automation Interface и создать в какой-то студии хороший парсер для php кода

Тоже бесполезно, т.к. Automation Interface довольно убог - на первый взгляд можно делать свои плагины, НО при попытке сделать что-нибудь серьезное спотыкаешься или на ограничениях этого интерфейса или на отсутствии необходимых методов (событий). Думаю, основная цель у них была предоставить доступ к Enterprise Architect Object Model для свой интеграции с эклипсом, а все остальное лишь бы было.

Если есть желание - у них на сайте есть пример, который вроде бы добавляет поддержку для нескольких языков (подробно не смотрел, но сейчас вроде бы они все уже включены), возможно, можно сделать также для php. НО за что тогда они получают деньги? заплати, а потом реализовывай то что нужно....

Надеяться на то что исправят в следующей версии я бы не стал - они уже пол года не могут добавить поддержку отображения значений параметров по умолчанию...

Недавно у них вышла 7.5 в ней начиная с корпоративной лицензии доступно выполнение скриптов (JavaScript, JScript, ...). Т.е. всего то нужно написать скрипт который будет парсить комментарии и модифицировать объекты....

НО (!!!):
1) нет возможности автоматизации (ПОЧЕМУ?!) - т.е. для каждого класса/пакета этот скрипт придется выполнять вручную (100% кто-нибудь забудет это сделать)
2) при синхронизации все равно типы параметров учитываться не будут (т.е. соответствие методов в модели и коде придется задавать вручную, что быстро надоедает при больших классах)

Если будет время, желание, и если кому то это нужно, возможно, на выходных реализую подобный скрипт.



Re: Enterprise Architect + PHP Doc. Ответ #6 : 11 Мая 2009, 13:29:37
Предлагаю обсудить проблемы, возникающие при использовании 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-&#1084;&#1072;&#1081;-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($vboolean $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", т.к. это будет более точно соотвествовать её содержанию.

Эта же тема на официальном форуме

« Последнее редактирование: 11 Мая 2009, 13:33:06 от LastDragon »



Re: Enterprise Architect + PHP Doc. Ответ #7 : 11 Мая 2009, 22:03:07
А в каком смысле обсудить? Констатировать, что ЕА хреновый код делает для РНР? Так Вам уже это известно, известно и то, что отвечает ЕА. Можно лишь писать в поддержку и указывать им на ляпы, надеясь, что в будущем ляпы будут исправлены



Re: Enterprise Architect + PHP5 Ответ #8 : 12 Мая 2009, 00:47:20
Спасибо LastDragon за подробное описание ляпов ЕА. ИМХО это стоит добавить в ФАК.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Enterprise Architect + PHP5 Ответ #9 : 12 Мая 2009, 20:43:27
А в каком смысле обсудить? Констатировать, что ЕА хреновый код делает для РНР? Так Вам уже это известно, известно и то, что отвечает ЕА.

Мне то известно, а вот тем кто захочет его (EA) использовать эта информация будет полезна.

Кроме того для одиночного фрилансера, который занимается UML в основном для своих проектов, альтернатив особо нет. Ближайший конкурент это Visual Paradigm for UML (всякие бесплатные UML редакторы не рассматриваю, т.к. ни один из тех что пробовал не понравился), но вот цена совсем не радует, ну и нет той гибкости при настройке кодогенерации (хотя последнюю версию только собираюсь посмотреть, но не думаю что там сильно что-то изменилось).



Re: Enterprise Architect + PHP5 Ответ #10 : 13 Мая 2009, 07:46:51
Мне то известно, а вот тем кто захочет его (EA) использовать эта информация будет полезна.

Кроме того для одиночного фрилансера, который занимается UML в основном для своих проектов, альтернатив особо нет. Ближайший конкурент это Visual Paradigm for UML (всякие бесплатные UML редакторы не рассматриваю, т.к. ни один из тех что пробовал не понравился), но вот цена совсем не радует, ну и нет той гибкости при настройке кодогенерации (хотя последнюю версию только собираюсь посмотреть, но не думаю что там сильно что-то изменилось).
Как Вы понимаете, обсуждение вряд ли получится. Коли уже не возникло, то скорее всего его и не будет.
Ваша информаци полезна, безусловно. Вопрос, а можно ли улучшить ситуацию? Ответ - может средства автоматизации, возможность создания внешних подключаемых билиотек под ЕА поможет решить проблему?



Re: Enterprise Architect + PHP5 Ответ #11 : 30 Августа 2009, 00:55:25
Собрал новую версию UMLAddin-а, точнее теперь он называется PHP5Plugin.

Изменения:
  • Написан на C#
  • Alias-ы теперь обновляются автоматически
  • Добавлена проверка переопределения методов (не работает при переименовывании)
  • Ненужный функционал можно отключить
  • Сделан инсталлятор

Требования:
  • Microsoft .NET Framework 3.5
  • Enterprise Architect 7.1 или 7.5

Подробнее...

Распространяется под GPL v3.

Скачать можно здесь.

Приветствуются любые замечания, пожелания и предложения. Лучше всего их отправлять на LastDragon.ru@gmail.com с пометкой "PHP5Plugin" в теме письма. Сообщения об ошибках пока тоже отправляем туда.




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19