Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Martynov от 04 Января 2008, 23:44:18
-
Здравствуйте. Разбираюсь в проектировании на UML (Rational Rose), на примере системы хранения результатов тестирования студентов.
Описание: Система должна хранить сведения о студентах: номер студенческого (уникален), Фамилия, Имя, Отчество. Студенты объединяются в группы, которые имеют свой уникальный номер, и номер курса на котором обучается группа. Также хранятся сведения о тестах: наименование и сложность. После тестирования студента по определённому тесту фиксируется результат в виде оценки и даты тестирования. Вот диаграмма классов прилагается.
Правильно ли я использовал отношение композиции в данном случае?
-
Отношение композиции случай связи целое-часть, но такого типа, когда часть не может существовать без целого. Уничтожение целого приводит к уничтожению и части.
Можно ли сказать, что группа состоит из студентов. Да. Но можно ли сказать, что при рассформировании группы студент перестает быть таковым? Думаю это слишком сильно. Студент может отсаться студентом, но уже другой группы. Т.е. между группой и студентом лучше иметь агрегацию.
Результат тестирование не часть студента, а часть работы студента. Таким образом связь композиция тут не допустима, здесь явная ассоциация. Я бы вообще сделал квалифицированную ассоциацию м/у Студент и Тест с классом-ассоциацией Результат тестирования.
Композиция может проявится при моделировани данных с использованием UML в двух случаях: когда связь - идентифицирующая, т.е. дочерняя сущность идентификационно-зависимая или когда дочерняя сущность слабая, но не идентификационно-зависимая. Черный ромб говорит об обязательной сущности в бинарной связи, т.е. минимальная и максимальная кардинальность (кратность) ровно 1.
-
Отношение композиции случай связи целое-часть, но такого типа, когда часть не может существовать без целого. Уничтожение целого приводит к уничтожению и части.
Можно ли сказать, что группа состоит из студентов. Да. Но можно ли сказать, что при рассформировании группы студент перестает быть таковым? Думаю это слишком сильно. Студент может отсаться студентом, но уже другой группы. Т.е. между группой и студентом лучше иметь агрегацию.
Т.е. если часть связана с целым композицией, то часть не может поменять своего целого? В случае агрегации это допустимо, студент может перейти в другую группу. Тогда это основное отличие композиции от агрегации! Я правильно понял?
Результат тестирование не часть студента, а часть работы студента. Таким образом связь композиция тут не допустима, здесь явная ассоциация. Я бы вообще сделал квалифицированную ассоциацию м/у Студент и Тест с классом-ассоциацией Результат тестирования.
Результат тестирования не мыслим без студента, которому он принадлежит и теста. Вот он как раз не может их изменить, и время его жизни целиком зависит от времени жизни студента и теста. Про класс-ассоциацию я думал, но все же мне результат тестирования показался сильным самостоятельным классом, или я ошибаюсь?
Композиция может проявится при моделировани данных с использованием UML в двух случаях: когда связь - идентифицирующая, т.е. дочерняя сущность идентификационно-зависимая или когда дочерняя сущность слабая, но не идентификационно-зависимая. Черный ромб говорит об обязательной сущности в бинарной связи, т.е. минимальная и максимальная кардинальность (кратность) ровно 1.
Вот от миграции ключей при возникновении идентифицирующей связи из-за композиции я и задался этим вопросом. Вот какая получает модель данных:
-
Ну не совсем так.
Вообще если мы говорим об моделеи данных или реализации в виде SQL БД, то всем этим управляют процедуры ограничения целостности: стандартные и не стандартные.
Композиция говорит о наличии обязательного родителя и возможно обязательного потомка. Т.е. скажем вы не сможете удалить группу пока в ней есть хотя бы один студент. Более того вы не сможете переназначить этого студенту в другую группы например. Однако если дочерняя сущность необязательна (0, 1 или много) особых проблем нет. Нет особой разницы и между агрегацией и композицией. Просто при использовании UML для моделирование ER, композиция используется, а агрегация нет. Вообще где-то у гуру читал, что агрегацию следовало бы запретить как вредный элемент :-)
Ваш результат тестирование снимает проблему связи многие ко многим между студентом и тестом, потому я и сказал, что результат тестирование фактически есть нечто иное как атрибуты связи студент делает тест. И мыслили Вы не диаграммой классов , а моделью данных ERD, на мой взгляд.
Ну и смотрите. разве номер студенческого может повторяться в разных группах?
-
Нет особой разницы и между агрегацией и композицией. Просто при использовании UML для моделирование ER, композиция используется, а агрегация нет. Вообще где-то у гуру читал, что агрегацию следовало бы запретить как вредный элемент :-)
Для меня разница возникла при моделировании данных ER из объектной модели. Композиция превратилась в идентифицирующую связь и перенесла ключ «номер группы» в сущность студент, где номера студенческого вполне достаточно для идентификации студента. Здесь составной первичный ключ лишний.
Одновременно экземпляр части должен входить только в один экземпляр целого. Тут есть шаткость, может ли этот экземпляр входить в другой композит по другой связи.
Да я читал что класс может иметь только одно отношение композиции, иначе при удалении одного из целых удалиться часть другого целого. Поэтому первая моя диаграмма неверна.
Дальше написано, что при удалении целого, часть удаляется. И все бы ничего, но целое так же отвечает и за создание части, а это в данном примере трудно представить. За создание результата студента скорее должен отвечать объект "событие тестирования" (если тесты сдаются группой), которого нет на диаграмме, но никак не студент или тест. так что композиты тут лучше не использовать.
Тогда получается композицию вообще нельзя использовать? Ведь по вашим словам все объекты создают некие управляющие классы вроде «событие тестирование». В предметной области студент проходит тест и создают результат тестирования, я так понимаю. Т.е. создать результат тестирования должен быть методом класса «Студент». А дергать этот метод может уже некий другой управляющий класс, например обрабатывающий действия пользователя системы. Или я не правильно понимаю?
По результатам сказанного получается вот такая диаграмма:
-
Опять же уровень декомпозиции!!!!
Давайте поймем какую модель делаем!?
Если физическую, то это одно, и ДК - это не самый лучший способ это делать.
Если логическую, то это совсем другое и ДК может быть тут принимима.
-
Пока писал, то перешли опять на логическую модель :)
-
Опять же уровень декомпозиции!!!!
Давайте поймем какую модель делаем!?
Я пытался сделать логическую диаграмму классов, потом из неё модель данных. Наверно это не правильно, но как сильно будет отличаться физическая модель от логической в данном случае?
Под сокращением ДК вы имели ввиду диаграмму классов? Тогда я не понял вот этого:
Если физическую, то это одно, и ДК - это не самый лучший способ это делать.
Если логическую, то это совсем другое и ДК может быть тут принимима.
-
Я пытался сделать логическую диаграмму классов, потом из неё модель данных. Наверно это не правильно, но как сильно будет отличаться физическая модель от логической в данном случае?
Да кординально, как и в любом проекте. А Вы сами не видите разницы м/у последней и предпоследней диаграммой. Посоветовал бы побольше почитать про лог и физ модели, например, здесь (http://www.intuit.ru/department/database/rdbdev/6/)
Под сокращением ДК вы имели ввиду диаграмму классов? Тогда я не понял вот этого:
ДК - это диаграмма классов, см. FAQ - UML (http://www.uml2.ru/index.php?option=com_content&task=view&id=71&Itemid=50)
А я не понял, что там не понятного :) Я хотел сказать, что для лог. модели ДК подходит, для физ моделеи лучше подходит нотация IDEF1.x (http://idefinfo.ru/content/view/14/49/)
Если мы "рисуем" лог модель, то надо еще добавить слова к связям и их направленность.
-
To Martynov
Понимаете следует определиться. Вы проектируете базу данных или приложение?
Ваша диаграмма классов - концептуальная, т.е. содержит классы-сущности. Лишена операций. Говорить о реализации пока преждевременно. Класс концептуальный может мигрировать в класс приложения, обрастая операциями, но может и не мигрировать.
При проектировании модели данных мы также проходим разные этапы: строим логическую модель, по ней физическую. Будет ли отличаться физическая модель от логической зависит уже от реализации, то есть других требований как функциональных, так и нефункциональных, причем от вторых возможно сильнее.
Проектирование БД основано на отношениях, связи между которым образуются путем миграции первичного ключа родительской сущности в область атрибутов дочерней. В зависимости от тип связи принадлежности и типа отношения, миграция первичного ключа возможна как в область ключевых атрибутов, так и в область неключевых.
При переходе к физической БД, вполне вероятно Вы перейдете к суррогатным ключам, это изменит и тип связей. Для корректного поддержания ссылочной целостности Вы, вероятно, воспользуетесь установкой различных процедур ссылочной целостности. Возможно придется дополнительно спроектировать триггеры и хранимые процедуры - это уже будет зависить от СУБД, используемой Вами.
Когда Вы будете проектировать классы Вашего приложения, то можно воспользоваться шаблонами проектирования. При этом помимо классов-сущностей возникнет потребность в создании управляющих классов и граничных классов.
Пока же Вы определили какую информацию будете хранить. Можно добавить в модель OCL выражения. Для быстрого прототипирования задачи можно воспользоваться технологией MDA в ее реализации BOLD for Delphi.
Однако Вам, как мне думается, следует прописать теперь функциональную часть, например в виде вариантов использования, диаграмм последовательностей и уже отсюда переходить к классам приложения.
-
Однако Вам, как мне думается, следует прописать теперь функциональную часть, например в виде вариантов использования, диаграмм последовательностей и уже отсюда переходить к классам приложения.
Стоп! Давайте не будем мешать все в кучу. Если мы говорим о лог модели БД, то давайте ее доведем до логического конца, а потом перходить к ВИ и т.д....
-
Значит, после построение концептуальной диаграммы классов основанной на анализе предметной области пути построения приложения и базы данных расходятся?
Для базы данных на основе концептуальной строится логическая модель данных, затем физическая. Тут возможно появление суррогатных ключей, приведение к третей нормальной форме др. оптимизации хранения данных.
Для приложения строятся другие диаграммы (последовательности например) и в конце получается физическая объектная модель со всеми управляющими и др. классами.
Но не получится ли между ними большой разницы, ведь классы должны всё таки отражаться в БД.
-
Например, класс должен оперировать с суррогатными ключами, введёнными при построении логической модели данных.
-
Далее все зависит от выбранной технологии.
Если это MDA (http://www.uml2.ru/forum/index.php?topic=311.0), то там на основе физической схемы данных прикручиваются взаимодейсвия и ограничения OCL, дополнительные сущности и интерфейс.
Если мы идем по классическому подходу, то мухи (БД) отдельно, котлеты (Приложение) отдельно. Т.е. делаем отдельно физ модель БД и отдельно модель классов приложения, кот. будут разительно отличаться.
-
По моему, концептуальная схема = логическая модель
-
По моему, концептуальная схема = логическая модель
В статье http://www.intuit.ru/department/database/rdbdev/6/ о логической модели данных, которую Вы мне дали, написано:
«Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.»
А как же наличие связи многие-ко-многим в логической модели? Это же не нормальная форма. В ERWin также на логическом уровне разрешены субкатегории. И то и другое пропадает на физическом уровне.
P.S. спасибо большое всем за развернутые ответы. :)
-
Получается логическая модель будет такой?
-
«Нормализация отношений информационной модели предметной области является механизмом создания логической модели реляционной базы данных.»
А как же наличие связи многие-ко-многим в логической модели? Это же не нормальная форма. В ERWin также на логическом уровне разрешены субкатегории. И то и другое пропадает на физическом уровне.
А так же там написано:
На практике часто рассматривают только две модели - логическую и физическую модели данных. При этом информационная и логическая модели данных не различаются и считаются синонимами. В рамках такого подхода некоторые специалисты в области баз данных считают, что информационная модель данных должна быть нормализована. Это означает, что проектировщики баз данных должны требовать от аналитиков, чтобы они приводили информационную модель данных к третьей нормальной форме! Такой подход имеет ряд недостатков. Во-первых, аналитики, являясь экспертами в предметной области, как правило, не представляют, что такое нормализация данных. Во-вторых, информационная модель данных должна быть независимой от физической модели данных, в рамках которой она будет реализовываться. Для реализации информационной модели данных может быть выбрана не реляционная, а, например, сетевая (СУБД ADABAS) или многомерная (СУБД Teradata) модели данных, тогда нормализация отношений модели не столь актуальна. В-третьих, проектировщики базы данны х должны иметь логическое представление данных, посредством которого, с одной стороны, общаться с аналитиками и пользователями в понятных для них терминах, и, с другой стороны, превращать полученные логические отношения в физические объекты базы данных.
Здесь есть ответы на два ваших вопроса:
1. Концептуальная модель (информационная модель) = логическая модель
2. Нормализацию не рекомендуют делать на лог уровне, с чем я согласен
Получается логическая модель будет такой?
НЕТ. Я же вроде не двусмысленно сказал, что к предпоследней модели "надо еще добавить слова к связям и их направленность".
Последняя Д у вас получилась больше похожая на физ представление.
-
Спасибо, вроде разобрался.
-
Если дополнить описание предметной области следующим:
Каждый тест состоит из тестовых заданий, на которые имеются варианты ответов, верные и неверные. По результатам тестирования должны хранится данные о том на какие тестовые задания ответил студент правильно или нет, и какие варианты ответа он выбрал, в случае неверности ответа. В тестовом задании бывает несколько верных ответов, нужно выбрать все их.
Получится такая логическая модель данных, я не ошибся?
-
Результат тестирования должен фиксировать Вариант Ответа, а НЕ Тестовое Задание.
А теперь добьем композицию и агрегацию:
На вашем примере Тестовое задание состоит из Вариантов ответов, и это правильно, и это композиция, т.е. "состоит из" - это композиция.
А Группа, НЕ "состоит из", она включает в себя Студентов, и это агрегация, Т.е. Студет "учится" в Группе, так будет правильнее
Т.е. если Вы будете руководствоваться этими правилами, то сразу отличите агрегацию от композиции. Еще раз:
* агрегация - это когда Части "включаются/собираются" в Целое, и Части могут существовать без Целого.
* композиция - это когда Целое "состоит из" частей, и Части НЕ могут существовать без Целого.
З.Ы. Получился прям мини ФАК по ДК
-
Результат тестирования должен фиксировать Вариант Ответа, а НЕ Тестовое Задание.
Связью «фиксирует» я хотел отразить то, что студент может ответить не на все вопросы теста. Необходимо зафиксировать на какие задания он отвечал, и если неверно ответил, то какие варианты ответов он выбрал. Подскажите как лучше это отобразить.
А теперь добьем композицию и агрегацию:
На вашем примере Тестовое задание состоит из Вариантов ответов, и это правильно, и это композиция, т.е. "состоит из" - это композиция.
А Группа, НЕ "состоит из", она включает в себя Студентов, и это агрегация, Т.е. Студет "учится" в Группе, так будет правильнее
Т.е. если Вы будете руководствоваться этими правилами, то сразу отличите агрегацию от композиции. Еще раз:
* агрегация - это когда Части "включаются/собираются" в Целое, и Части могут существовать без Целого.
* композиция - это когда Целое "состоит из" частей, и Части НЕ могут существовать без Целого.
Спасибо, обязательно запомню.
З.Ы. Получился прям мини ФАК по ДК
Это отлично, другим начинающим тоже будет хороший пример. :) А то в книжках не расписывают, почему именно так, а не по-другому.
Вот закончу с логическим уровнем, потом физический нарисую с применением суррогатных ключей.
-
Необходимо зафиксировать на какие задания он отвечал, и если неверно ответил, то какие варианты ответов он выбрал. Подскажите как лучше это отобразить.
В том то и дело, что лучше отоброзить - какие ответы Студен выбрал во время прохождения теста. Т.е. лучше направленная ассоциация от Результата тестирования к Варианту Ответа
З.Ы. Сам немного забыл про навигацию, поэтому нашел достаточно хорошее описание, когда и куда надо применять стрелки. Там разбирается пример композиции Circle -> Point:
The arrowhead on the other end (near Point) of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. In UML relationships are presumed to be bidirectional unless the arrowhead is present to restrict them. Had I omitted the arrowhead, it would have meant that Point knew about Circle. At the code level, this would imply a #include “circle.h” within point.h. For this reason, I tend to use a lot of arrowheads.
-
The arrowhead on the other end (near Point) of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. In UML relationships are presumed to be bidirectional unless the arrowhead is present to restrict them. Had I omitted the arrowhead, it would have meant that Point knew about Circle. At the code level, this would imply a #include “circle.h” within point.h. For this reason, I tend to use a lot of arrowheads.
Если я пишу базу данных, то в отношении студент группа первичный ключ сущности «Группа» заносится атрибутом в сущность «Студент», но не наоборот. Это понятно, стрелка от студента к группе. Но если взять приложение (диаграмму классов приложения), то у класса «Группа» вполне логично запросить список всех её студентов, также как у класса «Студент» запросить его группу. Здесь не очень понятно.
Ещё непонятно направление стрелки при класс-ассоциации «Проходит»
В том то и дело, что лучше отобразить - какие ответы Студен выбрал во время прохождения теста. Т.е. лучше направленная ассоциация от Результата тестирования к Варианту Ответа
Нарисовал диаграмму. Получается, чтобы узнать ответил ли студент правильно на задание, придется смотреть какие варианты он выбрал. И чтобы получить просто список заданий, на которые он отвечал, обращаться к вариантам ответов.
-
Для того, чтобы понять направление стрелки, т.е. навигация, полезно построить OCL выражения.
К примеру, я хочу узнать какие тесты выполнил студент такой-то, следовательно я толжен иметь возможность прослеживания всех связей некоего объекта студента со всеми экземплярами класса тест. Но я могу пожелать проследить кто из студентов выполнил такой-то тест, тоесть прослеживаю все экземпляры связей между объектом тест и соотвествующими экземплярами класса студент. Кстати тут очень помогут роли или квалификаторы
-
К примеру, я хочу узнать какие тесты выполнил студент такой-то, следовательно я толжен иметь возможность прослеживания всех связей некоего объекта студента со всеми экземплярами класса тест. Но я могу пожелать проследить кто из студентов выполнил такой-то тест, тоесть прослеживаю все экземпляры связей между объектом тест и соотвествующими экземплярами класса студент. Кстати тут очень помогут роли или квалификаторы
Значит если я хочу получать список студентов группы, и наоборот знать группу в которой учится студент связь на диаграмме класов будет двунаправленная. Но в логической модели данных однонаправленная?
-
Ребята, мне кажется все-таки надо все начать сначала. А сначала - это значит понять что за систему мы делаем, для чего, каково ее предназначение.
Если отталкиваться от первых моделей, то я мог бы представить такую постановку. На кафедре информатики все студенты, обучающиеся информатики, для получения зачета должны пройти некий набор тестов. При этом каждый студент обращается к лаборанту, получает очередной тест, проходит его и сдает лаборанту. Лаборант передает тесты преподавателю, преподаватель проверяет и отдает их лаборанту. Лаборант вводит результаты прохождения теста в систему.
Преподавателям кафедры показалась такая ситуация не очень эффективна, напрягает лаборантов, преподавателей да и студентов. Решено сделать автоматическую систему сдачи тестов, т.е. студент регистрируется в системе и в удобное для себя время проходит тесты. Система следит, чтобы студент не мог сдать очередной тест пока не сдал предыдущий. Студент разрешается пересдать тест (дается не более 3 попыток).
Исходя из того или иного описания можно проводить анализ и построение логической модели данных или концептуальной модели классов.
Исходя из описания будет ясно насколько важно выделять класс Группа. Если каждый студент группы должен пройти некий набор тестов, то очевидно тесты должны быть связаны с группой. Если номер группы - простой атрибут студента, то выделение сущности Группа - может быть полезным только для ограничения выбора номера группы из установленного списка. Однако если набор тестов зависит от специализации, т.е. номера группы, то мы получаем совершенно иную картину.
Важно или не важно хранить историю ответов на вопросы. Если оценка определяется на основании сравнения ответа на вопрос с контрольным ответом, то ясно что нужно хранить не оценку, а именно ответ на вопрос теста, тогда оценка будет вычисляться.
Система тестирования может охватывать не одну дисциплину, а целый набор дисциплин с разными авторами тестов, с разным набором тестов для разных групп. Все это важно для будущего приложения и модели данных
Потому предлагаю сначала описать эту предметную область как можно более точно и полно.
-
Если описать предметную область полно то получится достаточно большой размах, и никто из посетителей форума не захочет даже читать это описание. Я же вижу целью изучение проектирования, а не решение какой-то задачи. Для начала проще понять что 2*2=4 чем вычислять интегралы. Поэтому наоборот пытаюсь сузить предметную область до минимума, главное на примере уловить все особенности.
Попытаюсь сейчас описать этот минимум:
Задача системы - хранение данных о студентах, тестах, и том как студенты проходили эти тесты. Только хранение и просмотр, ни о каком процессе тестирования, назначения студенту теста для прохождения речи пока не идёт.
Значит данные о студентах: номер студенческого (уникален), Фамилия, Имя, Отчество. Студенты объединяются в группы, которые имеют свой уникальный номер, и номер курса на котором обучается группа.
Также хранятся сведения о тестах: наименование и сложность.
Каждый тест состоит из тестовых заданий, на которые имеются варианты ответов, верные и неверные. В тестовом задании бывает несколько верных ответов, ответ считается верным если пользователь выбрал все верные варианты ответов тестового задания.
После тестирования студента по определённому тесту фиксируется результат в виде оценки и даты проведения тестирования. Также данные о том, на какие тестовые задания ответил студент правильно или нет, и какие варианты ответа он выбрал, в случае неверности ответа. Студент может ответить не на все задания теста.
Поступление данных в систему прошу не рассматривать, оценка не высчитывается, она просто хранится. Вся задача хранить эффективно эти данные и просматривать:
1. Просмотр списка групп, сведений о группе (номер, курс, кол-во студентов, список студентов в группе)
2. Просмотр списка всех студентов (номер студ. ФИО, группа, курс)
3. Просмотр результатов тестирования студента (тест, дата тестирования, оценка, список пройденных заданий, у неверных выбранные варианты ответов)
4. Просмотр списка тестов (Наименование, сложность, кол-во заданий)
5. Просмотр заданий теста (задание, список вариантов ответов)
Всё.
-
а кто фиксирует данные прохождения теста? как студент проходит тест? какие типы тестовых заданий бывают? одновариантный, многовариантный, точный ответ, сопоставление и т.п.
учитывается ли время прохождения теста (вы пишите - число не пройденных вопросов, а зачем они нужны если никгде не говорится о порядке сдачи теста). зачем фиксировать не пройденный тест, если вы вообще не говорите об автоматизации теста, значит результаты теста фиксируются постфактум, зачем фиксировать непройденный тест? или недоконца пройденный тест
понимает я не вижу ничего сложного в вашей задаче. я делал разные тестовые программы первая из них была на паскале, она предлагала ввести данные студента, студент выбирал модуль для ответа, система генерировала случайный набор вопросов и фиксировала ответы в ходе выполнения тетса, отслеживала время теста и прекращала его в некоторый момент времени. преподаватель мог посмотреть статистику и видеть какие вопросы отвечены верно, какие не верно а какие вообще не отвечались
когда я делал систему на основе БД то приобращении студента к тесту формировалась строка особозашифрованных чисел, естествено по умполчанию она распозновалась как не отвеченные вопросы, по мере ответа это строка чисел менялась, окончательное ее сохранение просиходило либо по завершении теста либо по завершение времени, вся статистика оценки и прочее вычисляли при обращении. Т.е. многое перенесено было непосредственно в приложение.
Т.е. вариантов море.
Если Вы хотите понять как проектировать то я вижу два пути: у вас есть документы на базе которых вы строите модель данных, у вас есть описание предметной области, которое вы анализируете, строите матрицу связей, получаете модель: сначал сущность связь, потом модель основанную на ключах, потом полную атрибутивную модель.
Почитайте Крёнке Теория и практика баз данных - по-моему лучшей книги не придумаешь
-
а кто фиксирует данные прохождения теста? как студент проходит тест? какие типы тестовых заданий бывают? одновариантный, многовариантный, точный ответ, сопоставление и т.п.
Никто не фиксирует, уже прошли миллионы лет назад, возьмут данные из другой БД и пакетно зальют в эту созданную структуру. И надо только ПРОСМАТРИВАТЬ. Тестовые задания закрытой формы, с несколькими правильными ответам. Для правильности должны быть выбраны все правильные варианты. Я уже говорил.
Веря я в ваш богатый опыт создания таких систем, НУ НЕХОЧУ Я ИЗ МУХИ СЛОНА ДЕЛАТь. Просто хочу разобраться на простом примере.
Уже года 3 занимаюсь разработкой БД (MS SQL, ORACLE). Сделал не одну систему, причём реально используемые. Но проектированием систем детально не занимался, теперь решил заполнить пробел. Читаю про Rational Rose и Data Modeler. Если Вы готовы помочь мне в этом советом, а также сделать на форуме неплохой пример для кучи других жаждущих понять это, пожалуйста помогите. Буду очень благодарен.
-
Мальчики не ссортесь!
Вот что я нашел про навигацию в стандарте ОМГ:
Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently
from instances participating in links at the other ends of the association. The precise mechanism by which such access is
achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible,
and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating
associations from non-navigable ends.
Что-то я и сам запутался после серфинга по Инету. Т.е. правильные последнии ассоциации, как я сам и рисовал, но во всех примерах я видел что стрелка находится на другом конце от ромбика :( Эд, если знаешь точный ответ, то поясни плиз.
-
Мне кажется я отвечаю сверх корректно. То что я посоветовал читать книгу, так это есть следствие явных пробелов знаний у оппонента, которые проявились в ходе дискуссии.
Если коллеге Martynov интересно развиваться именно в этом направлении - т.е. RR и DM, то советую почитать книгу Нейбург и Максимчук "Проектирование БД с помощью UML".
Пацаны, я проблемы не понял и вопросов не понял. Что нужно? Как рисовать стрелочку и куда ее направлять? А зачем енто нужно на концептуальной модели? Это же у же реализация. Наличие или отсутствие навигации есть реализация.
Я обычно не парюсь и использую двунаправленную навигацию - это показывается ОТСУТСТВИЕМ стрелочек в любую сторону.
Вот что пишет достопочтенный Рамбо Буч и Якобсон в своей эпохальной книге UML руководство пользователей.
Навигация. С помощью простой, не содержащей дополнений ассоциации между двумя классами (скажем, Книга и Библиотека) можно осуществлять навигацию между их объектами. Если явно не оговорено противное, то навигация по ассоциации может осуществляться в обоих направлениях. Но бывают случаи, когда необходимо ограничить ее только одним направлением. Например, как показано на рис. 10.3, при моделировании сервисов операционной системы можно столкнуться с ассоциацией между объектами User (пользователь) и Password (пароль). Если дан объект класса User, то нужно уметь находить соответствующие объекты класса Password, но обратное недопустимо, то есть не должно быть возможности по паролю определить пользователя. Направление ассоциации можно выразить явно, дополнив ее стрелкой, указывающей на допустимое направление движения.
Примечание: Если задано направление движения, это не обязательно означает, что вы никогда не сможете добраться от объектов на одном конце ассоциации к объектам на другом ее конце. Навигация описывает, скорее, эффективность перемещения. Так, в приведенном выше примере все-таки можно найти пользователя, зная его пароль, с помощью других ассоциаций, не показанных на этом рисунке. Возможность осуществлять навигацию в данном случае означает толькото, что до объектов на другом конце ассоциации можно добраться легко и быстро (как правило, потому, что в объекте-источнике хранятся ссылки на объекты-цели).
Про композицию.
Композиция. Агрегирование является простой концепцией с достаточно глубокой семантикой. Простое агрегирование - чисто концептуальное отношение, оно лишь позволяет отличить "целое" от "части" (см. главу 5), но не изменяет смысла навигации по ассоциации между целым и его частями и не накладывает никаких ограничений на соотношение времен жизни целого и частей.
Однако существует вариация простого агрегирования - композиция, которая добавляет к семантике агрегирования новые важные особенности (для моделирования композиции используются атрибуты, см. главы 4 и 9). Композицией называется форма агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после самого композита, но, будучи созданы, живут и умирают вместе с ним. Впрочем, части могут быть удалены явным образом еще до уничтожения композита.
Это означает, что в случае композитного агрегирования объект в любой момент времени может быть частью только одного композита. Например, в оконной системе класс Frame (Рама) принадлежит только одному классу Window (Окно), тогда как при простом агрегировании "часть" может принадлежать одновременно нескольким "целым". Скажем, в модели дома объект Стена может принадлежать нескольким объектам Комната.
Кроме того, в композитном агрегировании целое отвечает за диспозицию своих частей, то есть композит должен управлять их созданием и уничтожением. Например, создав объект Frame в системе окон, вы должны присоединить его к объемлющему окну. Когда объект Window удаляется, он в свою очередь должен уничтожить принадлежащие ему объекты Frame.
Как показано на рис. 10.7, композиция является просто частным случаем ассоциации и обозначается путем дополнения ассоциации закрашенным ромбом на конце со стороны "целого".
Примечание: Композицию можно обозначить по-другому, включив символы частей внутрь символа композита. Эта форма особенно полезна, если вы хотите подчеркнуть отношения между частями, действительные только в контексте целого.
Агрегирование
Агрегирование. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого", как показано на рис. 5.7. Существует много важных разновидностей этого отношения (см. главу 10).
Примечание: Незакрашенный ромб отличает "целое" от "части"- - и только. Эта простая форма агрегирования является чисто концептуальной; она не влияет на результат навигации по ассоциации между целым и его частями и не подразумевает наличия между ними какой-либо зависимости по времени жизни.
По-моему не прибавишь не убавишь
-
Никто не фиксирует, уже прошли миллионы лет назад, возьмут данные из другой БД и пакетно зальют в эту созданную структуру. И надо только ПРОСМАТРИВАТЬ.
Видите как интересно, уже обнаруживается, что на заре зарождения разумной жизни, тесты уже вовсю использовались, более того, они уже хранились в какой-то БД :)
-
Если коллеге Martynov интересно развиваться именно в этом направлении - т.е. RR и DM, то советую почитать книгу Нейбург и Максимчук "Проектирование БД с помощью UML".
Конечно интересно, спасибо попытаюсь найти и почитать.
Про композицию и агрегацию думаю теперь разобрался железно!
Из все выше сказанного про навигацию попытаюсь сделать следующие выводы:
- в концептуальной модели между классом «Студент» и классом «Группа» двунаправленная агрегация, так как предметная область требует получения списка студентов по группе, а также получение сведений о группе студента.
- при построении физической модели связь может стать однонаправленной, например при построении физической модели реляционной БД для удовлетворения требований концептуальной модели достаточно однонаправленной связи (размещение первичного ключа группы в сущность Студент, sql позволит выбрать быстро всех студентов группы)
- в концептуальной модели между классом «Результат тестирования» и «Вариант ответа» существует однонаправленная ассоциация, так как результат тестирования должен знать выбранные варианты ответа, но вариант ответа не должен знать кем он был выбран, это будет справедливо и для физических моделей.
Поправьте если что не так понял.
-
Не хочется вступать в философский спор, но
- при построении физической модели связь может стать однонаправленной, например при построении физической модели реляционной БД для удовлетворения требований концептуальной модели достаточно однонаправленной связи (размещение первичного ключа группы в сущность Студент, sql позволит выбрать быстро всех студентов группы)
Смотрите, поскольку связь 1-ко-многим, то независимо от навигации среди атрибутов класса Группа будет атрибут Студент типа Студент.
Поскольку стоит агрегация, то навигация ничего нового не дает, как бы вы ее не меняли задание классов остается тем же самым.
Однако если будет ассоциация, то тут уже гораздо интереснее ситуация
1. Группа (нет навигации) - Студент (нет навигации)
имеем
Public номер As int
Public курс As int
Public m_Студент As Студент
и
Public номер зачетки As char(5)
Public ФИО As char(100)
2. Группа (навигация) - Студент (нет навигации)
имеем
Public номер As int
Public курс As int
Public m_Студент As Студент
и
Public номер зачетки As char(5)
Public ФИО As char(100)
Public m_Группа As Группа
3. Группа(нет навигации) - Студент(есть навигация)
ситуация подобна пункту 1
4. Группа(навигация) - Студент(навигация)
ситуация 2 повторяется
-
Проектирование систем - это деятельность по определению устройства системы. Устройство системы может быть описано комплектом текстовых спецификаций, моделей, таблиц, диаграмм и т.д. Проектирование систем производится на основании требований к системе и результатов исследования и моделирования как исходной, так и целевой предметной области.
Я понимаю стремление человека, занимавшегося БД в течение нескольких лет, строить всю работу по созданию системы "дата-центрично" (data-centric), но если хочется стать профессиональным системным архитектором, то стоит пересмотреть подходы.
Итак, напоминаю, что для того, чтобы осуществлять собственно проектирование системы, необходимо получить:
1. Модель предметной области (структура, процессы, переходы состояний).
2. Требования (функциональные и нефункциональные).
В итерационном подходе эти пункты не обязательно должны быть исчерпывающими, но по крайней мере содержательными.
-
Эдуард, Rational Rose с Вами не согласен.
«BClass» является агрегатом класса «AClass»
Двунаправленной отношение.
Сгенерированный Rational Rose код:
class AClass
{
public:
//##ModelId=4781001901B5
AAtribute;
//##ModelId=4781004C03B9
BClass a;
};
class BClass
{
public:
//##ModelId=478100250399
BAtribute;
//##ModelId=4781004C03BB
AClass *b;
};
Стрелка направлена к классу «AClass»:
class AClass
{
public:
//##ModelId=4781001901B5
AAtribute;
};
class BClass
{
public:
//##ModelId=478100250399
BAtribute;
//##ModelId=4781004C03BB
AClass *b;
};
Стрелка направлена к классу «BClass»:
class AClass
{
public:
//##ModelId=4781001901B5
AAtribute;
//##ModelId=4781004C03B9
BClass a;
};
class BClass
{
public:
//##ModelId=478100250399
BAtribute;
};
-
Проектирование систем - это деятельность по определению устройства системы. Устройство системы может быть описано комплектом текстовых спецификаций, моделей, таблиц, диаграмм и т.д. Проектирование систем производится на основании требований к системе и результатов исследования и моделирования как исходной, так и целевой предметной области.
Я понимаю стремление человека, занимавшегося БД в течение нескольких лет, строить всю работу по созданию системы "дата-центрично" (data-centric), но если хочется стать профессиональным системным архитектором, то стоит пересмотреть подходы.
Итак, напоминаю, что для того, чтобы осуществлять собственно проектирование системы, необходимо получить:
1. Модель предметной области (структура, процессы, переходы состояний).
2. Требования (функциональные и нефункциональные).
В итерационном подходе эти пункты не обязательно должны быть исчерпывающими, но по крайней мере содержательными.
Я читаю про Rational Unified Process. Это технология напрактике сейчас используется?
В этой теме я пытаюсь разобраться как правильно простроить концептуальную диаграмму классов, затем логическую и физическую модель данных.
-
Эдуард, Rational Rose с Вами не согласен.
Может быть. Разные средства моделирования реализуют ассоциации по-разному. Я экспериментировал в Enterprise Architect. Тут все зависит еще и от того, как рисуешь связь, т.е. кто источник, а кто мишень.
Однако хотелось бы понять как правильно.
Читая книгу Рамбо и Блаха ""UML2.0 Объектно-ориентированная разработкаи и моделирования", обнаруживаю следующее:
односторонние ассоциации реализуются при помощи указателя (в логическом смысле). При реализации это может быть указатель, ссылка языка программирования или даже внешний ключ базы данных.
для двухсторонней ассоциации могут быть три подхода:
одностороння реализация - реализовать в виде одностороннего указателя и выполнять поиск при прослеживании в обратном направлении. используется если частота прослеживания в одном направлении сильно отличается от другого направления.
двусторонняя реализация - с указателями в обоих направлениях.
реализация при помощи объекта.
Далее в книге есть указание на то, что использование агрегации и композиции следует ограничить при концептуальном моделировании, т.к. они относятся скорее к реализации.
Если рассматривать реализацию в виде БД, то тут мне кажется все достаточно определено. Первичный ключ родительской сущности помещается в виде внешнего ключа либо в область ключевых, либо в область неключевых атрибутов.
-
Читая книгу Рамбо и Блаха ""UML2.0 Объектно-ориентированная разработкаи и моделирования", обнаруживаю следующее:
односторонние ассоциации реализуются при помощи указателя (в логическом смысле). При реализации это может быть указатель, ссылка языка программирования или даже внешний ключ базы данных.
для двухсторонней ассоциации могут быть три подхода:
одностороння реализация - реализовать в виде одностороннего указателя и выполнять поиск при прослеживании в обратном направлении. используется если частота прослеживания в одном направлении сильно отличается от другого направления.
двусторонняя реализация - с указателями в обоих направлениях.
реализация при помощи объекта.
Спасибо за выдержку из книги, это ещё больше меня убеждает, что концептуальная модель отражает предметную область и её потребность. Физическая – как их реализовать, и совсем необязательно, что оно будет соответствовать концептуальной. Главное, чтобы требования были выполнены, а какими механизмами, двусторонней ассоциации или односторонней дело разработчика.
-
Спасибо за выдержку из книги, это ещё больше меня убеждает, что концептуальная модель отражает предметную область и её потребность. Физическая – как их реализовать, и совсем необязательно, что оно будет соответствовать концептуальной. Главное, чтобы требования были выполнены, а какими механизмами, двусторонней ассоциации или односторонней дело разработчика.
Трудно не согласиться. Концептуальная модель сосредотачивает внимание на том ЧТО, а не КАК. Это ясно. Кроме того концептуальная модель должна быть понятна, потому она ориентирована на понятия предметной области.
Она может быть не точной, она может быть избыточной - все это зависит от опыта, как мне думается.
Однако Вы же сами собственно начали свой первый пост именно с деталей реализации :)
Кстати направление ассоциации тоже может быть важным на уровне концептуализации, но скорее всего уже на других итерация, после более глубокого анализа.
-
Возвращаясь к поставленной задаче, если не у кого нет возражений против концептуальной модели, представленной в ответе №34, нарисовал физическую модель данных. Использовал суррогатные ключи (атрибуты с префиксом «ИД»), благодаря чему отказался от использования идентифицирующих связей, за исключением связывающей таблицы. Для сохранения ограничения композиции внешние ключи в сущностях, являющихся частями, обязательны (NOT NULL). Выскажите, пожалуйста, свои оценки и предложения.
-
Вполне нормальная схема. Теперь имеет смысл подготовить запросы в соответствии с Вашими потребностями и посмотреть насколько просто и эффективно все это будет работать
-
Ну что, на навигацию забили???
Судя по Розе (а мне кажется она все же ближе к истине), либо мы рисуем агрегацию/композицию у класса А либо мы рисуем там стрелку.
Но во всех примерах в Интете есть два разделения:
1. Либо вообще навигации нет
2. Либо навигация расположена на другом конце от агрегации/композиции
п.2 явно противоречит Розе.
-
Ну что, на навигацию забили???
Фу как грубо.
Судя по Розе (а мне кажется она все же ближе к истине), либо мы рисуем агрегацию/композицию у класса А либо мы рисуем там стрелку.
Но во всех примерах в Интете есть два разделения:
1. Либо вообще навигации нет
2. Либо навигация расположена на другом конце от агрегации/композиции
Агрегация и композиция вообще указывает на то, что целое должна быть обязательна. Часть может быть и не обязательной, но хоть что-то должно туда входить :-)
Если моделировать БД - то это однозначно говрить о миграци первичного ключа целой части в каждую ее часть, такми образом прослеживаемость должна быть от части к целому. Часть должна знать к какому целому она принадлежит.
Если рассуждать как ты говоришь, то кажется это тоже имеет смысл. При задании класса целого мы включаем в него атрибуты указатели на его части. Такми образом с точки зрения реализации класса навигация от целого к части кажется более убедительной чем наоборот.
Из этого спича можно заключить навигация важна именно в момент реализации и сильно зависит от способа реализации. IMHO конечно
-
Из этого спича можно заключить навигация важна именно в момент реализации и сильно зависит от способа реализации.
если вы ведете речь о навигации, как возможности перехода от объекта А к соответствующему объекту Б (вспоминая пользователь-пароль), то проектированием структуры таблиц этого не добиться, в ход уже идет предоставление/не_предоставление UI (доступы к запросам/данным через хранимки и т.п., как пример, отсутствие возможности сделать выборку пользователей по паролю и т.д.)