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

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

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

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

Введем понятие базиса решения задач. Под базисом понимается заранее заданный состав элементов подмножеств и .

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

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

1. В булевой матрице выделим подматрицу , , и определим её как базис решения задачи.

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

3. В соответствии с полученными оценками осуществим распределение элементов множества по множествам . В результате зафиксируем решение и промежуточную. Матрицу , , .

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

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

6. Следует отметить, что поиск решения задачи может осуществляться как в прямом направлении по схеме , так и в обратном направлении по схеме .

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

2.2 Декомпозиция прикладных задач и исходных документов систем обработки данных на этапе технического проектирования

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

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

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

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

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

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

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

Аналогично введём переменную

, , , где

В ряде случаев на данном этапе определяются характеристики задач и документов.

Введем - время разработки -ой задачи, - объем -ого документа, - общая стоимость разработки -ой задачи и -го документа, - время разработки и подготовки -го документа, -стоимость разработки -ой задачи, - стоимость подготовки -го документа.

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

Необходимо разбить систему на подмножества прикладных задач и используемых ими документов таким образом, чтобы минимизировать взаимосвязи между кластерами прикладных задач и документов в процессе проектирования СОД (рис 2.2.1).

Определим дополнительные переменные следующим образом:

Данная переменная отражает использование -го документа для решения задач -го кластера.

Переменная отражает использование в процессе решения -ой задачи -го кластера документов.

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

Задачу декомпозиции СОД сформулируем следующим образом.

Необходимо минимизировать функцию вида

.(2.2.1)

При ограничениях на:

- включение каждой прикладной задачи только в один кластер

, ;(2.2.2)

- включение документа только в один кластер документов

, ;(2.2.3)

- время разработки каждого кластера задач

, ;(2.2.4)

- стоимость проектирования каждого кластера задач

, ;(2.2.5)

- число прикладных задач в кластере

, ;(2.2.6)

- число исходных документов в кластере

, .(2.2.7)

Поставленная задача относится к блочно-симметричным задачам дискретного программирования. Для её решения разработан и предложен эффективный алгоритм позволяющий решать задачи большой размерности.

2.3 Проектирование модульных блок-схем систем обработки данных

В результатах декомпозиции сложных систем обработки данных на кластеры на этапе технического проектирования необходимо для каждого кластера разработать модульную блок-схему прикладного программного обеспечения и базы данных. Каждый кластер СОД и входящие в его состав прикладные задачи могут быть представлены в виде направлении графа процедур обработки данных, а кластер исходных документов - в виде совокупности информационных элементов. Эти данные являются исходными для проектирования прикладных программ и базы данных. Известно, что любой разветвленный граф отображения прикладной задачи можно представить в виде последовательного графа - цели отражающий последовательность реализации процедур [126]. Поэтому каждый кластер и задачу можно отобразить в виде линейной последовательности процедур.

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

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

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

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

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

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

Введем следующие переменные:

Введем вспомогательные переменные:

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

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

Переменную отражающую взаимосвязь между модулями блок-схемы и массивами базы данных можно определить следующим образом:

,

либо,

Определение указанных переменных вытекает из свойства симметричности блочно-симметричных задач.

Задача проектирования модульных блок-схем систем обработки данных (МСОД) формулируется следующим образом.

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12