Здравствуйте, уважаемые аналитики!

Передо мной стоит задача построения модели данных приложения. На мой взгляд, в конкретном случае данные удобно представлять в виде иерархической структуры. Для ее описания я решил использовать диаграмму классов, описанную при помощи UML (другого не придумалось). Вопросы следующие:

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

Диаграмму прикрепляю в качестве вложения.

На всякий случай далее привожу ее вербальное описание:

На данной модели сущность Требование (Requirement) представляет собой требование в программном проекте, аттрибут RequirementID – уникальный идентификатор требования, Content – выражение требования в текстовой форме. Для упорядочивания Требований организована иерархическая структура, представленная сущностями Группа (Group) и Проект (Project). Проект отличается от Группы лишь тем, что может и должен стоять на верхнем уровне иерархии. Как видно по диаграмме, в результате получается лес, в котором корнями деревьев являются Гроекты, которые могут включать Требования и Группы, которые, в свою очередь, также могут включать Требования и другие Группы. Далее, к каждому Требованию может быть прикреплено одно или несколько Изображений (LinkedImage), иллюстрирующих требование. Здесь аттрибут ImageSrc – это ссылка на само изображение. Сущность Соответствие (Accordance) представляет собой соответствие части текста некоторой области прикрепленного к Требованию изображения. Аттрибут ImageMap хранит область изображения, а RequirementPart – соответствующую часть текста требования.

Спасибо.

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

А ERWin не подойдет? На мой взгляд лучше, чем ERWin , и не предложишь.
Кажется, модель делана в VP UML? Но даже, если и нет, многие UML tools содержат средства работы с ERD.

В Розе есть инструмент Data Modeling, думаю он Вам здорово помог бы.

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

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

достаточно ли однозначно понимается модель?

С пояснениями да. Хотя а что если одни и теже группы встречаются в разных проектах, так же как и требования?
Всетаки рефлексифную связь на сущности Группа я показал бы более четко, возможно с указанием роли (Главная - подчиненная)

не лучше ли использовать какой-нибудь другой вид диаграм для моделирования (какой, почему)?

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

1. Почему есть RequirementID, но нет, например, ProjectID
2. Reguirement *:1 Group, Group *:1 Project ->  Reguirement *:1 Project как следствие и отдельное обозначение Reguirement *:1 Project лишнее

Григорий, насчет ID это не так важно, это будет важно при физической реализации. Данная модель концептуальная

Насчет связи между требованием и проектом - полностью согласен. Хотя может респондент имел в виду, что требование может и не принадлежать какой-либо группе?

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

1:* говорит, имхо, об обратном

Ну звездочка говорить лишь  о максимальной кардинальности кратности, минимальная тут не оговоривается.
Да я согласен нужно точно это передать. Думаю лучшим решением тут необязательность дочерней сущности. А то так и группу не создашь, и проект на введешь, пока не определишь группу, требование, рисунок, или соотвествие :-)

1. А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?
2. А как мы бум трассировать требования?
3. Не понятно назначение RequirementPart? Это сам тесткс или ссылка место в тексте Requirement.Content? Если последнее, то м.б. оргнизовать как-то Requirement.Content в виде отдельных кусков?
4. Нужны атрибуты требований

Вообще, рекомендую посмотреть релизацию любого Wiki движка, там все есть для СУТ, надо только кое-что добавить, что спечифично для СУТ.

З.Ы. А вообще пора ФАК писать по ДК, а то сам уже забываю какие стрелочки куда идут и что обозначают

А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?

Мы говорим о проекте автора или о проекции автора на существующие тулзы (например RequisitePro)?

У него имхо, RequirementPart - нотация части рисунка

Мы говорим о проекте автора или о проекции автора на существующие тулзы (например RequisitePro)?

Автор хотел комментов вот мы и сыпем, что на ум придет

Благодарю за комментарии.

Теперь по порядку...

Galogen, очень ценное замечание насчет использования композиции. Я по наивности приписывал агрегации свойства, которыми она не обладает, являясь исключительно концептуальной. Если заменить агрегацию на композицию, то все становится именно так как нужно, но меня несколько смущает определение, данное композиции в [1]: "Композиция - это форма агрегации с четко выраженными отношениями владения и совпадением времени жизни целого и частей. Части с нефиксированной множественностью могут быть созданны после самого композита, но однажды созданные живут и умирают вместе с ним. Кроме того, такие части могут быть явно удалены перед "смертью" композита." Вот тут непонятный момент с совпадением жизни. Я хочу иметь возможность создавать и удалять части в любой момент жизни целого и не могу понять позволяет ли мне это определенная выше композиция. Если здесь "перед смертью" означает, что после удаления части и до смерти целого не должно быть созданий и удалений других частей, то все впорядке. Помогите пожалуйста прояснить этот момент.

А ERWin не подойдет?

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

Кажется, модель делана в VP UML?

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

Хотя а что если одни и теже группы встречаются в разных проектах, так же как и требования?

Если я правильно понимаю, то множественность Project 1 : * Group четко заявляет, что любая Группа, если она существует, принадлежит одному и только одному Проекту. Если вы имели ввиду, что хорошо бы позволить одному и тому же Требованию или Группе входить в состав нескольких Групп/Проектов, то я такую возможность отрицаю, пользуясь привелегиями автора (На самом деле, потому что тогда придется возиться с трассировкой, блокировать сделанные изменения пока они не будут одобренны во всех местах включения требования или еще как-то, а я не хочу)

