Уровни репозитория
Репозиторий представляет собой хранилище всей информации о моделях. Информация в репозитории хранится в иерархическом виде по следующим уровням:
| Номер уровня | Описание |
|---|---|
| Уровень 1 | Репозиторий - обеспечивает логическое деление на группы проектов. Пользователь может выбирать репозитории из меню “Репозиторий/выбрать репозиторий”. |
| Уровень 2 | Проекты - содержат всю информацию в рамках отдельных разработок. |
| Уровень 3 | Конфигурации. Конфигурации являются удобным инструментом для управления версиями выпускаемых моделей или ПО и тому подобных задач. |
| Уровень 4 | Стадии. Служат для управления жизненным циклом проекта. |
| Уровень 5 | Системы. Система является самым нижним уровнем в иерархии проекта и содержит информацию непосредственно о модели: диаграммы в нотации UML, и другие объекты. |
Рекомендуемое деление конфигураций на стадии
Flexberry Designer никаким образом не навязывает какого-либо жизненного цикла производства программного обеспечения, однако мы рекомендуем “по-крупному” следующие стадии внутри конфигураций:
- Обследование, где определяются: функционал, требования, основные предметные сущности, и рамки проекта;
- Анализ и проектирование, где проясняются детальные предметные характеристики и функционал системы, детально “прорисовывается” модель системы.
- Объектный дизайн, где модель системы приводится к формальному виду, пригодному для генерации с неё структур баз данных и исходного кода системы.
Создать стадию можно следующим образом: выделить конфигурацию и нажать кнопку Создать.
Стадии могут быть двух типов:
- Стадия для анализа и создания “базового” приложения. Отмечена буквой D (1 на рисунке выше).
- Стадия для анализа. Генерация БД и собственно приложения недоступна. Отмечена буквой А (2 на рисунке выше).
Стадия для анализа может быть преобразована в полную версию:
Рекомендуемое деление стадии объектного дизайна на диаграммы и системы
Следует понимать, что когда на какую-либо диаграмму добавлены новые классы и связи между ними (например), реально, они не принадлежат диаграмме. Такие классы и связи принадлежат стадии, в которой находится эта диаграмма. Стадия хранит модель, а диаграммы являются лишь теми или иными отображениями частей этой модели. Это можно легко проверить:
- создать одну диаграмму классов,
- нарисовать на ней класс,
- назвать его,
- заполнить атрибутами
- и сохранить диаграмму.
Затем создать другую диаграмму классов, нарисовать на ней класс, вписать в него то же имя: в нём автоматически отобразятся те атрибуты, которые введены на первой диаграмме. На самом деле это - один и тот же класс, отображённый на двух диаграммах.
Когда выполняется генерация исходного кода, генератор не анализирует диаграммы, а анализирует структуру модели, находящейся непосредственно в стадии.
Таким образом, элементы модели уникальны в пределах стадии. Модель может быть распределена по диаграммам и системам любым удобным способом.
Однако существует ряд правил:
- В системах должны быть выделены логически обоснованные части;
-
На отдельных диаграммах размещаются:
- Модель предметной структуруры (уровень данных)
- Типы данных;
- Формы (пользовательский интерфейс);
- Бизнес-логика;
- Приложения.