Генерация исходных кодов по средством создания UML модели(Прочитано 58864 раз)
привет.

есть опыт генерации кода. причем не раз. и роза генерила, и визио пытался.
вообще многие визуальные средства проектирования это могут. например 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, но топику имхо это вполне соответствует.

Цитировать
Есть БД, в ней лежат данные в одной таблице есть поле А, на нем висит индекс. Теперь надо вместо поля А сделать два поля Б и В, которые генерируются из А по установленным правилам. Если делать руками, то добавлять поля, заливать в них данные, удалять индекс, затем удалять поле, затем перекладывать нужные индексы.
CASE-средства умеют создавать дифференциальный скрипты для 2-х схем, это и автоматизируется. Эти скрипты ложатся в версионный контроль к конкретной модели.

Цитировать
Или вот задача, когда одна таблица с денормализованными данными разламывается на две, связанные ограничением Forein Key? Что конкретно в такой ситуации будет автоматизировать твой инструмент в твоей компании?
Речь идёт не совсем о проектировании, а о рефакторинге SplitTable. Пока 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.
Денис мне напомнил, это была компания Инфотекс.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



привет всем.

просто вопрос. вот при создании scott/tiger в оракл, там есть такая пара таблиц работники-отделы.
 FOREIGN KEY (DEPTNO)
 REFERENCES DEPT (DEPTNO)

вдруг выясняется, что работник может работать не в одном отделе, а в нескольких.
мне кажеться, что надо добавить еще одну таблицу, которая будет связывать эти две.
а из таблицы EMP убрать поле DEPTNO.
все правильно?

реинжинеринг, добавили таблицу, получили скрипты. а дальше что?
за следующий шаг, запуск скриптов на базе, был жестоко бит не один девелопер.
кто будет данные разводить на новую схему?
я точно знаю, что я много чего не знаю в этой жизни. в том числе ни разу не встречал "моделлера", который может сам "перетасовать" данные по новой схеме.

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

про "шустрый редизайн структуры классов", как я понял, никто не спорит? :-)

во



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

В 70-80-х годах доминировала процессная парадигма (data processing) - данные поступают на вход системы, преобразуются, идут на выход. Доминировал каскад.

В 80-х смоллтоковцы придумали кучу хороших штук, пошла волна популяризации объектного подхода.

Но - разработчики БД так и остались в процедурно-функциональной парадигме и каскаде. Они продолжали считать, что изменения - это ненормально, это результат ошибочного проектирования и анализа и платить за ошибки проектирования ковырянием  в коде и данных - это естественная, хотя и неприятная необходимость.

В 90-х смоллтоковцы и проч. поняли, что изменения - это норма жизни, и надо уметь с ними работать. Популяризовались итерационные подходы, появился рефакторинг, развились компонентно-модульные практики.

Но - разработчики БД только встревоженно смотрели по сторонам и всё крепче держались за доброе старое-вечное. Тем более что объективно БД - это сильносвязанная система.

2000-е годы - рефакторинг в объектной разработке стал осознанной нормой жизни, встраивается в объектные инструменты.

Пионеры объектной разработки в лице Скотта Амблера и Фаулера добираются до баз данных, изучают их и предлагают методы "оживления" БД: http://www.agiledata.org/essays/tools.html

Понятно, что пока это не стало общим местом, но Microsoft стал включать элементы рефакторинга в свои БД-инструменты, стали появляться специализированные инструменты: 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? Смотрим текст.

В частности, интересно следующее:

Цитировать
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 матриц методом струйной печати?

Тем не менее нельзя чисто сравнивать материальное производство и программное производство. Все-таки мы имеем дело с информацией, а  информация совершенно другой тип ресурса




 

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