Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения

к.т.н. И.М. Слюсаренко, к.т.н. М.Ю Слюсаренко, «InfoSoftCom»

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

Развитие науки осуществляется в направлении интеграции отдельных ее направлений; при этом появляются обобщенные методологии, основные принципы которых применимы к частным дисциплинам. Так, со временем стало ясно, что теория надежности, информации, управления, самоорганизации и другие дисциплины кибернетики исследуют различные свойства одного и того же целостного объекта – сложной системы. Поэтому современные исследователи отождествляют кибернетику с системологией [1].

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

Содержание

1. Понятие системы

2. Материальные и знаковые системы. Программные системы как разновидность знаковых

3. Эмергентность свойств систем

4. Понятие объекта, объектно-ориентированной модели

5. Декомпозиция

6. Синтез и анализ в изучении сложных систем

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

8. Особенности проектирования программных систем

9. Системологическое описание проектирования программных систем

10. Заключение

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

1. Понятие системы

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

Таким образом, одним из основных понятий системологии является система, под которой понимается устойчивое материальное образование, обладающее некоторым компонентным (элементным) составом и структурой [1]. Структура – это устойчивые взаимосвязи или взаимодействия между элементами системы. Подсистема – это система, которая в некотором анализе рассматривается как неделимый компонент системы более высокого уровня. Между подсистемой и системой существуют взаимосвязи, которые и приводят к формированию из подсистем системы.

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

2. Материальные и знаковые системы. Программные системы как разновидность знаковых

Системы делятся на материальные и знаковые. Последние, в той или иной мере отражающие первые, называются их знаковыми моделями [1]. Наши представления о материальных образованиях являются знаковыми моделями, или знаковыми системами, которые в свою очередь образуют иерархию подсистем. Все основные понятия материальных систем применимы и к знаковым системам.

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

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

3. Эмергентность свойств систем

По определению эмергентность – это несводимость системных свойств системы к свойствам отдельных ее элементов (компонентов) [1]. Системное свойство, или системное качество – основное качество, отражающее назначение системы или ее основную функцию. Наличие эмергентности позволяет исследователю выделить конкретную систему среди других систем или в неявном случае определить существование системы на фоне значительного количества компонентов как входящих, так и не входящих в нее.

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

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

4. Понятие объекта, объектно-ориентированной модели

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

По определению Г.Буча, объект – это нечто, чем можно оперировать. Объект имеет состояние, поведение и идентичность [4, стр.473]. Объект в методологии объектно-ориентированного проектирования с точки зрения системологии является знаковым объектом. Г.Буч в своей книге [4, стр.92] приводит определение Смита и Токи: «Объект представляет собой конкретный опознаваемый предмет, единицу или сущность (реальную или абстрактную), имеющую четко определенное функциональное назначение в данной предметной области». Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств [4, стр.94]. К числу свойств объекта относятся присущие ему или приобретаемые им характеристики, делающие объект самим собой [4, стр.94]. Поведение – это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений [4, стр.96].

Объектная модель – это совокупность основополагающих принципов, лежащих в основе объектно-ориентированного проектирования, и/или парадигма программирования, основанная на принципах абстрагирования, инкапсуляции, модульности, иерархичности, типизации, параллелизма и устойчивости [4, стр.473]. Абстракция – это существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя. Абстрагирование – процесс выявления абстракций [4, стр.468]. Инкапсуляция – это процесс объединения и защиты элементов абстракции, которые образуют ее структуру и поведение. Служит для отделения внешних обязательств объекта от его реализации [4, стр.471].

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

Иерархия – это подчинение или упорядочение абстракций [4, стр.471]. Типизация – механизмы, препятствующие замене объектов одного типа на другой или, в крайнем случае, жестко ограничивающие такую замену [4, стр.477]. Параллелизм – это свойство, отличающее активные объекты от неактивных. Параллельный объект – активный объект, способный работать в многопоточной среде [4, стр.474].

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

Классы и объекты – это отдельные, но тесно связанные понятия. В частности, каждый объект является экземпляром какого-либо класса; класс может порождать любое число объектов. В большинстве практических случаев классы статичны, то есть все их особенности и содержание определены в процессе компиляции программы. Сами объекты, напротив, в процессе выполнения программы создаются и уничтожаются. Для оценки качества классов и объектов, выделяемых в системе, в соответствии с [4, стр.138] можно предложить следующие пять критериев: зацепление, связность, достаточность, полнота, примитивность.

Зацепление определяется как степень глубины связей между отдельными модулями. Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями.

Под полнотой подразумевается наличие в интерфейсной части класса всех характеристик абстракции. Примитивными являются только такие операции, которые требуют доступа к внутренней реализации абстракции [4, стр 139]. Таким образом, можно сделать следующие выводы:

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

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

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

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

5. Декомпозиция

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

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

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

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

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

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

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

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

6. Синтез и анализ в изучении сложных систем

Разделение или декомпозиции применяется в случаях, когда рассматривается существующая система или проектируется новая. При этом применяются два фундаментальных понятия системологии: анализ (как было сформулировано – рассмотрение) и синтез (проектирование) систем. Задачи анализа определяются как изучение свойств и поведения системы в зависимости от ее структуры и значений параметров, исходя из заданных свойств системы; задачи синтеза сводятся к выбору структуры и значений параметров, исходя из заданных свойств системы [5, стр.37].

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

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

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

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

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

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

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

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

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

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

8. Особенности проектирования программных систем

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

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

Наиболее адекватное определение архитектуры, на наш взгляд приведено в [4, стр. 470]: архитектура – это логическая и физическая структура системы, сформированная всеми стратегическими и тактическими проектными решениями. Хорошей архитектуре присуще следующие основные черты:

1. многоуровневая система абстракции;
2. модульность;
3. простота.

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

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

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

Г.Буч приводит мнение Ингалса [4, стр. 138], отражающие суть модульности: «для построения системы должен использоваться минимальный набор неизменяемых компонент; сами компоненты должны быть по возможности стандартизованы и рассматриваться в рамках единой модели». Применительно к объектно-ориентированному проектированию такими компонентами являются классы и объекты, отражающие ключевые абстракции системы, а единство обеспечивается соответствующими механизмами реализации.

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

9. Системологическое описание проектирования программных систем

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

Здесь каждый объект является экземпляром заданной абстракции. Структурой системы являются устойчивые взаимосвязи между подсистемами. Деление системы на подсистемы и объекты является условным и зависит от объема и сложности самой системы.

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

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

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

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

10. Заключение

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

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

1. Флейшман Б. С. Основы системологии, М.: Радио и Связь. 1982.
2. Слюсаренко И.М., Слюсаренко М.Ю. Системный подход в автоматизации процессов компаний.
3. Слюсаренко И.М., Слюсаренко М.Ю. Основы системологии и автоматизация бизнес-процессов компаний.
4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С ++, 2-е изд./Пер. с англ .- М.: «Издательство Бином», СПб.: «Невский диалект», 1999 г.
5. Бусленко Н. П. Моделирование сложных систем. М.: Наука. 1978г.