Ограничение связи один-ко-многим в ocl - PullRequest
1 голос
/ 07 марта 2020

Я новичок в ocl и застрял в проблеме. Я построил диаграмму классов UML для школы и хочу создать ассоциацию, которая соединяет одного учителя из класса Teachers со многими учениками из класса Students.

Моя проблема не в создании ассоциации, а в создавая ограничение, которое гарантирует, что один и тот же учитель будет подключаться к точному числу учеников с их именами, скажем, например, учитель Смит будет учить группу учеников по имени (Джон, Лили, Сами, Диана), эти имена уже есть в классе учеников с другими именами студентов.

1 Ответ

0 голосов
/ 08 марта 2020

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

Например, некоторые глупые гипотетические ограничения, которые только для иллюстрации:

  • Учащиеся, посещающие курсы, старше 16 лет: { self.student.age > 16 }
  • Учитель, имеющий класс еще не на пенсии (учителя на пенсии возможны, но они не будут ассоциироваться с учениками: { self.teacher.retired = false }
  • Учитель должен быть старше, чем каждый его ученик: { self.student->forAll(age<teacher.age) }

Если вы определите очень специфическое c ограничение, оно должно быть справедливо для каждой ассоциации между учителями и учениками:

  • { self.teacher.name='Smith' and Set { 'john', 'lily', 'sami', 'diana' }->includes(self.student.name) }

Это будет очень маленькая школа или, возможно, многие ученики и учителя будут иметь одно и то же имя ;-) Это не то, для чего предназначен OCL.

Если вы хотите описать конкретный случай c в сценарии, вам не следует использовать ограничения OCL. В старом UML 1.4.x была диаграмма объекта . Это позволило нарисовать определенные c экземпляры и задокументировать их конкретное c значение в данный момент времени. На такой диаграмме у вас будет один прямоугольник для учителя Смита и 4 прямоугольника для каждого участника группы.

По-видимому, этот вид диаграммы использовался не часто: UML 2.5 вообще не упоминает об этом. Так что в принципе это не должно использоваться. Но это тоже не запрещено. Я подозреваю, что эта форма диаграммы поможет вам больше, чем OCL, если вы хотите описать конкретный случай c.

...