Файл: Инфрам.pdf

289 для тестируемого модуля необходимое состояние информационной сре- ды и произвести требуемое обращение к нему. Это приводит к большо- му объему отладочного программирования и не дает гарантии, что тес- тирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программной системе.
Заметим, что последовательные слои программной системы, спроек- тированной снизу-вверх не обладают свойством быть решением, но обеспечивают весь спектр возможностей, предоставляемых базовым слоем, хотя и выраженных через более общие понятия. Поэтому можно считать, что синтетическое проектирование программ ориентировано, скорее, на обслуживание (или использование), чем на решение задачи.
Необходимо еще раз подчеркнуть, что слои возникают в синтетиче- ском проекте тогда, когда разработчик получает набор модулей, реали- зующих понятия, в терминах которых можно выразить любую програм- му, выразимую в базовых понятиях. Модули, в которых детали, если они не выразимы в данном слое, упрятываются, не меняя при этом смысла программы (выраженного в понятиях, доступных в рассматри- ваемом слое).
6.6.2. Метод нисходящей разработки (“сверху-вниз”)
Альтернативный метод проектирования операционных систем полу- чил название аналитического, или нисходящего проектирования, или
“сверху-вниз”. В этом случае разработчик исходит из желаемых свойств виртуальной машины пользователя и последовательно разрабатывает уточнения в направлении аппаратуры. Реализация этой виртуальной машины полностью не специфицируется. Неопределенные части проек- тируются в дальнейшем как компоненты (модули) системы. Эта работа продолжается до тех пор, пока система не определена настолько, что ее основные функции реализуются аппаратурой или модулями, непосред- ственно выполняемыми на аппаратуре.
В результате проектирования получается множество вложенных друг в друга компонентов. На каждом шаге проектирования у разработ- чика имеется некоторая абстракция функционального описания некото- рого компонента, и он должен уточнить эту абстракцию, разбив ее на более мелкие и более подробно проработанные части.
Аналогичный подход используется при проектировании структуры программной системы. На начальном шаге, используя внешний проект
(спецификации системы), формируется перечень всех функций системы.
Затем определяются их подфункции. Далее каждая подфункция может расчленяться до тех пор, пока ее составные части не будут окончательно уточнены. Метод нисходящего проектирования, иногда называемый функциональной декомпозицией, основан на двух стратегиях: пошаго- вом уточнении (детализации), разработанном Е. Дейкстрой, и анализе сообщений, базирующемся на работах Йордана, Константайна Г. Май- ерса [14]. Эти стратегии отличаются способами определения начальных спецификаций, методами, используемыми при разбиении задачи на час- ти, и правилами записи.

290
Для проверки проекта в процессе его разработки можно с самого на- чала применять моделирование. Этот подход побуждает разработчика
думать о том, какие функции должен выполнять некоторый компо-
нент, а не как данный компонент будет их реализовать. Компоненты системы можно моделировать более детально, по мере того, как продви- гается работа по проекту.
Первоначальное представление какого-либо компонента может быть некоторым алгоритмом, который для данного входа вырабатывает с не- которой временной задержкой соответствующий выход, и таким обра- зом моделирует работу данного компонента. По мере продвижения ра- бот по проектированию данный алгоритм замещается последователь- ным набором обращений к следующему множеству проектируемых компонентов. На каждой стадии разработки проекта можно оценить, чтобы проверить, продолжает ли он соответствовать поставленным це- лям.
Каждая абстракция системы соответствует некоторой программе мо- делирования, которая построена из иерархии процедур. Эта программа определяет, как нужно действовать с теми переменными, которые влияют на состояние системы на этом уровне абстракции. Программа, назовем ее P, соответствующая некоторому уровню абстракции, управ- ляется программой более высокого уровня абстракции, которую назо- вем Q. Программа Q принимает более глобальные решения, основыва- ясь на значениях ее собственных переменных , которые на самом деле являются абстракциями переменных программы P. Изменения в пере- менных программы Q соответствуют изменениям в переменных про- граммы P. Аналогично некоторые процедуры программы P делают за- просы на выполнение работ к программам более низких уровней абст- ракции.
Когда система окончательно спроектирована, ее можно реализовать путем замены основных алгоритмов на самом низком уровне абстрак- ции и средств, обеспечиваемых программой моделирования теми эле- ментами, из которых должна быть построена система. Если эта замена сделана правильно, полученная система будет представлять в точности те средства, которые определены на самом высоком уровне.
При реализации программы нисходящим методом первым кодирует- ся головной модуль – модуль верхнего уровня. При этом, поскольку этот вызывает модули соседнего низшего уровня, они представляются
заглушками – фиктивными модулями (имитаторами). С помощью за- глушек организуется непосредственный возврат в вызывающий модуль или осуществляться передача значений текстовых данных и печать ре- зультатов работы. Если заглушки имеют параметры, целесообразно ор- ганизовать их печать. После того как отлажен головной модуль, За- глушки последовательно заменяются функциональными модулями, которые в свою очередь будут вызывающими для следующих заглушек
(рис. 6.10).
В большинстве случаев аналитическое проектирование обеспечивает естественное расслоение программной системы: каждый следующий

