Спецификации управления

Диаграмма потоков управления (CFD)

Процессы, изображаемые на CFD являются в точности теми же самыми, как и на DFD, и поэтому имеют такие же номера и имена. Однако, в отличие от своих “близнецов” на DFD, эти процессы вырабатывают потоки управления в системе.

В DFD процессы взаимодействуют посредством передачи данных (сплошные стрелки), а в CFD – посредством передачи управления (пунктирные стрелки).

Стрелки показывают направление и способ передачи данных или управления (синхронный или асинхронный). Очень часто при проектировании встраиваемых систем смешивают DFD и CFD в рамках одного рисунка.

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

Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками на управляющем процессе-предке. Для этой цели обычно используются диаграммы переходов состояний (STD).С помощью STD можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены.STD состоит из следующих объектов:Состояние - может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.Начальное состояние - узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет только одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так: и внутри моделируемой системы При выполнении некоторого условия (например, СЧЕТЧИК=999 или КНОПКА НАЖАТА). Следует отметить, что не все события вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.условие представляет собой событие (или события),вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например "ПАРОЛЬ"=666, где ПАРОЛЬ - входной поток.Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. То есть действие – это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока то имя этого потока должно заключаться в кавычки например: "ВВЕДЕННАЯ КАРТА" = TRUE , где ВВЕДЕННАЯ КАРТА - выходной поток.Кроме того, для спецификации А-, Т-, E/D-потоков (типы управляющих потоков введены в главе 2) имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например:А: "ПОЛУЧИТЬ ПАРОЛЬ" - активировать процесс ПОЛУЧИТЬ ПАРОЛЬ.Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (производит ВЫВОД, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных на DFD), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий.На STD состояния представляются узлами, а переходы - дугами (рис. 6.1). Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и привязывается к входному состоянию).Рис. 6.1: Символы STDДиаграмма переходов состояний для примера банковской задачи приведена на рис. 6.2. Она содержит два состояния - ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты (ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА). При этом выполняется действие по запуску процесса 1.1 на рис. 2.8 (ПОЛУЧИТЬ ПАРОЛЬ). Отметим, что для запуска используется А-поток, обеспечивающий непрерывность процесса 1.1, т.е. возможность повторного ввода пароля. Переход из состояния ОБРАБОТКА в состояние ОЖИДАНИЕ осуществляется двумя различными способами. При условии трехкратного ввода неверного пароля (см. спецификацию процесса 1.1) кредитная карта удаляется из системы, при этом она переходит в режим ожидания очередного клиента. При условии КОРРЕКТНЫЙ ПАРОЛЬ выполняются действия по обеспечению требуемого сервиса (последовательное включение процессов 1.2 и 1.3) и удалению кредитной карты, и затем переход в режим ожидания очередного клиента.Рис. 6.2: STD для банковской задачиПри построении STD рекомендуется следовать правилам:· строить STD на как можно более высоком уровне детализации DFD;· строить как можно более простые STD;· по возможности детализировать STD;· использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.Применяются два способа построения STD. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех не бессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, затем следующие за ним и т.д. Результат (оба способа) - предварительная STD, для которой затем осуществляется контроль состоятельности, заключающийся в ответе на следующие вопросы:· все ли состояния определены и имеют уникальное имя?· все ли состояния достижимы? · все ли состояния имеют выход? · (для каждого состояния) реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)? · все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD?В ситуации, когда число состояний и/или переходов велико, для проектирования спецификаций управления могут использоваться таблицы и матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате. В качестве примера таблицы переходов состояний приведена таблица 6.1, соответствующая рассмотренной диаграмме переходов состояний (рис. 6.2). Первая колонка таблицы содержит список всех состояний проектируемой системы, во второй колонке для каждого состояния приведены все условия, вызывающие переходы в другие состояния, а в третьей колонке – совершаемые при этих переходах действия. Четвертая колонка содержит соответствующие имена состояний, в которые осуществляется переход из рассматриваемого состояния при выполнении определенного условия. Таблица 6.1Матрица переходов состояний содержит по вертикали перечень состояний системы, а по горизонтали список условий. Каждый ее элемент содержит список действий, а также имя состояния, в которое осуществляется переход.Используется и другой вариант данной нотации: по вертикали указываются состояния, из которых осуществляется переход, а по горизонтали - состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из "вертикального" состояния в "горизонтальное".

