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

Построить аналитическую модель классов не составляет труда. Но при переходе к проектной модели, а дальше к реализации, причем последнее очень важно, возникает сказанное выше.

Читаешь книги, понимаешь, что написано, даже вроде реализуешь, но все не то.

Потому прошу помощи по этому вопросу.

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

Пусть существует Клиент, который может делать множество заказов.
В каждом заказе можно заказать один или множество товаров
Один и тот же товар может быть заказ много раз в разных заказах

Каждому заказу присваивается некий уникальный номер.

В результате получается например модель1

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

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

Спасибо

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

Есть некая аналитическая модель, задача преобразовать ее в достаточную для создания кода модель классов.

Что-то мне непонятны Ваши затруднения. Как говорил герой одного известного (в определенных кругах) мультика: "Нет никакого фокуса". Вы просто добавляете поведение к исходной модели в соответствии с требованиями Вашей задачи. Постепенно за счет добавлений поведенческих аспектов и, возможно, других cущностей и/или атрибутов исходная (она же аналитическая) модель станет искомой. Если говорить в терминах объектного подхода - нет кода без классов.

Или я чего-то в Ваших исканиях опять не понял?

Или я чего-то в Ваших исканиях опять не понял?

Чего-то наверное не поняли

Меня интересуют пока вопросы трансформации.
Есть скажем ассоциация 1-ко-многим между двумя классами - ассоциация аналитическая.
Далее мы должны ее превратить в то что возможно будет в коде.

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

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

Если нужно что-то внести дополнительное в модель - давайте внесем - скажите только, у меня же пробел

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

Давайте сформулируем (для начала словами), что будет происходить с клиентами, заказами, товарами. Например, нужно ли отслеживать наличие товаров на складе и резервировать их или товаров всегда "неограниченное количество".

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

Водолей, я согласен со всеми Вашими словами.

За исключением практики. Действительно серьезной практики ООП нет.

Давайте опишем контекст следующими ВИ:

Разместить заказ (клиент)
Просмотреть статус заказа (клиент)
Выполнить заказ (некий менеджер)

Товары будем полагать для простоты в неограниченном количестве

У заказа будем иметь статусы: предложен, принят, выполнен. Еще можно предусмотреть статуч отменен, если он еще в статусе предложен.

В задаче про аттестацию все развиватеся слишком медленно и скорее всего вряд ли дойдет до реализации или даже проекта

У меня как раз был опыт разработки системы сбыта продукции :о)) Поэтому предложу более реальный вариант (потом его можно упростить):
- Клиента регистрирует в системе менеджер службы работы с клиентами, клиенты могут объединяться в группы (например, по регионам или оборотам)
- менеджер по сбыту продукции определяет прайс-лист для группы клиентов на товарный каталог (для простоты положим, что товарный каталог не меняется, хотя по жизни это не так), прайс-лист - набор цен для товаров, прайс-листы могут отличаться размером скидок, товарный каталог может содержать иерархию товаров (например двух-трех уровневую, но можно и больше)
- клиент на основании прайс-листа делает заказ (определяет заказываемые товары и их количество)
- менеджер по сбыту продукции рассматривает, согласовывает с клиентом и утверждает заказ
- заказ отправляется на комплектование и отгрузку, а клиенту отправляется счет и счет-фактура
- клиент оплачивает заказ и сообщает факт оплаты менеджеру по сбыту
- менеджер по сбыту (?) информирует менеджера склада о факте оплаты
- менеджер склада комплектует заказ (помним, что у нас идеальный склад, т.е. все всегда есть)
- клиент самовывозом забирает укомплектованный заказ, предварительно убедившись с помощью системы в его готовности.

осталось перевести эти пользовательские истории в сообщения классов (подсказка: смотрим на глаголы) и рисуем следующую итерацию диаграммы классов.

на следующей итерации будем утрясать параметры сообщений.

Водолей, спасибо. Очень интересно все это, но может начнем с науки.

Мне ваш подход понятен и импонирует, но он инженерный и, конечно, правильный. Но я хочу для начала пойти в теорию.
Приведенная модель - это чистая абстракция. Просто некоторый осмысленный пример.

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

Рассуждения таковы:
1. Клиент - Заказ
  Клиент трансформируется в таблицу Клиенты (КодКлиента(ПК), ФИО(Not Null), Адрес(Not Null))
  Заказ трансформируется в таблицу Заказы(НомерЗаказа(ПК), Дата (Инверсный ключ, Поумолчанию- Now()), КодКлиента(ВК))
  Отношение неидентифицирующее. Минимальная и максимальная кардинальность на стороне таблицы Клиенты - 1
  Минимальная кардинальность на стороне Заказы = 0, Максимальная - много
  Процедуры поддержания целостности: тригеры на стороне родителя Каскадное обновление каскадное удаления

