2. МЕТОДЫ СТРУКТУРНОГО АНАЛИЗА СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

Под структурными методами понимается совокупность методов и средств, которые позволяют выделять наиболее значимые аспекты проектируемой системы на этапе ее специфицирования. На каждой стадии определения спецификаций системы используются различные методы.
Структурные методы успешно применяются для разнообразных классов систем, таких как системы реального времени, обработки данных и управления процессами. Как правило, сложные системы состоят из большого числа как программных, так и аппаратных компонент. Эти компоненты (или подсистемы) взаимодействуют между собой. Для того чтобы будущая система смогла выполнять возложенные на нее функции, необходимо, чтобы взаимодействие между ее подсистемами было тщательно продумано и специфицировано.
Роль структурных методов в процессе специфицирования системы как раз и заключается в том, чтобы помочь разработчику определить систему в целом и разбить ее на реализуемые программно или аппаратно подсистемы. Иными словами, специфицирование системы - это определение того, ЧТО система должна делать (требования к системе) и КАКОЙ должна быть ее структура. За этапом специфицирования следуют этапы проектирования аппаратных подсистем и кодирования программных модулей.
В учебном пособии рассматриваются модели систем реального времени, основным назначением которых является специфицирование требований к функциям, выполняемым системой (модель требований) и структуре проектируемой системы (модель архитектуры системы). Ключевые особенности метода структурного анализа в нотации Hatley [ 7 ], состоят в следующем:

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

На рис. 2.1 показана взаимосвязь типов диаграмм, используемых в методе структурного анализа.

Рис. 2.1 Взаимосвязь диаграмм, используемых в структурном анализе систем реального времени.

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

• Context Diagram - контекстная диаграмма
• DCFD или Data/Control Flow Diagram - диаграмма потоков данных/управления
• STD или State Transition Diagram - диаграмма переходов в состояния
• Timing requirements - временные требования (т.е. требования на соотношения и задержки в системе, связанные с временем)
• Pspec или Process Specification - миниспецификация процесса
• Data Dictionary - словарь данных.

В следующих разделах раскрываются основные свойства данной модели, иллюстрируемые конкретными примерами.

Основным назначением данной модели является спецификация следующих двух аспектов системы :

• потоки информации в системе;
• управляющие воздействия в системе.

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

На рис. 2.2 приведен пример DFD для торгового автомата.

Рис.2.2 Диаграмма потоков данных для торгового автомата.

Для более точного описания процессов и потоков данных диаграмму необходимо сопроводить двумя дополнительными типами спецификаций :

• спецификации процессов (PSPEC - process specification);
• словарь данных (DD -data dictionary).

Спецификация процессов определяет то, каким образом каждый из определенных в системе процессов преобразует входящие в него потоки данных в выходные потоки данных. Уровень описания этого преобразования соответствует уровню самих потоков данных и может задаваться в виде таблицы решений, граф-схемы алгоритма или в виде текста на структурированном естественном языке. Например, спецификация процесса "ПРОВЕРИТЬ ОПЛАТУ" представлена на рис.2.3 в виде текста на структурированном естественном языке.

Спецификация процесса "ПРОВЕРИТЬ_ОПЛАТУ".

СПЕЦИФИКАЦИЯ ПРОЦЕССА 3 : ПРОВЕРИТЬ ОПЛАТУ.
ВХОДЫ : СТОИМОСТЬ, ОПЛАТА.
ВЫХОДЫ : СДАЧА, ДОСТАТОЧНАЯ_ОПЛАТА

Если ОПЛАТА >= СТОИМОСТЬ, то
присвоить ДОСТАТОЧНАЯ_ОПЛАТА значение "ДА"
присвоить СДАЧА значение ОПЛАТА - СТОИМОСТЬ
иначе присвоить ДОСТАТОЧНАЯ_ОПЛАТА значение "НЕТ"

В спецификации процесса "ПРОВЕРИТЬ_ОПЛАТУ" в качестве выхода указан поток "ДОСТАТОЧНАЯ_ОПЛАТА ", который является управлящим потоком и поэтому не должен отображаться на DFD. В [ 7 ] такие управляющие потоки отображаются на так называемых диаграммах потоков управления (CFD - Control flow diagram), описывающих модель ⌠параллельно■ с DFD. Возможен комбинированный подход, при котором оба типа потоков - данных и управления - отображаются на одной диаграмме (см. рис. 2.1). Далее оба подхода подробно рассматриваются в примерах. Пример модели торгового автомата следует нотации [ 7 ], а более сложный пример модели навигационного приемоиндикатора (см. пункт 3.5.3) демонстрирует второй подход к изображению потоков данных.