Общий порядок построения модели требований

Построение CASE-моделей целесообразно выполнять в следующем порядке:

1. По результатам обследования предметной области строится модель функциональной декомпозиции( FDD) объекта. На этом уровне определяются всефункции,которые выполняет объект, и процессы, протекающие в объекте (например, подразделениях предприятия) для выполнения функций, определяются связимежду функциями, между процессами. Функция- преобразование входных потоков в выходные, осуществляемое в соответствии с некоторыми внутренними правилами. Выполнение функции обеспечивает процесс. Процесс- совокупность взаимосвязанных действий (работ), преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется опре­деленными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. На этапе разработки технического задания приводится текстовое описание назначения системыв документе "Техническое задание", в разделе "Назначение и цели создания системы", подразделе "Назначение системы". Функциональные диаграммы модели являются предварительным этапом для построения диаграмм потоков данных (DFD) и позволяют получить общее представле­­ниео распределении функций и процессов.

( I - этап "Обследование объекта и обоснование необходимости создания АС"; II - этап "Разработка и утверждение технического задания на создание АС")

2. По функциональной модели (FDD) предметной области строится совокупность (иерархия) диаграмм потоков данных(DFD). Диаграммы потоков данных, используя функции, описанные на уровне функциональной модели (FDD), позволяют детализировать описание предметной областиза счет введения накопителей, потоков данных и внешних сущностей. Накопитель (хранилище) данных- приспособление для хранения информации, обладающее возможностью записи и извлечения данных. Способы доступа и хранения данных в накопителях в ходе анализа не уточняются. Хранилища являются прообразами файлов или баз данных. Поток данных- канал передачи данных от источника к приемнику. В качестве источников и приемников данных для потоков могут выступать внешние сущности, процессы и накопители. Внешняя сущность- объект, являющийся поставщиком и/или получателем информации. Например, «заказчик», «банк» и т.д. Внешние сущности обозначают источники и приемники, которые не представляют для анализа интерес в данный момент и служат для ограничения моделируемой части предметной области. Отражают взаимодействие системы с внешним миром.

3. Создается словарь данных( DataDictionary), в котором хранится и анализируется состав потоков и накопителей данных, взаимосвязь отдельных элементов потоков и накопителей данных. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.

4. Каждая логическая функция (процесс, действие, работа) может быть детализирована с помощью диаграмм потоков данных нижнего уровня, возможно с переходом на нотацию IDEF 3. Когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции(процесса, действия, работы) при помощи спецификации процесса - миниспецификации. Миниспецификация- это алгоритм описания задачи, выполняемой процессом, т.е. алгоритм преобразования входных потоков данных в выходные. Для каждого процесса нижнего уровня должна существовать одна и только одна миниспецификация . Множество всех миниспецификаций является полной спецификацией системы. Миниспецификации являются базой для кодогенерации . Решение о завершении детализации процесса с помощью диаграмм потоков данных и использовании миниспецификации принимается аналитиком исходя из следующих критериев: процесс имеет относительно небольшое количество входных и выходных потоков данных (2-3 потока); процесс выполняет единственную логическую функцию преобразования входной информации в выходную; возможно описать логику процесса при помощи миниспецификации небольшого объема (не более 20-30 строк, т.е. до одной страницы текста).

Миниспецификация содержит: списки входных и выходных данных; номер и/или имя процесса; тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные.

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

5. Хранимые в словаре данных (в репозитории) описания каждого накопителя (хранилища) данных используются для перехода к построению модели данных в виде диаграмм «сущность-связь»( ERD). В отличие от функциональных диаграмм (FDD) и диаграмм потоков данных (DFD) диаграммы «сущность-связь »(ERD) описываютинформационное пространство, в рамках которого реализуются процессы объекта предметной области. Выявляются и определяются элементы базы данных, в которых будут храниться данные системы. Выявляются и определяются их атрибуты и отношения. Модель данных должна быть привязана к функциональной модели: элементы модели данных и их атрибуты должны соответствовать накопителям данных.

6. В случае наличия реального времени диаграммы потоков данных (DFD) дополняются управляющими компонентами и спецификациями управления, например в виде диаграмм переходов состояний (STD). Событийная (поведенческая) модель описывает динамику функциониро­вания, в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Кроме диаграмм переходов состояний могут использоваться таблицы и матрицы переходов состояний.

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

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