(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Определение архитектуры приложений с помощью Rational Software Architect: Часть 2. Итеративное уточнение архитектуры

Этот цикл статей посвящен методам создания моделей для описания и распространения архитектуры сложных программных систем. Он иллюстрирует процесс разработки архитектуры системы интернет-сети ресторанного обслуживания (Online Catering) для вымышленной компании Yummy Inc. С помощью итеративного подхода создается описание основных действий по созданию архитектуры, необходимых для определения сложной программной системы с помощью IBM Rational Software Architect. В первой статье этого цикла объяснялось, как создать концепцию архитектуры на ранних этапах проекта. Во второй части мы покажем, как эта архитектура итеративно уточняется с помощью Rational Software Architect. Обе статьи предполагают, что читатели знакомы с методологией итеративной разработки.

Введение

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

  1. Выявление значимых требований
  2. Определение предполагаемой архитектуры
  3. Определение исходной модели развертывания
  4. Определение модели домена

Но обдумывание архитектуры ― не разовое действие. Это непрерывные усилия, которые опытные группы проектировщиков вкладывают в свою работу. Постепенно наращивая систему, группа выявляет новые технические проблемы и ищет новые архитектурные решения.

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

  1. Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
  2. Уточнение элементов проекта: архитектурно значимые элементы проекта.
  3. Уточнение архитектуры развертывания: единицы и топологии развертывания.

Итеративное совершенствование архитектуры

Обычно не нужно определять структуру всех компонентов своей системы. Как и все остальное в ходе проектирования, это делается лишь тогда, когда имеет смысл. Однако некоторые части сложных программных систем должны быть описаны подробнее других. Потому что некоторые компоненты могут быть труднее для понимания и реализации или они могут влиять на важнейшие элементы других подсистем. Некоторым организациям нужны более подробные спецификации, чтобы передать разработку деловому партнеру или географически распределенной группе. Иногда нужно более тщательно определить и задокументировать архитектуру для того, чтобы выполнить нормативные требования.

Электронная книга: Загрузите из блога автора электронную книгу Эволюционная архитектура ― с помощью Rational Software Architect v8.

Уточнение архитектурных механизмов

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

Цель этого этапа заключается в определении аналитических классов, необходимых для того, чтобы реализовать значимые требования к системе. Иными словами, нужно определить все элементы, необходимые для решения конкретных задач.

Для наглядности можно связать эти классы с аналитическим стереотипом. Для представления класса, действующего в качестве интерфейса к системе, используется стереотип Boundary . Компонент, осуществляющий контроль над другими классами, описывается классом Control . Класс, содержащий данные, определяется стереотипом Entity .

Графическое представление этих аналитических стереотипов приведено на рисунке 1.

Рисунок 1. Аналитические стереотипы
Три аналитических стереотипа

На рисунке 2 аналитический стереотип показан в применении к значимому требованию к системе. В примере Yummy Inc. требование к системе обработки заказов включает в себя несколько элементов (аналитических классов), таких как клиент, меню и обработка платежей.

Рисунок 2. Аналитические элементы пакета обработки заказов
Пакет обработки заказов и его элементы в виде дерева

После определения аналитических классов (рисунок 2) также может потребоваться определение статических и динамических аспектов некоторых значимых требований.

Затем для каждого значимого сценария определяются его статические и динамические аспекты. Rational Software Architect помогает архитектору ПО решить эту задачу, предоставляя шаблон реализации сценариев использования.

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

Рисунок 3. Шаблон реализации сценариев использования для функций заказа по меню.
Пакет заказа по меню

Каждая схема соответствует своему аспекту компонента. Схема классов (рисунок 4) отображает все классы, участвующие в реализации сценария использования (статика), в то время как циклограмма (рисунок 5) иллюстрирует взаимодействие между ними (динамика).

Рисунок 4. Схема классов для функции заказа по меню
Классы и отношения

Рисунок 5. Циклограмма для функции заказа по меню
Последовательность операций при заказе по меню

В конце этого шага с помощью UML-моделей будут разработаны реализации некоторых значимых требований, предъявляемых к системе. Это важная часть архитектуры, когда нужно отобразить статическую структуру и поведение некоторых компонентов сложной программной системы.

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

Уточнение структурной модели

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

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

В нашем примере система ресторанного интернет-обслуживания Yummy Inc. разрабатывается на платформе Java EE. Для обеспечения персистентности данных используется API Java Persistence (см. раздел Ресурсы), логика приложения реализуется с помощью Session Beans, а доступ к службе доставки осуществляется с помощью Web-сервисов.

При создании архитектуры и проектировании рекомендуется определять разные уровни решения и способ их взаимодействия. N -уровневая архитектура Java EE способствует разделению задач между уровнями.

В перспективе Architectural Layers системы Rational Software Architect шаблон структуры содержит представление, на котором можно определить зависимости между уровнями (рисунок 6).

Рисунок 6. Представление Architectural Layer Dependencies для системы Online Catering
Уровни приложения Online Catering

Когда архитектурные уровни определены, архитектор выполняет первую итерацию проектирования. Шаблон проекта Rational Software Architect содержит готовую структуру для этого. В спецификации компонента обычно есть интерфейсы и данные, используемые для взаимодействия с этим компонентом (рисунок 7). Как правило, это первое, что определяет архитектор ПО. Для каждого компонента важно указать данные, которыми он манипулирует, и его интерфейс, включая доступные операции.

Рисунок 7. Пакеты проектов для системы Online Catering
Атрибуты и операции

Обратите внимание, что поскольку на данном этапе уже выбрана платформа реализации, структурную модель можно обогатить информацией, относящейся к конкретной технологии. В нашем примере постоянные объекты помечены с помощью стереотипа JPA, чтобы показать, как объектная модель отображается на базу данных.

Для некоторых компонентов сложной программной системы может понадобиться углубленное проектирование. Помните, что структура детализируется только в том случае, если это помогает группе в реализации и выпуске приложения. На рисунке 8 представлена подробная схема классов, составленная с конкретной целью. Группа хочет создать Java-код из структурной модели с использованием некоторых преобразований, которые обеспечивает Rational Software Architect (подробнее о преобразованиях см. в разделе Ресурсы).

Рисунок 8. Подробная схема классов для генерации кода
Стереотипы для генерации кода

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

Уточнение архитектуры развертывания

Архитекторы отвечают за создание систем, удовлетворяющих бизнес-требованиям. Один из ключевых аспектов сложных программных систем ― способ их развертывания на физической архитектуре. Первоначальная модель развертывания обычно определяется при планировании архитектуры (см. ссылку на первую статью этого цикла в разделе Ресурсы). В ходе проекта архитекторы уточняют архитектуру развертывания, добавляя нефункциональные требования и ограничения, относящиеся к производственной среде.

Инструменты планирования процесса развертывания Rational Software Architect позволяют создавать топологии, демонстрирующие отношения между ИТ-ресурсами. Также можно планировать и проверять сценарии развертывания (подробнее о планировании и автоматизации процесса развертывания с помощью Rational Software Architect см. разделе Ресурсы).

Rational Software Architect помогает выполнить анализ развертывания на разных уровнях абстракции. Можно создавать логические топологии для принятия решений по операционной архитектуре сложной программной системы (рисунок 9). Логическая топология описывает систему на высоком уровне абстракции. В ней указывают, как организованы и связаны компоненты приложения и где они должны размещаться. Обратите внимание, что для лучшей прослеживаемости блоки, соответствующие решению, иногда не создаются с нуля, а выводятся из UML-элементов.

Рисунок 9. Пример логической топологии для системы Online Catering
Местоположение и узлы

Архитекторы также могут определять топологию для описания способа развертывания приложения. Модель этого типа описывает полный сценарий развертывания конкретного приложения и конкретную инфраструктуру, на которой оно развертывается (рисунок 10).

Рисунок 10. Пример подробной модели развертывания системы Online Catering
Компоненты и серверы

Поэтапное построение системы

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

Постоянное обдумывание архитектуры является частью усилий по разработке, и группа не должна писать новый код или изменять существующий, не подумав о том, как это изменение повлияет на приложение в целом. Популярный метод изменения существующего кода называется рефакторингом (см. раздел Ресурсы). Rational Software Architect предоставляет богатый набор инструментов для облегчения разработки и рефакторинга кода. С помощью инструмента рефакторинга можно изменить структуру кода (рисунок 11). А функция архитектурного обнаружения позволяет выделить в коде приложения шаблоны и антишаблоны (рисунок 12). Обе функции помогают улучшить код и выявить проблемы на ранних стадиях разработки программного обеспечения.

Рисунок 11. Инструмент рефакторинга в Rational Software Architect
Меню  Refactor и средства рефакторинга

Рисунок 12. Поиск шаблонов
Средства исследования архитектуры

Если при обдумывании архитектуры вы создали какие-то модели, то их можно преобразовать в код. Rational Software Architect содержит набор преобразований для создания кода Java, элементов Java EE или артефактов SOA (рисунок 13). Можно также генерировать модели из существующего исходного кода.

Рисунок 13. Преобразования в Rational Software Architect
Различные варианты преобразований

Так по мере постепенного построения системы создается рабочее ПО, соответствующее конструктивным решениям, принятым в ходе планирования архитектуры.

Заключение

Гибкие методы проектирования способствуют применению коротких итераций для построения системы шаг за шагом. Если подход Big Design Up Front (см. BDUF в разделе Ресурсы) оказался неэффективным и применяется главным образом в водопадных моделях, то это не означает, что из гибких проектов нужно выкинуть планирование архитектуры и структуры. Проектирование должно быть продуманным и последовательным. Продуманным, потому что уже в начале проекта можно предвидеть некоторые технические требования, основываясь на очереди нерешенных задач (планирование архитектуры). Последовательным, потому что в ходе итераций разработки проект адаптируется и обогащается при решении новых технических задач, с которыми сталкивается группа.

В первой статье этого цикла мы сосредоточились на типичных задачах планирования архитектуры и согласования технической концепции с предъявляемыми требованиями. В этой, второй статье мы описали, как архитектура уточняется в ходе итераций разработки. Rational Software Architect предоставляет шаблоны моделей для описания архитектуры сложной программной системы с разных точек зрения на протяжении всего жизненного цикла проекта (рисунок 14).

Рисунок 14. Модели для различных архитектурных представлений
Архитектурные представления и соответствующие модели

Обдумывание архитектуры ― это непрерывный процесс, который группы опытных разработчиков внедряют в свою работу. Он не всегда приводит к созданию формальной схемы. Имейте в виду, что если UML не подходит для вашего контекста, то ничто не мешает использовать вместо него эскизы Rational Software Architect, как если бы вы рисовали на доске. Эскизы Rational Software Architect носят менее формальный характер, чем UML-схемы, но могут служить хорошей альтернативой для конкретного проекта.


Загрузка

Описание

Имя

Размер

Метод загрузки

RSA-модели Yummy Yummy2011.zip 84 КБ HTTP 



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 27.09.2012 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
IBM RATIONAL Clearcase Floating User From Rational Clearcase Lt Floating User Trade Up License + Sw Subscription & Support 12 Months
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
IBM Rational Method Composer Authorized User License
IBM Rational Functional Tester Floating User License
Rational ClearQuest Floating User License
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
Программирование в AutoCAD
СУБД Oracle "с нуля"
Новости мира 3D-ускорителей
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Подскажите лучшее онлайн казино (8)
Вот нашёл интересную игровую площадку, и это онлайн казино Вавада. Может кто что подсказать по...
 
Помощь по MS Access (345)
Доброе время суток. Случайно оказался на этом сайте, искал статьи по OLAP. Вижу, что...
 
Требуется Краснодар: Java -разрабочик (2)
Обязанности: Разработка корпоративных backend-приложений для автоматизации розничных продаж...
 
Рабочее зеркало БК Мостбет - как найти? (3)
Узнайте обо всех особенностях по поиску рабочего зеркала БК Мостбет из нашей статьи...
 
Ставки на спорт (7)
Добрый вечер! Давно хочу попробовать зарабатывать на ставках. Что посоветуете? Стоит пробовать?
 
 
 



    
rambler's top100 Rambler's Top100