2.2. Контекстная диаграмма данных

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

• другие системы;
• пользователи;
• каналы информационного обмена.

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

Контекстная диаграмма данных для вышеприведенного примера изображена на рис. 2.4.

Рис.2.4 Контекстная диаграмма для модели торгового автомата

Если поток данных направлен от внешней сущности к процессу, то такая внешняя сущность именуется источником данных. Если поток данных направлен от процесса к внешней сущности, то последняя является приемником данных. Одна и та же внешняя сущность может быть одновременно приемником и источником данных.

2.3. Диаграммы потоков данных

Диаграммы потоков данных содержит объекты следующих типов :

• процессы;
• хранилища данных;
• потоки данных.

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

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

Рис.2.5 Изображение элементарных объектов DFD

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

Рис.2.6 Варианты образования и декомпозиции групп потоков данных.

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

• процессы первого уровня иерархии нумеруются с 1 до n, где n - число процессов на первом уровне иерархии модели требований ;
• номер процесса на j - ом уровне иерархии образуется как <Номер родительского процесса на уровне иерархии j - 1>.<Собственный номер на j-ом уровне>. Собственный номер является уникальным для каждого из родственных процессов и находится в диапазоне от 1 до k, где k - число родственных процессов.

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

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

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

Обычно спецификация представляется текстом на структурированном естественном языке. Структурированный естественный язык сочетает в себе строгость традиционного языка программирования с читабельностью текста на естественном языке. В тексте, написанном на структурированном естественном языке могут использоваться конструкции управления, соответствующие операторам выбора, цикла и присваивания в языке программирования. Зарезервированные слова записываются заглавными буквами:

1. Конструкция выбора:

если УСЛОВИЕ то
ДЕЙСТВИЕ1
иначе
ДЕЙСТВИЕ2
конец выбора.

Здесь УСЛОВИЕ - логический селектор, а ДЕЙСТВИЕ1 и ДЕЙСТВИЕ2 - действия, селектируемые конструкцией управления. Если значение логического выражения есть истина, то выполняется ДЕЙСТВИЕ1, иначе - ДЕЙСТВИЕ2.

2. Конструкция цикла:

пока УСЛОВИЕ выполнять
ДЕЙСТВИЕ
конец_цикла.

Здесь ДЕЙСТВИЕ выполняется пока значение логического выражения УСЛОВИЕ истинно.

3. Конструкция присваивания:

присвоить ПЕРЕМЕННАЯ значение ВЫРАЖЕНИЕ.

Здесь ПЕРЕМЕННАЯ является именем выходного потока или является локальной для данного процесса. Подобные переменные иногда применяют для упрощения записи, хотя в большинстве случаев их применение излишне.

4. Конструкция, указывающая возможность параллельного выполнения действий:

выполнять_параллельно
ДЕЙСТВИЕ 1
ДЕЙСТВИЕ 2
ДЕЙСТВИЕ 3
конец_параллельного_выполнения

В комментариях, которые начинаются знаком /* и заканчиваются знаком */ обычно указывают расчетные формулы, диаграммы и таблицы.

В выражениях и условиях могут встречаться имена локальных переменных, входящих и выходящих потоков, а также математические и логические символы (+, -, >, <, *, / и т.п.). Как правило, имена входных и выходных потоков пишутся заглавными буквами. Локальные переменные, если они используются. лучше писать прописными буквами, что позволит легко отличать их от потоков данных модели.

Словарь данных описывает каждый поток данных, определенный в системе. Пример описания декомпозиции сложных потоков данных на составные приведен на рис. 2.7.

ПРЕДМЕТЫ = МОНЕТЫ + НЕ_ДЕНЬГИ

МОНЕТЫ = [ РУБЛИ | КОПЕЙКИ | ГРИВЕННИКИ]

ТОВАРЫ = [ ШОКОЛАДКИ | КОНФЕТЫ | ЛИМОНАД ]

