Представление архитектурных знаний на основе онтологий: модуль структурных элементов

Аннотация

D. Ameller, X. Franch. Ontology-Based Architectural Knowledge Representation: Structural Elements Module В последние годы архитектурные знания (AЗ) превратились в дисциплину для разработки четких знаний архитекторов и процессов принятия архитектурных решений. В качестве консолидированного формализма для представления концептуальных знаний уже были предложены онтологии для представления AЗ. Следуя этой тенденции, в настоящее время мы разрабатываем онтологию для представления AЗ под названием Arteon. Онтология сформулирована в четырех модулях, и в этой статье мы сосредоточимся на одном из них, структурном модуле, который определяет элементы, необходимые для построения архитектура программного обеспечения. Поэтому мы разъясняем понятия архитектурного вида, каркаса и элемента, показываем их взаимосвязи, их точное определение требуется для управления архитектурным дизайном предписанным образом.

Вступление

Важнейшей задачей архитектора является создание архитектурно-проектных решений (ADD) [1]. В текущей практике архитекторы вносили дополнения, основываясь на своем опыте и интуиции, что может затруднить понимание, отслеживание и повторное использование дополнений. Даже такая практика может стать важным источником ошибок при проектировании. Эти ошибки на предварительных этапах разработки программного обеспечения, как уже неоднократно говорилось, приводят к высоким затратам на разработку, или они могут просто означать наихудший сценарий – провал проекта. Одна из основных причины, которые приводят нас к такой ситуации, заключаются в том, что архитектурные знания (AЗ) находятся только в умах архитекторов, они обычно не документируют свои решения, равно как и рассмотренные аргументы и альтернативы. Что касается исследовательского сообщества , то за последние два десятилетия архитектура программного обеспечения превратилась из простого структурного представления в 90-х годах в огромный методологический подход, а в настоящее время – в подход, ориентированный на принятие решений [2].

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

Среди других альтернатив мы выбрали использование онтологии для представления AЗ. Онтологии успешно использовались в других областях, где существовала необходимость представления знаний (например, разработка программного обеспечения, искусственный интеллект, семантическая сеть, биомедицина и т.д.). Наша онтология, Arteon, состоит из четырех модулей: Req-модуль, представляющий знания о требованиях к программному обеспечению; R-модуль, рассуждения и знания для принятия решений; SE-модуль, структурные элементы, представления и знания фреймворков; и MDD-модуль, знания, связанные с MDD. Несмотря на то, что четыре модуля взаимосвязаны (см. рис. 1), они слабо связаны и обладают достаточной степенью сцепления, чтобы их можно было использовать по отдельности или повторно.

Остальная часть этого документа разделена на: текущую работу в разделе 2, обзор SE-модуля в разделе 3 и выводы и будущая работа в разделе 4.

Текущая работа

Важная роль ADD в процессе проектирования архитектуры получила широкое признание [1,2,4]. Arteon можно считать шагом к этой консолидации, но наша позиция заключается в том, что концепции принятия решений должны быть изолированы от архитектурных элементов, и таким образом мы можем улучшить два вида знаний независимо. Дополнительные онтологии, скорее всего, будут сравниваться с модулем, а не с SE-модулем, который находится в центре внимания этой статьи.

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

• Акерман и Тайри [5] представили основанный на онтологии подход, ориентированный на ADD, но также включает часть онтологии, называемую архитектурных ассетах, которые похожи на структурные элементы, представленные в этой работе, но в их онтологии отсутствуют ключевые понятия, такие как вид и стиль.
• Arch Vol [6] – это онтология для представления архитектурного словаря. Терминология классифицируется по трем основным категориям: архитектурное описание (например, фреймворки, виды и точки зрения), архитектурный дизайн (шаблоны, стили, методологии и т.д.) и архитектурные требования (нефункциональные требования и сценарии). Большинство из этих концепций присутствуют в Arteon, не появляющиеся концепции, такие как анти-паттерн, не имеют прямого применения в архитектурном дизайн, который является конечной целью Arteon.


Рисунок 2 – Концептуальная модель SE-модуля

• Пал и др. [7] представили онтологию, которая фокусировалась на компонентах и соединителях как на общем способе описания архитектурных стилей. Эта онтология использует точные обозначения, поскольку конечная цель состоит в том, чтобы предоставить язык моделирования для архитектурных стилей. Знания, представленные в Arteon, могут быть использованы для создания моделей, но они не предназначены для использования в качестве языка моделирования.

