Интеграция средств объектного и структурного анализа при разработке программных систем

Богатырёв П.Ю.

Россия, Орел, Госуниверситет-УНПК

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

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

Основной особенностью процесса разработки программного обеспечения является его чрезвычайно высокая сложность. Брукс пишет: “Энештейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справится, лежит в самой природе системы” [цит. по 2, С. 12]. Стив Макконел, ссылаясь на Эдсгара Дейкстру, отмечает, что “компьютерные технологии — единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 10^9 , или разнице в девять порядков” [1, С. 75-76]. При этом он добавляет, что “за прошедшее с 1989 г. время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками” [1, С. 76]. Поэтому, боьбру со сложностью Макконел декларирует как “Главный Технический Императив Разработки ПО” [1, С.74-78]. В данной статье предлагается способ борьбы со сложностью программных проектов, заключающегося в создании интегрированной системы моделирования и описания программного проекта.

Одним из наиболее действенных средств борьбы со сложностью, как известно, является абстрагирование [2, С. 23]. В контексте разработки программных систем абстрагирование применяется двумя способами. Во-первых, это структурирование самого программного кода в соответствии с некоторой моделью. Буч выделяет пять видов таких моделей [2, С. 24]: процедурно-ориентированные (алгоритмы), объектно-ориентированные (классы и объекты), логико-ориентированные (цели, часто выраженные в терминах исчисления предикатов), продукционные (правила "если, то"), ориентированные на ограничения (инвариантные соотношения). В каждом из этих подходов программа представляется как иерархическая система взаимодействующих между собой элементов. При этом количество элементов, их строение, а также сложность взаимодействия даже в небольших проектах существенно затрудняют понимание системы программистом. При этом, в крупных компаниях эта проблема весьма актуальна. Программисты вынуждены работать с чужим кодом, написанным другими участниками проекта при недоступности автора кода, рефакторинге, ревизии кода, написания тестов, отладки, написания документации, поддержки и т.д. Согласно Спинеллису, “от 40 до 70% трудозатрат на разработку программных систем расходуется уже после того, как эта система впервые написана и запущена. Эти трудозатраты непременно включают в себя чтение, понимание и внесение изменений в исходный код” [6, С. 21]. Поэтому второй способ борбы со сложностью программного кода заключается в сопровождении его дополнительными описаниями, которые позволили бы упростить его восприятие программистами. Такое описание как правило представляется в виде описания программной архитектуры и представляется набором различных документов, описывающих систему с различных точек зрения [7, 9, 10].

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

 Анализируя все основные этапы развития языков программирования можно выделить два основных подхода, имеющих ортогональные друг другу представления. Это процедурное программирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное, основанное на объектной декомпозиции. Оба подхода хорошо зарекомендовали себя на практике послужив основой для огромного числа крупных успешных проектов[1, 2, 3, 11]. Для каждого из подходов было разработано множество теоретических и методологических материалов, обосновывающих эффективность данных подходов и описывающих способы их применения на практике.

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

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

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

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