Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: idaxebrn от 18 Марта 2010, 10:23:04
-
Добрый день!
Строю диаграмму классов предметной области (не уровня разработки - только описываю область в целом).
Всегда мучает вопрос - к какому классу правильней и логичней относить функции?
Так:
(http://s60.radikal.ru/i167/1003/c5/51a5900ac4dd.jpg) (http://www.radikal.ru)
или так:
(http://i026.radikal.ru/1003/2c/c70554999099.jpg) (http://www.radikal.ru)
Прошу дать совет. Спасибо.
-
На уровне предметной области операции классов обычно не отображаются.
Тем не менее при моделировании нужно опираться на понятие ответственности класса.
Исходя из этого принципа, очевидно, что первая диаграмма более корректна.
Кто регистирует заказ - очевидно это делает скажем клиент (хотя я бы лучше написал разместить заказ, все-таки регистрирует заказ сама система или какой-то служащий)
Кто подтверждает заказ - очевидно клиент.
Правда в данном случае это некоторые внешние события идущие от клиента - как я понимаю некоторого участника процесса заказа
Добавить элемент заказа - в принципе тоже ответственность клиента, хотя действительно эту операцию можно разместить в заказе
-
Спасибо, Galogen! Как всегда быстро и убедительно )
-
Позволю себе задать еще один вопрос:
Есть магазин, который со временем меняет режим работы.
Можно ли сможелитьвать это так:
(http://i020.radikal.ru/1003/99/ba75c3a6857c.jpg) (http://www.radikal.ru)
При этом какой класс должен иметь функцию смены режима? Видимо, класс "магазин"?
-
... добавлю, что необходимо вести журнал изменений режима работы.
-
если я правильно понимаю то для этого можно применять привязку сущности к связи. так называемая триарная связь получается. В вашем случае эта третья сущность будет отражать период актуальности связи Магазин-РежимРаботы
-
Позволю себе задать еще один вопрос:
Есть магазин, который со временем меняет режим работы.
Я бы сделал Режим работы - перечислением.
Сделал бы просто атрибут типа это перечесление или класс - со связью заморачиваться не стоит в таком контексте
Насчет журнала - т.е. необходимо вести историю типа: Дата - Режим работы.
На концептуальной модели я бы ввел класс Журнал и две ассоциации к магазину и к режиму соотвественно. Кратность на стороне журнала много.
А вообще во многих системах - это был бы просто исторический атрибут. Весь вопрос нужно ли например кроме даты и режима хранить еще ккие-то сведения - там причина изменения режима, основание -документ или еще что-то
-
Можно и с промежуточной сущностью, можно и атрибутом
Но тем не менее вариант привязки сущности к связи мне нравится больше изза того что он передает семантику и не подразумевает как это будет решено на физической модели. в случаях же с промежуточной связью и с атрибутом вас могут неправильно понять при переходе к ER модели.
Впрочем, на вкус и цвет....
-
Всегда мучает вопрос - к какому классу правильней и логичней относить функции?
Не совсем согласен с Эдом, скорее надо нарисовать Д Последовательности и сразу станет понятно у кого какая операция.
-
Прочитал у Фаулера, что двум участвующим в ассоциации объектам может соответствовать ТОЛЬКО ОДИН экземпляр класса-ассоциации. То есть магазин не сможет перейти на круглосуточный режим, потом вернуться на 12-ти часовой, и потом снова на круглосуточный.
Буду испольовать три класса - "магазин", "режим работы" и "журнал работы"
-
Можно и с промежуточной сущностью, можно и атрибутом
Но тем не менее вариант привязки сущности к связи мне нравится больше изза того что он передает семантику и не подразумевает как это будет решено на физической модели. в случаях же с промежуточной связью и с атрибутом вас могут неправильно понять при переходе к ER модели.
Впрочем, на вкус и цвет....
Прочитал у Фаулера, что двум участвующим в ассоциации объектам может соответствовать ТОЛЬКО ОДИН экземпляр класса-ассоциации. То есть магазин не сможет перейти на круглосуточный режим, потом вернуться на 12-ти часовой, и потом снова на круглосуточный.
Буду испольовать три класса - "магазин", "режим работы" и "журнал работы"
Молодец idaxebrn, именно это я хотел ответить kirillss. Кстати ничего в моих рассуждениях от реализации то и нет
-
Не совсем согласен с Эдом, скорее надо нарисовать Д Последовательности и сразу станет понятно у кого какая операция.
Не понял с чем ты не согласен в данном случае?
-
если я правильно понимаю то для этого можно применять привязку сущности к связи. так называемая триарная связь получается. В вашем случае эта третья сущность будет отражать период актуальности связи Магазин-РежимРаботы
Описываемая Вами ситуация не есть N-арная ассоциация, а есть класс-ассоциации. Как сказано было (ниже или выше) класс-ассоциации тут может и не подойти
-
Прочитал у Фаулера, что двум участвующим в ассоциации объектам может соответствовать ТОЛЬКО ОДИН экземпляр класса-ассоциации. То есть магазин не сможет перейти на круглосуточный режим, потом вернуться на 12-ти часовой, и потом снова на круглосуточный.
Не очень понял в чем проблема. Связь Магазин-режим работы многие-ко-многим так что не виже проблемы в том что каждому экземпляру такой связки соответствует ровно один экземпляр класса Журнал. НИКАКИХ ПРОТИВОРЕЧИЙ ТО НЕТ!!!!!!!!!
-
Речь про использоватние класса-ассоциации "Журнал" - он тут не подходит. Нужно использовать обычный класс.
-
... Кстати ничего в моих рассуждениях от реализации то и нет
Вы неправильно меня поняли - я не говорил что в ваших рассуждениях чтото от реализации. Просто те варианты которые были предложены имеют полные аналоги в ER реализации и при передаче от "рисователя-схем" к реализаторскому звену МОЖЕТ произойти потеря контекста.
Это ни за ни против этих методов - просто надо понимать это
И ВСЕ!!!!!!
-
Речь про использоватние класса-ассоциации "Журнал" - он тут не подходит. Нужно использовать обычный класс.
Обосновать можете?
-
Вот 3 страницы (108-110) книги Фаулера "Основы UML". Пример на мой взгляд ясно показывает, что связь-ассоциация имеет вышесказаное ограничение.
(http://s50.radikal.ru/i130/1003/b3/e5f8a0425f13.jpg) (http://www.radikal.ru)
(http://s39.radikal.ru/i086/1003/29/a5301264dac7.jpg) (http://www.radikal.ru)
(http://s46.radikal.ru/i113/1003/9b/b63c4796d69a.jpg) (http://www.radikal.ru)
-
Фаулер (или переводчик) в приведенных фрагментах книги все время путают классы и экземпляры классов.
Ассоциации связывают классы, а экземпляры классов связываются экземплярами ассоциаций (связями).
-
Который раз перечитываю и не могу найти некорректного перевода. denis-itk, а что именно вам не понравилось в тексте?
-
Обведенный фрагмент
"Класс-ассоциация дает возможность определить дополнительное ограничение, согласно которому двум участвующим в ассоциации объектам может соответствовать только один экземпляр класса-ассоциации"
Должно быть что-то типа такого
"Класс-ассоциация дает возможность определить дополнительное ограничение, согласно которому ЛЮБОЙ ПАРЕ ЭКЗЕМПЛЯРОВ двуХ участвующиХ в ассоциации КЛАССОВ может соответствовать только один экземпляр класса-ассоциации"
Кроме этого рис. 6.15, который призван заменить верхнюю часть рис. 6.16 (для удовлетворения соответствующим условиям) слишком наворочен. Проблема решается тернарной ассоциацией.
-
Чтобы не биться относительно фаулера и относительно перевода, залез вчера в UMLный стандарт В нем по поводу Association class имеется такое замечание :
"Note – It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at
each end, i.e., from the instance point of view, the multiplicity of the associations ends are ‘1.’"
Я честно говоря, затрудняюсь однозначно трактовать этот piece of text Но мне все таки кажется что с точки буквы стандарта UML случай idaxebrn корректно описывать с помощью ассоциированного класса.
Кроме того, там же приведена картинка на которой associated classifiers = Person (кардинальность связи = *) и Company (кардинальность связи = 1..*), а associated class = Job (с атрибутом Salary)
-
"Note – It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at
each end, i.e., from the instance point of view, the multiplicity of the associations ends are ‘1.’"
Следует заметить, что в экземпляре ассоциативного класса может быть только один экземпляр ассоциированных (у каждого конца связи) классификаторов, т.е. с точки зрения (с позиции) этого экземпляра кратность концов ассоциации равна 1.
Класс-ассоциация является особым представлением ассоциации. Потому каждый экземпляр класс-ассоциации, представляя собой конкретный экземпляр самой ассоциации, идентифицируется через участников такой ассоциации, т.е. через экземпляры классов на концах этой связи - экземпляра ассоциации. Это и предполагает независимо от значений атрибутов класса-ассоциации дефолтное значение скрытых от нас двух атрибутов представляющих идентификаторы объектов на концах связи. Совокупность этих атрибутов и есть идентификатор конкретного экземпляра ассоциации и он должен быть уникальным!!!!
Потому в схеме с ассоциативным классом невозможна такая ситуация:
Магазин | Режим работы | Дата начала действия режима
Магазин 1 | Режим работы 1 | 1/01/2010
Магазин 1 | Режим работы 2 | 1/02/2010
Магазин 1 | Режим работы 1 | 1/03/2010
Записи которые возможны в этом случае буду такими
Магазин | Режим работы | Дата начала действия режима
Магазин 1 | Режим работы 1 | 1/01/2010 1/03/2010
Магазин 1 | Режим работы 2 | 1/02/2010
Т.е. мы можем знать лишь дату последнего действия режима, но не сможем получить ответ на такой вопрос:
Сколько раз в течение года магази 1 работал по режиму 1 или какова общая продолжительность работы магазина 1 в течение года по режиму 1
-
Эдуард, на основе чего вы так решили? Ведь возможна и другая трактовка приведенного Note - да одному экземпляру связи между classifier соответствует ровно один экземпляр association class но нигде вроде как не написано (по крайней мере не нашел) что между парами экземпляров classifier не может быть многих связок. именно это я имел в виду когда говорил о том что не берусь однозначно трактовать этот Note
Кстати а как вы трактуете наличие рисунка-примера в тексте стандарта?
-
Правильно ли я понял задачу ?
(http://i037.radikal.ru/1003/58/9bbbb5b899e5.jpg)
-
не совсем понял, зачем вы выделили отдельно "журнал" и "элемент журнала"
-
Эдуард, на основе чего вы так решили? Ведь возможна и другая трактовка приведенного Note - да одному экземпляру связи между classifier соответствует ровно один экземпляр association class но нигде вроде как не написано (по крайней мере не нашел) что между парами экземпляров classifier не может быть многих связок. именно это я имел в виду когда говорил о том что не берусь однозначно трактовать этот Note
Этот пример более корректный согласно Note.
Магазин | Режим работы | Дата начала действия режима
Магазин 1 | Режим работы 1 | 1/01/2010
Магазин 1 | Режим работы 2 | 1/02/2010
Магазин 1 | Режим работы 1 | 1/03/2010
У каждого экземпляра "дата начала действия" есть по одному экземпляру Магазин и Режим работы.
-
не совсем понял, зачем вы выделили отдельно "журнал" и "элемент журнала"
Журнал в целом хранит всю историю изменений режимов работы. Элемент журнала - это факт изменения режима работы.
-
На мой взгяд логичнее сделать вот так:
(http://s58.radikal.ru/i159/1003/1b/958250a760da.jpg) (http://www.radikal.ru)
-
На мой взгяд логичнее сделать вот так:
А разве что-то изменилось? Кроме того, что название Элемент журнала изменилось на Режим работы ?
+ у вас у одного магазина может быть много журналов ? а у многих журналов только один режим работы?
Или я что-то неправильно трактую ?
-
название нижнего класса на моей схеме стоит изменит на "Элемент журнала"
просто я не вижу смысла рисовать класс журнал, который не имеет никакой смысловой нагрузки, кроме наличия элементов журнала.
-
Раз уж пошла такая интересная дискуссия, предложу еще одну тему для обсуждения:
что если для магазина необходимо знать историю какого-то атрибута, который невозможно вынести в справочник по типу "Режим работы". Например, атрибут "Стоимость парковки"
Как такое изобразить? Кто в этом случае будет третьим классом?
-
В DataWarehouse в этом случае говорят о Slowly Changed Dimension (SCD). Там аналогичная проблема возникает изза нежелания делать нормализацию. Самый часто используемый вариант SCD 2 - когда для каждого изменения отслеживаемого атрибута добавляется новая строка с указанием как правило двух дополнительных атрибутов - начало и конца периода актуальность строки (значения атрибута) Это называется SCD 2 Еще есть SCD 3 и SCD 6 !!!!
Не знаю насколько окажется полезной эта информация - просто похожая проблемка!!!
-
Этот пример более корректный согласно Note.
Магазин | Режим работы | Дата начала действия режима
Магазин 1 | Режим работы 1 | 1/01/2010
Магазин 1 | Режим работы 2 | 1/02/2010
Магазин 1 | Режим работы 1 | 1/03/2010
У каждого экземпляра "дата начала действия" есть по одному экземпляру Магазин и Режим работы.
А причем тут экземпляр "дата начало действия" - какие такие свойства кроме самой даты данный экземпляр имеет?
Позволю себе цитату:
Арлоу Д., Нейштадт И.
UML 2 и Унифицированный процесс. Практический объектно ориентированный анализ и проектирование, 2 е издание. – Пер. с англ. – СПб: СимволПлюс, 2007. – 624 с., ил.
В ОО моделировании распространена следующая проблема: когда между классами установлено отношение многие ко многим, встречаются такие атрибуты, которые не удается поместить ни в один из классов. Проиллюстрируем это примером, приведенным на рис. 9.18.
На первый взгляд это довольно безобидная модель:
• каждый человек (объект Person) может работать во многих компаниях (объект Company);
• каждая компания (Company) может нанимать много людей (объект Person).
Однако что происходит, если добавить бизнес правило, заключающееся в том, что каждый Person получает зарплату в каждой нанявшей его Company? Где должна быть записана эта зарплата: в классе Person или в классе Company?
Действительно, нельзя сделать зарплату Person атрибутом класса Person, потому что каждый экземпляр Person может работать на многие Company и в каждой получать разную зарплату. Аналогично нельзя сделать зарплату атрибутом Company, поскольку каждый экземпляр Company нанимает множество Person, зарплата которых может быть разной.
Решение кроется в том, что зарплата на самом деле является собственностью самой ассоциации. У каждой ассоциации найма, устанавливаемой между объектом Person и объектом Company, своя индивидуальная зарплата.
UML позволяет моделировать эту ситуацию с помощью класса ассоциации (рис. 9.19). Важно понимать этот синтаксис: многие люди думают, что класс ассоциация – это всего лишь прямоугольник, свисающий с ассоциации. Но ничто не могло бы быть дальше от истины, чем это.
На самом деле класс ассоциация – это линия ассоциации (включая все имена ролей и кратности), пунктирная нисходящая линия и прямоугольник класса на конце пунктирной линии. Короче говоря, класс ассоциация – все, что входит в затемненную область (рис. 9.19).
Классассоциация означает, что в любой момент времени между любыми двумя объектами может существовать только одна связь
Экземпляры класса ассоциации – это на самом деле связи, у которых есть атрибуты и операции. Уникальная идентификация этих связей определяется исключительно индивидуальностью объектов, находящихся на каждом конце. Этот фактор ограничивает семантику класса ассоциации: его можно использовать только тогда, когда между двумя объектами в любой момент времени установлена единственная уникальная связь. Это обусловлено тем, что каждая связь, которая является экземпляром класса ассоциации, должна быть уникальной. На рис. 9.19 применение класса ассоциации означает, что на модель накладывается следующее ограничение: для данного объекта Person и данного объекта Company может существовать только один объект Job (должность). Иначе говоря, каждый Person может занимать только одну Job в данной Company.
Однако если ситуация такова, что данный объект Person может занимать несколько Job в данном объекте Company, класс ассоциацию использовать нельзя – семантика не соответствует!
-
Раз уж пошла такая интересная дискуссия, предложу еще одну тему для обсуждения:
что если для магазина необходимо знать историю какого-то атрибута, который невозможно вынести в справочник по типу "Режим работы". Например, атрибут "Стоимость парковки"
Как такое изобразить? Кто в этом случае будет третьим классом?
Если честно, ничего не понял :)
-
Galogen:
Спасибо за разьеснения. Свою ошибку понял..больше так не буду :- )
-
Если честно, ничего не понял :)
Я о том, что не понимаю, как изобразить такое требование на схеме. Журнал режима работы понятно - класс "Элемент журнала" ассоциируется с классами "Режим работы" и "Магазин". (диаграмму выкладывал выше)
В случае со стоимостью парковки я же не могу использовать класс "Стоимость парковки". Как-то нелогично это...
-
В случае со стоимостью парковки я же не могу использовать класс "Стоимость парковки". Как-то нелогично это...
Опять ничего не понял :)
Но все-таки попытаюсь. Стоимость парковки у магазина величина однозначная. Верно?
Стоимость парковки может изменять свое значение время от времени. Т.е. можно рассмотреть (концептаульно) наличие класса Парковка (Стоимость, Дата начала действия, Дата завершения действия)
Если это так - то решение может быть похожим на ранее рассмотренное.
Другое дело, что реализация этого решения может быть совершенно разная. Например созданием специального домена исторический атрибут, который по мимо значения хранит и дату
-
ну и я позволю себе цитату!!!!
-
ну и я позволю себе цитату!!!!
И что следует из этой цитаты?
А только одно - Ларман слабо проясняет когда и зачем следует применять класс-ассоциации. Он лишь только замечает: "существование ассоциации "многие-ко-многим" является стандартным признаком, что ... зарождается полезный класс ассоциации". Если внимательно вчитаться, то можно заметить корни такого рассуждения в реляционной модели (IDEF1x), в которой связь м-ко-м есть неспецифичная и нуждается в типичной декомпозиции на три таблицы, одна из которых - есть таблица-связи, являющейся идентификационно-зависимой и в которой ключевым полем является составной ключ и которая может иметь (в нашем случае должна) неключевые атрибуты, принадлежащие самой связи.
Такая аналогия нам явно говорит, что сочетания составного ключа может быть только уникальным.
-
1 На мой взгляд то что говорит (и примеры которые он приводит) Ларман противоречат ранее приведенным цитатам. Это говорит о некоей двусмысленности и возможности различного толкования даже стандарта UML (а может в нем тоже произошли какието изменения так как между цитируемыми источниками есть разница во времени)
2 Я предлагаю прекратить показывать свою начитанность и сыпать цитатами, а просто подумать какие проблемы может вызвать использование associated class для исходной задачи. Это гораздо интересней!
-
подумать какие проблемы может вызвать использование associated class для исходной задачи. Это гораздо интересней!
А что тут думать? Все предельно ясно. Или Вам все еще не понятно? Советую посмотреть как реализуется класс-ассоциации в таких программных реализациях как Bold или ECO, там это можно "пощупать руками"
-
А что тут думать? Все предельно ясно. Или Вам все еще не понятно?
Какой же вы начитанный человек