Мальчики не ссортесь!

Вот что я нашел про навигацию в стандарте ОМГ:

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 конечно