Здравствуйте. Разбираюсь в проектировании на UML (Rational Rose), на примере системы хранения результатов тестирования студентов.
Описание: Система должна хранить сведения о студентах: номер студенческого (уникален), Фамилия, Имя, Отчество. Студенты объединяются в группы, которые имеют свой уникальный номер, и номер курса на котором обучается группа. Также хранятся сведения о тестах: наименование и сложность. После тестирования студента по определённому тесту фиксируется результат в виде оценки и даты тестирования. Вот диаграмма классов прилагается.
Правильно ли я использовал отношение композиции в данном случае?

Отношение композиции случай связи целое-часть, но такого типа, когда часть не может существовать без целого. Уничтожение целого приводит к уничтожению и части.

Можно ли сказать, что группа состоит из студентов. Да. Но можно ли сказать, что при рассформировании группы студент перестает быть таковым? Думаю это слишком сильно. Студент может отсаться студентом, но уже другой группы. Т.е. между группой и студентом лучше иметь агрегацию.

Результат тестирование не часть студента, а часть работы студента. Таким образом связь композиция тут не допустима, здесь явная ассоциация. Я бы вообще сделал квалифицированную ассоциацию м/у Студент и Тест с классом-ассоциацией Результат тестирования.

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

Отношение композиции случай связи целое-часть, но такого типа, когда часть не может существовать без целого. Уничтожение целого приводит к уничтожению и части.

Можно ли сказать, что группа состоит из студентов. Да. Но можно ли сказать, что при рассформировании группы студент перестает быть таковым? Думаю это слишком сильно. Студент может отсаться студентом, но уже другой группы. Т.е. между группой и студентом лучше иметь агрегацию.
 

Т.е. если часть связана с целым композицией, то часть не может поменять своего целого? В случае агрегации это допустимо, студент может перейти в другую группу. Тогда это основное отличие композиции от агрегации! Я правильно понял?

Результат тестирование не часть студента, а часть работы студента. Таким образом связь композиция тут не допустима, здесь явная ассоциация. Я бы вообще сделал квалифицированную ассоциацию м/у Студент и Тест с классом-ассоциацией Результат тестирования.

Результат тестирования не мыслим без студента, которому он принадлежит и теста. Вот он как раз не может их изменить, и время его жизни целиком зависит от времени жизни студента и теста. Про класс-ассоциацию я думал, но все же мне результат тестирования показался сильным самостоятельным классом, или я ошибаюсь?

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

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

Ну не совсем так.

Вообще если мы говорим об моделеи данных или реализации в виде SQL БД, то всем этим управляют процедуры ограничения целостности: стандартные и не стандартные.

Композиция говорит о наличии обязательного родителя и возможно обязательного потомка. Т.е. скажем вы не сможете удалить группу пока в ней есть хотя бы один студент. Более того вы не сможете переназначить этого студенту в другую группы например. Однако если дочерняя сущность необязательна (0, 1 или много) особых проблем нет. Нет особой разницы и между агрегацией и композицией. Просто при использовании UML для моделирование ER, композиция используется, а агрегация нет. Вообще где-то у гуру читал, что агрегацию следовало бы запретить как вредный элемент :-)

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

Ну и смотрите. разве номер студенческого может повторяться  в разных группах?

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

Для меня разница возникла при моделировании данных ER из объектной модели. Композиция превратилась в идентифицирующую связь и перенесла ключ «номер группы» в сущность студент, где номера студенческого вполне достаточно для идентификации студента. Здесь составной первичный ключ лишний.

Одновременно экземпляр части должен входить только в один экземпляр целого. Тут есть шаткость, может ли этот экземпляр входить в другой композит по другой связи.

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

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

Тогда получается композицию вообще нельзя использовать? Ведь по вашим словам все объекты создают некие управляющие классы вроде «событие тестирование». В предметной области студент проходит тест и создают результат тестирования, я так понимаю. Т.е. создать результат тестирования должен быть методом класса «Студент». А дергать этот метод может уже некий другой управляющий класс, например обрабатывающий действия пользователя системы. Или я не правильно понимаю?

По результатам сказанного получается вот такая диаграмма:

Опять же уровень декомпозиции!!!!
Давайте поймем какую модель делаем!?
Если физическую, то это одно, и ДК - это не самый лучший способ это делать.
Если логическую, то это совсем другое и ДК может быть тут принимима.

Пока писал, то перешли опять на логическую модель

Опять же уровень декомпозиции!!!!
Давайте поймем какую модель делаем!?

Я пытался сделать логическую диаграмму классов, потом из неё модель данных. Наверно это не правильно, но как сильно будет отличаться физическая модель от логической в данном случае?
Под сокращением ДК вы имели ввиду диаграмму классов? Тогда я не понял вот этого:

Если физическую, то это одно, и ДК - это не самый лучший способ это делать.
Если логическую, то это совсем другое и ДК может быть тут принимима.

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

Да кординально, как и в любом проекте. А Вы сами не видите разницы м/у последней и предпоследней диаграммой. Посоветовал бы побольше почитать про лог и физ модели, например, здесь

Под сокращением ДК вы имели ввиду диаграмму классов? Тогда я не понял вот этого:

ДК - это диаграмма классов, см. FAQ - UML
А я не понял, что там не понятного Я хотел сказать, что для лог. модели ДК подходит, для физ моделеи лучше подходит нотация IDEF1.x


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

To Martynov

Понимаете следует определиться. Вы проектируете базу данных или приложение?

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

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

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

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

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

Пока же Вы определили какую информацию будете хранить. Можно добавить в модель OCL выражения. Для быстрого прототипирования задачи можно воспользоваться технологией MDA в ее реализации BOLD for Delphi.

Однако Вам, как мне думается, следует прописать теперь функциональную часть, например в виде вариантов использования, диаграмм последовательностей и уже отсюда переходить к классам приложения.

Однако Вам, как мне думается, следует прописать теперь функциональную часть, например в виде вариантов использования, диаграмм последовательностей и уже отсюда переходить к классам приложения.

Стоп! Давайте не будем мешать все в кучу. Если мы говорим о лог модели БД, то давайте ее доведем до логического конца, а потом перходить к ВИ и т.д....

Значит, после построение концептуальной диаграммы классов основанной на анализе предметной области пути построения приложения и базы данных расходятся?
Для базы данных на основе концептуальной строится логическая модель данных, затем физическая. Тут возможно появление суррогатных ключей, приведение к третей нормальной форме др. оптимизации хранения данных.
Для приложения строятся другие диаграммы (последовательности например) и в конце получается физическая объектная модель со всеми управляющими и др. классами.
Но не получится ли между ними большой разницы, ведь классы должны всё таки отражаться в БД.

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

Далее все зависит от выбранной технологии.
Если это MDA, то там на основе физической схемы данных прикручиваются взаимодейсвия и ограничения OCL, дополнительные сущности и интерфейс.
Если мы идем по классическому подходу, то мухи (БД) отдельно, котлеты (Приложение) отдельно. Т.е. делаем отдельно физ модель БД и отдельно модель классов приложения, кот. будут разительно отличаться.

По моему, концептуальная схема = логическая модель