Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Еще раз о проектировании архитектуры ПС на основе объектно-ориентированной и компонентной методологии

Автор статьи [11] Дж. Макгрегор отмечает, что современная архитектура предлагает развернутую и точную модель системы. Методики формирования программной архитектуры предполагают детальный анализ системы перед ее реализацией. Такие методики, как Attribute Driven Design (ADD) [7], гарантируют, что программное обеспечение, реализованное на основе предварительно сформированной архитектуры, будет точно отвечать своему предназначению. Есть немало примеров использования архитектуры в стратегических целях.

Один из самых известных примеров - Common Object Request Broker Architecture (CORBA). Эта архитектура служит для связи унаследованных систем, для интеграции систем, написанных на разных языках, и поддержки взаимодействия между компьютерами с различными аппаратными архитектурами. CORBA позволяет дать новую жизнь унаследованным системам и в то же время быстро интегрировать в них новые приложения, что обеспечивает предприятиям стратегические преимущества перед конкурентами, модифицирующими унаследованные системы. Еще один пример - свободно распространяемая интегрированная среда разработки Eclipse.

В целом процесс проектирования архитектуры состоит из систематической декомпозиции элементов верхнего уровня на совокупности более мелких элементов. На рис. 6.12 исходный элемент путем декомпозиции разделяется на элементы «Модель», «Контроллеры» и «Представления». Каждый из них влияет на общее поведение исходного элемента.

Декомпозиция как основа проектирования архитектуры

Рис. 6.12. Декомпозиция как основа проектирования архитектуры

любой программной системы

С помощью подхода ADD архитектор выбирает конкретную декомпозицию, стремясь улучшить определенные свойства конечного продукта. Следует, однако, иметь в виду, что каждая декомпозиция, как правило, какие-то свойства ухудшает. На рис. 6.12 декомпозиция «“Модель” -“Представление” - “Контроллер”» (Model - View - Controller, MVC) выбрана для расширения возможностей модификации системы, в частности, для более эффективного добавления новых представлений модели. Но такая декомпозиция приведет к снижению производительности, поскольку при возникновении любых изменений «Модели» придется уведомлять «Представление». С точки зрения архитектора, это приемлемый компромисс, поскольку система работает не в реальном (компьютерном) времени, а в расчете на восприятие изменений человеком.

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

Представления

Контроллеры

Представления

Многоуровневая декомпозиция

Рис. 6.13. Многоуровневая декомпозиция

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

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

 
<<   СОДЕРЖАНИЕ   >>