Определение уровней в репозитории, рекомендации по делени. модели на конфигурации, стадии, системы и распределение модели на диаграммах

Уровни репозитория

Репозиторий представляет собой хранилище всей информации о моделях. Информация в репозитории хранится в иерархическом виде по следующим уровням:

Номер уровня Описание
Уровень 1 Репозиторий - обеспечивает логическое деление на группы проектов. Пользователь может выбирать репозитории из меню “Репозиторий/выбрать репозиторий”.
Уровень 2 Проекты - содержат всю информацию в рамках отдельных разработок.
Уровень 3 Конфигурации. Конфигурации являются удобным инструментом для управления версиями выпускаемых моделей или ПО и тому подобных задач.
Уровень 4 Стадии. Служат для управления жизненным циклом проекта.
Уровень 5 Системы. Система является самым нижним уровнем в иерархии проекта и содержит информацию непосредственно о модели: диаграммы в нотации UML, и другие объекты.

Рекомендуемое деление конфигураций на стадии

Flexberry Designer никаким образом не навязывает какого-либо жизненного цикла производства программного обеспечения, однако мы рекомендуем “по-крупному” следующие стадии внутри конфигураций:

  • Обследование, где определяются: функционал, требования, основные предметные сущности, и рамки проекта;
  • Анализ и проектирование, где проясняются детальные предметные характеристики и функционал системы, детально “прорисовывается” модель системы.
  • Объектный дизайн, где модель системы приводится к формальному виду, пригодному для генерации с неё структур баз данных и исходного кода системы.

Создать стадию можно следующим образом: выделить конфигурацию и нажать кнопку Создать.

Стадии могут быть двух типов:

  • Стадия для анализа и создания “базового” приложения. Отмечена буквой D (1 на рисунке выше).
  • Стадия для анализа. Генерация БД и собственно приложения недоступна. Отмечена буквой А (2 на рисунке выше).

Стадия для анализа может быть преобразована в полную версию:

Рекомендуемое деление стадии объектного дизайна на диаграммы и системы

Следует понимать, что когда на какую-либо диаграмму добавлены новые классы и связи между ними (например), реально, они не принадлежат диаграмме. Такие классы и связи принадлежат стадии, в которой находится эта диаграмма. Стадия хранит модель, а диаграммы являются лишь теми или иными отображениями частей этой модели. Это можно легко проверить:

  • создать одну диаграмму классов,
  • нарисовать на ней класс,
  • назвать его,
  • заполнить атрибутами
  • и сохранить диаграмму.

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

Когда выполняется генерация исходного кода, генератор не анализирует диаграммы, а анализирует структуру модели, находящейся непосредственно в стадии.

Таким образом, элементы модели уникальны в пределах стадии. Модель может быть распределена по диаграммам и системам любым удобным способом.

Однако существует ряд правил:

  • В системах должны быть выделены логически обоснованные части;
  • На отдельных диаграммах размещаются:
    • Модель предметной структуруры (уровень данных)
    • Типы данных;
    • Формы (пользовательский интерфейс);
    • Бизнес-логика;
    • Приложения.