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

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

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

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

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

Становление моделирования ПА как научно-практической дисциплины приходится на период конца 1980;х — начала 1990;х годов и может рассматриваться как результат эволюционного развития методологий и технологий разработки ПС, сопровождающийся сменой парадигм в программной инженерии. Неправильно было бы утверждать, что до этого периода ПС не имели архитектуры. Программы, создаваемые в 1960;х годах, делились на модули, программистами определялась логика их взаимодействия, идентифицировались глобальные свойства, которыми должна была обладать программа в целом [1]. Уже тогда при построении программ разработчики руководствовались определенными стратегиями организации программ, которые можно было бы рассматривать как архитектурные образцы [1,2]. Однако применение этих образцов было преимущественно неформальным, поскольку не существовало методологий и средств, требуемых для их формального описания, использования и анализа.

Ситуация изменилась в связи с появлением в 1970;х годах повышенного интереса к проектированию ПС (Software Design) со стороны исследователей. В этот период явного акцента на решение проблем, связанных с моделированием ПА, не наблюдалось, поскольку основное внимание исследователей было направлено, в первую очередь, на определение проектирования как деятельности, отличной от реализации ПС, специализированных методик, инструментальных средств и систем обозначения (в дальнейшем — нотаций или языков описания). Тем не менее, результатом исследований стало появление первых средств автоматизации проектирования (CASE (computer-aided software engineering) tools), применение которых упорядочивало процесс проектирования, но не обеспечивало четкую организацию процесса разработки ПС в целом.

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

Конец 1980;х — начало 1990;х годов характеризовались появлением новых информационных технологий (ИТ), обеспечивающих организацию распределенных вычислений в неоднородных средах, что предоставило разработчикам множество альтернатив при разработке ПС. Примерами могут служить: технология промежуточного программного обеспечения, технология менеджеров транзакций [3]. Причина появления новых технологий во многом определялась той ролью, которую стали отводить ИТ в различных компаниях, а также появлением и бурным распространением персональных компьютеров, их объединением в рамках корпоративных компьютерных сетей. Для многих организаций наличие соответствующих ПС являлось необходимым условием доминирования на рынке, а иногда и выживания. Многие компании достигли конкурентных преимуществ благодаря использованию ИТ. В то же время экспансия персональных компьютеров в различной степени сделала доступными ПС практически каждому сотруднику организаций. В 1990 году в мире насчитывалось около 30 тысяч больших универсальных компьютеров, в то время как число персональных компьютеров составляло свыше 30 миллионов [4]. Результаты использования ИТ для персональных компьютеров делались очевидными: легкий в применении графический интерфейс пользователя, фактически неограниченный доступ к ресурсам персонального компьютера с индивидуального рабочего места и новое представление о компьютерах и программах, выполняемых на них.

Как результат, существенно расширился спектр задач, которые могли быть эффективно решены с использованием ИТ, что способствовало их широкому проникновению в различные сферы деятельности. Во многих организациях информационная система приобрела статус корпоративной системы, охватывая большое количество существующих в организации процессов. В условиях роста значимости ИТ при достижении конкурентных преимуществ и распространения персональных компьютеров произошло увеличение доли средств, выделяемых в организациях для информатизации своей деятельности. Так, если в 1970 году организации в среднем тратили на информатизацию около 1% своего бюджета, то в 1990 году этот процент составлял уже 3% и к настоящему моменту продолжает увеличиваться [4]. Высокая стоимость проектов информатизации определила стремление организаций минимизировать вероятность их провала. Для разработчиков такое стремление проявилось в виде требования организаций-заказчиков предоставить им гарантии успешного выполнения проектов. Это делалось возможным, если уже на самых ранних этапах разработки были известны свойства (характеристики), которыми будет обладать создаваемое ПС. С учетом увеличения размера и сложности ПС это привело к тому, что проектирование, спецификация и анализ высокоуровневой структуры ПС становились одним из самых важных аспектов процесса разработки. В то же время в процессе исследований было установлено [2], что высокоуровневая структура системы позволяет осуществить не только анализ на предмет соответствия ПС выдвинутым требованиям, но может выступать также в качестве базиса при решении различных проблем, возникающих при проектировании крупномасштабных программных систем, управлении и оценке процесса разработки, повторном использовании решений и др. Именно в этот период моделирование ПА стало выделяться в самостоятельную научно-практическую дисциплину, оставаясь при этом составной частью программной инженерии.

