генерация кода по uml-схеме

[Malaja]

у меня тормоз: например, есть 2 класса, связанные между собой отношением композиции:

MyDialog <>---------MyEdit  ( <> должен быть черным )
                  1         1...*

Т.о. что я ожидаю при генерации? Мое предположение:

Код:

	class MyDialog
	{
		MyDialog();
		// chto-to eshhe

		MyEdit m_Edit;
	};

Я права или как? 

[Malaja]

Ой, сейчас увидела, что неверно изобразила линию - он адолжна быть сплошной..

Ну и тогда туда же, т.к. до конца не вижу разницы при генерации кода (пардон за тупость) - как будет выглядеть код при таком соотношении как:

1) ассоциация

MyDialog __________> MyEdit
            1         1...*

2) агрегация

MyDialog <>_______MyEdit 
                  1         1...*

[npak]

Ирина, у тебя кратность композиции 1..*
поэтому должен быть список объектов типа MyEdit

Код:

vector<MyEdit> m_Editors;

[Алексей++]

Ирина, не умничай, покажи пальцем (с)

(или просвети меня, темноту, о чём речь... )

[Malaja]

npak,

согласна, спасибо за поправку!
Но главное - при композиции это должен быть непременно мембер класса или нет?

проблема в следующем:
я раньше никогда не пользовалась генерацией кода по схеме, а сейчас попала в проект, где это делают (правда, они решили обойтись малыми деньгами и вместо rational rose используют rhapsody - судя по нервным откликам коллег это катастрофа, т.к. нет никаких обычных книг, а хелп практически непригоден).
Ну и соответственно хочу срочно понять что к чему А тут еще ребята усложнили все, что было возможно, и повводили кучу макросов в код (а где код этих макросов, я пока не знаю), поэтому просто сделать схемку и посмотреть что к чему, возможным не представляется...

Леш,
ежели б сама знала
Смотри, например ты можешь зайти в rational rose, сделать схему проекта в uml-е, нарисовав все свои классы со всеми их мемберами и функциями, и указав, кто с кем и как связан. Затем нажать на кнопку "генерировать код" и получишь скелет программки со всеми .h и .cpp, т.е. сэкономишь кучу времени (если умеешь быстро рисовать схемки )

Вот я и пытаюсь понять, что будет сгенерировано в различных случаях.

[Dimka]

Malaja, права, но не совсем. Множественность объектов MyEdit обозначена как 1..* - значит членом MyDialog будет не объект MyEdit, а коллекция объектов MyEdit. Скорее всего, вспомогательный класс.

И вот тут начинаются проблемы с генерацией кода Поскольку про коллекцию в диаграмме ничего не сказано. Тогда нужно конфигурировать генератор кода так, что в случае отношения "1 ко многим" автоматически задавалась какая-то определённая реализация коллекции. Отношения же "многие ко многим" вовсе запретить.

Судя по точке с запятой в конце декларации класса речь идёт о C++. В этом случае множественность "0..1" должна задаваться через указатель с допустимым значением NULL.

Разницы между реализацией однонаправленной ассоциации, агрегации и композиции в коде нет. Это понятия логической модели, которые могут помочь разработчику понять поведение систем объектов. Обратно из кода они не восстанавливаются (если программист не озаботился комментарием или генератор кода не добавил в комментариях специфичические распознаваемые атрибуты).

Кроме того, реализация композиции или агрегации (отношений типа "часть и целое") никак не ограничивается тем, что ссылка на "часть" непременно хранится в "целом". Это лишь разновидность ассоциации, в которой направление доступа обозначается стрелкой. Никто не мешает "частям" хранить ссылки на "целое", при этом с точки зрения логики системы их значение (часть или целое) в отношении сохраняются.

[npak]

Насколько я помню, агрегация - это включение в инстанс независимых объектов, а композиция ограничивает время жизни вложенных объектов временем жизни контейнера.

То есть агрегацию можно генерировать как вектор ссылок. После удаления контейнера сами вложенные объекты останутся живы.

Код:

vector<MyEdit&> m_AggregatedEditors;

Композицию как вектор инстансов. После удаления диалога будут удалены все редакторы.

Код:

vector<MyEdit> m_CompositionEditors;

Есть небольшой трюк - vector<> дает кратность отношения 0..*, поэтому нужно в конструкторе предусмотреть создание хотя бы одного редактора

[npak]