Т.е. имея точные правила преобразования я сумел из модели класса сформировать структуры БД. Возможно в дальнейшем у меня появятся дополнительные требования и дополнительные потребности в создания альтернативных процедур поддержания целостности

Аналогично я бы хотел иметь правила преобразования аналитической модели в проектную и некую начальную структуру классов (скелет классов). Тут вариантов больше согласен, но их не бесконеное множетсво и всегда можно объяснить почем так а не иначе добавив в начале Если, то

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

Если смотреть на эталон в этой области - ErWin (или как он сейчас называется), то там были галочки - добавить триггер такой-то или сякой-то, по умолчанию туда добавлялся простой код по каскадному обновлению, удалению и т.д.
Тут (ЕА) наверное также, нужно расширять параметры элемента и делать специализированный кодогенератор.

Мне ваш подход понятен и импонирует, но он инженерный и, конечно, правильный. Но я хочу для начала пойти в теорию.

Как раз в том проекте был у нас соблазн всё сделать по теории. Но практика показала, что соблюдение всех загогулин избыточно :о((
Суть в том, что должны быть не все возможные артефакты проекта, а лишь необходимые для решения задачи.

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

Рассуждения таковы:
1. Клиент - Заказ
  Клиент трансформируется в таблицу Клиенты (КодКлиента(ПК), ФИО(Not Null), Адрес(Not Null))
  Заказ трансформируется в таблицу Заказы(НомерЗаказа(ПК), Дата (Инверсный ключ, Поумолчанию- Now()), КодКлиента(ВК))
  Отношение неидентифицирующее. Минимальная и максимальная кардинальность на стороне таблицы Клиенты - 1
  Минимальная кардинальность на стороне Заказы = 0, Максимальная - много
  Процедуры поддержания целостности: тригеры на стороне родителя Каскадное обновление каскадное удаления

Т.е. имея точные правила преобразования я сумел из модели класса сформировать структуры БД. Возможно в дальнейшем у меня появятся дополнительные требования и дополнительные потребности в создания альтернативных процедур поддержания целостности

Аналогично я бы хотел иметь правила преобразования аналитической модели в проектную и некую начальную структуру классов (скелет классов). Тут вариантов больше согласен, но их не бесконеное множетсво и всегда можно объяснить почем так а не иначе добавив в начале Если, то

Есть у меня определенное ощущение, что цель искусственна.

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

Далее. Исходным материалом для формирования модели является всё-таки словесно-формульное описание задачи, для адептов добавлю "обычно". Довольно хорошо про это написано в книжке Баркера ("CASE*Method - Entity Relationship Modelling" by Richard Barker. (c) Copyright 1990 Oracle Corporation UK Limited (c) Перевод с английского к.т.н. Крюкова А.В., 1992. - кстати, советую почитать)

Итак, построили (нарисовали) логическую модель. Потом действительно можно тождественными преобразованиями (в том числе с использованием спецсредств) трансформировать ее в хоть в диаграмму классов, хоть в физическую модель БД. Но (!) отмечу, что это именно тождественные преобразования, т.е. логическая модель никуда не делась и, более того, не изменилась, а лишь была реализована на другом уровне. Я вообще не считаю диаграмму классов и модель БД чем-то различным - с этим можно спорить, но на мой взгляд бесполезно.

Касательно способа реализации.
"Первичная" модель делается ручками из примитивов (вспоминаем ERwin, PowerDesigner, встроенные фичи СУБД и иже с ними), так же ее можно записать в виде кода. "Трансформация" в физическую реализацию выполняется либо ручками (медленно, но при наличии нужного уровня квалификации довольно надежно), либо с помощью автоматических преобразователей (быстро, но всё равно потом надо проверять). Разумеется, из одной логической модели может быть построено много вариантов, я уж не говорю о приложениях.  

ну а для поведенческих аспектов нет ничего лучше имеющихся заготовок. (врочем и у них есть минусы)

P.S. Кстати, если Ваш интерес связан с реализацией подобного автоматического преобразователя, то это похвально, но, по-моему, сейчас бессмысленно. Во всех отношениях дешевле будет использовать любой подходящий (или просто грамотного специалиста) и приноровиться к его особенностям. Причина - скорость прохождения из точки А в точку Б.
Более того, я уже делал подобную работу и на своем опыте убедился в ее трудозатратности (т.е. значительных затратах на создание инструмента) и, следовательно, недостаточной эффективности. Хотя адаптивность получается довольно высокой, я уже писал про это. Но самое важное, что кодирование никуда не девается (вспоминаем правило Парето) :о((
Более-менее приемлемый вариант получается при создании целого комплекса средств автоматизации программистского труда (RAD'ы тут не считаются). Ну а это пока несбыточная мечта, к сожалению.

Есть у меня определенное ощущение, что цель искусственна.

да цель искусственна

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

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

как Вам такая идея (не моя): пишешь "код" один раз, а по нему генеришь классы, структуру БД, код различного уровня?

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