291 уровень понятий в расширяющемся дереве может рассматриваться как слой. Иногда выдвигаются возражения против методологии проектиро- вания сверху-вниз, заключающиеся в том, что она не определяет, какое из двух направлений дерева программной структуры является более предпочтительным: от ветви к ветви или от уровня к уровню. Однако рекомендация выражать решение на каждом уровне исключительно в терминах этого уровня практически решает эту дилемму.
Рис. 6.10. Последовательность проектирования сверху-вниз
6.6.3. Заключительные замечания по структурному проектированию
Обе рассмотренные методологии естественным образом приводят к явно выраженной расслоенной структуре программной системы, обес- печивая равную доступность модулей одного слоя. В обеих методоло- гиях слой представляет собой полное непротиворечивое множество мо- дулей, даже если понятие полноты в каждом случае имеет различные оттенки.
Сферы применения этих двух методов дополняют друг друга. Кратко это можно сказать так: при программировании решения отдельной зада- чи предпочтительнее аналитическое проектирование, а при создании программных систем для решения класса задач – синтетический метод.
Поэтому синтетическое проектирование часто используется при напи-

292 сании операционных систем, а аналитическое – при написании специа- лизированных программных систем.
Возможен другой путь использования методов структурного проек- тирования. Система может быть спроектирована методом сверху-вниз, а реализована методом снизу-вверх. В этом случае общий проект струк- туры программной системы выполняется методом сверху-вниз, а моду- ли фактически объединяются в систему по методу снизу-вверх. При таком подходе налицо все преимущества реализации методом снизу- вверх и в тоже время не приносится в жертву возможность общего ох- вата системы, предоставляемая методом проектирования сверху-вниз.
Существует другая интерпретация взаимной дополняемости этих двух принципов проектирования, объясняющая, почему в большинстве важных задач используется оба подхода. Для трудных и больших задач обстановка, обеспечиваемая базовым уровнем, как правило, слишком удалена, чтобы к ней можно было прийти аналитическими методами проектирования. Поскольку при выборе абстрактных свойств, полезных для решения данной широкой задачи, можно учитывать предыдущий опыт, на этапах приведения системы к уровню этих предположительно полезных абстрактных понятий можно с успехом применять синтетиче- ское проектирование, что значительно снижает объем разработок ана- литического характера.
Между сторонниками методов проектирования снизу-вверх и свер- ху-вниз ведется много дискуссий. Многие полагают, что проектирова- ние сверху-вниз больше соответствует идее, когда следует принимать решения на ранних стадиях проектирования и оставлять решения по детальной реализации на более поздние этапы. Однако проектирование сверху-вниз требует лучшего осмысливания на ранней стадии процесса проектирования. Проектирование снизу-вверх не требует вначале пол- ного осмысливания системы, так как каждый слой программной систе- мы добавляется к уже полностью определенному предыдущему слою.
Вследствие этого, как указывается в [41], некоторые разработчики про- грамм пропагандируют метод сверху-вниз, но на практике проектируют системы методом снизу-вверх; особенно это касается операционных систем.

293 мой, приведенной на рис. 6.11. Здесь M
i
(i = 1, 2, …, n) – виртуальная машина i –го уровня.
Рис. 6.11. Обобщенная схема проектирования многослойного про- граммного продукта
Технология проектирования по методу сверху-вниз сосредоточива- ется вокруг двух основных моментов [6, 14, 19, 41] : задание директив, касающихся того, как осуществлять пошаговые уточнения и как объединять в модули выделенные функции про- граммной системы, установленные на этапе внешнего проектирова- ния системы; задание методов представления проектируемого потока управления и его взаимодействия с данными.
Работу в соответствии с таким подходом можно, прежде всего, раз- делить на два главных этапа:
1) на первом этапе (шаг 1) выполняется начальный набросок системы
(на основании установленных требований, предъявляемых к систе- ме) причем модулей как таковых нет;
2) на втором этапе (шаги 2 – n) определяются и реализуются модули с помощью пошагового уточнения.
Рассмотрим теперь более подробно эти шаги [26].
Шаг 1. Исследуется внешний проект системы (внешние специфика- ции, определяющие все функции пользователей и взаимодействующих систем) и предлагается общая структура программной системы в виде некой виртуальной машины VM
1
, снабженной соответствующими опе- рандами (структурами данных) и некоторым множеством операторов
(структурами программ).

