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

• Автор: Ахтырченко, Кирилл Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2001
• Место защиты: Москва
• Количество страниц: 149 с. : ил

Содержание

1. ГЛАВА 1. ТЕКУЩЕЕ СОСТОЯНИЕ РАБОТ

1.1 Классификации структур пл

1.2 Моделирование транзакционных вычислений на архитектурном уровне проектирования

1.3 Обратное проектирование ПА.

2. ГЛАВА 2. МЕТОД КЛАССИФИКАЦИИ СТРУКТУР ПРИ МОДЕЛИРОВАНИИ ПА.

2.1 ПОДХОД К КС

2.2 Измерения признаки классификации.

2.3 Результат классификации4

2.4 Применение КС в процессе моделирования ПА

3. ГЛАВА 3. МОДЕЛИРОВАНИЕ ТРАНЗАКЦИОННЫХ ВЫЧИСЛЕНИЙ НА АРХИТЕКТУРНОМ УРОВНЕ ПРОЕКТИРОВАНИЯ
3.1 Метамодель и модель ТС ПС
3.2 Связи ТС с другими структурами архитектурного уровня проектирования
3.3 Переход от модели ТС к ТС ПС.
3.4 Описание ТС ПС на ПМЬ.
3.5 Метод построения ТС
4. ГЛАВА 4. МЕТОД ОБРАТНОГО ПРОЕКТИРОВАНИЯ ПА .
4.1 Основные артефакты результаты применения МОП ПА
4.2 Реализуемый МОП ПА поток работ.
4.3 ТЕХНОЛОГИЯ применения и АДАПТАИЯ МОП ПА
4.4 Связь МОП ПА с процессом прямого ИНЖИНИРИНГА ПС
4.5 Степень удовлетворения МОП па выдвинутым требованиям.
ЗАКЛЮЧЕНИЕ ОСНОВНЫЕ РЕЗУЛЬТАТЫ.
СПИСОК ИЛЛЮСТРАЦИЙ .
СПИСОК СОКРАЩЕНИЙ
СПИСОК ЛИТЕРАТУРЫ


Как правило, на основе созданной модели ПрО, целей, экономических показателей и ограничений на проект осуществляется формирование требований, где под требованием подразумевается способность выполнять определенную функцию (функциональное требование) или быть конформной определенным условиям []. Полученные результаты являются основополагающей информацией, которая поступает на вход процесса моделирования ПЛ. Создание или выбор ПА. Не существует формальных, предусматривающих строго предопределенную последовательность действий, методов создания или выбора ПА. Результат зависит от многих факторов, включая цели организации, требования к ПС и опыт архитектора. Тем не менее, существуют механизмы, поддерживающие данный вид деятельности, как например, методы анализа ПА, архитектурные стили и образцы проектирования. Представление (описание) ПА. ПА выступает как средство, обеспечивающее понимание ПС, коммуникации между заинтересованными лицами. С другой стороны, воплощая проектные решения, она является основой для реализации и обеспечения последующего эволюционного развития ПС. Поэтому описание ПА должно быть информативным, недвусмысленным, читабельным и в максимальной степени формализованным. Последнее обусловлено еще и тем, что ПА является исходной информацией лля формализованных методов анализа, включая симуляцию, верификацию и прототипирование. Для описания ПА применяются языки визуального моделирования, например, язык ЦМЬ [, ], и формальные языки описания программных архитектур (АЛЬб) [1,2,,]. Анализ (оценка) программной архитектуры. Данный вид деятельности предусматривает применение различных методов анализа ПА. Например, на основе Метода Анализа Программных Архитектур (Software Architecture Analysis Method (SAAM)), предложенного в [2], может быть оценен ряд характеристик качества ПС (переносимость (portability), расширяемость (extensibility) и т. В отличие от SAAM, ориентированного на анализ характеристик качеств, формальные языки описания ПА позволяют осуществить анализ свойств, различимых (наблюдаемых) во время исполнения (runtime) ПС []. Обеспечение гарантий соответствия ПА реализации IIC. Этот вид деятельности направлен на достижение соответствия реализации ПС разработанной ПЛ. Существует ряд ПР, где моделирование Г1А является одним из доминирующих видов деятельности, являясь составной частью ядра используемой методологии. Примером таких процессов могут быть Унифицированный Процесс, созданный компанией Rational [] и Архитектурный Метод Проектирования (ABD Method) []. На Диафамме 1 представлены виды деятельности процесса моделирования IIA и устанавливаемые между ними связи. В качестве средства описания была применена диафамма вариантов использования (Use Case Diagram) языка IJML. Заметим, что на диафаммс не показаны причинно-следственные отношения между видами деятельности, поскольку они могут существенно отличаться в зависимости от рассматриваемых ПР ПС. Диафамма 1. На Диаграмму 1 также были вынесены виды деятельности: «Реинжиниринг программной архитектуры» (включает обратное проектирование программной архитектуры) и «Повторное использование программной архитекту ры». Первый из них, применительно к обратному проектированию, осуществляется в случае, если при создании ПС имеется унаследованная система, ПА которой не описана. Второй включает деятельность по разработке и описанию повторно используемых архитектурных решении. Оба вида деятельности расширяют вид деятельности «Создание или выбор программной архитектуры». Существует ряд близких по отношению к ПА направлений (концепций), затрагавающих вопросы структурной организации ПС и поддерживающих моделирование ПА [1, 2, - ]. В последующих разделах приводится краткое описание направлений, которые в наибольшей степени соотносятся с моделированием ПА. Формальные методы, как правило, не применяются самостоятельно при моделировании ПА, а выступают формальными базисами в рамках других направлений, например, ЯОА. Язык CSP (Communicating Sequential Processes) [J. Одной из задач, встающих перед разработчиками ПС, является проблема приобретения опыта и передачи знаний.