Главная | Обратная связь | Поможем написать вашу работу!

Модели конечных автоматов

Модели конечных автоматов* используются для моделирования поведения системы, реагирующей на внутренние или внешние события. Такая модель показывает состояние системы и события, которые служат причиной перехода системы из одного состояния в другое. Модель не показывает поток данных внутри системы. Этот тип модели особенно полезен для моделирования систем реального времени, поскольку этими системами обычно управляют входные сигналы, приходящие из окружения системы. Например, система сигнализации, рассмотренная в главе 13, реагирует на сигналы датчиков перемещения и дверных датчиков и т.д.

* В русской научной литературе модели конечных автоматов, в том контексте, как они представлены в книге обычно просто называют диаграммами состояний, без упоминания "конечных автоматов". - Прим. ред.

Модели конечных автоматов являются неотъемлемой частью методов проектирования систем реального времени [155, 156, 338, 35*]. В работе [155] определены диаграммы состояний, которые стали основой системы нотаций в языке моделирования UML.

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

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

Реальная микроволновая печь на самом деле намного сложнее описанной здесь системы. Вместе с тем эта модель показывает все основные средства системы. Для упрощения модели я предполагаю такую последовательность действий при использовании печи.

1. Выбор уровня мощности (половинная или полная).

2. Ввод времени работы печи.

3. Нажатие кнопки запуска, после чего печь работает заданное время.

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

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

Рис. 7.5. Диаграмма состояний автомата микроволновой печи

На рис. 7.5 видно, что система первоначально реагирует на нажатие кнопок полной или половинной мощности. Пользователь может изменить свое решение после нажатия одной из этих кнопок и выбрать другую кнопку. Кнопка запуска сработает только после задания времени работы печи и закрытия двери. Нажатием кнопки запуска начинается работа печи в течение указанного времени.

Нотации UML позволяют определять действия, которые выполняются в том или ином состоянии. Но для создания системной спецификации необходима более детальная информация о стимулах и состояниях системы (табл. 7.1). Эта информация может храниться в словаре данных, как будет показано далее в этом разделе.

Таблица 7.1. Описание состояний и стимулов микроволновой печи

Состояние	Описание
Ожидание	Печь находится в состоянии ожидания входных данных. На дисплее высвечивается текущее время
Режим половинной мощности	Мощность печи устанавливается на 300 Вт. На дисплее отображается "Половинная мощность"
Режим полной мощности	Мощность печи устанавливается на 600 Вт. На дисплее отображается "Полная мощность"
Установка времени	Пользователем устанавливается время работы печи. Дисплей показывает заданное время
Выключено	В целях безопасности печь выключена. Внутренность печи освещена. Дисплей показывает "Не готов"
Включено	Питание печи включено. Внутри печи света нет. Дисплей высвечивает "Готов"
Работа	Печь работает. Внутри печи включается свет. Дисплей отображает обратный отсчет таймера. По окончании работы звучит звуковой сигнал в течение 5 секунд. Свет включен. Пока звучит сигнал, дисплей высвечивает "Приготовление закончено"
Стимулы	Описание
Половинная мощность	Пользователь нажимает кнопку режима половинной мощности
Полная мощность	Пользователь нажимает кнопку режима полной мощности
Таймер	Пользователь нажимает одну из кнопок таймера
Число	Пользователь вводит число
Дверь открыта	Переключатель двери печи в состоянии "Не закрыто"
Дверь закрыта	Переключатель двери печи в положении "Закрыто"
Запуск	Пользователь нажимает кнопку запуска
Отмена	Пользователь нажимает кнопку отмены

Основная проблема метода конечного автомата состоит в том, что число возможных состояний может быть очень велико. Поэтому для моделей больших систем необходима структуризация возможных состояний системы. Один из способов структуризации состоит в использовании суперсостояний, которые объединяют ряд отдельных состояний. Такое суперсостояние подобно одному состоянию модели высокого уровня, которое детализируется на отдельной диаграмме. Для иллюстрации этого понятия рассмотрим состояние Работа модели микроволновой печи (см. рис. 7.5). Это суперсостояние более детально показано на рис. 7.6.

Рис. 7.6. Работа микроволновой печи

Состояние Работа включает ряд подсостояний. Диаграмма на рис. 7.6 показывает, что в состоянии Работа сначала проверяется готовность печи к работе и, если обнаружены какие-либо проблемы, включается аварийная сигнализация и печь выключается. В состоянии Нагрев работает микроволновой генератор в течение указанного времени, по завершении его работы автоматически подается звуковой сигнал. Если во время работы печи будет открыта дверь, система переходит в состояние Выключено, как показано на рис. 7.5.

Модели данных

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

Наиболее широко используемой методологией моделирования данных является моделирование типа "сущность-связь-атрибут", которое показывает структуру данных, их атрибуты и отношения между ними*. Этот метод моделирования был предложен в середине 1970-х годов Ченом (Сhen, [71]); с тех пор разработано несколько вариантов этого метода [76,154,170,1*].