К сожалению, не существует универсального общепризнанного определения ПА. Данный объект определяется различными способами [5].

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

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

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

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

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

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

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

Наличие тех или иных структур, являющихся составной частью ПА, обусловлено целями, которые исследователи и/или разработчики планируют достичь в процессе ее моделирования. Обобщая [2, 9−11], можно утверждать, что использование ПА позволяет достигнуть следующих целей при разработке ПС.

ПА обеспечивает достижение понимания ПС, коммуникации на высоком уровне проектирования, коммуникации между заинтересованными лицами.

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

Одновременно с этим, ПА выступает в качестве базиса при проектировании и эволюции прототипов ПС.

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

ПА выступает в качестве базиса при анализе ПС, реализуемых в них технологических решений.

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

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

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

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

ПА, реализуя принцип обратной связи, в свою очередь, воздействует на внешнюю среду. Объектами влияния могут быть организационная структура разрабатывающей ПС организации, корпоративные цели организации, требования к следующим версиям ПС, корпоративные знания и опыт, «Технологическая культура» [2].

Например, в соответствии с ПА, а именно — декомпозицией ПС на компоненты, могут быть сформированы структура работ и команды разработчиковПА может наложить ограничения на те изменения, которые заказчик желает увидеть в новой версии ПС. Разработка новых ПА может привести к изменениям, в том числе смене парадигм в программной инженерии. Примером могут служить те изменения, которые произошли в технологиях построения распределенных информационных систем вследствие появления Общей Архитектуры Брокера Объектных Запросов (CORBA)[12],.

В зависимости от интересующих свойств (характеристик) ПС с ПА связывают различные структуры или «взгляды» (представления — view), которые в совокупности описывают ПА. Так, обобщая взгляды на ПА из [2, 11, 13], можно выделить следующие основные структуры.

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

Модульная структура (Module (Development) structure). Модульная структура определяет организацию ПС как совокупности модулей — программных единиц, с которыми могут быть соотнесены рабочие задания, выполняемые членами проектной команды. Примером связи, устанавливаемой между модулями, может быть «является подмодулем». В зависимости от того, как осуществляется выделение модулей, какие виды межмодульных связей используются, имеются различные формы модульных структур. Примерами форм являются: группировка модулей в подсистемы, а также многоуровневая иерархическая организация модульной структуры.

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

Физическая структура (Physical structure). Физическая структура определяет отображение элементов ПС на аппаратное обеспечение. Как правило, в рамках данной структуры осуществляется распределение процессов по объединенным в сеть вычислительным узлам — элементам структуры. Моделирование физической структуры бывает особенно важно при распределенных вычислениях и параллельной обработке данных.

Описанные выше структуры являются наиболее распространенными [2, 11, 13, 14, 15−17]. В то же время, при моделировании ПА используются и другие структуры: структура «вызовов» (Call structure), структуры, определяющие потоки данных и потоки управления (Data Flow structure and Control Flow structure), структура использования (Uses structure), структура классов (Class structure) [2]. Применение каждой из них соотносится с моделированием определенных аспектов (характеристик) ПС и обеспечивает отличный от других взгляд на ПС.

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