Смотри, например ты можешь зайти в rational rose, сделать схему проекта в uml-е, нарисовав все свои классы со всеми их мемберами и функциями, и указав, кто с кем и как связан. Затем нажать на кнопку "генерировать код" и получишь скелет программки со всеми .h и .cpp, т.е. сэкономишь кучу времени (если умеешь быстро рисовать схемки )

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

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

Сколько я видел попыток внедрить UML в процесс разработки, нигде люди не выдерживали "идеологической чистоты". Обкладывали матом розу, кодогенератор и лично Гради Буча, переписывали всё ручками, а для отчетов начальству постфактум рисовали красивые диаграммки.

[Malaja]

dimka,

стоп, не так быстро!

На данный момент вид коллекции меня еще мало волнует Точнее, у них запрет на stl, все должно быть на стандартном c++, поэтому это пока для самая маленькая проблема
Сначала надо понять основу.

Т.е. получается, что в принципе я была права, когда сказала, что элемент (ы) типа MyEdit должен быть мембером класса MyDialog, а не переменной, область видимости которой где-то в какой-то функции. и все это вне зависимости от типа связи? Так?

А разница, видимо, в том, что при композиции хранящиеся в MyDialog объекты типа MyEdit должны быть уничтожены при вызове деструктора класса MyDialog, а при  агрегации и ассоцоации - нет. Так?

[Malaja]

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

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

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

[Dimka]

Насколько я помню, агрегация - это включение в инстанс независимых объектов, а композиция ограничивает время жизни вложенных объектов временем жизни контейнера.

И на положение ссылок это не влияет: можно в разных направлениях делать. Хотя, конечно, как правило "целое" содержит ссылки на "части".

Т.е. получается, что в принципе я была права, когда сказала, что элемент (ы) типа MyEdit должен быть мембером класса MyDialog, а не переменной, область видимости которой где-то в какой-то функции. и все это вне зависимости от типа связи? Так?

Пожалуй да... Если объект не член класса, а просто используется внутри метода, то это будет скорее зависимость, чем ассоциация.

А разница, видимо, в том, что при композиции хранящиеся в MyDialog объекты типа MyEdit должны быть уничтожены при вызове деструктора класса MyDialog, а при  агрегации и ассоцоации - нет. Так?

На уровне логики это не определяется Композиция описывает отношение между "целым" и его неотъемлемыми частями. Как человек и голова А агрегация - более слабое отношение, как светильник и лампочка.

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

[Malaja]

dimka,

понятно, спасибочки!

Еще раз огромное всем спасибо за объяснения! 

[Алексей++]

Ирин, ой, сколько незнакомых словов ))
Что есть rational rose и для чего оно ? И почему это экономит время ?

[Finch]

Алексей1153++, http://ru.wikipedia.org/wiki/UML

[npak]

Да, имел я сомнительное удовольствие писать код во внешнем туле. Это возможно, если инструмент хорошо интегрирован с компилятором и отладчиком. Если нет, то проще выкинуть его нахрен, написать и отладить код в нормальных инструментах, а потом нарисовать диаграммку обратно

[Вахмурка]

 А я никогда не пользовался генераций кода по UML схеме. Использую UML только для анализа, и так что б чего не забыть.
Да из диаграммы классов (как я понял в данном случае) генерировать код, невелика выгода, ручками можно быстрее написать.

[Malaja]

Ой, Леш, прости - вчера меня поймали на совещание (я же новая, их расписания художественного трепа еще не знаю), отвертеться не удалось ;-( Ну а потом уже свалить побыстрее захотелось

Этот самый rose - инструмент, в котором можно строить различные uml-схемки (насколько я поняла, наиболее распространенными являются диаграммы классов и диаграммы последовательностей). Посмотри тут: http://www.intuit.ru/department/se/ibmrrose/ - это весьма неплохой краткий курс молодого бойца по построению таких схемок в rose.
Опять же там можно сделать схемку всех классов и затем сгенерировать код (якобы ручками это будет дольше и не так аккуратно). Практического опыта не имею, поэтому ничего сказать пока не могу.

npak,

слушай, я очень сильно подозреваю, что ты прав на все 100 Но у местного начальства другое мнение... да и тул еще кривой и хреновый, но зело дешевый по сравнению с другими... Я видела, как он компилирует - это финиш... Т.е. он подключает компилятор студии, но идет только до 1-ой ошибки, после чего откключается... исправляешь ошибку и опять стартуешь процесс компиляции... Плюс все это длится несуразно долго по сравнению со студией...