Главная » Мануалы

1 ... 9 10 11 12 13 14 15 ... 32

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

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

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

В качестве объектов разработки, иллюстрирующих излагаемые в книге методы, выбраны следующие три системы:

1. LIFE - система, реализующая ЭКОЛОГИЧЕСКУЮ ИГРУ, в которой играющие стороны используют клавиатуру и текстовый дисплей.

2. FORMS (ФОРМАТИРОВАННЫЙ ВВОД)- система, позволяющая оператору вводить с клавиатуры данные по форме, высвечиваемой на экране дисплея, и получать этот документ в печатном виде строка за строкой по мере заполнения высвеченного бланка.

3. DIALOGUE - ДИАЛОГОВАЯ СИСТЕМА, обеспечивающая операторам, расположенным в разных пунктах, возможность взаимодействия посредством пересылки сообщений, которые при передаче формируются, а при приеме отображаются на экранах их дисплеев.

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

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

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

4.2. Стратегия проектирования

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

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

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

4.2.1. Стратегия функционального синтеза и декомпозиции

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

Рис. 4.2. Функциональная декомпозиция по принципу сверху - вниз .

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

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

На рис. 4.3 иллюстрируется соответствующая такой ситуа-ции стратегия функционального синтеза по принципу снизу -

Рис. 4.3. Функциональный синтез по принципу снизу -

Шаг 3,

Рис. 4.4. Функциональный синтез и декомпозиция по принципу изнутри - к границам .

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

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

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

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

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

4.2.2. Стратегия проектирования, ориентированная на структуру данных

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

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

4.2.3. Стратегия структурного проектирования, ориентированного на потоки данных

Стратегия проектирования, о которой будет идти речь в дальнейшем, может быть названа структурным проектирование

(а) Система.

(6) Последовательный поток данных. Рис. 4.5. Последовательный информационный поток.

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

На рис. 4.5 схематически отображен процесс структурного проектирования, ориентированный на информационные потоки,

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

Функциональные элементы F1, F2 и F3 являются блоками преобразования, характер которых на данном этапе не раскрывается. Нежесткость назначения этих функциональных блоков на информационном потоковом графе подчеркивается их условным представлением в форме облачка, как это делалось ранее на рис. 3.1. Узлы графов информационных потоков иногда еще изображают в виде кружков; в этом случае их называют пузырьковыми диаграммами. В дальнейщем мы будем называть узлы информационных потоковых графов модулями.

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

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

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

GET A

PUT D

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

для управления приемом и выдачей данных требуются вспомогательные процедуры GET и PUT.

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

Другой подход заключается в использовании иерархического управления, как показано на рис. 4.8. Здесь (рис. 4.8, о) в ИПГ включен управляющий модуль, который воздействует только на центральную часть графа, а конечные узлы управляются непосредственно модулями F1 и F3. Иерархический структурный граф, реализующий этот ИПГ, приведен на рис. 4.8,6, где модули F1, F2 и F3 реализованы в виде блоков с соответствующими процедурами сопряжения GET, CONTROL и PUT. Функции преобразования F1, F2 и F3 введены в тела этих блоков.

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

Одной из привлекательных особенностей стратегии проектирования, ориентированной на потоки данных, является то, что ИПГ сами по себе не предопределяют никаких решений в отношении того, будут ли они реализовываться в виде последовательных или иных систем. Значительная часть проекта мо-

fUT D
GET A

Рис. 4.6. Вертикальное управление последовательным потоком данных. ( Вертикальная структурная схема получается непосредственно из диаграммы последовательногэ потока данных путем подвешивания ее за один конец .)

УПРАВЛЕНИЕ 1 о->-0

[а] Видоизмененный граф последовательного потока данных, отображающий возможности прямого управления,

GET A

fUT 0

{6} Горизонтальный структурный граф.

Рис. 4.7. Горизонтальное управление последовательным потоком данных.

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

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

УПРАВЛЕНИЕ

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

f1 PACK

GET S

CONTROL 2 РАСК

PUT C

PACK

\б) Иерархический структурный граф в виде совокупности пакетов.

Рис. 4.8. Иерархическое управление последовательным потоком данных

1 ... 9 10 11 12 13 14 15 ... 32