28.02.2011/147

Действующая модель

Требования

Цель

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

Общие требования

Для получения готовой программы нужны следующие элементы:

• Модель
• "Преобразователь" модели в код
• Декоратор(-ы)

Программа (вообще система, не только исполняемый код или БД) описывается моделью. Модель может включать:

• Сущности и связи между ними
• Объекты
• Поток объектов
• Процессы и связи между ними

Кроме модели, нужно:

• "Преобразователь" модели в программу

Пожелания

Постараться уйти от чисто "технических" описаний атрибутов - "displayed", "read only", "mandatory" и т.п.

Модель

Объекты

Это похоже на классическое описание классов - самое простое, давно освоенное дело.

Нужно описание объектов, с которыми работает пользователь, точнее, это бизнес-сущности. Объект описывается как совокупность (агрегат) сущностей, реквизитов и связей. У объекта всегда должна быть определена главная сущность, экземпляр которой соответствует экземпляру объекта. Эта сущность может отвечать за множество объектов.

В описании объекта могут декларироваться ограничения на связи и реквизиты. Например, вводим сущность "человек", тогда объект "мужчина" - это "человек", у которого реквизит "пол" имеет значение "муж.".

Объекты классифицируются в иерархической структуре (или тэговой?). Варианты классификации:

• Стереотипы - линейный список
• Единая для всех иерархическая структура классов
• Пара "тэг-значение"
• Отдельный класс "классификатор". Создаем столько классификаторов, сколько нам надо, иерархических и нет, привязываем к ним объекты. Есть стандартные классификаторы (для облегчения первоначального заполнения), которыми можно не пользоваться.

Объект имеет текущее состояние (многосегментное?) - не понятно, надо ли, может лучше обойтись текущим положением объекта на DFD диаграмме.

Запускаем модель и можем увидеть результат - работающее приложение, пусть медленно, но работающее. Вариант (худший, но часто единственный) - через компиляцию, как в RAD.

Процессы

Процесс описывает этап обработки объекта. Как-то можно получить (от процесса или от объекта) информацию о том, какие объекты на каких этапах находятся. Нужны стандартные виды процессов. Нужно сразу классифицировать процессы, чтобы можно было группировать пункты меню по их запуску в отдельные подменю.

Выборки

Определяем выборки (view). Декоратор работает только с выборкой. Объекты включаются в выборку

• по текущему состоянию
• по текущему процессу
• объединение других выборок
• текущее положение курсора в выборке - тоже выборка
• шаблоны представления или декораторы - формочки не описываются принципиально, все должно работать по общему шаблону. Вообще шаблоны и декораторы не должны быть связаны с моделью, чтобы можно было их поменять в любой момент
• на реквизите должны быть атрибуты - показывать, не показывать, показывать в зависимости от состояния объекта... - надо посмотреть в RAD
  • для состояний (перечень отмеченных состояний с возможностью выбора всех) объекта (класс) показывать/не показывать реквизит

Действия

Важно

• клавиши и их комбинации - стратегический подход. Не описывать каждую комбинацию отдельно, а определить группы и семантику - объект имеет функции, функции сгруппированы. в зависимости от его текущего состояния
  • действия, меняющие состояние объекта
  • действия, меняющие содержимое объекта
  • действия по передаче объекта другому процессу

Группы действий (пунктов меню), по примеру IE, Outlook

• Файл - работа с документом в целом
  • создание, открытие, сохранение, удаление
  • закрытие окна с объектом
• Редактирование
  • работа с clipboard
  • функции по изменению содержимого объекта
  • поиск
• Просмотр - варианты отображения, управление декоратором
• Избранное - переход к другим представлениям, наращиваемый пользователем список
• Переход - переход к другим представлениям, статический список
• Действия
  • функции по изменению состояния объекта
• Инструменты - управление системой (специальный singletone)
• Помощь
  • вызов описания текущего контекста
  • поиск в описаниях
  • подключение и работа со сторонними описаниями и help-ами

Если действие запрещено, то оно либо не показывается, либо показывается запрещенным

Преобразователь

Способы редактирования объектов

• Форма полного редактирования. Выглядит как таблица из двух столбцов: "поле" и "значение".
• Список объектов - грид
• Другие формы, каждая имеет свое предназначение (классификация форм по цели). Одно предназначение может иметь много форм (?).

На будущее

• просмотр (отладка) выполнения программы по графической модели
• метаданные (общие правила) могут использоваться на правах read-only в других проектах

Клавиши

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

• Clipboard
• работа с окнами - переход, изменение размеров, закрыть
• операции поиска, фильтрации
• выполнение обработки объекта
• создание, сохранение, удаление объекта, перемещение его в другое место хранения, дублирование
• посмотреть детали объекта

Группа/подгруппа действий --> семантика отдельного пункта -->