Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Метод нисходящей разработки («сверху вниз»)

Альтернативный метод проектирования операционных систем получил название аналитического, или нисходящего, проектирования, или «сверху вниз». В этом случае разработчик исходит из желаемых свойств виртуальной машины пользователя и последовательно разрабатывает уточнения в направлении аппаратуры. Реализация этой виртуальной машины полностью не специфицируется. Неопределенные части проектируются в дальнейшем как компоненты (модули) системы. Эта работа продолжается до тех пор, пока система не определена настолько, что ее основные функции реализуются аппаратурой или модулями, непосредственно выполняемыми на аппаратуре.

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

Аналогичный подход используется при проектировании структуры программной системы. На начальном шаге, используя внешний проект (спецификации системы), формируется перечень всех функций системы. Затем определяются их подфункции. Далее каждая подфункция может расчленяться до тех пор, пока ее составные части не будут окончательно уточнены. Метод нисходящего проектирования, иногда называемый функциональной декомпозицией, основан на двух стратегиях: пошаговом уточнении (детализации), разработанном Э. Дейкстрой, и анализе сообщений, базирующемся на работах Иордана, Константайна, Г. Майерса [14]. Эти стратегии отличаются способами определения начальных спецификаций, методами, используемыми при разбиении задачи на части, и правилами записи.

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

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

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

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

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

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

 
<<   СОДЕРЖАНИЕ   >>