Подход для моделирования правил архитектурного проектирования Authors: ANDERS MATTSSON, Combitech AB, Sweden and University of Limerick, Ireland BRIAN FITZGERALD, University of Limerick, Ireland BJORN LUNDELL, University of Skovde, Sweden and University of Limerick, Ireland BRIAN LINGS, University of Sk¨ovde, Sweden

Цель Главная цель исследований заключалась в разработке подхода для моделирования правил архитектурного проектирования. Требования к подходу: - поддается автоматизации - легкий для понимания

Рассмотренные методы и походы - OMGs MDA [OMG 2003], DSM [Karsai et al. 2003; Tolvanen and Kelly 2005], and Software Factories [Greeneld and Short 2004] from Microsoft - ADD [Bass et al. 2003; Wojcik et al. 2006]; RUP 4+1 Views [Kruchten 1995, 2004]; QASAR [Bengtsson and Bosch 1998; Bosch 2000; Bosch and Molin 1999]; S4V [Hofmeister et al. 2000; Soni et al. 1995]; BAPO/CAFCR [America et al. 2004; van Der Linden et al. 2004]; and ASC [Ran 2000] - ADL [Medvidovic and Taylor 2000; Medvidovic et al. 2002, 2007] ACME, Aesop, C2, MeatH, AADL

Основные проблемы - Замедление детального проектирования - Преждевременное детальное проектирование - Плохое качество обзора - Плохая связь

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

Пример

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

Традиционный подход D1. Элемент данных Data Item является классом, который отражает состояние системы или ее окружения, которые необходимы приложению. D2. Элемент данных Data Item должен наследовать Infrastructure::Subject. D3. Элемент данных Data Item должен быть определен в пакете элементов данных Data Items. D4. Только общие операции элемента данных Data Item должныы быть установлены и необходимо получить операций чтения и записи данных, хранящихся в классе. D5. Элемент данных Data Item может быть набором элементов данных Data Items. D6. Набор операций для элемента данных Data Item должны всегда заканчиваться вызовом его Notify операции.

Подход авторов статьи

Автоматизация Автоматизация была обеспечена путем разработки инструментов для автоматической проверки, что система выполнила архитектурные правила. MOFScript является инструментом для преобразования текста, например, для поддержки генерации кода или документации из моделей. Object Constraint Language (OCL) является декларативным языком для описания правил, которые применяются к Unified Modeling Language (UML) модели, разработанный в IBM, а сейчас является частью UML стандарта.

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

Система для тестирования подхода Программная платформа для цифровых телевизионных приставках для стандартов DVB. Разработана с использованием инструментов моделирования Rhapsody. Размер программной платформы была приблизительно LoC в C++

Инструмент Инструмент построен в C + + В настоящее время инструмент ограничивается чтением Rhapsody модели Общие количество часов по созданию инструмента составляет примерно 200

Итоги - Разработали подход для моделирования архитектурных правил дизайна в UML. - Автоматизировали подход. - Протестировали на реальном проекте.