Метод (алгоритм) декомпозиции

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 31.01.2014
Размер файла 563,4 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru

Введение

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

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

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

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

уровень «черного ящика» (описание входов >и выходов системы);

уровень состава системы (перечисление элементов системы);

уровень структуры системы (описание взаимосвязей между элементами системы).

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

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

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

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

1. Декомпозиция систем

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

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

Г. Буч в своей книге задает непростой вопрос : существует ли наилучший метод проектирования? На этот вопрос однозначного ответа нет. По сути дела этот вопрос сводится к другому вопросу: существует ли лучший способ декомпозиции сложной системы? Если он и существует, то пока никому не известен. Также этот вопрос можно поставить и по-другому: как наилучшим способом разделить сложную систему на подсистемы? Правильное разделение системы на составные части, представление предметной области в виде набора объектов, или разбиение программы на модули является почти такой же сложной задачей, как выбор правильного набора абстракций.

Г. Буч в своей книге приводит правило Клеменса и Вейса, которым активно пользуются разработчики программного обеспечения при выделении модулей программ: «Особенности системы, подверженные изменениям, следует скрывать в отдельных модулях; в качестве межмодульных можно использовать только те элементы, вероятность изменения которых мала». Также необходимо отметить, что поскольку модули служат элементарными и неделимыми блоками программы, которые могут использоваться повторно, это должно учитываться при распределении классов и объектов по модулям.

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

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

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

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

1.1 Варианты декомпозиции

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

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

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

1.2 Тривиальная декомпозиция

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

1.3 Функциональная декомпозиция

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