Рис.2.7 Описание составных потоков данных

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

• единицы измерения;
• диапазон значений;
• разрешающая способность;
• частота измерения.

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

Для дискретных примитивов множество атрибутов следующее :

• число значений;
• список значений;
• частота измерения.

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

Таблица 2.1

Таблица 2.2

Составные потоки определяются через примитивы или уже определенные составные потоки. Для описания структуры таких потоков используется специальная нотация. При описании составного потока допускается использование имен определенных в словаре потоков и специальных символов. Специальные символы и их значения приведены в таблице 2.3.

Таблица 2.3

Таблица специальных символов словаря

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

Для описания управляющих воздействий в системе используются следующие два средства :

• диаграмма потоков управления (CFD);
• спецификация управляющего процесса, определяющая управление в системе.

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

Ниже на рис. 2.8 показано взаимодействие модели управления с моделью обработки данных в виде классической реализации петли обратной связи.

Рис. 2.8 Взаимодействие моделей обработки данных и управления

Итак, входные данные в систему перерабатываются моделью обработки данных в выходные данные, однако некоторые процессы вырабатывают еще и потоки управления (условия как некоторые логические предикаты ⌠обычных■ потоков данных и события как изменения значений этих предикатов). В качестве управляющих входов может рассматриваться, например, переключение режимов системы, задаваемое извне.

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

   Модель управления представляет собой некоторый аналог описания функционирования конечного автомата (старая трактовка) или описания модели состояний (более новая). Главные цели модели управления в изложенной интерпретации следующие:

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

По аналогии с описанием обрабатывающего процесса в виде его спецификации PSpec, описание управляющего процесса обозначается как CSpec. Описание может включать в себя такие компоненты, как таблицы событий, таблицы решений, таблицы переходов в состояния, диаграммы переходов в состояния (STD). Вариант STD, реализованный в Select Yourdon Tool, является достаточно мощным средством для описания произвольного управляющего процесса на высоком уровне абстрагирования, поэтому далее в примерах мы будем рассматривать только форму описания в виде STD.

На рис. 2.9 приведен пример CFD для торгового автомата.

Рис.2.9 Диаграмма потоков управления торгового автомата

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

Контекстная диаграмма управления является подвидом диаграммы потоков управления. Отличие диаграммы данного вида от контекстной диаграммы данных состоит в том, что на ней вместо потоков данных изображаются потоки управления в системе. Контекстная диаграмма данных для рассмотренного ранее торгового автомата изображена на рис. 2.10.

Рис.2.10 Контекстная диаграмма управления для торгового автомата.

Спецификации управляющих процессов задаются при помощи диаграмм переходов состояний и таблиц активизации процессов. Диаграммы переходов состояний системы удобно представлять в виде конечного автомата. Потоки управления, оканчивающиеся на CFD линией или исходящие из линий являются входными и выходными сигналами конечных автоматов. Конечный автомат представляется либо в виде графа переходов или в табличном виде. Граф переходов конечного автомата для торгового автомата представлен на рис.2.11.

Рис.2.11 Диаграмма переходов в состояния для торгового автомата

Граф переходов определяет все возможные состояния системы и как осуществляются переходы из состояния в состояние под воздействием управляющих сигналов. Каждому переходу на графе соответствует метка "Событие / Действие".

Таблица активизации процессов определяет условия при которых процессы на DFD запрещены и разрешены. Условиями запрета или разрешения процессов являются действия из диаграммы переходов состояний. Запрет процесса означает то, что процесс не производит операций по преобразованию входящих в него потоков данных в выходные потоки данных. Столбцы таблицы соответствуют процессам, а строки - действиям. Единица в клетке таблицы [i, j] означает, что при генерации управляющего воздействия, соответствующего i-ой строке таблицы, процесс, соответствующий столбцу j, разрешен, а нуль - запрещен. Ниже приводится таблица 2.4 активизации процессов для торгового автомата.

Таблица 2.4

Как и в случае DFD, CFD дополняются словарем требований, содержащим описания всех потоков управления на диаграмме. Пример описания потоков управления в словаре требований приведен в таблице 2.5.

Таблица 2.5

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

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

Таким образом, модель требований к системе описывает следующие аспекты системы :