294
Заметим, что на этом шаге данные представляются в том виде, с ко- торым имеет дело пользователь: приказ, счет, сообщение, отчет, вход- ной или выходной документ и т. п. Кроме того, данными могут быть специально описанные сигналы, поступающие в систему от взаимодей- ствующих с ней других систем, устройств или линий связи. Для маши- ны M
1 определяется программная система, которая удовлетворяет внешнему проекту системы. Обозначим ее следующим образом:
VM
1
= < O
1
, D
1
> , где O
1
– множество операторов виртуальной машины VM
1
; D
1
– множество данных виртуальной машины VM
1
, причем O
1 и
D
1
опреде- ляются внешними спецификациями системы SP
В
S
(см. гл.5).
Шаги
2 – n. На последовательно выполняемых шагах предложенная структура уточняется посредством разложения на модули (структуры данных и программные структуры). Это уточнение продолжается до тех пор, пока на шаге n не будут получены модули, которые могут быть сформулированы с помощью имеющихся в распоряжении разработчи- ков языков программирования и реализованы на имеющимся (или зара- нее заданном) компьютере.
Уточнение, выполняемое на каждом шаге, можно рассматривать как два параллельно выполняемых процесса: процесса анализа, т.е. процесса декомпозиции, состоящего из дис- кретной последовательности шагов, на каждом из которых система исследуется и представляется более детально; процесса синтеза, т.е. процесса композиции, когда последовательно, шаг за шагом, происходит построение системы.
Этот процесс уточнения может быть описан следующим образом:
1. Процесс состоит из дискретной последовательности шагов.
2. На шаге i в результате принятия решений S
i вводятся новые (более простые) модули (компоненты) m ij
M i и соответствующие множест- ва операторов o ij и множества операндов d ij
Виртуальная машина i-го уровня представляется следующим обра- зом:
VM i
= < M i
, O i
, D i
>, где M i
= { m ij
| j = 1, 2, …, N i
} – множество модулей уровня i, N i
– количество модулей уровня i;
O i
= { o ij
| j = 1, 2, …, N i
} – множество операторов модулей вирту- альной машины M
i
, в котором каждый оператор можно представить как отображение некоторой функциональной f ij и синтаксической спе- цификации s ij конкретного модуля m ij
:
< f ij
, s ij
> o ij
, где f ij
SP
Вн
S и s ij
SP
Вн
S
, где SP
Вн
S
– внут- ренние спецификации, определяющие i-й уровень виртуальной машины.
Заметим, что на уровне i=1используются внешние спецификации вирту- альной машины пользователя SP
В
S
(см. гл. 5);
D i
= { d ij
| j = 1, 2, …, N i
} – множество операндов модулей M i
, в котором каждый операнд можно представить как отображение некото-

295 рой синтаксической и семантической спецификации ss ij данных кон- кретного модуля m ij
: ss ij d ij
, где ss ij
SP
Вн
S
,
SP
Вн
S
– внутренние спецификации, оп- ределяющие интерфейс соответствующей виртуальной машины.
Заметим, что любой модуль m ij
M i выполняет некоторый набор операторов O ij и использует некоторый набор данных D ij
, для которых выполняются следующие условия:
1) возможно, что множества операторов различных модулей пересека- ется (т.е. модули используют одни и те же операторы) O ij
∩ O ik
, j k, при этом N i
|O ij
∩ O ik
| ≥ 1 (Замечание: значение мощности этого пересечения не может быть равным нулю, так как это бы зна- чило, что модули i-го уровня идентичны модулям i+1 уровня);
2) возможно также, что множества операндов различных модулей пе- ресекается (модули используют одни и те же операнды) D ij
∩ D ik
, j k, при этом N i
|D ij
∩ D ik
| ≥ 1 (справедливо замечание, ука- занное в п. 1));
3) O ij
O i
, при этом возможно, что для некоторого модуля O ij
= ;
4) D ij
D i
, при этом возможно, что для некоторого модуля D ij
= ;
5) невозможно одновременное выполнение условий O ij
= и D ij
= для одного и того же модуля.
3. Шаги процесса уточнения зависят от определяющих разложение решений S
i
. На основе этих решений определяются множества операто- ров и операндов, реализуемых модулями следующего слоя, которые необходимы для выполнения модулей предыдущего слоя: m ij
M
i
(S
i
(O ij
)
O i+1 j
) & (S i
(D ij
)
D
i+1 j
), j = 1, 2, …, N
i+1 4. На основе полученных результатов решения
S i
формируется множество модулей слоя (виртуальной машины) M i+1
:
VM i1
= < M i+1
, O i+1
, D i+1
>, где M i+1
= { m i+1 j
| j = 1, 2, …, N i+1
} – множество модулей уровня i+1, N i+1
– количество модулей уровня i+1, при этом N i+1
> N i
;
O i+1
= { o i+1 j
| j = 1, 2, …, N i+1
} – множество операторов модулей виртуальной машины M
i+1
, в котором спецификации каждого операто- ра можно представить как отображение части функциональной и син- таксической спецификации модулей m ij виртуальной машины M
i
;
D
i+1
= { d i+1 j
| j = 1, 2, …, N i+1
} – множество операндов модулей виртуальной машины M i+1
, в котором спецификации каждого операнда можно представить как отображение части синтаксической и семанти- ческой спецификации модулей m ij виртуальной машины M i
5. Решение S i
принимается на основе некоторой стратегии. Имеется три основные стратегии разбиения при применении композиционного анализа [20]. Для разбиения модулей (подмодулей) используется одна из следующих стратегий. Разбиение STS (исток – преобразование – сток) предполагает деление модуля на функции, занимающиеся получе- нием данных, изменением из формы (преобразованием), а затем достав- кой их в некоторую точку вне модуля. Операционное разбиение состоит в делении модуля на части, каждая из которых выполняет операции от-