На данной модели сущность Требование (Requirement) представляет собой требование в программном проекте, аттрибут RequirementID – уникальный идентификатор требования, Content – выражение требования в текстовой форме. Для упорядочивания Требований организована иерархическая структура, представленная сущностями Группа (Group) и Проект (Project). Проект отличается от Группы лишь тем, что может и должен стоять на верхнем уровне иерархии. Как видно по диаграмме, в результате получается лес, в котором корнями деревьев являются Гроекты, которые могут включать Требования и Группы, которые, в свою очередь, также могут включать Требования и другие Группы. Далее, к каждому Требованию может быть прикреплено одно или несколько Изображений (LinkedImage), иллюстрирующих требование. Здесь аттрибут ImageSrc – это ссылка на само изображение. Сущность Соответствие (Accordance) представляет собой соответствие части текста некоторой области прикрепленного к Требованию изображения. Аттрибут ImageMap хранит область изображения, а RequirementPart – соответствующую часть текста требования. |
Для ее описания я решил использовать диаграмму классов, описанную при помощи UML (другого не придумалось).А ERWin не подойдет? На мой взгляд лучше, чем ERWin , и не предложишь.
достаточно ли однозначно понимается модель?С пояснениями да. Хотя а что если одни и теже группы встречаются в разных проектах, так же как и требования?
не лучше ли использовать какой-нибудь другой вид диаграм для моделирования (какой, почему)?Я бы предпочел ERWin. Он заточен для работы именно с данными и помогает быстро и эффектно построить модель БД, он умеет быстро и гладко соединяться с большим набром субд, генерить sql код и много других прелестей. Но это дело вкуса и доступности инструментов.
Хотя может респондент имел в виду, что требование может и не принадлежать какой-либо группе?
А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?
Мы говорим о проекте автора или о проекции автора на существующие тулзы (например RequisitePro)?Автор хотел комментов вот мы и сыпем, что на ум придет :)
А 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. А я вообще не понял зачем тут группа? Нельзя просто требования связать в виде иерархии и привязать к Проекту?1. bas, а что значит "требования связать в виде иерархии"? Я не очень себе это представляю... Расскажите, пожалуйста, как вы это видите. Группу я ввел для "группировки" требований, что удобно, особенно когда их много.
2. А как мы бум трассировать требования?
3. Не понятно назначение RequirementPart? Это сам тесткс или ссылка место в тексте Requirement.Content? Если последнее, то м.б. оргнизовать как-то Requirement.Content в виде отдельных кусков?
4. Нужны атрибуты требований
Вообще, рекомендую посмотреть релизацию любого Wiki движка, там все есть для СУТ, надо только кое-что добавить, что спечифично для СУТ.
пора ФАК писать по ДКДК - диаграмма классов, я правильно понимаю? Тогда скорее нужно писать ФАК по связям ;)
На мой взгляд, в конкретном случае данные удобно представлять в виде иерархической структуры.Почему? Зачем себя ограничивать?
ORM - есть такая нотация, называется Object Role Modeling. Не надо забывать, что аббревиатуры неоднозначны.А что имел ввиду Galogen, когда говорил, что ORM не нотация? Какую расшифровку этой аббревиатуры?
Я по наивности полагал, что xml-файл всегда представляет собой иерархическую базу данных. Теперь, когда я узнал что такое иерархическая модель данных на самом деле, убедился в ошибочности своих представлений.ЦитироватьНа мой взгляд, в конкретном случае данные удобно представлять в виде иерархической структуры.Почему? Зачем себя ограничивать?
А что имел ввиду Galogen, когда говорил, что ORM не нотация? Какую расшифровку этой аббревиатуры?Наверное, он имел в виду Object-Relational Mapping :)