• потоки данных в системе (DFD);
• спецификации процессов обработки данных (PSPEC);
• потоки управления в системе (CFD);
• спецификации управляющих процессов в системе (STD и таблицы активизации процессов).

Взаимосвязь вышеуказанных понятий приведена на рис. 2.12.

Рис.2.12 Структура модели требований

2.10. Модель архитектуры системы

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

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

Основным средством для представления модели архитектуры системы является диаграмма межмодульных потоков (AFD - architecture flow diagram). AFD показывает разбиение системы на составляющие (или модули) и информационные потоки между ними. AFD предназначена для распределения функциональных требований, описанных в модели требований, между физическими сущностями системы и, в случае необходимости, добавления новых процессов для обеспечения новых физических интерфейсов, не описанных в модели требований. На рис.2.13 представлена AFD для торгового автомата.

Рис.2.13 Диаграмма межмодульных потоков торгового автомата

AFD дополняется спецификациями модулей (аналог PSPEC в модели требований) и словарем архитектуры (AD - architecture dictionary). Спецификация модуля описывает его входы и выходы и содержит информацию о том какие процессы из модели требований размещаются в данном модуле. Пример спецификации модуля приведен на рис.2. 14.

СПЕЦИФИКАЦИЯ_МОДУЛЯ : КОНТРОЛЛЕР_ВЫДАЧИ_ТОВАРОВ
ВХОДЫ : ИНФОРМАЦИЯ_О_ВЫБОРЕ_КЛИЕНТА
ДАННЫЕ_ОБСЛУЖИВАНИЯ
ИНФОРМАЦИЯ_О_НАЛИЧИИ_ТОВАРОВ
ДАННЫЕ_О_ПРИНЯТОЙ_ОПЛАТЕ
ВЫХОДЫ : ИНФОРМАЦИЯ_О_ТОВАРЕ
ИНФОРМАЦИЯ_О_ПРОДАННОМ_ТОВАРЕ
ЗНАЧЕНИЕ_ВОЗВРАЩАЕМЫХ_ДЕНЕГ
РАЗМЕЩЕННЫЕ_ПРОЦЕССЫ : 1.2, 3, 4, 5.1, 5.2, 5.3

Рис. 2.14. Пример спецификации модуля

AD содержит определения потоков управления и данных из модели требований и, в дополнение к этому, какие модули AFD являются входными и выходными для этих потоков. В таблице 2.6 приведен пример фрагмента словаря архитектуры системы.

Таблица 2.6

В дополнение к определению физических сущностей, из которых состоит система (модулей) и потоков между ними, требуется указать, каким образом обеспечивается поток информации между модулями. Для этой цели составляется диаграмма межмодульных связей (AID - architecture interconnect diagram) и спецификации межмодульных связей. На AID отображаются физические информационные каналы, посредством которых осуществляется межмодульное взаимодействие. Спецификации межмодульных связей - это описание в текстовом виде характеристик физических информационных каналов. На рис. 2.15 и рис. 2.16 представлены, соответственно, диаграмма межмодульных связей и пример спецификации межмодульной связи.

Рис.2.15 Пример диаграммы межмодульных связей

СПЕЦИФИКАЦИЯ_КАНАЛА : КАНАЛ_ВЫДАЧИ_ТОВАРОВ

Информация по данному каналу будет посылаться в виде дискретного сигнала, последовательным кодом. Информация о товаре кодируется при помощи 8 бит, всего возможно 256 возможных комбинаций.
Характеристики данного канала:
Уровень логической "1" : 5 +- 0.2 В
Уровень логического "0" : 0 В

Рис. 2.16 Пример спецификации межмодульной связи

В AD вносится информация о соответствии абстрактных потоков данных и управления физическим каналам. Таблица 2.7 дает пример фрагмента AD, дополненного информацией о привязке абстрактных потоков физическим каналам.

Таблица 2.7

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

Модель требований и модель архитектуры в совокупности образуют общую модель спецификации системы. В процессе проектирования спецификаций системы модель требований и модель архитектуры создаются параллельно. При создании модели архитектуры модель требований размещается по физическим модулям. Однако при этом модель архитектуры дополняется следующими аспектами:

• определение интерфейса пользователя с системой;
• организация ввода-вывода;
• обслуживание системы, встроенное тестирование и обработка отказов в системе.

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