Один из подходов, обеспечивающий совместное согласованное использование различных структур, был предложен в [14]. Он заключается в определении, помимо основных четырех структур, пятой, элементами которой являются сценариипоследовательности действий, выполняемых ПС и являющихся абстракцией функциональных требований. Следствием введения пятой структуры становится возможность показать, насколько правильно «работают» элементы различных структур в рамках некоторого сценария. Данный подход применен в Унифицированном Процессе Разработки Программных средств (USDP) [16] и Архитектурном Методе Проектирования (ABD Method) [15].

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

Моделирование ПА является частью процесса разработки ПС, а ПА — его артефактом. Выделяют следующие виды деятельности в процессе разработки, которые соотносятся с моделированием ПА [2,11].

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

2. Достижение понимания требований к ПС. Как правило, на основе созданной модели ПрО, целей, экономических показателей и ограничений на проект осуществляется формирование требований, где под требованием подразумевается способность выполнять определенную функцию (функциональное требование) или быть конформной определенным условиям [18]. Полученные результаты являются основополагающей информацией, которая поступает на вход процесса моделирования ПА.

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

4. Представление (описание) ПА. ПА выступает как средство, обеспечивающее понимание ПС, коммуникации между заинтересованными лицами. С другой стороны, воплощая проектные решения, она является основой для реализации и обеспечения последующего эволюционного развития ПС. Поэтому описание ПА должно быть информативным, недвусмысленным, читабельным и в максимальной степени формализованным. Последнее обусловлено еще и тем, что ПА является исходной информацией для формализованных методов анализа, включая симуляцию, верификацию и прототипирование. Для описания ПА применяются языки визуального моделирования, например, язык UML [19, 20], и формальные языки описания программных архитектур (ADLs) [1, 2, 21,22].

5. Анализ (оценка) программной архитектуры. Данный вид деятельности предусматривает применение различных методов анализа ПА. Например, на основе Метода Анализа Программных Архитектур (Software Architecture Analysis Method (SAAM)), предложенного в [2], может быть оценен ряд характеристик качества ПС (переносимость (portability), расширяемость (extensibility) и т. п.). В отличие от SAAM, ориентированного на анализ характеристик качеств, формальные языки описания ПА позволяют осуществить анализ свойств, различимых (наблюдаемых) во время исполнения (runtime) ПС [22].

6. Обеспечение гарантий соответствия ПА реализации ПС. Этот вид деятельности направлен на достижение соответствия реализации ПС разработанной ПА.

Существует ряд ПР, где моделирование ПА является одним из доминирующих видов деятельности, являясь составной частью ядра используемой методологии. Примером таких процессов могут быть Унифицированный Процесс, созданный компанией Rational [17] и Архитектурный Метод Проектирования (ABD Method) [15].

На Диаграмме 1 представлены виды деятельности процесса моделирования ПА и устанавливаемые между ними связи. В качестве средства описания была применена диаграмма вариантов использования (Use Case Diagram) языка UML. Заметим, что на диаграмме не показаны причинно-следственные отношения между видами деятельности, поскольку они могут существенно отличаться в зависимости от рассматриваемых ПР ПС.

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

•icinciude" /^, include" include".

Анализ и оценка программной Представление (описание) программной архитектуры архитектуры f / t ¦ include".

I «include» ^ ^ «include"44 еинжениринг программной архитектуры, 'bartend».

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

Диаграмма 1. Процесс моделирования ПА.

На Диаграмму 1 также были вынесены виды деятельности: «Реинжиниринг программной архитектуры» (включает обратное проектирование программной архитектуры) и «Повторное использование программной архитектуры». Первый из них, применительно к обратному проектированию, осуществляется в случае, если при создании ПС имеется унаследованная система, ПА которой не описана. Второй включает деятельность по разработке и описанию повторно используемых архитектурных решений. • Оба вида деятельности расширяют вид деятельности «Создание или выбор программной архитектуры».