* К сожалению, автор не приводит определения понятий "сущность", "связь" и "атрибут", хотя в рассматриваемых методах моделирования они являются базовыми и строго формализованы. Приведем их краткое описание. Сущность (entity) - реальный или абстрактный объект, имеющий определяющее значение для рассматриваемой системы (это может быть объект как самой системы, так и ее окружения). Каждая сущность должна иметь уникальное имя и обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь. Сущность соответствует классу (или типу) объектов, а не конкретному экземпляру класса. Связь (relation) - поименованная связь (ассоциация) между двумя сущностями. Именование связей осуществляется с помощью глаголов (например, имеет, определяет, принадлежит и т.п.). Атрибут (attribute) - любая характеристика сущности (предназначается для идентификации, классификации, численной параметризации или описания состояния сущности). Значения атрибутов однозначно идентифицируют экземпляр сущности. - Прим. ред.

Язык моделирования UML не имеет определенных обозначений для этого типа моделей данных, что желательно для объектно-ориентированного процесса разработки ПО, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моделей данных можно использовать модели классов UML совместно с именованными ассоциациями между классами. Хотя такие модели данных не могут служить примером "хорошего" языка моделирования, удобство использования стандартных обозначений UML перевешивает возможные несовершенства таких конструкций.

Для описания структуры обрабатываемой информации модели данных часто используются совместно с моделями потоков данных. На рис. 7.7 представлена модель данных для системы проектирования ПО. Такую систему можно реализовать на основе комплекса инструментальных CASE-средств, показанного на рис. 7.4.

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

Рис. 7.7. Модель данных для системы проектирования ПО

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

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

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

Перечислим преимущества использования словаря данных.

1. Существует механизм управления именами. При разработке большой системной модели, вероятно, придется изобретать имена для сущностей и связей. Эти имена должны быть уникальными. Программа словаря данных может проверять уникальность имен и сообщать об их дублировании.

2. Словарь может служить хранилищем организационной информации, которая может связать анализ, проектирование, реализацию и модернизацию системы. Вся информация о системных объектах и сущностях находится в одном месте.

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

В примере словаря данных, приведенном в табл. 7.2, представлены имена, взятые из модели данных системы проектирования (см. рис. 7.7). Это упрощенный пример, где опущены некоторые имена и сокращена соответствующая информация.

Таблица 7.2. Пример словаря данных

Имя	Описание	Тип	Дата
имеет метки	Отношение 1:N между сущностями типа Узел или Связь и сущностями типа Метка*	Связь	5.10.1998
Метка	Содержит информацию об узлах и связях. Метки представляются пиктограммами и соответствующим текстом	Сущность	8.12.1998
Связь	Отношение 1:1 между сущностями, представленными узлами. Связи имеют тип и имя	Связь	8.12.1998
имя (метка)	Каждая метка имеет имя, которое должно быть уникальным	Атрибут	8.12.1998
имя (узел)	Каждый узел имеет имя, которое должно быть уникальным. Имя может содержать до 64 символов	Атрибут	5.11.1998

* "Отношение 1:N" - это сокращение от "отношение один-ко-многим". Аналогично "отношение 1:1" (см. далее в таблице) - "отношение один-к-одному ". - Прим. ред.

Объектные модели

Объектно-ориентированный подход широко используется при разработке программного обеспечения, особенно для разработки интерактивных систем. В этом случае системные требования формируются на основе объектной модели, а программирование выполняется с помощью объектно-ориентированных языков, таких, как Java или C++.

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

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

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

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

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

Идентификация объектов и классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов – это основа для анализа и проектирования системы. Методы определения объектов описаны в главе 12. Здесь рассматриваются лишь некоторые объектные модели, полезные для анализа систем.

Рис. 7.8. Часть иерархии классов для библиотечной системы

Различные методы объектно-ориентированного анализа были предложены в 1990-х годах Бучем (Booch, [54]), Кодом и Джордоном (Goad and Yourdon, [74]), а также Рамбо (Rumbaugh, [302]). Эти методы имели много общего, поэтому три главных разработчика – Буч, Рамбо и Якобсон (Jacobson) – решили интегрировать их для разработки унифицированного метода [304]. В результате разработанный ими унифицированный язык моделирования (Unified Modeling Language – UML) стал фактическим стандартом для моделирования объектов. UML предлагает нотации для различных типов системных моделей. Вы уже видели модели вариантов использования и диаграммы последовательностей в главе 5, а также диаграммы состояний ранее в этой главе.

В UML класс объектов представлен вертикально ориентированным прямоугольником с тремя секциями (рис. 7.8).

1. В верхней секции располагается имя класса.

2. Атрибуты класса находятся в средней секции.

3. Операции, связанные с классом, приводятся в нижней секции прямоугольника.

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

⇐ Предыдущая 47 48 49 50 515253 54 55 56 Следующая ⇒