Генерация исходных кодов по средством создания UML модели(Прочитано 57405 раз)
А кто нить знает какие инструменты позволяют генерить код PHP в Eclipse(желательно с обратной возможностью)? Я нашёл пока только SDE от Visual Paradigm, и интегрированный Sparx который почему то не интегрируется в Linux. Неужели нет ничего бесплатного для Eclipse? Правда я ещё не совсем разобрался в чём недостатки бесплатного SDE, но на моём Linuxe он не хочет работать, зависая при попытке создать диаграмму.
« Последнее редактирование: 15 Апреля 2011, 23:29:02 от RuZzz »



Цитирую абзац из описанногомной выше учебника (стр. 128):
Здесь четко написано что ребята из IBM генерят код из моделей. То, что это не всегда и очень трудно тоже написано.
Извините, что я привожу вырезки из книги и не могу подтвердить того, что написано. Но раз пишут и рассказывают детально как это сделать, значит, я думаю, такое возможно.
Написать можно все угодно. До сих пор пока я не видел, что бы кто то показал как это действительно работает. Я не исключаю, что на простых примерах что то и получается, но более изощренные модели думаю врядли смогут быть корректно переведены в код автоматически.
Верить проспектам IBM нельзя. (в конце концов если бы это было так - сейчас программы бы писались со скоростью размножения микробов, однако мы этого не наблюдаем почему то... интересно почему...)
       Мы пытались сделать генерацию кода по UML модели. Во первых это только JAVA, для C# есть инструмент, но чтобы сделать генерацию нужно очень много усилий приложить.
ИМХО: генерация кода из  UML абсолютно пустая трата времени на написание шаблонов преобразования. Всех случаев преобразований учесть невозможно. Мне например не ясно как из одного класса модели анализа сделать преобразование этого класса в 2 или более классов модели дизайна. Даже проблема не в том как сделать, а как понять, что в этом случае надо такое делать, а в другом нельзя. И как мне показалось многие делают просто копированием модели анализа в модель дизайна (но только там уже все на чистом английском языке), а потом эти классы программист вручную докручивает - создает дополнительные классы и т.д. При чем все вот эти докрутки потом никак не отразятся в модели дизайна.
Это преобразование одностороннее: UML->код, обратное невозможно.
Если так уж очень хочется набить собственные шишки - попробуйте Sparx Enterprise Architect  или Visual Paradigm там есть гибкие инструменты для настройки кодогенерации. Но по своему опыту скажу - очень много времени уходить на написание этих преобразований, а толку от полученного кода очень мало, так как программист с использованием современных средств разработки сделает тоже самое очень  быстро. Главное ему объяснить как все это должно работать.
     Поэтому лично я вижу преимущество UML  в его наглядности и использую в качестве "объяснялки" - чтобы донести до программиста как выглядит модель предметной области, а уж программист сам решает оно будет выглядеть в коде.
Два года назад я ходил на курсы по Rational Software Architect, которые вел Новиков Леонид Борисович, который так же присутствует на этом форуме. Он рассказывал, что он чего то там делал на тему преобразований, возможно сейчас уже сможет поделиться (надеюсь положительным) опытом.

Большим недостатком Rational на мой взгляд является отсутствие нормального инструмента для проектирования базы данных. То, что есть в составе Rational Software Architect (я не видел только 8й версии этого продукта) - это какая то жалкая пародия на case средство, по сравнению например с Erwin или Power Designer.

У меня сейчас возникло сомнение в том, что это правильный путь (UML-код), возможно стоить посмотреть такое направление: база данных -код. Внутренний голос мне подсказывает, что это более правильный путь. Сейчас уже есть такие инструменты, но сам пока не пробовал. Например так: вести модель UML только для всеобщего понимания, параллельно проектировать базу (например Erwin), по базе генерировать код.

Но опять же не нужно из крайности в крайность метаться. Нужно трезво подходить и взвешивать все ЗА и ПРОСТИВ в каждом случае, учитывая специфику. В мелких проектах - однозначно, что шкурка выделки не стоит.




 

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