Форум Сообщества Аналитиков

×


Вопрос по диаграмме классов(Прочитано 20473 раз)
Re: Вопрос по диаграмме классов Ответ #30 : 19 Марта 2010, 11:29:23
название нижнего класса на моей схеме стоит изменит на "Элемент журнала"
просто я не вижу смысла рисовать класс журнал, который не имеет никакой смысловой нагрузки, кроме наличия элементов журнала.



Re: Вопрос по диаграмме классов Ответ #31 : 19 Марта 2010, 12:15:19
Раз уж пошла такая интересная дискуссия, предложу еще одну тему для обсуждения:
что если для магазина необходимо знать историю какого-то атрибута, который невозможно вынести в справочник по типу "Режим работы". Например, атрибут "Стоимость парковки"
Как такое изобразить? Кто в этом случае будет третьим классом?



Re: Вопрос по диаграмме классов Ответ #32 : 19 Марта 2010, 12:39:49
В DataWarehouse  в этом случае говорят о Slowly Changed Dimension (SCD).  Там аналогичная проблема возникает изза нежелания делать нормализацию. Самый часто используемый вариант SCD 2 - когда для каждого изменения отслеживаемого атрибута добавляется новая строка с указанием как правило двух дополнительных атрибутов - начало и конца периода актуальность строки (значения атрибута) Это называется SCD 2 Еще есть SCD 3 и SCD 6 !!!!

Не знаю насколько окажется полезной эта информация - просто похожая проблемка!!!




Re: Вопрос по диаграмме классов Ответ #33 : 19 Марта 2010, 14:11:26

Этот пример более корректный согласно 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, классассоциацию использовать нельзя – семантика не соответствует!
« Последнее редактирование: 19 Марта 2010, 14:20:17 от Galogen »



Re: Вопрос по диаграмме классов Ответ #34 : 19 Марта 2010, 14:21:19
Раз уж пошла такая интересная дискуссия, предложу еще одну тему для обсуждения:
что если для магазина необходимо знать историю какого-то атрибута, который невозможно вынести в справочник по типу "Режим работы". Например, атрибут "Стоимость парковки"
Как такое изобразить? Кто в этом случае будет третьим классом?
Если честно, ничего не понял :)



Re: Вопрос по диаграмме классов Ответ #35 : 19 Марта 2010, 14:49:05
Galogen:
Спасибо за разьеснения. Свою ошибку понял..больше так не буду :- )





Re: Вопрос по диаграмме классов Ответ #36 : 19 Марта 2010, 15:14:25
Если честно, ничего не понял :)
Я о том, что не понимаю, как изобразить такое требование на схеме. Журнал режима работы понятно - класс "Элемент журнала" ассоциируется с классами "Режим работы" и "Магазин". (диаграмму выкладывал выше)
В случае со стоимостью парковки я же не могу использовать класс "Стоимость парковки". Как-то нелогично это...



Re: Вопрос по диаграмме классов Ответ #37 : 19 Марта 2010, 18:10:38
В случае со стоимостью парковки я же не могу использовать класс "Стоимость парковки". Как-то нелогично это...
Опять ничего не понял :)
Но все-таки попытаюсь. Стоимость парковки у магазина величина однозначная. Верно?
Стоимость парковки может изменять свое значение время от времени. Т.е. можно рассмотреть (концептаульно) наличие класса Парковка (Стоимость, Дата начала действия, Дата завершения действия)
Если это так - то решение может быть похожим на ранее рассмотренное.
Другое дело, что реализация этого решения может быть совершенно разная. Например созданием специального домена исторический атрибут, который по мимо значения хранит и дату



Re: Вопрос по диаграмме классов Ответ #38 : 22 Марта 2010, 10:43:32
ну и я позволю себе цитату!!!!



Re: Вопрос по диаграмме классов Ответ #39 : 22 Марта 2010, 12:19:38
ну и я позволю себе цитату!!!!
И что следует из этой цитаты?
А только одно - Ларман слабо проясняет когда и зачем следует применять класс-ассоциации. Он лишь только замечает: "существование ассоциации "многие-ко-многим" является стандартным признаком, что ... зарождается полезный класс ассоциации". Если внимательно вчитаться, то можно заметить корни такого рассуждения в реляционной модели (IDEF1x), в которой связь м-ко-м есть неспецифичная и нуждается в типичной декомпозиции на три таблицы, одна из которых - есть таблица-связи, являющейся идентификационно-зависимой и в которой ключевым полем является составной ключ и которая может иметь (в нашем случае должна) неключевые атрибуты, принадлежащие самой связи.
Такая аналогия нам явно говорит, что сочетания составного ключа может быть только уникальным.



Re: Вопрос по диаграмме классов Ответ #40 : 22 Марта 2010, 13:14:51
1 На мой взгляд то что говорит (и примеры которые он приводит) Ларман противоречат ранее приведенным цитатам. Это говорит о некоей двусмысленности и возможности различного толкования даже стандарта UML (а может в нем тоже произошли какието изменения так как между цитируемыми источниками есть разница во времени)
2 Я предлагаю прекратить показывать свою начитанность и сыпать цитатами, а просто подумать какие проблемы может вызвать использование associated class для исходной задачи. Это гораздо интересней!



Re: Вопрос по диаграмме классов Ответ #41 : 22 Марта 2010, 15:56:24
подумать какие проблемы может вызвать использование associated class для исходной задачи. Это гораздо интересней!
А что тут думать? Все предельно ясно. Или Вам все еще не понятно? Советую посмотреть как реализуется класс-ассоциации в таких программных реализациях как Bold или ECO, там это можно "пощупать руками"



Re: Вопрос по диаграмме классов Ответ #42 : 22 Марта 2010, 16:31:34
А что тут думать? Все предельно ясно. Или Вам все еще не понятно?
Какой же вы начитанный человек




 

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