Составители:
требования к целевой системе разбиваются на функциональные элементы,
называемые процессами, и вся совокупность этих требований представляется в
виде сети процессов, соединенных потоками данных. Основное назначение
диаграммы потоков данных – показать, как каждый процесс преобразовывает
входные потоки данных в выходные, и описать связи между процессами.
Диаграмму можно дополнить необходимой информацией, которая включает
правила описания алгоритма функционирования процесса (обработки входных
данных) и спецификацию на потоки передачи данных (тип данных, формат,
состав и т.д.). В случае необходимости отдельно добавляются и впоследствии
учитываются требования РМВ.
В рамках описания модель управления описывает правила и законы
управления процессами, составляющими сеть процессов функциональной
модели, но не раскрывает содержимого этих процессов. Задачей данной модели
является указания правил, по которым процессы “активизируются” и
выполняют свои функции. Эти правила могут быть выражены одним из
множества способов, например таблицами истинности, диаграммами смены
состояний (автоматная модель), таблицами активизации процессов и т.д.
Представленный способ описания ИУС является достаточно
общепринятым на данный момент и с небольшими модификациями и
дополнениями реализован в различных средствах архитектурного
проектирования [3, 31, 35]. На самом деле можно заметить определенное
сходство такого способа описания с одной из разновидностей сети обработки
потоков данных (Dataflow Process Network). Преимущество такого способа
заключается в том, что он интуитивно понятен большинству разработчиков и
является одним из “естественных” способов представления системы, пусть
даже иногда при этом страдает формальность описания.
1.2.1.2 Целевое прикладное программирование
Принципиально другой способ описания ИУС можно получить, если
рассматривать систему с точки зрения целевого прикладного
программирования. Обычно такое представление системы необходимо
создавать, если спроектированная система предоставляет возможность
доопределить свою [прикладную] функциональность конечному пользователю.
Именно в этом случае конечный пользователь должен иметь представление о
системе, как о неком сложном устройстве, допускающем прикладное
программирование. Другими словами, конечный пользователь имеет
возможность “конфигурировать” целевую систему для выполнения конкретной
(необходимой именно этому пользователю) функции управления. Под
“конфигурированием” системы в частном случае можно понимать ее целевое
прикладное программирование. Целевым это программирование называется
потому, что таким образом определяется целевая функция системы. Если такой
способ описания системы рассматривать не с точки зрения конечного
пользователя, а уже на этапе проектирования самим проектировщиком, то его
задача несколько видоизменяется. Вместо того, чтобы сразу спроектировать
21
Страницы
- « первая
- ‹ предыдущая
- …
- 20
- 21
- 22
- 23
- 24
- …
- следующая ›
- последняя »
