Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: krendel от 13 Апреля 2007, 13:11:53
-
здраствуйте!
Интересует вопрос генерации исходных кодов посредством создания УМЛ модели, есть ли примеры создания таких модлей.
Если есть выложите пожалуйста отдельным архивом.
-
Можно начать например с изучения чужого опыта.
UML и Rational Rose. Упражнения (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=71)
Так же можно посоветовать практикум по проектированию ПО Вендрова А.М. Издательство "Финансы и статистика". Ну и конечно help help help, выбранного вами uml инструментария
-
Да очень много зависит от инструмента - может он генерить или не может код. А пример может быть один, положить на диаграмму два класса, связать их обобщением и добавить атрибутов и операций. После этого можно сгенерить карказ этих классов. Код пока полноценно генерить никто не может, только шапки.
-
Код пока полноценно генерить никто не может, только шапки.
Думаю это пока в приницпе не возможно, слишком много творчества в реальной обработки событий - однако то что создается каркаССССС :-) уже не плохо, снимается рутинная работа. Правда, я так и не имел сам реальной практики генерации кода, потому не могу уверено говорить об удобстве
-
Господа, чтобы получить нормальный каркас - нужно сначала подготовить хорошую модель.
ИМХО - основное время займет именно моделирование. Создать классы на основе модели навряд ли сложно...
-
Господа, чтобы получить нормальный каркас - нужно сначала подготовить хорошую модель.
ИМХО - основное время займет именно моделирование. Создать классы на основе модели навряд ли сложно...
Ну если человек прав, то уж прав! :-)
-
пасип за ответы, но вроде Продукт компании Рэйшнл может генерить код
,хотя сам не пробовал пока
-
пасип за ответы, но вроде Продукт компании Рэйшнл может генерить код
,хотя сам не пробовал пока
Дык, генерят, а чтобы им их не генерить :-) Только все-таки не полный код, а каркас кода имхо. Что тоже конечно не мало. Например тот же ORM.
-
У нас есть положительный опыт генерации полноценного кода из УМЛ модели, правда мы используем свой собственный генератор: модель создается в case средстве, выгружается в xmi, и подается на вход генератору. Вот (http://subscribe.ru/archive/comp.soft.prog.veselchak/200702/23233420.html) статья, написанная моим коллегой, о том, как мы докатились до всего этого :)
-
IBM Rational Software Architect позволяет генерить структурный и полноценный код по моделям UML. Как в точности это работает не знаю,. т.к. сам такого не делал, но читал учебник где подробно об этом рассказывается (не смог найти готовую модель исп. в учебнике 8)).
Кому интересно можно почитать книгу из серии ibm.com/redbooks "Шаблоны: управляемая моделями разработка в среде IBM Rational Software Architect"
Английский экземпляр книги можно скачать здесь
http://www.redbooks.ibm.com/abstracts/sg247105.html?Open
ЗЫ Создавать полноценный исходник по моделям,имхо, задача почти невозможная. Нужно создавать правильные и подробные модели, что почти не реально. Если научиться это делать, то программисты (кодеры) останутся без работы или придется им становиться проектировшиками.
-
ЗЫ Создавать полноценный исходник по моделям,имхо, задача почти невозможная. Нужно создавать правильные и подробные модели, что почти не реально. Если научиться это делать, то программисты (кодеры) останутся без работы или придется им становиться проектировшиками.
Не совсем четко понимаю, что значит полноценный код? Т.е. нечто, что требует просто компиляции и вы получите готовое приложение? Немогу себе такого пока представить. Да те же формы, логика обработка в форме ну и т.д.
Лично я имею пока единственный опыт такой работы - это использования BOLD и ECO. Там ты выстраиваешь модель классов, добавляешь OCL выражения. Но все равно просто так - чтобы ручками не поработать - не получается, поскольку даже формы надо сделать же и настроить. А если модель посерьезнее, классы с методами тогда вообще без кодогенерации и дальнейшего написания кода - не обойтись.
Ну даже если представить, что код можно было писать прямо внутри операции на модели, а в каких извините выражениях?
В ECO по мимо ДК, можно использовать диаграмму состояний, что-то там создается и через OCL настраивается. К сожалению с ECO не работал - нет нужного дистрибутива.
Наверняка есть какие-то другие примеры использования MDA. Однако как показывает практика - все эти технологии еще так далеки от совершенства, что программисту еще можно спать спокойно
-
Когда я работал на фирме, там был свой кодогенератор правда для TCL. Много кода можно было получить из настроенной модели БД, но если нужна была логика, то она либо зашивалась в ХП, либо писалась ручками, но автоматизация была вполне достойной и не составлло проблем добавить убрать поле и создать новый справочник.
-
Не совсем четко понимаю, что значит полноценный код? Т.е. нечто, что требует просто компиляции и вы получите готовое приложение? Немогу себе такого пока представить.
Цитирую абзац из описанногомной выше учебника (стр. 128):
"В данном случае трансформации способны генерироать весь исполняемый код на основе диаграмм операций, которые определяют поведение каждого компонента, и на основе заданной технической архитектуры. В других сценариях генерируется только структурный код и для завершения реализации к нему нужно добавить более детальный код. В таких случаях особое внимание уделяется выбору такого способа разработки, который бы гарантировал что код и модель останутся синхронизированными. В нашем примере генерируется весь код и вручную никаких изменений вносить не требуется. Хотя при таком подходе проблема синхронизации исчезает, не всегда возможно добиться такой полноты генерации кода"
Здесь четко написано что ребята из IBM генерят код из моделей. То, что это не всегда и очень трудно тоже написано.
Извините, что я привожу вырезки из книги и не могу подтвердить того, что написано. Но раз пишут и рассказывают детально как это сделать, значит, я думаю, такое возможно.
-
Виталий,
Возможно и это уже делалось 6 лет назад у нас в России и без помощи IBM Rational, но как говорят консультатны некоторые value <<< work.
Вот ссылка на спор на sql.ru:
http://www.sql.ru/forum/actualthread.aspx?tid=115568&hl=mda
http://www.sql.ru/forum/actualthread.aspx?tid=131509&hl=mda
-
как говорят консультатны некоторые value <<< work.
Согласен!
-
привет.
есть опыт генерации кода. причем не раз. и роза генерила, и визио пытался.
вообще многие визуальные средства проектирования это могут. например jdeveloper оракловский.
лично мое мнение - ненавижу!
в мало-мальски сложном проекте, автогенерато делает столько мусора, что его потом надо разгребать долго и нудно.
и самое противное, что если завтра разработчик вдруг "гениально придумал" другую схему классов,
то его и попросят переписать всю кастомизацию, которую сделали на старую.
т.е. сгенерить то можно... только от нее проблем больше, чем пользы.
из той же серии другой пример из практики.
заказчик как то бессонной ночью нарисовал свое видение бизнеса, и сгенерил сразу и базу и набор классов.
утром приходим на работу, он так мирно "поправте там, что б работало"... хорошо был за океаном - убили бы.
для тех, кто не понял. если вы работали проект 2-3 месяца, и вам выкатывают пустые болванки, которые со сделанным никак не стыкуются... успокаивает только то, что платят вам не за результат, а за время.
там где платят за результат - генератор используют только 1 раз. но это уже другая история. :-)
во
-
Поскольку мне еще ни разу не удавалось сделать проект от начала до конца с помощью UML, то соотвественно ни разу не генерил исходный код. Даже ради тренировки. Причины разные: нет большой потребности; нет нормального инструмента (только триальные или кракнутые); нет задач, которые требовали бы такого исполнения; нет предметов, в которых бы я мог это заставить сделать студентов:-). Поэтому хотелось бы все-таки узнать, что понимается под полноценной генерацией кода? Полностью готовое приложение, которое только нужно откомпилировать? Скелет такого приложения? Полускелет, т.е. часть рутинного кода создано, но часть не создано?
Хотелось бы посмотреть некий практический пример, от начала до конца. Пусть простенький. И лучше если на Delphi :-)
-
А вообще в автогенерации кода есть одна большая неприятная вещь (и коллеги уже сказали об этом): управление изменениями. Если генерация происходит один раз, потом код модифицируется вручную, то связь с исходной моделью теряется. Если генерация происходит много раз, то надо четко разграничивать: что пишет машина, а что человек.
Стоп, Сергей. А как же процесс от Borland, той же Розы и других монстров soft индустрии, которые рекламируют свои живые циклы? И любое изменение в модели отражается на коде, и наоборот.
В MDA там вообще первентсво модели таково, что ты просто не сможешь использовать модель, если она некорректна, и в любом случае придется сначала модель корректировать.
А насчет что пишет машина, а что человек -так комментарии же генерятся.
-
Сергей, я же не спорю, что генерация кода в настоящий момент - это очень не эффективно по разным причинам.
Неспорю я и о технологии MDA. Я вообще не знаю реальных проектов с этой технологией. Хотя пишут, что есть реализация для Болд и ЕСО.
Я просто задаю вопросы, таким образом. Вызываю огонь так сказать на себя:-)
-
Покажи мне компанию, которая использует MDA для выпуска промышленного софта в промышленных масштабах.
У нас в компании по крайней мере структура БД целиком из модели управляется.
Попробуй выкинуть из класса в модели пару членов, которые уже завязаны в рукописном коде, что будут делать твои инструменты?
А насчет что пишет машина, а что человек.. Представь, ты сгенерил горстку файлов, которые даже компилируются, потом подправил руками, перекомпилировал, а потом перегенерил из измененной модели, что будет с твоими ручными правками?
А зачем ты перегенерировал из изменённой модели, прежде чем внести изменения в модель из кода с помощью инженерного анализа (reverse engineering)? Если руки неоттуда растут, тут уже никакие технологии не помогут) Нельзя внедрять инструменты и технологии без разработки и следования технологическим сценариям.
Однако, мое отношение к таким фокусам сходно с высказаннам ВО. Не то, чтобы ненавижу, но не люблю.
И даже могу сказать почему. Возьми одну модель небольшого размера 30-50 классов, измени в ней немножко (выкинь пару классов, добавь пару классов, перетяни по другому связи). А потом отдай другому человеку и попроси сказать, чем отличаются эти модели. Сколько времени на это уйдет?
Опять 25. Почему человек должен заниматься сличением моделей, когда это встроенная возможность инструмента? Я не понял, тебе понятие Round-Trip Engineering не встречалось как класс что-ли?
Единственное представление приложения, подлежащее на сегодня уверенному управлению изменениями - это исходный код в виде плоского текста. Все остальное пока от лукавого.
На худой конец, XMI - это тоже плоский текст. Вот только смысла нет его сравнивать, т.к. это прекрасно делает CASE (иначе для чего он тогда нужен?).
Если для сборки приложения нельзя написать один make файл, то процесс сборки приложения будет неповторяемым, а, следовательно, неприменимым в промышленных масштабах.
Кто сказал, что нельзя?
-
Ой, Денис-Ка, спасибо за выручку. ;) А то чувствую, что-то не то, но ответить нечем - нет опыта....
-
Покажи мне компанию, которая использует MDA для выпуска промышленного софта в промышленных масштабах.
Ходил я в одну на собеседование. Не помню как называлась (если интересно поищу), но уверяли, что у них процес MDD.
У нас в компании по крайней мере структура БД целиком из модели управляется.
Денис, так никто про БД и не говорит, все давно это используют. Коворят именно о генерации приложения (AS and Client)
-
Нет братцы, я чего-то не понимаю. Не профессионально это как-то. Одни рассуждают исходя из прочитанного, другие рассуждают абсолютно, не имея никакого опыта. Однако драка стоит еще та!
Может для начала спросим себя: а имел ли кто-то из присутствующих реальный опыт разработки приложения заявленным способом, т.е. через генерацию исходников из модели. Лично! Не по наслышке, не - вот знакомые так делаю и говорят - полная туфта.
И при этом этот опыт действительный, т.е. полноценный, а не взялись попробовали, исплевались и отказались.
Меня тоже интересует КАК и с ПОМОЩЬЮ ЧЕГО достигается синхронизация кодов и модели.
Могу, конечно, предположить - существуют же инструменты синхронизации версий кода и очень активно используются.
Наверное существуют и инструменты синхронизации кода и исходной модели. Опять же синхронизация думаю подлежит не все, а если и все, то в первую голову будут пересинхронизированы моделеобразующие элементы. Т.е. в случае Сергея, уж коли он разделил таблицы, или структуру таблицы, будь любезен внести эти изменения в модель. Иначе на кой хрен мне модель - которая рядом не валялась с твоим исходным кодом и реализацией.
И опять же все это пустые слова, пока мы не поговрим с человеком,который конкретно работал по такому сценарию - модель - генерация кода; изменение кода - перестройка модели - анализ изменений. Однако что-то мне говорит, что мы как всегда нашу российскую действительность - выдаем за общемировую практику и истину в последней инстанции.
Лично я тоже не где не видел, чтобы из UML получали сразу код и сразу готовый и чистый. Однако это не значит этого делать нельзя. Я приводил пример про MDA не случайно - думаю это пример того, что вообщем-то возможно. По крайней мере, у меня такой опыт - было сделано приложение, часть обновлений модели и наоборот происходило главным образом вручную, поскольку нет всей линейки инструментов от того же Borland.
Приложение сделал - начал работать - понял что допустил ошибку в структуре, от чего не реализуются те вещи, которые должны реализоваться, - возвращаюсь в модель, переделываю связи, перегенерирую объектное простанство приложения. Компилирую приложение и запускаю - все стало работать как надо. При этом заметьте, я ничего не изменял. Были формы, были куски кода написанного вне рамок модели: управление, открытие и закрытие БД, коды вызова автоформ, сохранение базы и т.п.
Однако есть но - базу (xml файл) пришлось сначало кильнуть, но вроде есть инструмент для адаптации БД при адаптации модели...
-
Это великолепно, но про структуру БД здесь оффтопик, мы говорим о UML. Но раз зашла речь, скажи мне, как управляется такая ситуация из модели...
Речь шла, напомню, про генерацию кода из UML-модели.
У нас аналитик рисует объектную модель в виде классов UML, из неё инструмент генерит логическую модель БД (PIM в терминологии MDA), далее архитектор БД генерит физическую модель БД (PSM в терминологии MDA), сравнивает её с имеющейся моделью, производит слияние и синхронизацию моделей, рисует заголовки хранимых процедур, генерит код для выбранного подмножества объектов и ХП, выполяет тут же его из CASE-а. Далее программисты пишут внутренний код для этих процедур, архитектор засасывает его в модель, проверяет на корректность и синхронизирует. И так на каждой итерации.
Если понятие "архитектуры" здесь кажется малоуместным, хорошо, значит речь про MDD/MDE (http://en.wikipedia.org/wiki/Model-driven_development), но топику имхо это вполне соответствует.
Есть БД, в ней лежат данные в одной таблице есть поле А, на нем висит индекс. Теперь надо вместо поля А сделать два поля Б и В, которые генерируются из А по установленным правилам. Если делать руками, то добавлять поля, заливать в них данные, удалять индекс, затем удалять поле, затем перекладывать нужные индексы.
CASE-средства умеют создавать дифференциальный скрипты для 2-х схем, это и автоматизируется. Эти скрипты ложатся в версионный контроль к конкретной модели.
Или вот задача, когда одна таблица с денормализованными данными разламывается на две, связанные ограничением Forein Key? Что конкретно в такой ситуации будет автоматизировать твой инструмент в твоей компании?
Речь идёт не совсем о проектировании, а о рефакторинге SplitTable (http://databaserefactoring.com/SplitTable.html). Пока CASE-инструменты не поддерживают рефакторинги БД напрямую, в отличие от рефакторингов в объектных IDE, но я думаю, это вопрос времени. Кстати, уже сейчас используя возможности макросов в CASE-средстве можно попытаться реализовать в нём каталог рефакторингов.
Вот теперь скажи мне такую вещь, возможно я что-то недопонимаю. Приложение пишут 20 человек, причем пишут руками прямо исходный код. Если я внедряю моделлер, куда они должны писать теперь исходный код, в какое конкретно место какого конкретно моделлера? Ты назови имя этой мегаприлады и имя конкретной функции в нем.
Sybase PowerDesigner умеет генерить код и восстанавливать его из C#, Java, VB. С этими заголовками вполне может работать разработчик в своём любимом IDE.
Опять же. ы не мудри, ты пальцем покажи. Имя моделлера в студию. И я бы не отказался увидеть скриншоты результатов этого самого инжиниринга для двух моделей по два класса и два атрибута. Интересует что конкретно я получаю и в каком виде. А то может правда чего пропустил в запале...
Синхронизация кода и моделей: http://download.sybase.com/presentation/pdvideo/pd_appd1.exe секция 3.
Синхронизация моделей: http://download.sybase.com/presentation/pdvideo/pd_entr1.exe (19 Мб), секция 3.
Каково место модели в этом процессе сборки? Какую обработку она проходит и на что влияет?
Объектная модель используется в начале итерации, сборка происходит уже из исходных кодов, а не модели.
-
Ходил я в одну на собеседование. Не помню как называлась (если интересно поищу), но уверяли, что у них процес MDD.
Денис мне напомнил, это была компания Инфотекс (http://www.infotecs.ru/index.htm).
-
привет всем.
просто вопрос. вот при создании scott/tiger в оракл, там есть такая пара таблиц работники-отделы.
FOREIGN KEY (DEPTNO)
REFERENCES DEPT (DEPTNO)
вдруг выясняется, что работник может работать не в одном отделе, а в нескольких.
мне кажеться, что надо добавить еще одну таблицу, которая будет связывать эти две.
а из таблицы EMP убрать поле DEPTNO.
все правильно?
реинжинеринг, добавили таблицу, получили скрипты. а дальше что?
за следующий шаг, запуск скриптов на базе, был жестоко бит не один девелопер.
кто будет данные разводить на новую схему?
я точно знаю, что я много чего не знаю в этой жизни. в том числе ни разу не встречал "моделлера", который может сам "перетасовать" данные по новой схеме.
я еще раз повторяю свой поинт: по проекту, который уже разработывается, работать моделлером, который позволяет за 5 минут сгенерить 20 разных схем - можно, но малополезно. а если его пользует человек малоопытный - опасно.
про "шустрый редизайн структуры классов", как я понял, никто не спорит? :-)
во
-
bo, это опять к вопросу о скорости прохождения изменений в среде, культуре разработки.
В 70-80-х годах доминировала процессная парадигма (data processing) - данные поступают на вход системы, преобразуются, идут на выход. Доминировал каскад.
В 80-х смоллтоковцы придумали кучу хороших штук, пошла волна популяризации объектного подхода.
Но - разработчики БД так и остались в процедурно-функциональной парадигме и каскаде. Они продолжали считать, что изменения - это ненормально, это результат ошибочного проектирования и анализа и платить за ошибки проектирования ковырянием в коде и данных - это естественная, хотя и неприятная необходимость.
В 90-х смоллтоковцы и проч. поняли, что изменения - это норма жизни, и надо уметь с ними работать. Популяризовались итерационные подходы, появился рефакторинг, развились компонентно-модульные практики.
Но - разработчики БД только встревоженно смотрели по сторонам и всё крепче держались за доброе старое-вечное. Тем более что объективно БД - это сильносвязанная система.
2000-е годы - рефакторинг в объектной разработке стал осознанной нормой жизни, встраивается в объектные инструменты.
Пионеры объектной разработки в лице Скотта Амблера (http://www.agiledata.org/) и Фаулера (http://www.martinfowler.com/articles/evodb.html) добираются до баз данных, изучают их и предлагают методы "оживления" БД: http://www.agiledata.org/essays/tools.html
Понятно, что пока это не стало общим местом, но Microsoft стал включать элементы рефакторинга в свои БД-инструменты (http://weblogs.asp.net/aaguiar/archive/2007/01/12/visual-studio-tools-for-database-professionals-rename-refactoring.aspx), стали появляться специализированные инструменты: http://www.sundog.net/index.php/databaserefactoring/page/overview/ , плагины: http://www.red-gate.com/about/news/jolt_award_2007.htm
Процесс идёт, но очень сильна инерция - базданщиков старой школы очень много и они с трудом воспринимают перемены (таков их естественный менталитет).
-
Разница между БД и объектно-ориентированым приложением в том, что объект инициализируется кодом и изменение его структуры и поведения воспринимается при перекомпиляции и новом запуске приложения. А тебе, Денис, тут толкуют, что схема данных в БД обременена данными, которые в ней лежат, по этому кроме изменения схемы надо писать скрипты, перекидывающие данные, а информацию, как данные перекладывать принципиально нельзя достать из старой схемы и новой, ну недостаточно ее там.
Я напомню, что в большинстве случаев развитие модели БД идёт по конструктивному принципу - т.е. появляются новые объекты, увеличиваются домены данных и т.д. Трансформационные же изменения, описанные в книге по рефакторингу баз данных, в большинстве случаев можно сопроводить автоматическими операциями над данными. В тех редких случаях, когда изменения не тривиальны, можно выполнить их на уровне СУБД и реинтегрировать в модель. Общее правило такое: "частным задачам - частные решения".
Тот процесс, что ты описал для каждой итерации ("и так на каждой итерации") может быть проведен, если каждый раз база разворачивается пустой, но тогда вопрос, куда деваются все накопленные данные?
Где написано, что база разворачивается пустой? Давай я себя ещё раз процитирую, если непонятно:
Ан рисует объектную модель в виде классов UML
Инструмент генерит логическую модель БД (на итерации - +дельта)
Ар БД генерит физическую модель (на итерации - +дельта)
Ар БД сравнивает её с имеющейся моделью
Ар БД производит слияние и синхронизацию моделей (получает дельту моделей)
Ар БД рисует заголовки хранимых процедур
Ар БД генерит код для выбранного подмножества объектов и ХП (получает DDL-дельту)
Ар БД выполяет тут же его из CASE-а
И все же ты так и не показал, как сравнить две модели, а сравнение версий - ключ к версионному контролю.
Что помешало тебе посмотреть видеоролики? Как я тебе ещё должен показывать, на пальцах? Тебе лень поставить PD, открыть 2 модели и сделать Compare, Merge? Прикладываю свои картинки.
А из того, что сама модель при компиляции никак не участвует (по твоим словам) вытекает, что это не MDA, то есть приложение, управляемое моделью, а просто генератор шаблонного кода с использованием UML. Но это во-первых не новость, а во-вторых не так уж и ценно.
Так, а что такое MDA? Смотрим текст (http://en.wikipedia.org/wiki/Model-driven_architecture).
В частности, интересно следующее:
MDA Concerns
...
Idealistic: MDA is conceived as a forward engineering approach in which models are transformed into implementation artifacts (e.g. executable code, database schema) in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application[7].
This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) are not supported. This constitutes a problem in situations where such post-transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called "pragmatic MDA"[8]. Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
(выделение моё). Я - про прагматичный MDA, который работает.
-
По этому определению, любой генератор кода - это MDA инструмент. Если понимать модель не как UML модель, а как любую модель. А если MDA - это генератор кода именно из UML, то в чем, собственно, ценность введения нового термина и шумихи вокруг него?
А вот вовсе и не так. MDA- не генератор кода как таковой, MDA при некоторых условиях вообще не использует генерацию кода, если не считать создания объектного ядра.
И вовсе тут дело не в кодогенерации, а в мышлении. MDA - это способ мышления, способ программирование (если хотите). Другое дело до какой стадии дошла MDA - да технологически еще сырое дело. Ну и что, ООЯ в свое время было таким же.
И я думаю, что на этом
>full MDA approach may be too idealistic for some real world deployments
консенсус достигнут. Чудес не бывает.
чудеса делают люди. Я думаю MDA имеет будущее. Возможно она трансформируется, перекристаллизуется, выродится в нечто совершенно иное и более могучее и прагматичное.
-
Сергей, а как по-твоему, расценивать, например: печать фото, или печать скажем OLED экранов, или создание TFT матриц методом струйной печати?
Тем не менее нельзя чисто сравнивать материальное производство и программное производство. Все-таки мы имеем дело с информацией, а информация совершенно другой тип ресурса
-
А кто нить знает какие инструменты позволяют генерить код PHP в Eclipse(желательно с обратной возможностью)? Я нашёл пока только SDE от Visual Paradigm, и интегрированный Sparx который почему то не интегрируется в Linux. Неужели нет ничего бесплатного для Eclipse? Правда я ещё не совсем разобрался в чём недостатки бесплатного SDE, но на моём Linuxe он не хочет работать, зависая при попытке создать диаграмму.
-
Цитирую абзац из описанногомной выше учебника (стр. 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), по базе генерировать код.
Но опять же не нужно из крайности в крайность метаться. Нужно трезво подходить и взвешивать все ЗА и ПРОСТИВ в каждом случае, учитывая специфику. В мелких проектах - однозначно, что шкурка выделки не стоит.