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

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

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


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

Методы структурного проектирования

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

Этот метод применялся в 60-х гг. XX в. при разработке операционных систем, в частности операционной системы ТНЕ. Он получил название метода восходящей разработки, или синтетического, или снизу вверх. Применяя этот метод, разработчик начинает с основного аппаратного оборудования. «Чистая» аппаратура представляет собой для пользователя довольно неудобную машину, чтобы решать на ней задачу. Поэтому разработчик на первом шаге добавляет к компьютеру слой программного обеспечения. Этот слой программ вместе с нижележащей аппаратурой обеспечивает выполнение некоторого множества команд, определяющих новую виртуальную машину. На следующем шаге выделяется другое нужное свойство, добавляется новый слой программного обеспечения и получается очередная виртуальная машина. Процесс продолжается до тех пор, пока не будет получена виртуальная машина с требуемыми пользователю свойствами (рис. 6.9).

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

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

Начато

УМ,

ум.

I

I

I

и

УМ;

и

I

_У_

УМХ с требуемыми свойствами

Ьм N=7

Рис. 6.9. Последовательность проектирования «снизу вверх»

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

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

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

Разработчики, использующие синтетический подход к проектированию программ, сталкиваются с серьезными трудностями: начальные этапы утомительны, затрагивают самые базовые понятия и связаны с написанием длинных текстов на языке программирования. С другой стороны, нельзя пропустить их в описании и сразу перейти к понятиям «среднего уровня». Описание представляет собой как бы двойную загадку: первое (что всегда имеет место в этом подходе в его чистом виде) - как догадаться, какие понятия являются полезными для решения конкретной задачи; второе - как получить эти промежуточные понятия из базовых.

На первый взгляд порядок разработки «снизу вверх» кажется вполне естественным. Каждый модуль при программировании выражается через уже запрограммированные, непосредственно подчиненные модули, а при тестировании используются уже отлаженные модули. Однако современная технология не рекомендует такой порядок разработки программной системы [17].

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

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

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

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

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

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