Существует ряд близких по отношению к ПА направлений (концепций), затрагивающих вопросы структурной организации ПС и поддерживающих моделирование ПА [1, 2, 21 — 23]. Такими направлениями являются: формальные методы (formal methods) моделирования ПАобразцы проектирования (design patterns) ПСархитектурные стили (architectural styles) — эталонные модели и архитектуры (reference models and reference architectures) — «языки описания архитектур (architecture description languages) ПС (ЯОА) — языки визуального моделирования (visual modeling languages) ПСязыки программирования (programming languages) — языки определения интерфейсов (interface definition languages) — языки описания межмодульного взаимодействия (module interconnection languages).

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

Формальные методы, как правило, не применяются самостоятельно при моделировании ПА, а выступают формальными базисами в рамках других направлений, например, ЯОА. Так, при описании и анализе ПА используются следующие формальные методы:

Абстрактная Химическая Машина (Chemical Abstract Machine) [24];

Z — нотация (Z-notation) [25,26]- в Логика первого порядка (first-order logic) [27];

Теория Графов (Graph Theory) [28,29];

Машина состояний (State Machine) [22]- - Сети Петри (Petri Nets) [22, 29];

Язык CSP (Communicating Sequential Processes) [22].

Одной из задач, встающих перед разработчиками ПС, является проблема приобретения опыта и передачи знаний. Направление образцов проектирования (Design.

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

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

В отличие от эталонной модели архитектурный стиль (АС) есть: множество типов компонентов (например, хранилище данных, процесс, процедура) — топология, определяющая взаимосвязи времени исполнения (runtime) между компонентами этих типовмножество семантических ограничений (например, информационное хранилище не позволяет изменять хранящиеся в нем данные) — множество «соединителей» (connectors) — абстракций, которые обеспечивают коммуникацию и координацию при взаимодействии компонентов. Примерами «соединителей» могут быть «вызов удаленных процедур» (remote procedure call (RPC)), «поток данных» (data stream), «сокеты» (sockets).

AC, как и образцы проектирования, и эталонные модели, направлены на решение задач приобретения опыта и передачи знаний. АС определяет правила организации семейства систем в терминах образцов структурной организации [1]. Имеется большое количество описанных АС [30], примерами которых могут быть: «client/server» (клиент/сервер), «pipe/filter» (канал/фильтр) и «data-centered» (централизованные данные).

Эталонные архитектуры можно рассматривать как отображение эталонных моделей на компоненты программных средств и потоки данных между этими компонентами. В то время как эталонные модели воплощают стандартную декомпозицию функциональности, эталонные архитектуры определяют отображение функциональности на компоненты. Одной из возможных связей между эталонными моделями, АС, эталонными и ПА может быть следующая [2]: результатом применения некоторого АС по отношению к эталонной модели является эталонная архитектура, которая может быть конкретизирована до уровня ПА.

ЯОА (ADLs) [1, 2, 21, 22] образуют одно из наиболее развитых направлений формализованного моделирования ПА. Примерами языков являются: Wright, UniCon, SADL, Rapide, ACME, ArTek, AESOP, Modechart. Согласно [21], ЯОА — это язык, предоставляющий средства для моделирования концептуальной ПА. Основными элементами таких языков, как правило, являются: компоненты", для которых могут быть определены поддерживаемые ими интерфейсы (или в терминах языка ACME [31] - «порты») — соединители" (connectors), реализующие протоколы взаимодействия «компонентов» и также поддерживающие определенные интерфейсы (или в терминах языка ACME [31] - «роли») — архитектурные конфигурации, которые являются композицией «компонентов» и «соединителей» и могут быть представлены в виде иерархической структурыограничения" на композицию «компонентов» и «соединителей» в рамках архитектурных конфигураций.

Большая часть ЯОА предусматривает типизацию компонентов и соединителей, позволяет описывать их «семантику» (динамику поведения). Ряд языков, например, Rapide и Wright [22], имеют средства описания и повторного использования АС. Такие языки, как ACME, AESOP и UniCon [21], делают — возможным описание на уровне языка нефункциональных требований.

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

ЯОА предоставляют средства анализа свойств моделируемого ПС, позволяют описывать и анализировать на архитектурном уровне различные виды межкомпонентного взаимодействия, включая потоки данных и потоки управления. Например, язык Wright [20] предоставляет практические средства описания и анализа образцов дискретного асинхронного взаимодействия на уровне ПА и АС. Как было сказано ранее, анализ свойств ПС требует формализованного описания ПА, в том числе — семантики компонентов и соединителей. Для этой цели в ЯОА используются [22]: State Machine, CSP, Z-нотация, сети Петри, логика первого порядка, теория графов и другие формальные методы.

Языки визуального моделирования, используемые для описания и анализа программной архитектуры, можно разделить на три категории:

Языки, являющиеся визуальным представлением формализованного текстуального описания ПА, например, на ЯОА [31].

Языки, неформально описывающие ПА, например, с помощью «box and line» диаграмм [22] и используемые без каких-либо поддерживающих их формальных методов.

Общецелевые языки моделирования, т. е. допускающие в различной степени моделирование, как ПА, так и других моделей, возникающих в процессе разработки программных средств. Примером языка данной категории является UML (Unified Modeling Language), который определяется в [20] не только как язык визуализации, но и как язык спецификации, конструирования и документирования. В основу методологии моделирования, поддерживаемой этим языком, положен подход [14], обеспечивающий совместное согласованное использование различных структур программного средства. Язык UML, с одной стороны, имеет строго определенную семантику, описанную на базе четырехуровневой метамодели языка, а с другой стороны, является расширяемым, предоставляя средства введения новых элементов языка [19, 20]. Имеются отдельные примеры интеграции языка UML с другими средствами и методами моделирования ПА [32, 33]. В настоящий момент он стандартизируется OMG [19].

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

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

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

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

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

Текст диссертации включает введение, четыре главы, заключение, список литературы и приложения.

1. Shaw М., Garlan D. Software Architecture. London: Prentice-Hall, 1996.

2. Bass L., Clements P., Kazman R. Software Architecture in Practice. Reading: Addison Wesley, 1998.

3. Orfali R., Harkey D., Edwards J. The Essential Distributed Objects. New York: Wiley Computer Publishing, 1996.

4. Vaskevitch D. Client/Server Strategies. A survival guide for corporate reengineers. Foster City: IDG Books Worldwide, 1995.

5. Software Architecture, What is software architecture? URL: http//www.sei.cmu.edu/architecture/definitions.html, Carnegie Mellon University.

6. Garlan D., Shaw M. An Introduction to Software Architecture // Advances in Software Engineering and Knowledge Engineering. Vol. 2, World Scientific Publishing Company, Singapore, pp. 1−39, 1993.

7. Философский словарь/ Под ред. И. Т. Фролова М.: Политиздат, 1980.

8. Хомяков Д. М., Хомяков П. М. Основы системного анализа. М.: Изд-во механико-математического факультета МГУ, 1996.

9. Perry D.E., Wolf A.L., Software Architecture // ACM SIGSOFT Software Engineering Notes. 1992. 17, N4. 40−52.

10. Morris C.R., Ferguson C.H. How Architecture Wins Technology Wars // Harvard Business Review, 1993, p. 86−96.

11. Clements P.C., Northrop L.M. Software Architecture: An Executive Overview. Technical Report CMU/SEI-96-TR-003, ESC-TR-96−003. Pittsburgh, 1996.

12. Hoque R. CORBA 3 Developer’s Guide. Foster City: IDG Books Worldwide, 1998.

13. Budgen D. Software Design. Reading: Addison-Wesley, 1994.

14. Kruchten P.B. The 4+1 View Model of Architecture // IEEE Software. 1995. 12, N 6. 4250.

15. Kruchten P. The Rational Unified Process: an introduction. Reading: Addison Wesley, 1999.

16. GradyR.B. Practical Software Metrics For Project Management and Process Improvement. London: Prentice Hall, 1992.

17. OMG Unified Modeling Language Specification. Version 1.3. June 1999. http://www.omg.org.

18. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User Guide. Reading: Addison Wesley, 1999.

19. Medvidovic N. A Classification and Comparison Framework for Software Architecture Description Languages. Technical Report UCI-ICS-97−02. Irvine, 1996.

20. Allen R.J. A Formal Approach to Software Architecture: Thesis, Pittsburgh, 1997.

21. Gamma E., Helm R., Johnson R., Vlisssides J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading: Addison Wesley, 1995.

22. Wermelinger M. Specification, Testing and Analysis of (Dynamic) Software Architecture with the Chemical Abstract Machine. Departamento de Infomatica, Universidade Nova de Lisboa, Portugal. 1998.

23. Abowd G., Allen R., Gralan D. Formalizing style to understand descriptions of software architecture. Technical Report CMU-CS-95−111. Pittsburgh, 1995.

24. SpiveyJ.M. The Z Notation: A Reference Manual. London: Prentice Hall, 1992.

25. Moriconi M. Qian X., Riemenschneider R. Correct architecture refinement // IEEE Transactions on Software Engineering, 1995. 21, N 4. 356−372.

26. Murphy G.C., Notkin D., Sullivan K. Software reflexion models: Bridging the gap between source and high-level models. Proceedings of the Third ACM SIGSOFT Symposium on the Foundations. Washington, 1995. pp. 18−28.

27. Брой M. Информатика, Часть 3. M.: Диалог-МИФИ, 1996.

28. Gacek С. Detecting Architectural Mismatches During Systems Composition: Thesis. Los Angeles, 1998.

29. Garlan D., Monroe R., Wile D. Acme: An Architecture Description Interchange Language // Proceeding of CASCON'97, 1997. Toronto, pp 169−183.

30. Robbins J.E., Medvidovic N., Redmiles D.F., Rosenblum D.S. Integrated Architecture Description Languages with a Standard Design Method. University of California, Irvine, 1997.

31. Egyed A. Integrated Architectural Views in UML. Technical Report USC/CSE-99-TR-514. Los Angeles, 1999.

32. Designing Software Architecture Using UML and Action Guide, www.bredemeyer.com.

33. Shaw M., Carlan D. Formulations and Formalisms in Software Architecture // Computer Science Today, number 1000 in LNCS, 1995. p. 307−323.

34. Muller H.A., Wong К., Tilley S.R. «Dimensions of Software Architecture for Program Understanding», Department of Computer Science Unversity of Victoria, Software Engineering Institute, Carnegie Melon Unversity.

35. Edwards J., DeVoe D. 3-Tier Client/Server At Work. New Work: Wiley Computer Publishing, 1997.

36. Common Business Object and Business Object Facility. OMG TC Document CF/96−01−04. http://www.omg.org.

37. Саймон A. P. Стратегические технологии баз данных: менеджмент на 2000 год. М.: Финансы и статистика, 1999.

38. Worah D., Sheth A. Advanced Transaction Models and Architectures. Boston: Kluwer Academic Publishers, 1997.

39. Vogel A., Rangarao M. Programming with Enterprise JavaBeans, JTS, and OTS: Building Distributed Transactions with Java and С++. New Work: Wiley Computer Publishing, 1999.

40. Дейт К.

Введение

в СИСТЕМЫ БАЗ ДАННЫХ, Киев Москва: Диалектика, 1998.

41. Katz F., Boucher К. Essential Guide to Object Monitors. New Work: Wiley Computer Publishing, 1999.

42. OMG Workflow Management Facility Specification, VI.2, April 2000. www.omg.org.

43. Intelligent Workflow State of the Art in Workflow, www.ai.sri.com.

44. Рузинкевич M., Цикоцки А. Определение и выполнение потоков транзакций // СУБД, 1995. N2. 106−115. N 4. 58−68.

45. Kamath M., Ramamritham К. Bridging the gap between Transaction Management and Workflow Management. Department of Computer Science University of Massachusetts, www-ccs.cs.umass.edu.

46. Object Management Group, www.omg.org.

47. Orfali R., Harkey D., Edwards J. Instant CORBA. New Work: Wiley Computer Publishing, 1997.50. www.workflowsoftware.com.

48. Biliris A., Dar S., Gehani N., Jagadish H.V., Ramamritham K. ASSET: A System For Supporting Extended Transactions // Proceedings of the 1994 ACM SIGMOD International Conference on Management of Data, pp. 44−54. Minneapolis, Minnesota, 1994. ,.

49. Eder J., Liebhart W. Workflow Transactions. Department of Informatics, University of Klagenfurt, Austria, January, 1996.

50. Worah D., Sheth A. What do Advanced Transaction Models Have to Offer for Workflow? Large Scale Distributed Information Systems Lab, The University of Georgia.

51. Chrysanthis P., Ramamritham K. ACTA: A Framework for Specifying and Reasoning about Transaction Structure and Behavior // Proceedings of the 1990 ACM SIGMOD International Conference on Management of Data, pp. 194−203. Atlantic City, 1990.

52. B.B. JIunaee Документирование и управление конфигурацией программных средств. М.: СИНТЕГ, 1998.

53. John Bergey, William Hefley, Walter Lamia, Dennis Smith A Reengineering Process Framework, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1995.

54. Paul Clements, Robert Krut, Ed Morris, Kurt Wallnan The Gadfly: An Approach to Architectural Level System Comprehension // Fourth IEEE Workshop on Program Comprehension, Berlin, March 1996.

55. Power Designer 7.0. Documentations.

56. Rick Kazman, S. Jeromy Carriere Playing Detective: Reconstructing Software Architecture from Available Evidence. Technical Report CMU/SEI-97-TR-010. Pittsburgh, 1997.

57. Rick Kazman, S. Jeromy Carriere View Extraction and View Fusion in Architectural Understanding, Software Engineering Institute, Carnegie Mellon University, Pittsburgh.

58. Murthy G., Notkin D. Lightweight Lexical Source Model Extraction // ACM Transactions on Software Engineering and Methodology, 5(3), 1996.

59. Guo G. Y., Atlee J. M., Kazman R. A Software Architecture Reconstruction Method, Department of Computer Science, University of Waterloo, Software Engineering Institute, Carnegie Mellon University.

60. Сахаров А. А. Принципы проектирования и использования многомерных баз данных (На примере Oracle Express Server) // СУБД, 1996. N 3.

61. Ахтырченко К. В., Леонтьев В. В. Распределенные объектные технологии в информационных системах//СУБД, 1997. N 5−6.

62. Jim Davies, Steve Schneider, A brief history of Timed CSP, University of Reading, University of London.

63. Moss J.E.B. Nested Transactions: An Approach to Reliable Computing. LCS-TR-260, Massachusetts Institute of Technology, Cambridge, MA, 1981.

64. Смит Д. М., СмитД.К. Абстракции баз данных: Агрегация и Обобщение // СУБД, 1996. N2. 141−160.

65. Буч Г. Объектно Ориентированный Анализ и Проектирование с примерами приложений на С++. М.: Издательство Бином, 1998.

66. Fowler М., Scott К. UML Distilled Applying the Standard Object Modeling Language. Reading: Addison Wesley, 1997.

67. Rational Unified Process, version 2000.02.10, Rational Software Corporation.

68. Бъерн Страуструп Язык программирования С++. M.: Невский Диалект Изд-во БИНОМ, 1999.

69. Питер Пин-Шен Чей, Модель «СУЩНОСТЬ-СВЯЗЬ» шаг к единому представлению данных. // СУБД, 1995. N 3.

70. William R. Duncan, A Guide to the Project Management Body of Knowledge, Project Management Institute, 2000.