Общие сведения об Ember Flexberry Designer

Запуск Flexberry Designer и создание нового проекта

Регистрация и вход во Flexberry Designer Online

Для того чтобы зарегистрироваться во Flexberry Designer и авторизоваться на портале, необходимо выполнить следующие шаги:

  1. В первую очередь нужно открыть портал flexberry.net.
  2. Далее кнопку Войти. Открыта страница авторизации и регистрации. Если регистрация уже есть, то можно авторизоваться.
  3. Отметить чекбокс Я не работ. Указать реальный электронный адрес, на него придет письмо с активацией учетной записи. Указать фио и нажмать кнопку зарегистрироваться.
  4. Система отображает уведомление, что на электронный адрес направлено письмо. Открыть почту, найти письмо от no-reply@flexberry.net, в котором есть ссылка для подтверждения записи, также приходит письмо с паролем для авторизации.
  5. Нажать на ссылку. Отображено уведомление Верификация успешно завершена. Нажать Ок.

Открыта стартовая страница Flexberry Designer Online, на котором отображены его разделы.

  • Все проекты. В этом разделе находится список всех созданных проектов.
  • Мои лицензии и обращения. В данном разделе находится список лицензий и обращений в поддержку. Лицензия нужна для Flexberry Designer Desktop. Список обращений – это все вопросы и ответы на них от службы поддержки дизайнера.
  • Flexberry Designer Desktop. В данном разделе можно скачать Flexberry Designer Desktop. Это профессиональная версия FD Online. Необходим для разработки офлайн или сложных многоструктурных приложений. Требует специальной лицензии. Для создания приложения в режиме онлайн специальной лицензии не требуется.
  • Профиль пользователя
  • Портал flexberry.net. Переводит на портал Flexberry Platform, на котором можно ознакомиться с разнообразием продуктов, разрабатываемых с помощью платформы.
  • Исходный код платформы. Клик по кнопке переводит на GitHab к системе Flexberry Platform. Здесь возможно поучаствовать в доработке продуктов платформы через систему пулл-реквестов.
  • Документация. По кнопке Документация открывается сайт с документацией по продуктам платформы Flexberry. В самом верху ссылка на документацию по работе с дизайнером.
  • Чат. Здесь расположены «комнаты», в которых можно задать интересующие вопросы о работе с дизайнером, его разработке и документации. На вопросы отвечают грамотные специалисты, которые всегда готовы помочь и поддержать.

Создание нового проекта

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

Название проекта – желательно называть проект так, чтобы было понятно, какое приложение планируется создать. При этом оно должно быть кратким и емким. Кодовое имя проекта – это то, как проект будет называться в команде. Возможно, аббревиатура или цель проекта. Если оставить пустым, поле создастся автоматически по названию проекта. Кодовое имя проекта должно быть на английском языке или записываться латиницей. Доступ – кто будет иметь возможность просматривать и редактировать проект. Описание – краткое описание проекта.

Проект можно не только создать, но и импортировать уже существующий. Для этого в поле Выбрать проект на основе сохраненного файла выбрать проект по кнопке Выбрать файл. После того, как все поля будут заполнены, проект можно будет сохранить. В последствии эти данные можно отредактировать. В результате будет открыта страница проекта, на которой в последствии будет отображен список всех созданных классов. Создание классов – это одна из основных функций Flexberry Designer Online.

Краткий обзор возможностей Flexberry Designer Online

При создании проекта открывается страница Модель приложения, которая представляет собой список классов (по сути, набор элементов), описывающих предметную область приложения и его функциональность. Flexberry Designer Online позволяет создавать разнообразные типы классов от простых сущностей (объекты приложения) и форм до собственных типов и бизнес-серверов. Классы можно также создавать во время создания диаграммы. Диаграммы позволяют не только создать классы, но и установить связи между ними, что в будущем позволит связать различные формы в приложении. Также некоторые виды диаграмм помогают детализировать предметную область, описать процессы, которые должно реализовать приложение. Навигация позволяет создать меню приложения, распределить формы по группам и/или ролям. Генерация позволяет создать рабочий прототип приложения, который пригоден для первичной демонстрации заказчику. На этой основе приложение легко дорабатывать в соответствии с пожеланиями заказчика, так как основные моменты предметной области уже отражены. Приложение можно настроить в соответствии с потребностями приложения, указать пути генерации для клиентской и серверной частей приложения, дополнить описание. Также пункт меню настройки позволяет удалить проект.

