Порядок и особенности создания диаграммы классов для проекта

Основы работы с диаграммами классов

Диаграммы классов «от аналитика» и после объектного дизайна

Аналитик при общении с заказчиком создает с помощью диаграмм представление о предметной области, которое в последствии уточняется и дополняется разработчиком в соответствии с требованиями архитектуры и генерации будущего проекта. Проект с диаграммами от аналитика обычно в названии содержат уточнение «Как должно быть», а проект разработчика – «Реализация».

Разработчик детализирует предметную область с тем, чтобы:

  • не было связей многие-ко-многим (добавляются промежуточные классы),
  • не было связей типа агрегация (могут использоваться только ассоциация, композиция и наследование), а также связей с множественностью один-к-одному,
  • всем атрибутам был присвоен необходимый для хранения и обработки тип данных,
  • не было противоречий в структуре диаграммы, которые могут привести к сбоям генерации,
  • классы были распределены по типам (сущность, перечисление, пользовательский тип и т.д. – подробнее в рассказано в Модуле 3 в скринкасте Меню «Модель приложения»,
  • диаграммы были распределены по каталогам, уточняющим предназначение классов (справочники, описание конкретной группы классов, например, личности, территории и т.п.),
  • для класса были прописаны методы, если они необходимы на стадии проектирования и создания прототипа приложения.

Также разработчик создает формы и представления для последующей генерации прототипа будущего приложения. В следующем скринкасте мы расскажем о добавлении и редактировании классов и связей на диаграмме классов.

Добавление и редактирование классов и связей

Класс может иметь разные стеротипы: сущность, приложение, перечисление и т.д. (Подробнее в скринкасте Модуль 3. Модель приложения). Связи устанавливаются, преимущественно, между классами типа «Сущность» (implementation). Также связь может быть установлена между сущностью и интерфейсом или внешним интерфейсом.

Свойства ассоциации

  • Описание связи – пояснения к связи (например, для чего она или почему именно такая).
  • Имя роли у мастера – имя роли со стороны мастера, дублирует имя роли на диаграмме.
  • Имя публикации роли мастера – это название свойства мастера в OData-интерфейсе (это веб-ориентированный API-интерфейс для доступа к данным и манипулирования ими).
  • Множественность у мастера – может быть 0..1 (тогда в БД для основного класса значение мастера может быть Null) или 1 (тогда в БД для основного класса значение мастера может быть только Not Null).
  • Модификатор доступа мастерового свойства – это protected (#), то есть доступ ограничен содержащим классом или типами, производными от содержащего класса; public (+), то есть свойство является общедоступным; private (-), то есть доступ к свойству ограничен. Связь с мастером является хранимой – это флаг для генерации поля в БД со ссылкой на мастера
  • Имя роли у основного класса – это наименование, которое будет отображаться у основного класса в таблице. Например, для таблицы Заказ это будет Кладовщик.
  • Имя публикации роли у основного класса – это название свойства основного класса в OData-интерфейсе.
  • Множественность у основного класса – это * любое значение. Для генерации поддерживается только этот вариант. Если нужно конкретное значение, отличное от *, то надо контролировать в коде.
  • Автогенерируемый TypeUsage – идентификатор для атрибута, ограничивающего список типов в иерархии наследования.
  • TypeUsage - атрибут, ограничивающий список типов в иерархии наследования, на который распространяется данная связь. При использовании наследования возникает проблема определения нужного типа при использовании ассоциации. Другими словами, если мастером типа является тип, связанный наследованием, то непонятно, какой конкретно из типов иерархии наследования является мастером. Класс А имеет мастера М, от которого имеется, как минимум, два наследника: M1 и M2. Для разрешения проблемы можно использовать специальные метаданные, позволяющие указать, что свойство M (ссылка на мастеровой класс) в классе данных A, в данном конкретном (сугубо прикладном) случае, может принимать не только значения типа M, а ещё и M1, и M2. Это осуществляется на уровне программного кода. Соответственно, если имеется объект данных a (экземпляр класса A), то его мастером может быть экземпляр любого из классов M, M1, M2.

TypeUsage

  • Имя связи в базе данных – это имя поля в БД, в котором будет храниться ссылка на мастера

Свойства композиции

  • Описание связи - пояснения к связи (например, для чего она или почему именно такая).
  • Имя роли у агрегатора – имя роли со стороны начала композиции, дублирует имя роли на диаграмме.
  • Имя публикации роли агрегатора – это название свойства агрегатора в OData-интерфейсе.
  • Имя роли у детейла - наименование, которое будет отображаться у основного класса в таблице. Например, для таблицы СостояниеЗаказа это будет Заказ.
  • Имя публикации роли у детейла – это название свойства агрегатора в OData-интерфейсе
  • Множественность у агрегатора – всегда 1, так как в случае композиции в БД для основного класса значение мастера не может быть Null.
  • Автогенерируемый TypeUsage агрегатора – аналогично этому же свойству у ассоциации.
  • TypeUsage агрегатора – аналогично этому же свойству у ассоциации.
  • Имя связи в базе данных - это имя поля в БД, в котором будет храниться ссылка на мастера
  • Автогенерируемый TypeUsage детейла – аналогично этому же свойству у ассоциации.
  • TypeUsage детейла – аналогично этому же свойству у ассоциации.

Атрибуты и типы атрибутов классов данных

Атрибуты класса можно редактировать как со списка классов в модели приложения (Модель приложения-группа Сущности – клик по классу – Правка), так и с диаграммы (Диаграммы-соответсвующая диаграмма классов-выбранный класс-кнопка редактировать (шестеренка) – открывается аналогичная форма редактирования класса). У атрибута есть имя (то, как он будет отображен в БД и программном коде), заголовок (как наименование будет отображено в приложении), описание (например, для чего этот атрибут) и тип. Атрибут может быть хранимым и нехранимым (в таком случае его значение вычисляется в коде приложения и используется для операций в коде, без хранения в БД). Тип атрибута обязательно должен быть указан, так как это необходимо для хранения данных в БД и операций в программном коде. Flexberry Designer Online использует встроенные типы данных (string – строка, int – целое число, double – число с точкой, bool – логический и т.п., также есть типы для хранения значений null и возможность создать собственный тип).

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

Тот класс, множественность которого равна 1 (в редких случаях 0..1 для ассоциации) является главным, то есть мастером. Например, полка и товар на полке: на одной полке может быть много товаров, но один и тот же товар не может лежать на разных полках (именно товар, а не вид, то есть конкретная книга, ручка, банка и т.д.). Такая связь будет ассоциативной, так как если полка сломается, товар можно просто переложить на другу. Совсем иная ситуация будет с домом и квартирой. В одном доме может быть много квартир, но конкретная квартира всегда принадлежит одному дому, ее нельзя переместить в другой. Соответственно при исчезновении дома, квартиры тоже не будет. Такая связь называется Композицией. Соответственно класс, множественность которого может варьироваться от 0 до n будет являться подчиненным, то есть детейлом. Классам на связи можно прописать роль (задать наименование внешнему ключу БД). В примере приложения Склад (пример построения Диаграммы классов) такими ролями обладают связи от класса Сотрудник (Менеджер, Кладовщик, Бухгалтер). По имени роли будет назван столбец в таблице детейла для таблицы-мастера. Показать на диаграмме классов.

Ограничения при построении диаграммы классов

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

Пример ограничения диаграмм 1

2.Наследник от детейла не может являться детейлом наследника класса-мастера.

Пример ограничения диаграмм 2

3.Нельзя делать циклы в наследовании

Пример ограничения диаграмм 3

4.Нельзя наследовать класс от нескольких классов (у класса мб много наследников но только один родитель).

Пример ограничения диаграмм 4