Arteon: SE-модуль

В этом разделе мы сосредоточимся на SE-модуле Arteon. На рис. 2 мы представляем концепции этого модуля и взаимосвязи между ними, в то время как на рис. 3 мы показываем пример этих концепций в типичном сценарии веб-приложения. Большинство из этих концепций уже известны в этом сообществе. Но на самом деле мы можем обнаружить как незначительные расхождения, так и серьезные заблуждения в их использовании, поэтому мы должны тщательно их определять (по возможности, мы просто придерживаемся в некоторой степени общепринятого определения). Это наиболее важные концепции в SE-модуле:

Архитектурный вид. Представление всей системы с точки зрения связанного набора проблем [8]. Представления полезны в больших и сложных архитектурах, где попытка понять всю архитектуру в одном представлении может оказаться, по меньшей мере, трудной задачей. В примере (рис. 3) есть 4 вида: логичика, разработка, развертывание и платформа. Представления могут использоваться для отображения статических частей системы, таких как те, что приведены в примере, или поведенческих аспектов, таких как представление процесса, определенное в [9]. Наша онтология может использоваться как для статических, так и для поведенческих представлений, но наша текущая работа больше ориентирована на статические представления.

Архитектурный фреймворк. Определяет набор представлений для представления архитектуры, этот набор представлений также называется моделью представления. Примерами архитектурных фреймворков являются: RM-ODP [10] и модель представления 4+1 [9]. В примере (рис. 3) мы используем вариацию модели представления 4+1, которая учитывает представление платформы. Другие фреймворки, такие как TOGAF [11] и Zachman [12], поддерживаются частично, поскольку они определяют полную структуру предприятия , а нас интересует только программная часть.

Архитектурный элемент. Абстрактное понятие, обозначающее виды элементов, которые архитекторы могут решить использовать в своих архитектурных решениях. Мы рассматриваем четыре вида элементов: стили, вариации стилей, компоненты и реализации (подробности см. в следующих определениях). Все виды элементов имеют некоторые общие характеристики: они могут быть специализированными (например, 3-слойный стиль – это специализация многослойного стиля). Они могут устанавливать отношения или зависимости с другими элементами из других представлений. Глядя на рис. 3 мы можем увидеть несколько примеров: Tomcat с точки зрения платформы связан с сервером приложений, классы DAO связаны с пакетом DAO, пакет скриптов связан с PHP и т.д. Зависимости особенно полезны для обеспечения согласованности архитектуры при внесении изменений.

Стиль. Архитектурные стили (также известные как архитектурные паттерны) были широко определены в [13] и [14]: Архитектурный паттерн определяется набором типов элементов, топологическим расположением элементов, указывающим на их взаимосвязи, набором семантических ограничений и набором механизмов взаимодействия. Стили не следует путать с шаблонами проектирования, стили определяют всю структуру архитектуры для конкретного архитектурного представления, в то время как шаблон проектирования может быть применен к одной или нескольким частям архитектуры (обычно в одном и том же архитектурном представлении). В примере: в логическом представлении мы используем 3-слойный стиль; в представлении разработки мы используем стиль веб-приложения; в представлении развертывания мы используем специализированный стиль клиент-сервер, разделенный базой данных и сервером приложений [15]; и в представлении платформы мы используем стиль стекового решения.

Вариация стиля. На практике часто встречаются архитектуры, которые не следуют чистому архитектурному стилю. Вместо этого они следуют основному стилю , сопровождаемому некоторыми вариациями (примеры этих вариаций для многослойного стиля можно увидеть в [16], стр. 8). Обычно архитектор применяет несколько вариантов (некоторые из них являются альтернативами, см. несовместимые отношения на рис. 2) повысить степень удовлетворения требований. Мы можем определить изменение стиля как незначительную модификацию стиля, например, типичное изменение стиля заключается в применении узор в конкретной части архитектуры. В примере: 3-слойный стиль изменен с помощью шаблонов DAO и контроллеров; стиль веб-развертывания изменен с помощью репликации базы данных; и стиль веб-платформы изменен с помощью варианта FOSS. В настоящее время мы не пытаемся справиться со сложностью использования более чем одного стиля в одном представлении, но в большинстве случаев подойдет один стиль, сопровождаемый вариациями.

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