Настройки проекта

Название проекта, кодовое имя проекта и описание расшифрованы выше.

Доступ:

  • Открыт для вас – доступ к проекту будет только у вас.
  • Открыт для всего интернета – проект будет иметь открытый доступ.

Настройки генерации

Могут быть для клиентской и серверной части, если требуется разделить. Серверная часть обычно используется для сложных, «тяжелых» алгоритмов, чтобы не перегружать пользовательский интерфейс. Клиентская часть нужна для обработки «на лету». Логин, пароль для репозитория с клиентской частью и ветка для клиентской части, а также аналогичные поля для серверной части используются, если требуется генерировать приложение в уже существующий репозиторий. Если репозитория у еще нет, то при первой генерации дизайнер сам создаст новые репозитории на Githab по названию проекта (для него сгенерирует и привяжет ssh ключи сам) и сгенерирует код в созданные репозитории. Кроме того, проект может быть опубликован в gh-pages. Также возможно изменить локализацию (язык, на котором отображается дизайнер) и тему дизайнера. Для экспорта проекта нужно открыть страницу Настройки и в разделе Действия с проектом выбрать Я хочу выполнить экспорт проекта. Также можно сделать бэкап проекта по кнопке Я хочу сделать бэкап проекта.

Создание основных видов диаграмм. Основы проектирования ИС

Порядок проектирования ИС

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

  • характеристики объекта автоматизации
  • определить основную задачу, которую будет реализовывать приложение
  • описать бизнес-процессы, которые будут реализованы в приложении

Далее необходимо создать диаграмму вариантов использования, являющуюся самым общим представлением функциональных требований к системе. Она позволяет описать основные процессы, которые необходимо реализовать. Затем полезно составить диаграмму видов деятельности, представляющую собой блок-схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой. После того, как определены функциональные требования к системе и её границы, следует проанализировать предметную область с целью построения диаграммы классов. Далее полезно описать сценарии, которые необходимо реализовать в приложении, с помощью диаграммы последовательностей. Также сценарии можно описать с помощью диаграммы сотрудничества, позволяющей описать взаимодействие объектов и акцентирующей внимание в первую очередь на организации объектов. Диаграмма состояний определяет последовательность состояний объекта, вызванных последовательностью событий. Эта диаграмма позволит уточнить предметную область, дополнить, при необходимости, диаграмму классов. Диаграмма развертывания является физической диаграммой в языке UML. Она отображает физические взаимосвязи между программными и аппаратным компонентами проектируемой системы.

Постановка задачи на проектирование

Описано в статье Постановка задачи на примере.

Создание диаграммы вариантов использования

Описано в статье Построение диаграммы вариантов использования на примере.

Построение диаграммы видов деятельности

Описано в статье Построение диаграммы видов деятельности на примере.

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

Описано в статье Построение диаграммы классов на примере.

Меню Модель приложения

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

Стереотипы классов

Сущность (implementation) – класс, представляющий объект реального мира, экземпляры которого будут храниться в базе данных приложения. Создать пару.

Перечисление (enumeration) – тип данных, который определяется в виде набора идентификаторов. Создать пару.

Бизнес-класс (businessserver) – класс, код которого вызывается в процессе изменения экземпляров связанных с ним сущностей.

Тип (type) – сложный тип данных или объект реального мира, экземпляры которого не будут храниться в базе данных приложения. Целесообразно создавать, если нужны в коде вспомогательные бизнес-объекты, которые не нужно хранить в базе данных.