Предположим наша задача сводится к применению некоего функционального оператора к большому массиву данных: S[i]=F(a[i]). Предположим также, что выполнение функции F над одним элементом массива занимает достаточно большое время и нам хотелось бы это время сократить. В этом случае мы можем попытаться представить исходную функцию как композицию нескольких фунуций: S(a[i])=I(H(R(a[i]). Произведя декомпозицию мы получим систему последовательных задач:

x=r(a[i]);

y=h(x);

b[i]=i(y);

Каждая из этих задач может быть выполнена на отдельном узле кластера. Как можно заметить общее время обработки одного элемента массива a[i] в результате не изменяется, а скорее немного увеличивается за счет межпроцессорных пересылок. Однако общее время обработки всего массива заметно снижается за счет того, что в нашем примере одновременно идет обработка сразу трех элементов массива.

У данного метода декомпозиции есть пара особенностей, о которых надо помнить.

Первая особенность состоит в том, что выход кластера на максимальную эффективность происходит не сразу после запуска задачи, а постепенно, по мере того, как происходит частичная обработка первого элемента массива. Второй и третий процессоры в нашем примере, которые отвечают за выполнение функций g(x) и f(y), будут простаивать до тех пор, пока не закончится выполнение функции h(a[1]) на первом процессоре. Третий процессор будет простаивать до окончания выполнения функции g(a[1]). По аналогичному сценарию, только в зеркальном отображении, происходит окончание работы.

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

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

1.4 Декомпозиция данных

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

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

1.5 Обобщенное правило декомпозиции

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

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

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

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

Таким образом, в общем виде правило декомпозиции заключается в выполнении следующих основных этапов:

Определение системных(ого) свойств(а), значимых (ого) для решения поставленной задачи. В примере - высота полета самолета.

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

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

2. Модели систем как основание декомпозиции

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

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

Содержательная модель как основание декомпозиции

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

Пример 1.

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

Рис.15.1 -- Первый уровень дерева целей из примера 1

Декомпозиция проведена по модели входов организационной системы

Рис.15.2 -- Схема входов организационной системы

Модель организационной системы включает входы:

от «нижестоящих» систем (здесь клиентуры -- подцель 1);

от «вышестоящих» систем (народного хозяйства в целом -- подцель 2);

от «существенной среды» (в данном случае от флотов капиталистических государств -- подцель 3, и социалистических государств -- подцель 4).

Очевидно, что такая декомпозиция неполна, поскольку отсутствует подцель, связанная с собственными интересами морского флота. Это, по-видимому, не столько ошибка экспертов-аналитиков, сколько стиль тогдашнего руководства. Через 15 лет пришлось говорить о том, что «остаточный» подход создал серьезные проблемы в работе флота в целом.

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

Установив, что декомпозиция осуществляется с помощью некоторой модели, сквозь которую мы как бы рассматриваем расчленяемое целое, далее следует ответить на естественно возникающие вопросы:

модели какой системы следует брать в качестве основания декомпозиции?

какие именно модели следует брать?

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

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

2.1 Связь между формальной и содержательной моделями

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

Пример 2.

Схема входов организационной системы на рис.2. является полной: к ней нечего добавить (перечислено все, что воздействует на систему), а изъятие любого элемента лишит ее полноты.

Пример 3.

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

Пример 4.

К числу полных формальных моделей относится марксова схема любой деятельности человека, которая в «Капитале» применялась для анализа процесса труда (см.рис.3). В схеме выделены: субъект деятельности; объект, на который направлена деятельность; средства, используемые в процессе деятельности; окружающая среда; все возможные связи между ними.

Рис.15.3 -- Общая схема деятельности

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

2.2 Проблема полноты моделей

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

Для иллюстрации вернемся к примеру 1. Фреймовая модель входов оргсистемы (см.рис.2) рекомендует, в частности, определить конкретно, что именно понимается под «существенной средой», т.е. взаимодействие с какими реальными системами не своего ведомства должно войти в основание. Судя по результату анализа, его авторы учитывали только взаимодействие морского флота с флотами других государств. Для каких-то целей этого достаточно. Но ясно также, что в других случаях может потребоваться учет взаимодействия с сухопутным транспортом, речным и воздушным флотами. Если возникнет вопрос о ресурсах, то потребуется учет связей с ведомствами, производящими топливо и энергию, продукты питания, всевозможную технику, услуги и т.д. Таким образом вопрос достаточной детализации содержательных моделей в отличие от фреймовых всегда остается открытым. Чтобы сохранить полноту и возможность расширения содержательной модели, можно рекомендовать осуществлять логическое замыкание перечня ее элементов компонентой «все остальное». Ее присутствие будет постоянно напоминать эксперту, что, возможно, он не учел что-то важное.

Компромиссы между полнотой и простотой моделями

Начнем с обсуждения требований к древовидной структуре, которая получится как итог работы по всему алгоритму. С количественной стороны эти требования сводятся к двум противоречивым принципам:

полноты (проблема должна быть рассмотрена максимально всесторонне и подробно);

простоты (все дерево должно быть максимально компактным -- «вширь» и «вглубь»).

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

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

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

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

3. Типы сложности

класс алгоритм декомпозиция

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

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

3.1 Алгоритм декомпозиции

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

Блок 1. Объектом анализа может быть что угодно -- любое высказывание, раскрытие смысла которого требует его структурирования. На определение объекта анализа затрачиваются весьма значительные усилия. Формулировка глобальной цели системы, как правило, требует неоднократного уточнения и согласования. От правильного выбора объекта анализа зависит, действительно ли мы будем делать то, что нужно.

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

Блок 3. Этот блок содержит набор фреймовых моделей и рекомендуемые правила их перебора либо обращение к эксперту с просьбой самому определить очередной фрейм.

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

Блоки 5-10 были достаточно пояснены ранее.

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

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

Подведем итог

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

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

Рис.15.4 -- Укрупненная схема алгоритма декомпозиции

3.2 Метод декомпозиции сложных систем

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

В качестве оснований декомпозиции сложных систем предлагается использовать так называемые стандартные модели, которые описывают некоторые инвариантные характеристики некоторого класса систем [3,9]. Рассмотрим стандартные модели, которые могут использоваться при построении содержательной модели системы, относящейся к классу организационно-технологических объектов. К этому классу относятся предприятия, организации, учреждения, автоматизированные системы управления и т.д.

В самом общем виде модель системы может быть представлена в виде совокупности “система - окружающая среда” и связей между ними (см. рис. 2.9).

Рис.2.9. Модель системы на уровне "входов - выходов"

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

Для многих задач исследования и управления целесообразно представление системы в виде совокупности “система управления - объект управления” (см. рис. 2.10).

Рис.2.10 Модель системы с выделением управляемой и управляющей частей

Рассмотрим стандартные модели для объекта управления и системы управления.

Стандартные модели для декомпозиции объекта управления (ОУ):

1. Выделение в ОУ подсистем социальной деятельности: "производство", "население" (коллектив), "природа" (см. рис. 2.11).

2.

Рис.2.11 Модель основных подсистем социальной деятельности

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

2. Выделение основного производства (процесса) и вспомогательного производства.

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

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

3. Выделение подсистем, соответствующих “жизненному циклу” конечного продукта (см. рис. 2.12) [2].

Рис. 2.12 Модель жизненного цикла конечного продукта

4. Декомпозиция ОУ (подсистемы ОУ) по составу подсистем - производителей отдельных конечных продуктов. Здесь предполагается, что каждому продукту соответствует определенная подсистема - производитель этого продукта.

5. Выделение стадий производства конечного продукта, соответствующих технологически законченным процессам. В работе [9] выделены типовые элементы, из которых конструируются реальные технологические сети (см. рис. 2.13):

а) последовательная структура;

б) расходящаяся структура;

