WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |

2.5.2.2. Архитектурные решения SEI В Институте Программной Инженерии (SEI) разработан подход к формированию архитектуры, исходящий из того, что для конкретной SIS, кроме базовых «точек зрения», может потребоваться дополнительный набор видов. А значит, архитектору должны быть предоставлены возможности создания необходимых ему типовых видов, в частности «box and line» средства.

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

Функциональность Анализ, проектирование, реализация Мобильность Наджность Разработка, управляемая Архитектура SIS Эффективность качеством SIS SIS Сопровождаемость Удобство ……. Качество Рис. 16. Архитектура, управляемая качеством SIS Архитектурные решения SEI согласованы со стандартом ИСО/МЭК 9126. Особое внимание рекомендуется уделять рассуждениям в группе разработчиков и документированию решений.

2.5.2.3. Архитектурные решения RM ODP Архитектурные решения RM-ODP [88] предоставляют пять точек зрения (рис. 17) на систему:

организационная точка зрения описывает постановку цели, области применения, способы и правила применения;

информационная точка зрения описывает выражение (проявление) и семантику обрабатываемых системой данных, форматы и модели данных;

компонентная (вычислительная) точка зрения описывает разделение приложения на функциональные модули и определяет их интерфейсы;

инженерная точка зрения представляет распределение отдельных элементов системы по физическим ресурсам, а также их связи;

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

Организационный вид Определение требований Определение Информационный вид Вычислительный вид спецификаций Инженерный вид Проектирование Технологический вид Реализация Рис. 17. Архитектура RM ODP При помощи этих пяти точек зрения могут быть описаны как существующие системы, так и разработаны новые SIS и приложения. Стандарт содержит лингвистические средства для описания видов и систему правил для переходов между видами.

2.5.2.4. Архитектурные решения SIMENS В архитектурных решениях Siemens (рис. 18) использование «концептуального вида» в системе «видов» было предложено до создания языка UML, в котором необходимость визуального концептуального моделирования в разработках SIS была переведена на уровень стандарта.

Система видов включала:

концептуальный вид как описание архитектуры системы в понятиях, раскрывающих основные элементы SIS и связи между ними;

модульный вид, раскрывающий функциональную декомпозицию SIS и е распределение по уровням детализации;

вид исполнения, специфицирующий динамическую структуру SIS;

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

Архитектура SIS А И П С П П Концептуальный вид А О Р Л А Н Т Е Модульный вид У Н Р И А Е Кодовый вид Исходный код Рис. 18. Архитектурные решения Siemens 2.5.2.5.Архитектурные решения ADS Подход «Cпецификации рационального описания архитектуры (Rational ADS)» развивает подход «4+1» до его применений, включающих автоматизированные производственные системы, встроенные системы и другие системы, в которых может отсутствовать программное обеспечение. Вариант расширения представлен на рис. 19.

Требования «Проблемная область» «Нефункциональные тре Use-case «Опыт пользователей» бования» Проектирование «Логика» «Процессы» Реализация «Реализация» «Развертывание» Верификация «Тестирование» Рис. 19. Архитектура ADS В архитектуре виды распределены между четырьмя «точками зрения» (Требования, Проектирование, Реализация и Верификация). Содержание видов соответствует содержанию видов, рассмотренных выше, или понятно из названия. Архитектура нашла сво воплощение в инструментально-технологической среде RUP. Она согласована со стандартами ISO/MEK-12207 и IEEE-1471.

Ещ одним примером сопоставления архитектурных концептуальных систем может служить работа [69], в которой (из-за разнородности систем) проводится сопоставление по трм фундаментальным позициям: «цели», «вход» и «выход-результат».

2.6. Примеры систем видов В архитектурной практике находят применение и другие системы видов, содержащие виды, отличающиеся от представленных выше. Одной из таких систем, связанной со специфическим взглядом на качество SIS является система видов, предложенная в монографии Rozanski и P.Wood [73].

Система видов включает:

1. Информационный вид (Фиксирует историю, преобразования, управление и распределение информации. Используются подходящие модели, отражающие статику и потоки данных. Цель анализа – ответить на существенные вопросы о содержании данных, структуре, принадлежности, умолчаниях, ссылках и перемещениях).

2. Вид согласованности (Описывает согласованность структуры SIS и карту функциональных компонентов, что позволяет ясно идентифицировать части системы, управляемо выполняющих согласованные действия. Это влечт за собой создание моделей, демонстрирующих процессы и трассы их реализации с учтом коммуникативных отношений).