Typedef (typedef) - тип данных, который можно сопоставлять вручную с генерируемыми в базу данных или приложение типами данных. Нужен, если не хватает типов по умолчанию.

Интерфейс (interface) – контракт в виде перечня публичных свойств и методов, которые должны быть реализованы в связанных с ним сущностях или типах.

Внешняя сущность (external) – класс, который явно не объявлен в модели, но будет доступен в исходном коде, в том числе сущность из другого проекта. При генерации на уровне кода подразумевается, что объявление данного класса содержится во внешней или системной библиотеке. В частном случае подразумевается, что можно указать для внешнего класса ссылку на класс из другого проекта (стадии) во Flexberry Designer. В этом частном случае подразумевается, что класс на уровне кода объявлен в другом солюшене (аддоне), который должен быть подключен разработчиками к основному проекту вручную (например, через NuGet-пакет, созданный на основе другого солюшена; подключение “внешних” библиотек на уровне генерации не подразумевается). Когда это используется: ссылка на класс из других проектов (т.е. стадий) указывается тогда, когда для нескольких проектов есть какие-то общие библиотеки, и классы из неё переиспользуются в разных проектах. Другой вариант - соответствующий внешний класс представляет собой класс из системной библиотеки или любой внешней библиотеки (аддона). Тогда на уровне модели есть возможность поставить связь к внешнему классу и включить его в представление базового класса, а на уровне кода после генерации типом данных для соответствующего свойства будет являться класс, который объявлен в этой “внешней” библиотеке (подключаться она должна вручную разработчиком в проект; если это класс из системной сборки, например, то она уже при первой генерации проекта может быть автоматически уже подключена как вариант).

Приложение (application) – класс, который хранит общую информацию о генерируемом приложении.

Пользовательская форма (userform) – класс, представляющий «пустую» форму приложения (вся разметка и логика для неё должна быть сделана полностью вручную разработчиком), которая также может быть добавлена в структуру меню (в “контейнер” класса со стереотипом “application”). Можно использовать в случае, когда на уровне модели приложения необходимы специальные формы, которые ни списковыми, ни формами редактирования не являются (т.е. чтобы, глядя на модель было видно, какие формы в приложении вообще есть).

Слой гео-сервера (geolayer) – класс, который задает настройку слоя ГИС подсистемы.

Стиль слоя гео-сервера (geolayerstyle) – класс, который задает настройку слоя ГИС подсистемы.

Сущность с пользовательским стереотипом (custom) – класс с произвольной семантикой, код которого не будет генерироваться в приложение.

В списке диаграмм автоматически созданные диаграммы для каждого класса. В поле поиска на форме Модель приложения ввести наименование (или часть) класса из списка. Отображен класс (или несколько классов), отвечающий заданному условию. В поле Все типы выбрать любой из созданных типов. Отображены только классы выбранного типа.

Фильтрация и поиск диаграмм

В пункте меню Диаграммы расположены все созданные в рамках проекта диаграммы. Они отличаются по типу, имеют уникальные названия. Если список большой, то удобно воспользоваться поиском или фильтрацией. Для поиска диаграммы нужно в поле Поиск ввести наименование или часть наименования диаграммы. Список будет отредактирован в соответствии с заданным условием. Также можно отфильтровать диаграммы по типу. Для этого в выпадающем списке выбрать интересующий тип диаграммы.

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

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

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

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

  • не было связей многие-ко-многим (добавляются промежуточные классы),
  • не было связей типа агрегация (могут использоваться только ассоциация, композиция и наследование), а также связей с множественностью один-к-одному,
  • всем атрибутам был присвоен необходимый для хранения и обработки тип данных,
  • не было противоречий в структуре диаграммы, которые могут привести к сбоям генерации,
  • классы были распределены по типам (сущность, перечисление, пользовательский тип и т.д. – подробнее в рассказано в Модуле 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