в) сходящаяся-расходящаяся структура;

г) структура с реверсом (рециклом).

Стадии производства и их соединение образуют технологическую сеть.

Рис.2.13 Типовые технологические сети

6. Выделение структурных элементов подсистем и их взаимосвязей (рис. 2.14).

Рис. 2.14 Модель структуры системы (подсистемы)

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

На рис. 2.15 - 2.18 приведены модели структур для различных подсистем социальной деятельности: “производство”, “коллектив”, “природа”, “управление”.

Рис.2.15 Модель структуры подсистемы "производство"

Рис. 2.16 Модель структуры подсистемы "коллектив"

Рис.2.17 Модель структуры подсистемы "природа"

Заключение

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

Список литературы

Флейшман Б. С. Основы системологии, М.: Радио и Связь. 1982.

Слюсаренко И.М., Слюсаренко М.Ю. Системный подход в автоматизации процессов компаний.

Слюсаренко И.М., Слюсаренко М.Ю. Основы системологии и автоматизация бизнес-процессов компаний.

Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С ++, 2-е изд./Пер. с англ .- М.: «Издательство Бином», СПб.: «Невский диалект», 1999 г.

Бусленко Н. П. Моделирование сложных систем. М.: Наука. 1978г.

Хорошев А.Н. Введение в управление проектированием механических систем: Учебное пособие. -- Белгород, 1999. -- 372 с. -- ISBN 5-217-00016-3 Электронная версия 2011г.

Труды Лондонского королевского общества, (1998) против 454, 903-995, Норден E. Хуан

учебник, презентация, 21 июля 2004 года, Норден E. Хуанг.

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

Размещено на Allbest.ru

...