Всетаки рефлексифную связь на сущности Группа я показал бы более четко, возможно с указанием роли (Главная - подчиненная)

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

1. Почему есть RequirementID, но нет, например, ProjectID

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

2. Reguirement *:1 Group, Group *:1 Project ->  Reguirement *:1 Project как следствие и отдельное обозначение Reguirement *:1 Project лишнее

Здесь интереснее. Я создал связь Requirement *:1 Project для того, чтобы показать, что наряду с Группами в Проект могут включаться и Требования напрямую, имхо, без этой связи такое было бы невозможно. Вы не согласны?

Ну звездочка говорить лишь  о максимальной кардинальности кратности, минимальная тут не оговоривается.
Да я согласен нужно точно это передать. Думаю лучшим решением тут необязательность дочерней сущности. А то так и группу не создашь, и проект на введешь, пока не определишь группу, требование, рисунок, или соотвествие :-)

Я так понимаю, меня опять подвело мое "додумывание" в стиле "но это же логично!"... Когда я обозначаю множественность *, то имею ввиду 0..*, так как не сомневался в том, что звездочка допускает и отсутствие реализаций класса, если их количество не ограничено б'ольшим числом. Соответственно, Проект может существовать и в отсутствие  подчиненных объектов. Лучше не экономить на символах, да?

1. А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?
2. А как мы бум трассировать требования?
3. Не понятно назначение RequirementPart? Это сам тесткс или ссылка место в тексте Requirement.Content? Если последнее, то м.б. оргнизовать как-то Requirement.Content в виде отдельных кусков?
4. Нужны атрибуты требований

Вообще, рекомендую посмотреть релизацию любого Wiki движка, там все есть для СУТ, надо только кое-что добавить, что спечифично для СУТ.

1. bas, а что значит "требования связать в виде иерархии"? Я не очень себе это представляю... Расскажите, пожалуйста, как вы это видите. Группу я ввел для "группировки" требований, что удобно, особенно когда их много.
2. Не будем
4. Для моей конкретной задачи, пожалуй, не нужны
<Вообще...>. Спасибо за рекомендацию. Но данном случае речь не идет о реализации полноценной СУТ.
 
и, наконец, 3... Пока не хочется вдаваться в подробности, скажу только что Accordance.RequirementPart ссылается на конкретную часть текста конкретного требования.

пора ФАК писать по ДК

ДК - диаграмма классов, я правильно понимаю? Тогда скорее нужно писать ФАК по связям

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

З.Ы.: Увидел возможную непонятку в модели... У меня получается, что группа может входить и в состав проекта и в состав другой группы одновременно, так? Это было бы крайне нежелательно... Группа может входить в состав самой себя? Как этого избежать? Или у меня просто начался ночной тупняк?

---------------------------------------------

[1]: Буч, Рамбо, Якобсон. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. - М.: ДМК Пресс, 2007. (Перевод не очень нравится, наверное, в оригинале лучше)

Уважаемый Gotyou.

Мне кажется, у вас есть недопонимание сути вопроса, связанного с понятием иерархическая БД.

Во-первых, иерархическая модель данных представляет собой подкласс теоретико-графовых моделей.
Во-вторых, связью Требование-Проект, Вы уже нарушаете принцип иерархичности. Почитайте например Карпову  Базы данных. Модели, разработка, реализация. Питер, 2001 (стр. 39)
В-третьих, использование XML вовсе не означает, что ваша БД будет иерархической, с чего Вы такое придумали?

Агрегация хотя и имеет место быть, но как пишут гуру UML и ООП, использование агрегации нужно избегать. Хотя разница между композитом и агрегатом вполне понятна. Агрегат состоит из вполне независимых частей, которые вполне могут быть использованы где-то еще. Композит же по смыслу состоит из частей, существование которых вне оного, теряет какой- либо смысл.

При использовании UML для моделирования данных, знак композиции принято указывать у родительской сущности, которая либо идентифицирует дочернюю (например - Клиент - Заказ) либо не идентифицирует, но указывает на некоторое подчинение одного от другого (Руководитель- Подчиненный).

Моделирование данных достаточно стандартизированный и устоявшийся процесс. Мне думается нужно просто правильно его использовать и не придумывать лишнего. В вашем распоряжении либо расширенная модель сущность-связь, либо стандарт IDEF1x.

ORM вообще-то из другой немного оперы. ORM - это не нотация

Насчет понятия связей и их проектирования, что они значат и как работают, советую все-таки почитать например Крёнке. Теория и практика построение баз данных. 9-е издание, Питер 2005

Уважаемый Galogen,
 
  Я разобрался почему почему эта модель не может быть иерархической БД.

Спасибо за пояснения и рекомендации.

Уважаемый Gotyou.

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

Тогда вопрос, вы теперь в целом поняли, что будете делать реляционную модель данных, или в крайнем случае объектно-реляционную?

Пожалуй, что так. Я так же понял, что нужно приобрести более четкие знания в этой области, поэтому займусь изучением литературы. Спасибо.

Эд, человек спрашивал про нотации, а ты ему про Erwin - ай-яй-яй )

В качестве нотаций для моделирования структур данных могут использоваться IDEF1X, ORM, crow's feet, UML class diagram, SERM и проч.

ORM - есть такая нотация, называется Object Role Modeling. Не надо забывать, что аббревиатуры неоднозначны.

С помощью реляционных нотаций можно моделировать иерархические БД, т.к. первые более мощные.

И на XML можно делать иерархические БД, вот только в данном случае неясно - зачем.

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

Почему? Зачем себя ограничивать?