Реализация. Реализации – это реальные элементы, которые составят архитектуру программного обеспечения, когда оно будет реализовано. Эта часть знаний становится важной, поскольку в настоящее время большая часть программного обеспечения создается с использованием существующих частей программного обеспечения (или аппаратного обеспечения в некоторых случаях). В примере реализации будут следующими: классы, реализованные на некотором языке программирования, дистрибутив пакета, предоставляемый языком программирования, физические части оборудования, на которых развернута система (например, балансировщик нагрузки, который фактически реализован устройством от Cisco Systems) и конкретные версии компонентов платформы. В последних двух случаях эти знания могут быть повторно использованы в различных архитектурах и могут быть использованы для обеспечения удовлетворения требований или для обнаружения несовместимостей. Знания, не подлежащие повторному использованию (например, реализованные классы), не будут частью знаний этой онтологии. Чтобы лучше понять важность этой концепции, мы могли бы подумать в Сервис-ориентированные архитектуры (SOA). Эти архитектуры состоят из сервисов, которые иногда уже реализованы сторонними компаниями. Мы можем использовать знания о внедренных сервисах для более детального проектирования SOA.

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

Выводы и будущая работа

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

Мы внесем улучшения в Arteon, включая SE-модуль. Например, мы хотим заполнить онтологию данными, связанными с SOA, во время этого сбора знаний мы можем обнаружить некоторые детали, относящиеся к предметной области, которые важны в процессе принятия решений, но не представимы в текущем состоянии онтологии.

Другим направлением этой работы, которое уже ведется, является предоставление инструментальной поддержки для управления АЗ и руководства процессом принятия решений. С текущим состоянием этого инструмента можно ознакомиться по ссылке: http://www.essi.upc.edu/~ocollell/architech

Список использованных источников

1. Jansen, A., Bosch, J.: Software architecture as a set of architectural design decisions. In: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture, pp. 109–120. IEEE Computer Society Press, Washington, DC, USA (2005)
2. Kruchten, P., Capilla, R., Dueas, J.: The decision view’s role in software architecture practice. IEEE Software 26(2), 36 (2009)
3. Atkinson, C., Kuhne, T.: Model-driven development: a metamodeling foundation. IEEE Software 20(5), 36–41 (2003)
4. Tyree, J., Akerman, A.: Architecture decisions: Demystifying architecture. IEEE Softw. 22, 19–27 (2005)
5. Akerman, A., Tyree, J.: Using ontology to support development of software architectures. IBM Syst. J. 45, 813–825 (2006)
6. Babu, T.L., Seetha Ramaiah, M., Prabhakar, T.V., Rambabu, D.: Archvoc–towards an ontology for software architecture. In: Workshop on SHAring and Reusing architectural Knowledge. SHARK-ADI. IEEE Computer Society Press, Los Alamitos (2007)
7. Pahl, C., Giesecke, S., Hasselbring, W.: Ontology-based modelling of architectural styles. Information and Software Technology 51(12), 1739-1749 (2009)
8. ISO/IEC 42010 (IEEE std.): Systems and Software engineering – Recomended practice for architectural description of software-intensive systems (2007)
9. Kruchten, P.: The 4+1 view model of architecture. IEEE Software 12, 42–50 (1995)
10. Farooqui, K., Logrippo, L., de Meer, J.: The iso reference model for open distributed processing: An introduction. Computer Networks and ISDN Systems 27(8), 1215–1229 (1995)
11. TOGAF. The Open Group Architecture Framework Version 9 (2009)
12. Zachman, J.A.: A framework for information systems architecture. IBM Syst. J. 26(3), 276–292 (1987)
13. Shaw, M., Garlan, D.: Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, Englewood Cliffs (1996)
14. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. Addison-Wesley Professional, Reading (2003)
15. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Matera, M.: Designing Data-Intensive Web Applications. Morgan Kaufmann Publishers Inc., San Francisco (2002)
16. Avgeriou, P., Zdun, U.: Architectural Patterns Revisited – a Pattern Language. In: Proceedings of the 10th European Conference on Pattern Languages of Programs (EuroPLoP 2005), Irsee, Germany (July 2005)