Подобные документы

  • Алгоритм декомпозиции графов и расчеты динамики логических сетей. Преобразование пространства булевых векторов. Описание блоков программной реализации и их взаимодействие. Разработка программы "слияния" статистик на основе алгоритма объединения.

    дипломная работа [111,8 K], добавлен 07.03.2012

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

    курсовая работа [1,1 M], добавлен 23.05.2012

  • Появление первых вычислительных машин и возникновение "стихийного" программирования. Структурный подход к декомпозиции сложных систем. Развитие модульного и объектно-ориентированного программирования. Особенности компонентного подхода и CASE-технологий.

    презентация [1,5 M], добавлен 14.10.2013

  • Унифицированный язык моделирования. Методы объектно-ориентированного анализа и проектирования. Создание диаграммы последовательности и диаграммы сотрудничества. Главная диаграмма классов. Добавление связей между классами. Зависимость между пакетами.

    курсовая работа [2,7 M], добавлен 23.06.2011

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

    контрольная работа [17,0 K], добавлен 27.09.2010

  • Основы проектирования реляционных баз данных. Схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа. Примеры графического изображения конкретных классов. Представление об информационной модели данных.

    презентация [1,6 M], добавлен 14.10.2013

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

    реферат [57,1 K], добавлен 30.08.2009

  • Особенности объектно-ориентированного проектирования. Основные понятия объектно-ориентированного подхода. Основы языка UML, варианты его использования. Диаграммы классов и взаимодействия. Разработка диаграммы прецедентов (вариантов использования).

    курсовая работа [1,1 M], добавлен 13.05.2014

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

    лабораторная работа [212,0 K], добавлен 10.03.2013

  • Описание проектного решения стратегической системы, этапы объектно-ориентированного анализа и проектирования. Описание связей между объектами. Программная реализация, построение модели состояний объекта. Руководство пользователя и описание программы.

    курсовая работа [388,8 K], добавлен 17.11.2011

  • Анализ объектно-ориентированного программирования, имитирующего способы выполнения предметов. Основные принципы объектно-ориентированного программирования: инкапсуляция, наследование, полиморфизм. Понятие классов, полей, методов, сообщений, событий.

    контрольная работа [51,7 K], добавлен 22.01.2013

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

    курсовая работа [187,2 K], добавлен 27.08.2012

  • Общая характеристика объектно-ориентированного подхода в программировании, его основные свойства и принципы. Разработка программы для автоматизация деятельности кафе на основе объектно-ориентированного подхода, проектирования и реализации схемы данных.

    курсовая работа [1,2 M], добавлен 22.01.2012

  • Анализ проблематики построения объектно-ориентированного канала связи. Основные понятия протокола Modbus. Возможности CodeSys для реализации объектно-ориентированного подхода. Разработка методики кроссплатформенной библиотеки для интеграции устройств.

    курсовая работа [38,6 K], добавлен 15.06.2013

  • Использование объектно-ориентированного программирования - хорошее решение при разработке крупных программных проектов. Объект и класс как основа объектно-ориентированного языка. Понятие объектно-ориентированных языков. Языки и программное окружение.

    контрольная работа [60,1 K], добавлен 17.01.2011

  • Проведения анализа существующих генных сетей. Три типа вершин актуальных объектов для поточечной редукции: источники, стоки и проводящие вершины. Существующие методы декомпозиции. Алгоритм "walktrap" на основе случайных блужданий и определения смежности.

    курсовая работа [2,6 M], добавлен 28.02.2012

  • Основные операции с АВЛ-деревьями, добавление и удаление элемента из сбалансированного дерева. Эффективность сортировки вставкой в АВЛ–дерево и итераторы. Алгоритм реализации АВЛ–деревьев через классы объектно–ориентированного программирования.

    курсовая работа [281,1 K], добавлен 29.11.2010

  • Изучение принципов объектно-ориентированного программирования, в котором основными концепциями являются понятия классов и объектов. Свойства этого вида программирования: инкапсуляция, полиморфизм, наследование. Описание класса. Конструкторы и деструкторы.

    презентация [74,8 K], добавлен 14.10.2013

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

    лекция [58,9 K], добавлен 21.07.2009

  • Понятие математической модели. Безусловные и условные типы задач оптимизации. Принципы, термины и преимущества объектно-ориентированного программирования. Характеристика среды разработки Delphi 7.0. Программная реализация метода кодирования Хаффмена.

    курсовая работа [1,3 M], добавлен 05.10.2014

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.