3.2.Диаграмма переходов состояний
Диаграмма переходов состояний является графической формой представления конечного автомата – математической абстракции, используемой для моделирования детерминированного поведения технических объектов или объектов реального мира.
На этапе анализа требований и определения спецификации диаграмма переходов состояний демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий. Под управляющими воздействиями или сигналами в данном случае понимают управляющую информацию, получаемую системой извне, например, управляющими воздействиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воздействие, разрабатываемая система должна выполнить определенные действия, а затем, или остаться в том же состоянии, или перейти в другое состояние, зафиксировав некоторые изменения в системе.
Для построения диаграммы переходов состояний необходимо в соответствие с теорией конечных автоматов определить основные состояния, управляющие воздействия (или условия перехода), выполняемые действия и возможные переходы разрабатываемого ПО. Условные обозначения, используемые при построении диаграмм переходов состояний, показаны на рис. 3.3.
Для интерактивного ПО с развитым пользовательским интерфейсом основные управляющие воздействия – команды пользователя, для ПО реального времени – сигналы от датчиков и/или оператора производственного процесса. Общим для этих типов ПО является наличие состояния ожидания, когда система приостанавливает работу до получения очередного управляющего воздействия (рис. 3.4). Для интерактивного ПО наиболее характерно получение команд различных типов, а для ПО реального времени – однотипных сигналов, либо от многих датчиков, либо требующих продолжительной обработки.
В отличие от интерактивных систем для систем реального времени обычно установлено более жесткое ограничение на время обработки полученного сигнала. Такое ограничение часто требует выполнения дополнительных исследований поведения системы во времени, например, с использованием сетей Петри или марковских процессов.
К ПО, при разработке которого требуется уточнение особенностей поведения посредством построения диаграммы переходов состояний, относится и ПО, ориентированное на работу в сети. При этом обычно отдельно строят модели поведения сервера и клиента, представляя сообщения, передаваемые между ними в виде управляющих воздействий.
Пример 3.1. Рассмотрим диаграмму переходов состояний для программы построения таблиц значений и графиков функций одной переменной. Программа должна обеспечивать возможность изменения типа представления, шага и отрезка, а также сохранения введенных формул.
Программа относится к классу интерактивных, соответственно на этапе анализа и определения спецификаций целесообразно уточнить поведение программы на уровне интерфейса с пользователем. Один из возможных вариантов поведения представлен на рис. 3.5.
Полученную диаграмму переходов состояний следует согласовать с заказчиком ПО.
3.3.Функциональные диаграммы
Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого ПО. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделирования SADT (Structured Analysis and Design Technique) в 1973 году.
Отображение взаимосвязи функций активностной модели осуществляется посредством построения иерархии функциональных диаграмм.
Функциональная диаграмма представляет собой схематическое представление взаимосвязей нескольких функций. Каждый блок такой диаграммы соответствует некоторой функции, для которой должны быть определены исходные данные, результаты, управляющая информация и механизмы ее осуществления – человек или технические средства.
Все перечисленные выше связи функции представляются дугами, причем тип связи и ее направление строго регламентированы: дуги, изображающие каждый тип связей, должны подходить к блоку с определенной стороны (рис. 3.6), а направление связи должно указываться стрелкой в конце дуги.
Физически дуги трех первых типов представляют собой наборы данных, передаваемые между функциями. Дуги, определяющие механизм выполнения функции, в основном используют при описании спецификаций сложных информационных систем, которые включают как автоматизированные, так и ручные операции.
Блоки и дуги маркируются текстами на естественном языке. Дуги могут разветвляться и соединяться вместе различными способами. Разветвление означает, что часть или вся информация может использоваться в каждом ответвлении дуги. Дуга всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если ветвь дуги после ветвления не помечена, то непомеченная ветвь содержит весь набор данных. Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 3.7).
Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня детализации: диаграммы каждого следующего уровня уточняют структуру родительского блока. Построение модели начинают с единственного блока, для которого определяют исходные данные, результаты, управление и механизмы реализации. Затем он последовательно детализируется с использованием метода пошаговой детализации. При этом рекомендуется каждую функцию представлять не более чем 3–7-ю блоками. Во всех случаях каждая подфункция может использовать или продуцировать только те элементы данных, которые использованы или продуцируются родительской функцией, причем никакие элементы не могут быть опущены, что обеспечивает непротиворечивость построенной модели.
Стрелки, приходящие с родительской диаграммы или уходящие на нее нумеруют, используя символы и числа. Символ обозначает тип связи: I – входные, С – управляющие, M – механизмы, R – результаты. Число – номер связи по соответствующей стороне родительского блока, считая сверху вниз и слева направо.
Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень – А0, следующий – А1, А2 и т.п., следующий – А11, А12, А13 и т.д., где первые цифры – номер родительского блока, а последняя – номер конкретного субблока родительского блока.
Детализацию завершают при получении функций, назначение которых хорошо понятно, как заказчику, так и разработчику. Эти функции описывают, применяя естественный язык или псевдокоды.
В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и строят словарь данных, в котором определяют структуры и элементы данных, показанных на диаграммах.
Таким образом, в результате получают спецификацию, которая состоит из иерархии функциональных диаграмм, описаний функций нижнего уровня и словаря, имеющих ссылки друг на друга.
Пример 3.2. Разработку функциональных диаграмм продемонстрируем на примере уточнения спецификаций программы построения графиков и таблиц функций одной переменной (см. пример 3.1).
Диаграмма, показанная на рис. 3.8, а, является диаграммой верхнего уровня. На ней хорошо видно, что является исходными данными для программы, и получения каких результатов мы ожидаем.
Диаграмма, показанная на рис. 3.8, б, уточняет функции программы. На ней показаны четыре блока: ввод/выбор и ее разбор, добавление функции в список, построение таблицы значений и построение графика функции. Для каждого блока определены исходные данные, управляющие воздействия и результаты. Согласно правилам обозначения входов/выходов, имеющих продолжение на родительской диаграмме, на диаграмме использованы следующие обозначения: I1 – функция; I2 – отрезок; I3 – шаг; C1 – вид график/таблица; R1 – график функции на отрезке; R2 – таблица значений функции на отрезке.
Словарь в этом случае должен содержать описание всех данных, используемых в системе.
Функциональную модель целесообразно применять для определения спецификаций ПО, не предусматривающего работу со сложными структурами данных, так как она ориентирована на декомпозицию функций.
|
