Технологическое оборудование гап

1   2   3   4   5   6

1 - если в выбираемом варианте G(X) для формирования массива Jk используется

процедура Fr.

О-в противном случае

(по всем массивам, кроме выходных), что означает требования связности графа G*cGo и наличия хотя бы одного варианта преобразования множества входных массивов Jbx(x) в каждый выходной, т.е. такого, чтобы

Математические постановки и алгоритмы решения этой и других задач синтеза ИО АСУ приведены в книге: Мамиконов А.Г., Пискунов А.Н., Цвиркун А.Д.: «Модели и методы проектирования информационного обеспечения АСУ», М, Статистика, 1978-221с.


6.5. Модульный принцип разработки информационного и программного

обеспечения.


Модульный принцип проектирования АСУ связан с процессом разбиения (декомпозиции) системы на отдельные слабосвязанные компоненты, допускающие их относительно независимую разработку и использование.

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

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

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

При разработке ИО и ПО АСУ модульность кроме уменьшения сложности обеспечивает также ряд других преимуществ:

1) Упрощает процесс разработки и отладки программ;

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

3. Легче обеспечивается разработка управляющих программ;
   
4. Лучше используются возможности программистов.
   

Существуют 2 стратегии модульного проектирования: «сверху вниз» и «снизу вверх».

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

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

При использовании стратегии модульного проектирования «снизу вверх» разработка начинается с нижнего уровня и продолжается до достижения требуемого решения.

Реализация любой из этих стратегий предполагает использование принципов разработки модульных систем:

1. Функциональность - модуль должен представлять функционально законченную и максимально независимую совокупность операций по обработке данных;
   
2. Связность - модуль реализует совокупность взаимосвязанных функций, требующих одних и тех же данных;
   
3. Последовательность - модуль включает несколько функций, которые реализуются последовательно, причем выходные результаты одной функции являются входными для другой;
   
4. Однородность - в модуле объединяются однородные по своему функциональному назначению процедуры;
   
5. Унификация - модуль должен быть применим как можно к большему числу задач АСУ без дополнительной перестройки.
   

Опыт разработки АСУ показывает, что использование модульного принципа разработки, а также тщательный анализ и структуризация задач существенно повышают скорость и качество программирования, отладки и внедрения, облегчают дальнейшее совершенствование системы.


6.5.1. Задачи разбиения информационного и программного обеспечения АСУ на

функциональные модули.


Проблема разделения ИО и ПО АСУ на отдельные модули является одной из наиболее трудных и слабо формализуемых, т.к. такое разделение связано с планированием и организацией работы системщиков и программистов, их взаимодействием в процессе программирования, отладки и внедрения задач.

Процедуры обработки данных Рис.6.3.

Разбиение ИО АСУ на модули сводится к разбиению заданного множества процедур на непересекающиеся подмножества, имеющие минимальное число общих информационных элементов.

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



Для формализации задачи введем следующие обозначения.

-матрица взаимосвязи процедур и информационных элементов.

1) ограничение на число выделяемых модулей:


2) ограничение на число элементов в модулях:


3) ограничение М на мощность множества процедур в модулях:


4) ограничение на количество сложных типов связей:











- если процедура а_j входит в модуль A_і;

- в противном случае

Оптимизируемый критерий (суммарное число информационных элементов, общих для различных модулей A_і и Aj ):





для заданных процедур j и j* (6)

5) ограничение на разделение отдельных сложных процедур по различным модулям:


Задача (1)-(6) является задачей квадратичного целочисленного программирования. Для удобства решения эта задача может быть сведена к линейной форме путем линеаризации выражений (1) и (5).

Критерий (1) может быть записан следующим образом

- если е- й элемент входит в модули А; и AJ; -в противном случае


где

1-если е-й элемент входит в модули А_j и А_i;

0-в противном случае

С использованием введенной переменной ограничение (5) имеет вид:


(8)


Таким образом, задача разбиения, представленная выражениями (7), (2), (3), (4), (8) и (6) имеет линейный вид и может быть решена с помощью стандартной программы линейного целочисленного программирования.

Пример.

Рассмотрим использование изложенного метода на примере определения оптимального числа модулей в задаче «Выпуск бюллетеня» АСУ «Обмен», рассмотренном в статье А.Г. Мамиконова и др. «Вопросы модульного построения сложных программ», сборник трудов ИЛУ, М, 1977, вып.13, стр. 32-42,а также (8), стр.1576-157.

Граф задачи содержит 28 процедур и 35 информационных элементов.

Задача распределения процедур по модулям решалась с учетом следующих ограничений:

1. число модулей m₀ < 5;
   
2. общее число информационных элементов в каждом из модулей
   
3. общее число процедур в каждом модуле
   

В результате решения задачи был получен оптимальный состав проектируемых модулей:

1-й модуль. Процедуры 1-7,10-12, число обрабатываемых элементов - 23.

2-й модуль. Процедуры 8,9, 13-19, число обрабатываемых элементов - 24.

3-й модуль. Процедуры 20-28, число обрабатываемых элементов - 10.

Число информационных связей между модулями 1 и 2 равно 16, между 1 и 3 равно 4 и между 2 и 3 равно 7. Оптимальное (минимальное) число информационных связей между процедурами 157. Относительно большая информационная связь между модулями 1 и 2 объясняется наличием в модуле 1 процедуры ввода данных. Без учета этих простейших информационных связей общее число связей равнялось бы 12.