3. Разработка (Раскрывает архитектуру, которая поддерживает процесс разработки SIS. Указывает на определнные аспекты разработки, требующие включения в процесс разработки специалистов определнных квалификаций (например, тестирование, сопровождение)).



4. Размещение (Описывает среду, в рамках которой система будет разврнута, с учтом зависимостей системы от «реального времени» среды. Вид включает аппаратуру не только системы, но и е среды(например, сетевое окружение)) 5. Операционный (Раскрывает как система инсталлируется, функционирует (используется), администрируется и поддерживается. В построении вида целесообразно использовать уровень задач) Ещ одна версия системы видов приведена в публикации [59], в которых предлагается целостный взгляд на архитектуру SIS, получивший название SPAMMED.

Система SPAMMED базируется на следующей системе видов:

1. Вид с позиции системы требований (Requirements over_View).

2. Вид с позиций сервисов (Service View).

3. Вид с позиций инфраструктуры ПО (Software Infrastructure View).

4. Вид процессов (Process View).

5. Вид предметной области SIS (Business Domain View).

6. Вид размещения (Deployment View).

7. Вид среды разработки (Development Environment View).

8. Вид с позиций коммерческой и компьютерной безопасности (COMMSEC & COMPUSEC View).

9. Вид с позиций сохранности (Safety View).

3. Рациональный процесс архитектурного моделирования 3.1. Архитектурные парадигмы В публикациях по архитектуре ПО поднимаются вопросы о парадигмах ПО как «модели постановки проблемы и е решения», определяющей основные подходы к проблемам архитектуры.

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

1. Объектно-ориентированная парадигма, в рамках которой используется Объектно-Ориентированный Подход (ООП) к структуризации SIS на всех этапах е жизненного цикла.

2. Компонентно-ориентированная парадигма, исходящая из принципов сборочного проектирования, конструирования и производства SIS, в основе которых лежат программные «компоненты» как единицы сборки.

3. Сервисно-ориентированная парадигма, применение которой базируется на идее массового сервисного обслуживания пользователей SIS по их запросам.

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

1. Объектно-ориентированная парадигма. В основе этой парадигмы лежат идеи, методы и средства Объектно-Ориентированного Анализа и Проектирования (ООАП). Наиболее последовательно эта парадигма раскрыта в методологии унифицированного процесса разработки [39] и реализована в работе [40] в комплексе инструментально-технологических средств Rational Unified Process (RUP). Если SIS разработана в такой среде, то говорят, что она имеет Объектно-Ориентированную Архитектуру (ООА, Object-Oriented Architecture).

К числу основных характеристик ООА относятся:

- реализация основных принципов ООП, в первую очередь инкапсуляции, наследования и полиморфизма;

- классы объектов являются основными единицами моделирования, проектирования и реализации;

- объекты и их взаимодействие находятся в центре интересов ООА;

- интерфейсы реализуются как специальные классы объектов, обслуживающих взаимодействие объектов;

- удалнные объекты используются точно так же, как и локальные объекты.

Наиболее хорошим примером ООА является Common Object Request Broker Architecture (COBRA), разработанная группой OMG. COBRA определяет объектную модель, в соответствии с которой распределнные объекты должны создаваться, использоваться и управляться. COBRA также определяет Reference Architecture (как систему образцов и инструкций), раскрывающую «как достигается взаимодействие между распределнными объектами». Для этих целей предлагается язык определения интерфейсов (Interface Definition Language, IDL). Объект клиента получает связь с объектом сервера, после чего он в состоянии активизировать его методы тем же самым образом, как и методы локальных объектов.

ООА может быть представлена различными совокупностями видов. Одной из наиболее распространнных таких совокупностей является система видов Ф. Кратчена «4+1 views» [41]. Для описания видов обычно используются средства языка UML.

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

Промышленное производство компонентов, а также платформы, подобные J2EE, CORBA Component Model и Microsoft.Net, перевели компонентно-ориентированную парадигму (и основанную на этой парадигме версию разработки Component-based software development (CBSD)) в практическое русло. Говорят, что системы, разработанные на основе CBSD, имеют Компонентно-Ориентированную Архитектуру (КОА,Component-Based Architecture, CBA).

К числу основных характеристик KОА (CBA) относятся:

- опора на компонентные модели (подобные CORBA Component Model );





- компоненты являются основными единицами моделирования, проектирования и реализации;

- интерфейсы и взаимодействие находятся в центре интересов разработки архитектуры SIS;

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

- компонентные модели требуют от компонентов поддержки «действий по самоанализу» так, чтобы их функциональности или свойства могли быть открыты и использованы «во время сборки» или в реальном времени;

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

Компонентная модель также включает программную модель, раскрывающую как распределнные компоненты должны быть разработаны, собраны и размещены на физическом оборудовании. Кроме CORBA Component Model (CCM) на практике широко используются JavaBeans и Enterprise JavaBeans в рамках Java 2 Enterprise Edition (J2EE).

Для представления CBA могут быть использованы различные совокупности видов, например совокупность, использованная в стандарте для RM-ODP. Для описания видов часто используют средства UML.

3. Сервисно-ориентированная парадигма. Большой класс SIS, особенно реализованных в виде WEB-приложений, разрабатывают как системы сервисов, к которым открыт оперативный доступ клиентов. Про систему такого рода говорят, что для е разработки использовалась Сервисно-Ориентированная Архитектура (СОА, Service-Based Architecture, SBA).

К числу основных характеристик СОА (SBA) относятся:

- свободное соединение, заключающееся в том, что любой сервис может быть получен как ответ на запрос из любого (разрешнного) источника;

- для сервиса не требуется ничего запоминать от одного вызова до другого (состояния загружаются как часть данных сервиса из базы данных или поступают от запросчика сервиса);

- сервисы являются основными единицами моделирования, проектирования и реализации;

- определение, описание, открытие сервиса, протоколы доступа и аспекты качества являются центральными интересами в архитектурном проектировании SIS;

- сервис «выставляет напоказ» свои возможности, включая функциональность, данные и характеристики качества сервисов через описание на специальных языках, таких как язык описания WEB-сервисов (Web Service Description Language, WSDL);

- сервис может быть независимо и динамически обнаружен (открыт) и использован;

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

Сервис может быть реализован с использованием компонентноориентированных технологий или объектно-ориентированных технологий. Описание сервиса обычно регистрируется в базе сервисов в определнном формате, например, в таком как Universal Description, Discovery and Integration (UDDI). С одной стороны SBA может быть представлена с помощью средств RM-ODP и UML, однако необходимо помнить, что эти средства не совсем адекватны задаче моделирования сервисов. Для описания сервисов более подходят специализированные языковые средства, такие как WSDL.

К месту отметить, что OOA, CBA и SBA предоставляют различные возможности и выгоды и могут быть использованы взаимодополнительно. С точки зрения функциональности сервис может быть реализован с помощью совокупности компонентов с учтом необходимых характеристик качества. В то же время функциональность компонента может быть структурирована в объектно-ориентированном виде и реализована с помощью объектно-ориентированного алгоритмического языка. Однако каждая из парадигм имеет специфику в представлении архитектуры SIS.

Как результат сопоставления парадигм, в [71] предлагается следующий набор практических принципов для применения парадигм в разработке архитектуры SIS:

1.Первый принцип нацеливает разработчиков на то, чтобы Понять приложение и Очертить его границы.

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

3. Третий принцип указывает на необходимость первоочередного построения Use Case сценариев для интерфейсов, которые являются ключевыми понятиями в каждой из представленных парадигм. Сценарии помогут прояснить роли, ответственность, характеристики взаимодействия и ожидаемые свойства базовых единиц разработки, а также помогут идентифицировать, какой из трх типов единиц (объекты, компоненты, сервисы ) является наиболее подходящим для разрабатываемой SIS.

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

Отметим, что совокупность парадигм, используемых в конкретной разработке, не исчерпывается вариантами OOA, CBA и SBA и открыта для модификаций и дополнений.

3.2. Варианты архитектур 3.2.1. Основы архитектурных подходов В архитектурной практике сложился ряд направлений, в каждом из которых используется определнный акцент на том, что, по мнению последователей направления (в определнных условиях), является центральным или базовым в разработках и использовании архитектуры. К числу таких направлений относятся:

1. объектно-ориентированная архитектура (object-oriented architecture) :

2. архитектура, базирующаяся на компонентах (component-basearchitecture);

3. сервисно-ориентированная архитектура (service-oriented architecture);

4. архитектура, базирующаяся на событиях (event-based architecture);

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.