Путаница относительно отношений ассоциации в UML - PullRequest
1 голос
/ 20 марта 2019

Для начала, я действительно запутался между отношениями ассоциации между классами в UML, поскольку существует однонаправленная и двунаправленная связь.

Я составил простой пример:

enter image description here

Но я просмотрел несколько примеров в Интернете, и яВыяснилось, что в большинстве примеров используется однонаправленная связь между классом Patient и классом Doctor.

Когда я интерпретирую диаграмму, я интерпретирую ее так, чтобы «класс пациента знал о классе доктора, а класс доктора не знал о классе пациента».Но это все еще не имело особого смысла, поскольку почему класс доктора не знал о классе пациента?

Может кто-нибудь объяснить мне более подробно?Это будет высоко ценится.

Ответы [ 2 ]

3 голосов
/ 21 марта 2019

Интерпретация вашей диаграммы

Ваша диаграмма говорит, что:

  • a Doctor может иметь несколько Patients, но имеет по крайней мере один (кратность 1..n)
  • a Patient может иметь несколько Doctors и не может иметь ни одного (кратность 0..n)
  • a Doctor attends to a Patient
  • a Patient объект может найти связанные Doctor объекты (стрелка навигации в конце ассоциации)
  • ничего не сказано о том, может ли Doctor найти его / ее Patient s (отсутствие каких-либо признаков навигации на другом конце ассоциации). Итак, мы не знаем

Потенциальные проблемы на вашей диаграмме

Во-первых, существует явная путаница относительно того, где разместить множественность, потому что у вновь назначенного врача может не быть пациента, когда он / она начинает свою практику. И наоборот, пациент без врача - это не пациент, а здоровый человек. Так что имейте в виду, что кратность находится рядом с целью : так что 1..n - это число Patients для Doctor, а не наоборот.

Тогда треугольник рядом с надписью «присматривает» указывает на смысл чтения. Вот оно Doctor attends to Patient. Но в целом, это пациенты, которые обращаются к врачам. Таким образом, треугольник должен быть на другой стороне и симметричен тому, который вы нарисовали. (извините этот последний пункт был в порядке , я все еще могу улучшить свой английский; -) * * 1052

Вопрос о судоходстве

Теперь к навигации . Диаграмма показывает, что Patient знает и может найти ассоциированные Doctor s. В системе регистрации больниц имеет смысл, когда пациент приходит и не помнит имя доктора, чтобы искать потенциальных врачей.

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

Может быть, есть обратная навигация, но она не явная (потому что ящик предположил, что это было так очевидно). Может быть, в этом направлении нет судоходства. Так что Doctor не знает его Patients. Это может иметь смысл, например, если система регистрации больниц считает, что Пациент - это Пациент больницы, и взаимодействие всегда должно проходить через администрацию. Doctor может в таком случае иметь навигационную связь с Appointment, которая имеет навигационную ассоциацию с Patient или другим видом косвенная навигация .

0 голосов
/ 20 марта 2019

Термины «однонаправленная ассоциация» и «двунаправленная ассоциация» не используются / не определены в UML. Скорее, они ссылаются на то, как в ООП реализована ассоциация с одним опорным свойством или парой взаимно обратных опорных свойств (см. Также это руководство ).

В концептуальной модели нас не волнуют вопросы типа «знает ли класс пациентов о классе доктора?». Скорее, мы просто моделируем тот факт, что существует связь между двумя классами.

Вопрос, если в отношении ассоциации между A и B, A «знает о» B лучше сформулировать так: нужен ли экземплярам A прямой доступ к экземплярам B? В этом случае мы добавили бы ссылочное свойство A::b, чтобы иметь возможность прямого доступа / извлечения всех связанных B объектов. Это можно выразить в диаграмме классов, поместив маленькую точку на стороне B ассоциации (называемой «точкой конечной собственности ассоциации» в UML).

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

...