Создание машины состояний
В нашем примере дополним класс Дисциплина новыми возможностями. Каждая дисциплина будет иметь определенный статус. Возможно добавление дисциплины преподавателю (состояние Выбран преподаватель). После чего она может быть принята на рассмотрение (состояние Выбрана дисциплина), затем либо назначена преподавателю (состояние Назначена), либо отклонена (состояние Отклонена). Состояние Отклонена дисциплина также получит, если сумма часов предложенных преподавателю дисциплин превысит допустимую нагрузку на преподавателя. В случае отклонения дисциплины рассматриваемый экземпляр класса Дисциплина автоматически удаляется. Покажем, как реализовать такой алгоритм исключительно на уровне модели, не прибегая к кодированию на языке Delphi.
Перейдем в модельное пространство проекта. Выберем элемент clSubjectи с помощью контекстого меню дадим командуAdd>ECOStateMachine. В рамках Проектировщика откроется новое, первоначально пустое окно. В нем будет построена соответствующая модель. Назовем модельStatesOfSubject.
Поместим на диаграмму начальное состояние Initial.
Добавим на диаграмму четыре основных состояния дисциплины с помощью инструмента State. Дадим им имена:ChosenLecturer(Выбран преподаватель),ChosenSubject(Выбрана дисциплина),Appointed(Назначена),Rejected(Отклонена).
Поместим на диаграмму конечное состояние Final.
Согласно проектной логике, свяжем эти состояния отношением-переходом с помощью инструмента Transition(см. Рисунок 9 .64).
Рисунок 9.64 – Диаграмма машины состояний
Вернемся на диаграмму классов ЕСО. Видно, что в классе Дисциплина появилось новое свойство State_1 типаString(назовем егоSubjectState), обозначающее нашу машину состояний. Теперь можно ввести выражениеOCLдля вычисляемого поля Количество рабочих часов (LectAmountHours) класса Преподаватель. В свойствеDerivationOCLэтого атрибута создадим с помощью встроенногоOCL-редактора выражение:
self.roleSubjects->select(SubjectState='Appointed').SubjAmountHours->sum
Оно означает, что в поле Количество рабочих часов каждого объекта Преподаватель будет сумма часов тех дисциплин, которые ему уже назначены (поле SubjectStateимеет значениеAppointed).
Для каждого перехода надо задать триггер.
В терминологии модели ЕСО триггер — это действие, которое производится при выполнении определенного условия и модифицирует текущее состояние (вызывает переход к другому состоянию).
Добавим в класс Дисциплина три триггера. Каждый триггер добавляют командой контекстного меню Add>Trigger. Дадим этим триггерам соответствующие имена:Choose,AppointиReject. Их свойстваAliasзаполним русскоязычными названиями: Выбрать, Назначить и Отклонить (см. Рисунок 9 .65).
Рисунок 9.65 – Список возможных состояний класса Дисциплина
Для действия «Выбран преподаватель» создавать триггер не нужно. Согласно нашей модели считается, что экземпляр класса Дисциплина получает этот статус, как только он сформирован.
Распределим триггеры по переходам на диаграмме машины состояний. Будем выбирать по очереди каждую связь (переход между состояниями) и выбирать в ее свойстве Triggerнужное имя триггера из раскрывающегося списка.
Зададим правило перехода из состояния Выбрана дисциплина в состояние Назначена. Пока что ограничений или дополнительных требований на этот переход не наложено, и пользователь может бесконтрольно менять состояние дисциплины. Правило перехода задается в свойстве Guard(сторожевое условие) в виде условного выраженияOCL:
(self.roleLecturer.LectAmountHours+self.SubjAmountHours)<=self.roleLecturer.MaxAmountHours
Данное выражение означает, что сумма рабочих часов преподавателя, претендента на ведение выбранной дисциплины, и количества часов этой дисциплины должно быть меньше или равно максимальному количеству рабочих часов преподавателя. Теперь возможность назначить дисциплину, если сумма рабочих часов превышает допустимое значение, недоступна, пока преподавателю не увеличат максимальное количество часов или не сократят количество часов для дисциплины.
Рисунок 9.66 – Добавляем триггеры и сторожевое условие к диаграмме машин состояний
- «Технологии разработки программного обеспечения»
- Оглавление
- Введение
- Анализ проблемы. Постановка задачи
- Введение
- Описание примера
- Составление списка заинтересованных лиц
- Анкетирование и проведение интервью
- Список потребностей заинтересованных лиц
- Задания
- Контрольные вопросы
- Моделирование объекта автоматизации
- Введение
- Введение в методологиюAris
- Описание инструментаAris. Начало работы
- Построение организационной модели
- Построение диаграммы цепочек добавленного качества
- ПостроениеeEpCмодели
- Описание объектов автоматизации
- Задания
- Контрольные вопросы
- Разработка модели вариантов использования и их спецификаций
- Введение
- Разработка модели вариантов использования
- Модель вариантов использования
- Построение модели вариантов использования
- Спецификация вариантов использования
- Основной поток
- Альтернативные потоки
- Специальные требования
- Пример спецификации варианта использования
- Алгоритм расчёта рейтингов
- Задания
- Пример написания раздела
- Назначение документа
- Наименование системы
- Сведения о заказчике и исполнителе
- Основания для выполнения работ, сроки и финансирование
- Основные понятия, определения и сокращения
- Актуальность разработки системы
- Назначение и цели создания (развития) системы
- Требования к содержимому раздела
- Пример написания раздела
- Характеристики объекта автоматизации
- Требования к содержимому раздела
- Пример написания раздела
- Организация и планирование научно-исследовательской и инновационной деятельности
- Исполнители научно-исследовательских работ
- Учет и отчетность по научно-исследовательским работам
- Требования к системе
- Требования к содержимому раздела
- Пример написания раздела
- Требования к системе в целом
- Требования к структуре и функционированию системы
- Требования к численности и квалификации персонала
- Требования к функциям (задачам)
- Описание вариантов использования
- Состав и содержание работ по созданию системы
- Требования к содержимому раздела
- Пример написания раздела
- Порядок контроля и приемки системы
- Требования к содержимому раздела
- Пример написания раздела
- Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- Требования к содержимому раздела
- Пример написания раздела
- Создание служб необходимых для функционирования системы
- Функциональные этапы внедрения системы
- Требования к документированию
- Требования к содержимому раздела
- Пример написания раздела
- Паспорт системы
- Общее описание системы
- Руководство администратора
- Руководство пользователя
- Регламент эксплуатации
- Источники разработки
- Правила оформления
- Задание
- Бизнес-логика
- Объектно-реляционное отображение
- Структура бд
- Создание проекта вBorlandDeveloperStudio
- Добавление нового модуля в проект
- Создание классов с помощью диаграммыUml
- Добавление полей
- Добавление свойств
- Добавление процедуры
- Добавление функции
- Создание отношений между классами
- Ассоциация
- Агрегация
- Наследование
- Пример создания классов
- Создание классов и отношений между ними слоя объектно-реляционного отображения
- Создание классов слоя бизнес-логики
- Невизуальные компоненты интерфейса используемые в примере
- TimageList
- TActionManager
- Визуальные компоненты используемые в примере
- TBitBtn
- TdbGrid
- TcomboBox
- TPageControl
- Пример разработки интерфейса
- Главная форма
- Форма редактирования параметров студента
- Форма редактирования книг
- Форма отображения списка книг
- Подключение классов
- Сохранение проекта
- Задание
- Шаблоны проектирования
- Шаблон InformationExpert(информационный эксперт)
- Преимущества
- Шаблон Creator(создатель)
- Преимущества
- Шаблон LowCoupling(слабое связывание)
- Преимущества
- Шаблон HighCohesion(высокое зацепление)
- Преимущества
- Шаблон Controller(контроллер)
- Преимущества
- Применение шаблонаInformationExpert
- Применение шаблонаCreator
- Использование шаблонаHighCohesion
- Применение шаблонаController
- Задание
- Технология eco
- Язык объектных ограничений ocl
- Mdi-контейнеры
- Создание простого mda-приложения
- Основные этапы разработки приложения
- Обзор возможностей Borland Developer Studio 2006 для разработки mda-приложения
- Создание моделиUml
- Создание бд и настройкаEcOкомпонент
- Создание интерфейса
- Связывание интерфейса с моделью
- Создание логики наOcl
- Задания
- Контрольные вопросы
- РазработкаMda-приложения с использованием машин состояний
- Введение
- Автоматы
- Состояния
- Подавтоматы
- Диаграммы состояний
- Создание mda-приложений с использованием машин состояний
- Модификация модели uml
- Создание машины состояний
- Обновление базы данных
- Модификация пользовательского интерфейса
- Связывание интерфейса с моделью
- Применение автоформ
- Расширение пользовательского интерфейса
- Задания
- Контрольные вопросы
- Расширенные возможности разработкиMda-приложений
- СозданиеMda-приложения с расширенными возможностями
- Модификация моделиUml
- Программное добавление объекта
- Программное удаление объекта
- Программное редактирование объекта
- Работа со справочником
- Поиск объектов
- Задания
- Контрольные вопросы
- Заключение
- Библиографический список