Понятие мастера, детейла, связей между классами, стереотипы классов

Ключевые понятия

Структура данных определяет структуру приложения. В основу систем кладётся структура данных, выражаемая диаграммой классов UML.

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

Класс, относительно которого в конкретной ситуации рассматриваются ассоциации, называется внутренним классом, а остальные — внешними.

Вложением (подобъектом) называется атрибут класса, чей тип — другой класс.

Мастеровые ассоциации

Ассоциации, подобные ассоциации между Internal и Master1 называются мастеровыми, а внешний класс со стороны множественности 1, либо 0..1 называется мастеровым или мастером.

Мастеровая ассоциация может быть проведена между классами, каждый из которых является детейлом, а шапка у них общая. Пример этому — ассоциация Detail2-Detail3.

Детейловые композиции, агрегатор, шапка

Ассоциации агрегации или агрегации-композиции, подобные Internal-Detail1 называются детейловыми, а внешний класс — детейловым, либо просто детейлом. Внутренний класс по отношению к детейлу также называют агрегатором или шапкой.

Наследование

Ассоциации наследования, подобные Internal-InternalChild называются наследованием, внутренний класс в такой ассоциации — предок, а внешний — потомок.

При наследовании атрибутный состав и состав связей всегда расширяется и не может сокращаться.

Flexberry ORM полностью реализует объектно-ориентированную концепцию, поскольку кроме инкапсуляции и полиморфизма даёт возможность полноценно использовать наследование при объектно-реляционном отображении.

Стереотипы

Классам на диаграмме классов приписываются стереотипы, позволяющие указать назначение того или иного UML-класса.

В Flexberry Designer предопределены следующие стереотипы:

  • Implementation, стереотип по-умолчанию (на диаграммах указывается пустым значением), обычный UML-класс, реализуемый в исходный код классами объектов данных. Классы могут связываться любыми ассоциациями;
  • TypeDef, стереотип, указывающий синоним типа. При генерации кода синонимы приводятся к базовым типам целевого языка с помощью пользователя (в код попадает базовый тип, а синоним не указывается никак). На диаграммах не может быть связан никакими ассоциациями;
  • Type, стереотип, вводящий новый тип. При генерации кода на целевом языке объявляется этот тип, и при объявлениях членов классов, параметров и т.п. используется он.
  • Enumeration, стереотип, вводящий перечислимый тип. На диаграммах не может быть связан никакими ассоциациями;
  • Interface, стереотип, вводящий .Net-интерфейс. Интерфейсы могут связываться любыми ассоциациями;
  • BusinessServer, стереотип, соответствующий бизнес-серверу — .Net классу, где расположена реализация бизнес-операций прикладной системы;
  • EditForm, стереотип, соответствующий форме редактирования — .Net классу, где расположена реализация формы для редактирования объекта данных;
  • ListForm, стереотип, соответствующий форме списка — .Net классу, где расположена реализация формы для отображения списка объектов данных;
  • PrintForm, стереотип, соответствующий форме печати — .Net классу, где расположена реализация формы для печати;
  • UserForm, стереотип, соответствующий пустой форме;
  • EventArg, стереотип, соответствующий параметрам события (event), при генерации полученный класс наследуется от System.EventArgs;
  • Application, стереотип, соответствующий приложению: форме рабочего стола и настроечному классу;
  • Role, стереотип, соответствующий роли в системе полномочий;
  • External, стереотип, соответствующий любому внешнему (не объявленному в CASE, языковому) классу.
  • ExternalInterface, стереотип, соответствующий любому внешнему (не объявленному) интерфейсу.
  • Пользователь может указать произвольный стереотип.

Неочевидные ограничения объектной структуры (как не надо делать)

Нотация UML описывает назначение своих элементов, однако никак не декларирует «правильность» их использования.

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

Циклические детейлы

Детейл любого уровня не может являться наследником шапки, поскольку в таком случае получается что объект наследника должен включать сам себя.

Противоречивая агрегация

Наследник от детейла не может являться детейлом наследника шапки.

Однако

Вот такая ситуация возможна: