Раздел 1. Перед началом работы

Об этом руководстве

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

Продукты семейства IBM Rational облегчают весь процесс разработки приложения - от исходной идеи до выпуска продукта и выявления дефектов. В семейство Rational входят инструментальные средства определения требований (IBM Rational RequisitePro), визуального моделирования (IBM Rational Software Modeler) и кодирования (IBM Rational Application Developer) приложения, отслеживания дефектов (IBM Rational ClearQuest) и управления изменениями (IBM Rational ClearCase). Все эти инструменты могут использоваться как независимо, так и с поддержкой методологии IBM Rational Unified Process (RUP).

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

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

В первой части этого руководства показано, как использовать Rational RequisitePro в целях управления и организации технического задания для нового проекта. Далее, после того как вы разработаете собственный общий список требований, можно будет перейти к разделу, в котором показано, как использовать Rational Software Modeler для моделирования приложения в соответствии с предварительно определенными требованиями.

Данное учебное руководство подразделяется на следующие разделы:

• Знакомство с процессом разработки;
• Разработка спецификации требований с помощью Rational RequisitePro;
• Документирование требований проекта с помощью решения Rational RequisitePro и приложения Microsoft® Word;
• Доступ к данным о требованиях с помощью Rational Software Modeler;
• Преобразование требований в модель приложения;
• Сопоставление элементов модели с исходными требованиями.

Предварительные условия

Для запуска представленных здесь примеров и образцов программного кода необходимо загрузить ознакомительные версии продуктов Rational RequisitePro, Rational Software Modeler и Rational Application Developer, а также пакет RUP, в который входит полная документация по техническим аспектам, методам и системам, составляющим основу методологии RUP. Также потребуется текстовый редактор Microsoft Word (как минимум - Word 97, однако рекомендуется Word 2000 или более поздние версии).

Для прохождения этапов данного руководства вам потребуются следующие компоненты:

• Rational RequisitePro (версия 2003.06.x)
• Rational Application Developer (версия 6.0)
• Rational Software Modeler (версия 6.0)
• RUP

Раздел 2. Разработка с использованием интегрированных приложений Rational

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

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

Рис. 1. Простой процесс разработки

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

Методология RUP подразумевает схожую, но более простую модель управления процессом разработки. Модель Rational прекрасно иллюстрирует способ применения инструментов Rational в процессе разработки.

Разработка с использованием RUP

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

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

Процессом разработки можно управлять полностью вручную, однако он определенно нуждается в автоматизации, которую как раз обеспечивают продукты семейства Rational. Использование инструментальных средств Rational упрощает процесс разработки, позволяя как отдельным сотрудникам, так и коллективам в целом экономить время и усилия при создании приложений. В результате формируется цикл разработки, представленный на рисунке 2.

Рис. 2. Модель RUP

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

Разработка с использованием инструментальных средств Rational

В состав ПО Rational входит множество инструментальных средств, позволяющих разрабатывать приложения в соответствии с методологией RUP. Вы можете применить определенные средства к разным этапам процесса разработки согласно рисунку 3. Обратите внимание на то, что представленные здесь инструменты приведены только в качестве примера - пакет программ Rational Suite® насчитывает много разных инструментов, и какой из них следует использовать в вашем случае, зависит от разрабатываемого приложения.

Рис. 3. Инструментальные средства Rational и модель RUP

Инструменты, представленные на рисунке 3, имеют следующие области применения:

• Rational RequisitePro: Этот инструмент позволяет обновлять управляемые им требования непосредственно в программе или с помощью редактора Microsoft Word. Для изменения требований достаточно отредактировать содержимое документа, при этом само средство поможет вам обновить, проанализировать и объединить необходимые требования;
• Rational Software Modeler: Это средство пришло на смену ранее использовавшемуся компоненту Rational Rose® XDE. Построенное на платформе Eclipse, оно успешно использовалось в семействе продуктов IBM WebSphere® в качестве основы для интегрированной среды разработки (IDE) WebSphere Studio Application Developer. Rational Software Modeler предоставляет пользователю интерфейс для моделирования приложения до начала написания программного кода;
• Rational Application Developer: Это средство предоставляет среду IDE для преобразования моделей в программный код и финальные приложения. Rational Application Developer также снабжает пользователей интегрированной средой для тестирования готового приложения;
• Rational ClearCase: Это средство обеспечивает управление конфигурацией базы кода и моделей. WebSphere Studio Application Developer и Rational Rose XDE, взаимодействуя с Rational ClearCase, способны обеспечить всю команду разработчиков механизмами управления всеми аспектами процесса разработки;
• Rational ClearQuest: Данный инструмент облегчает отслеживание дефектов и управление операциями. Отслеживание дефектов позволяет выявить ошибки и найти их первоначальную причину. Механизм управления операциями дает возможность отслеживать операции над различными компонентами проекта, включая программный код, модели и другую информацию. Интеграция Rational ClearQuest с другими приложениями Rational позволяет отслеживать дефекты и операции в широком диапазоне компонентов и требований, проверяя информацию в любой точке проекта;
• Rational PurifyPlus: Rational PurifyPlus обеспечивает текущий анализ приложения, позволяющий проследить, как оно использует ресурсы памяти. "Утечка" памяти и другие проблемы такого рода являются одним из самых распространенных дефектов в приложениях, за исключением опечаток и ошибок в программном коде, которые должны устраняться с помощью тестирования и специальных методик, применяемых при использовании инструментальных средств Rational. Интеграция этого инструмента со средой WebSphere Studio Application Developer обеспечивает пользователей информацией об элементах приложения, вызывающих те или иные проблемы;
• Rational TestManager: Rational TestManager предоставляет единый интерфейс для тестирования набора параметров приложения, позволяя проводить это тестирование в автоматическом режиме, что особенно важно, если разработка выполняется на разных платформах;
• Team Unifying Platform: Rational Team Unifying Platform (TUP) представляет собой набор основных инструментальных средств (RUP, Rational RequisitePro, Rational ClearCase, Rational ClearQuest, Rational TestManager и Rational SoDA®), дополненный новым инструментом Rational ProjectConsole. Rational ProjectConsole собирает информацию о метриках и состоянии со всех инструментов, включая Rational Rose XDE, и обеспечивает централизованный просмотр и анализ этих сведений для всех разработчиков.

Приложение по ведению аукциона

Во всех частях этого руководства в качестве примера предлагается создать приложение по ведению аукциона, моделью которого выступает приложение, используемое во множестве программных продуктов IBM, например, WebSphere Studio Application Developer. Приложение создается с самого начала, при этом на каждом этапе процесса разработки используется соответствующее средство Rational. Интернет-аукцион (Online Auction) - это веб-приложение на базе технологии Java# 2 Enterprise Edition (J2EE), использующее Java-приложения, Java Database Connectivity (JDBC), HTML, код JavaScript, файлы JavaServer Pages (JSP) и ряд других компонентов. В результате сочетания этих компонентов формируется система ведения аукциона, по функциональности схожая с порталами eBay, Yahoo и Amazon.

Работающую версию приложения IBM Online Auction можно получить, загрузив ее как компонент среды WebSphere Studio Application Developer (это один из предоставляемых бесплатных примеров). Для просмотра системы необходимо установить WebSphere Studio Application Developer, а затем воспользоваться встроенной справкой и инструкциями по созданию проекта WebSphere на основе программного кода Auction. Также, с веб-сайта IBM можно загрузить видеоурок по созданию системы. (Более подробная информация представлена в разделе "Ресурсы".)

Раздел 3. Управление требованиями в методологии Rational

RequisitePro

В рамках базовых понятий, требование представляет собой наиболее фундаментальную функциональность, которую приложение должно предоставлять пользователю. Требования должны быть максимально определенными и специализированными. Предположим, для системы ведения аукциона вы определили следующее требование "возможность покупать и продавать товары с помощью системы, похожей на аукцион" .

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

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

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

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

Усиление роли требований в процессе разработки

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

Так сложилось, что трудности всегда возникают при передаче требований разработчикам, а затем при использовании требований для проектирования модели, написания программного кода и создания компонентов приложения, предоставляющих необходимую функциональность. К счастью, большую часть этих проблем решает интеграция Rational RequisitePro с Rational Software Modeler.

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

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

• Каков самый последний набор требований?
• Соответствует ли текущая разработка заявленным требованиям?
• Все ли требования представлены в рамках модели приложения?
• Отвечает ли проект первоначальным целям заинтересованных лиц?

Чтобы ответить на эти вопросы, необходимо сопоставить требования с компонентами модели.

Краткий обзор прецедентов

использоваться в создаваемом приложении. Теоретически, можно (но не рекомендуется) использовать RUP с другими типами требований. Однако это не приведет к нужному результату, а поток информации и описаний между различными компонентами будет также другим.

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

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

С точки зрения формата, прецедент представляет собой текстовое описание, соответствующее этой основной модели в рамках RUP:

1. Краткое описание;
2. Действующие лица;
3. Специальные требования;
4. Предпосылки;
5. Постусловия;
6. Точки расширения.

Например, в случае с приложением по ведению аукциона, речь может идти о представленном ниже примере последовательности, инициированной действующим лицом при подаче заявки в системе аукциона:

• 3. Поток событий
• 3.1 Основной поток
• 3.1.1 Заявка (предложение цены): Прецедент начинается в тот момент, когда покупатель предлагает свою цену на текущую позицию.
• 3.1.2 Ввод суммы: Покупатель вводит сумму предложения. Система подтверждает, что сумма предложения превышает текущую ставку на значение, кратное шагу заявки для данной позиции.
• 3.1.3 Покупатель подтверждает заявку: Покупатель подтверждает свое намерение разместить заявку.
• 3.1.4 Обработка заявки: Система добавляет заявку к данной позиции.
• 3.1.5 Подтверждение заявки: Система подтверждает наличие заявки путем отправки покупателю электронного сообщения. Продавец также уведомляется по электронной почте.

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

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

Интеграция Rational RequisitePro

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

• Rational ClearQuest обеспечивает управление запросами на изменение. Пользователь может внести отдельные изменения в первоначальную спецификацию требований. В части 3 данного руководства подробно описывается интеграция первоначальных требований с вносимыми изменениями;
• Интеграция с Rational TestManager позволяет создавать тестовые системы, используемые для проверки всех требований в первоначальном проекте. Этот уровень интеграции рассматривается в части 5 данного руководства;
• Rational RequisitePro можно интегрировать с Microsoft Office Project. Взяв за основу требования и снабдив отдельные требования дополнительными свойствами, вы сможете создать план проекта на основе представленной спецификации требований;
• Тем не менее, в данном руководстве рассматривается интеграция Rational RequisitePro с продуктом Rational Software Modeler, который предоставляет разработчикам средства моделирования, и продуктом Rational Application Developer, который обеспечивает среду IDE для написания программного кода приложения. В следующем разделе мы приступим к составлению технического задания - спецификации требований.

Раздел 4. Составление спецификации требований

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

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

В решении Rational RequisitePro требования хранятся в базе данных. Тем не менее, их можно записывать и редактировать посредством связи с редактором Microsoft Word, что позволяет руководителям проектов и нетехническим специалистам составлять требования в рамках знакомого интерфейса, одновременно составляя и обновляя информацию в базе данных.

В Rational RequisitePro накапливается информация, которую менеджеры проекта и руководители групп используют для определения проекта. После того как будет составлена первоначальная версия требований, разработчики уже могут использовать собранные сведения для создания приложения.

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

Основные преимущества использования Rational RequisitePro

Основное преимущество Rational RequisitePro перед отдельной документацией заключается в управлении, которое обеспечивает исходная структурированная база данных. Структурированный формат данных позволяет составлять отчеты, создавать соединения с другими требованиями и записывать дополнительную информацию об этих требованиях. Такая функциональность намного шире, чем типовые возможности документов Microsoft Word.

Другим преимуществом Rational RequisitePro является возможность записи и отслеживания изменений отдельных требований. Такая информация полезна даже в том случае, если работа над требованиями ведется изолированно - всего одним специалистом. Но особенную ценность она приобретает в тех ситуациях, когда требования используются, отслеживаются и обновляются группой пользователей. Появляется возможность проследить, какие изменения были внесены и по какой причине.

Создание нового проекта

Чтобы начать процесс составления требований, необходимо создать в рамках Rational RequisitePro новый проект:

1. Откройте Rational RequisitePro, а затем в меню выберите: File > New. На экране появится список доступных шаблонов проекта (как показано на рисунке 4);

   

   Рис. 4. Шаблоны проектов Rational RequisitePro

2. Выберите шаблон Use-Case Template, чтобы создать документ, который будет использоваться в системе RUP. На экране появится окно свойств проекта Rational RequisitePro Project Properties;

   

   Рис. 5. Определение свойств нового проекта

3. В качестве имени проекта введите Auction. Выберите каталог и базу данных. (Для данного примера используйте встроенную базу данных Microsoft Access.) Далее необходимо указать описание проекта.

После того как будет создан новый проект, на экране появится окно, схожее с окном, приведенным на рисунке 6. (Все элементы древовидной структуры в левой области окна развернуты в текущем проекте RequisitePro в целях просмотра: на этом этапе процесса элементы в правой области окна не отображаются.) Каждая папка в древовидной структуре (слева) называется блоком (package) , который логически объединяет документы и требования в целях организации элементов проекта.

Рис. 6. Интерфейс проекта Rational RequisitePro

Создание документов требований

В рамках Rational RequisitePro требования можно создать тремя следующими способами: непосредственно в Rational RequisitePro, с помощью веб-интерфейса или путем использования специального расширения Microsoft Word, позволяющего создавать требования непосредственно в документе Microsoft Word, который в свою очередь в фоновом режиме обновляет базу данных. В результате, продолжая ориентироваться на базу данных, вы можете создавать на основе редактора Microsoft Word собственные документы требований, включая любой дополнительный описательный или сопроводительный текст.

Прежде всего, необходимо создать новый блок, в котором будет размещаться информация для прецедента "Bid on Item":

1. Нажмите правую кнопку мыши на папке Use Cases, а затем выберите команду New Package;
2. В окне Package Properties (см. рис. 7) введите Bid on Item в качестве имени блока.

   

   Рис. 7. Создание нового блока прецедентов

Теперь в этом блоке можно указать определение прецедента "Bid on Item". Вы можете импортировать существующий документ, но в рамках данного руководства потребуется создать новый документ, который будет использоваться для определения прецедентов в отношении раздела системы ведения аукциона "Bid on Item".

1. Находясь внутри папки Use Cases, нажмите правую кнопку мыши на папке Bid on Item и выберите New > Document. На экране появится окно, представленное на рисунке 8;

   

   Рис. 8. Создание нового документа

2. В качестве имени документа, которое будет отображаться в проекте, введите Bid on Item, а затем введите краткое описание содержания этого документа;
3. В ниспадающем списке Document Type выберите документ прецедента, чтобы открыть документ, основанный на предварительно определенном шаблоне, который соответствует шаблону документа, используемому в системе RUP. (В рамках Rational RequisitePro некоторые документы Microsoft Word доступны для использования в системе в качестве шаблонов Microsoft Word. На рисунке 9 представлено окно, открывающееся в редакторе Microsoft Word.)

   

   Рис. 9. Пустой документ прецедента в редакторе Microsoft Word

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

Составление требований

В рамках решения Rational RequisitePro требования упорядочиваются в привычной древовидной структуре (как файлы и папки в файловой системе). Таким образом, можно выделить первичный уровень прецедентов, который предоставляет основную информацию о данном разделе, при этом более подробные сведения указываются в дочерних (подчиненных) требованиях. Такая структура соответствует структуре документа прецедента в рамках методологии RUP.

При редактировании документа Rational RequisitePro в редакторе Microsoft Word появляется дополнительная панель инструментов и меню (см. рис. 10). Они обеспечивают переход к системе Rational RequisitePro и позволяют создавать требования для проекта Rational RequisitePro непосредственно в документе Microsoft Word.

Рис. 10. Панель инструментов Rational RequisitePro в редакторе Microsoft Word

Чтобы создать требование в рамках документа Microsoft Word:

1. Введите текстовое описание прецедента непосредственно в документе Microsoft Word. (Для данного примера используйте текст Bid on Item .);
2. Выделите введенный в документе текст и нажмите New Requirement (первая кнопка с изображением квадратных скобок ([]) на панели инструментов Rational RequisitePro);
3. В окне Requirement Properties (см. рис. 11) укажите тип требования (Use Case), введите имя требования и убедитесь в правильности информации о блоке и месторасположении. (Эти два свойства должны вводиться автоматически в зависимости от места внутри редактируемого документа.)

   

   Рис. 11. Создание нового требования для прецедента "Bid on Item"

Выбранный в редакторе Microsoft Word текст документа будет заменен полем, содержащим текстовую информацию, только что введенную в базу данных Rational. Обратите внимание на то, что до того, как вы сохраните и закроете документ в Microsoft Word, данный элемент будет помечен как незаконченный (pending). В рамках процесса сохранения вся информация импортируется в базу данных Rational RequisitePro.

Теперь необходимо повторить эту процедуру, чтобы добавить внутри прецедента "Bid on Item" дополнительную информацию, которая определяет отдельные этапы в рамках требования "Bid on Item".

Расширение информации о требованиях

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

В рамках Rational RequisitePro используются полностью настраиваемые типы требований. Стандартные поля применяются в типах требований, доступных в списке предварительно определенных типов проекта (примером служит используемый здесь шаблон Use-Case), но фактические поля обладают должной гибкостью и могут использоваться для хранения информации любого рода. Дополнительные поля могут принимать свободную или фиксированную форму, а также могут использовать специальные всплывающие списки.

В рамках данного проекта вам необходимо добавить в тип прецедента исходное поле. Это позволит определить лицо, изначально ответственное за то или иное требование. Чтобы добавить поле в тип требования:

1. Откройте свойства проекта;
2. Перейдите на вкладку Attributes (см. рис. 12). В ниспадающем списке Requirement Type выберите Use Case. На экране появится список атрибутов, определенных для данного типа на текущий момент;

   

   Рис. 12. Добавление новых атрибутов в тип требования

3. Нажмите Add. Атрибуты имеют ярлык (имя поля, заполняемое при создании требования), тип и дополнительный список значений, который используется в ниспадающем меню или списке. Для типа указывается тип поля в базе данных, например: целое число, плавающая точка, текстовая строка, дата, время, URL-адрес или список (выбор одной или нескольких позиций). Выберите List (Single Value);
4. Заполните список информацией, представленной на рисунке 13 (для разделения значений используйте клавишу Return).

   

   Рис. 13. Добавление определений атрибутов

Теперь у вас есть свойство или поле, определенное в соответствии с основным типом требования Use Case. Это свойство можно снабдить информацией о том, кто первым представил данное требование.

Ракурсы и отчеты

В Rational RequisitePro для отображения информации и отношений ракурсы используют стандартные методики запросов к базе данных требований. Каждый ракурс состоит из запроса, который инициирует отображение информации, и вида ракурса - одного из четырех предварительно определенных форматов просмотра данных. К этим видам ракурса относятся:

• Матрица атрибутов (Attribute Matrix): простая таблица требований и соответствующих атрибутов;
• Матрица трассируемости (Traceability Matrix): Таблица в виде матрицы, отображающая отношение между двумя списками требований (например, отношение между запросами заинтересованных лиц и основными требованиями к программному обеспечению);
• Древовидная структура трассируемости (Traced into): Древовидная структура, показывающая, отношения между требованиями (например, древовидная структура, описывающая то, как заинтересованное лицо, разработчик и другие требования относятся к основным требованиям по программному обеспечению);
• Древовидная структура трассируемости (Traced out of): Древовидная структура, которая отображает требования, отслеживаемые от указанного типа требования (например, отображение всех требований, отслеживаемых от запроса заинтересованного лица).

Матрица трассируемости будет использоваться далее в этом руководстве для сопоставления проектов модели Rational Software Modeler с предъявленными требованиями.

Раздел 5. Моделирование приложений с помощью Rational Software Modeler

Rational Software Modeler предоставляет пользователям инструмент моделирования приложений, выполняемого до создания компонентов и написания программного кода. Rational Software Modeler сменяет Rational XDE, предоставляя несколько значительных усовершенствований интерфейса и функциональности Rational XDE.

Ключевая особенность Rational Software Modeler заключается в том, что благодаря более широкому применению платформы Eclipse 3.0 в этом решении расширена функциональность и возможности интеграции с другими продуктами Rational. Eclipse используется решением WebSphere Studio Application Developer (в Rational XDE использовалась предыдущая версия Eclipse) и постепенно становится стандартной средой для всех приложений IBM в сфере разработки и написания программного кода. Rational Software Modeler функционирует так же, как и новый продукт Rational Application Developer (в основе которого тоже лежит платформа Eclipse), который будет использоваться в других разделах данного руководства. С помощью Eclipse решение Rational Software Modeler получает доступ к множеству усовершенствованных наборов инструментов и сред, которые облегчают обработку разных типов данных разработки, например, моделей и структур классов.

Например, Rational Software Modeler (а также Rational Application Developer) использует присущие платформе Eclipse функции перспектив для обеспечения интеграции с другими компонентами и инструментальными средствами в пакете Rational Suite. В этом руководстве основное внимание уделяется интеграции с Rational RequisitePro и в этой связи пользователю предоставляется перспектива Requirements.

Начнем с обзора Rational Software Modeler.

Обзор Rational Software Modeler

На рисунке 14 представлен продукт Rational Software Modeler, в котором открыт простой проект с пустой моделью.

Рис. 14. Интерфейс Rational Software Modeler

В левой части размещается панель Model Explorer, которая обеспечивает поиск и выбор моделей, существующих в проекте. В этой древовидной структуре представлены модели, их компоненты, документация и другие сведения, рассортированные по папкам и документам. Более крупная панель в правой верхней части окна используется как рабочее пространство для создания и обработки моделей. Справа от нее размещена палитра, включающая в себя различные типы диаграмм Unified Modeling Language (UML), которые можно добавить в рассматриваемую модель.

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

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

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

Создание нового проекта UML

Создайте новый проект, содержащий ваши модели:

1. Откройте Rational Software Modeler;
2. Выберите в меню: File > New > Project;
3. В окне New Project (см. рис. 15) выберите UML Project. Нажмите Next;

   

   Рис. 15. Выбор мастера создания проектов

4. В окне UML Modeling Project введите Auction в качестве имени. Нажмите Next;
5. На последнем экране мастера (см. рис. 16) выберите Use Case Model на панели Templates, чтобы автоматически создать в проекте отдельную модель UML;

   

   Рис. 16. Создание модели UML на основе шаблона Use Case Model

6. Введите имя в текстовое поле File name. Нажмите Finish. На экране должно появиться окно, представленное на рисунке 17.

   

   Рис. 17. Пустой проект моделирования UML

На рисунке представлена базовая структура для проекта прецедента. Чтобы перейти к основной части прецедента Auction, закройте панель Instructions, нажав на вкладке кнопку X.

Теперь можно приступать к заполнению модели, используя информацию, которая была создана в предыдущих разделах руководства, посвященных Rational RequisitePro.

Создание новой диаграммы прецедента

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

1. Нажмите правую кнопку мыши на Auction Model, а затем выберите Add Diagram > Use Case Diagram. На панели в правой части окна появится новая диаграмма;
2. панели Model Explorer измените имя диаграммы на Bid On Item .

Теперь все готово к добавлению объектов в диаграмму. Следует помнить о том, что основной причиной создания требований и утверждений прецедентов в Rational RequisitePro является необходимость фиксирования функций и возможностей приложения, непосредственно, до момента его создания. Вторая, более долгосрочная цель - использование этих требований в качестве способа для отслеживания процесса разработки приложения.

Итак, вам необходимо создать диаграмму для своего прецедента. Для этого потребуется интегрировать Rational RequisitePro с Rational Software Modeler.

Раздел 6. Доступ к требованиям

Соединение с проектом требований

Чтобы создать объект, связанный с предъявленными требованиями, в рамках модели UML-решения Rational Software Modeler, необходимо открыть проект Rational RequisitePro в Rational Software Modeler. Эту операцию можно выполнить разными способами, включая переход на другую перспективу. Используемая по умолчанию перспектива Requirements, например, обеспечивает полноценную среду для просмотра и обработки требований.

Тем не менее, учитывая необходимость продолжить создание диаграммы прецедента, вам потребуется открыть проект Requirements и вызвать требование прецедента, которое будет связано с данной диаграммой. Для этого нужно добавить ракурс Requirement Explorer к текущей перспективе в Rational Software Modeler путем выбораWindow > Show View > Requirement Explorer для создания ракурса Requirement Explorer (см. рис. 18). Этот ракурс можно перенести на другую панель или создать для него новую панель, перетащив заголовок ракурса в новое место.

Рис. 18. Добавление Requirement Explorer в Rational Software Modeler

Теперь у вас есть ракурс, позволяющий просматривать требования, созданные посредством проекта Rational RequisitePro. Открытый ранее проект Rational RequisitePro будет отображаться в данном ракурсе. Чтобы открыть проект, который отсутствует в списке или еще не используется, нажмите пиктограмму Open Project. В появившемся окне выберите необходимый файл проекта Rational RequisitePro. Для открытия документа система может запросить у вас имя пользователя и пароль.

Теперь на экране отображается древовидная структура требований из проекта Rational RequisitePro (как показано на рисунке 19).Обратите внимание на то, что в данном случае ракурс созданных ранее требований немного расширен.

Рис. 19. Открытый проект требований

Просмотр требований

Снова обратитесь к Requirement Explorer, представленному на рисунке 20.

Рис. 20. Requirements Explorer

Основная структура повторяет древовидную структуру в Rational RequisitePro. Высокая степень интеграции выражается не только в том, что на экране отображаются сведения о требованиях, но и в том, что здесь копируются ракурсы и организация (порядок) требований в Rational RequisitePro. Чтобы провести сравнение, обратитесь к рисунку 21, на котором представлена та же самая древовидная структура в Rational RequisitePro.

Рис. 21. Просмотр требований в Rational RequisitePro

Нажмите правую кнопку мыши на требовании из древовидной структуры в окне Requirement Explorer (в Rational Software Architect), а затем выберите пункт Properties. Таким образом, вы сможете просмотреть свойства требования - родительский объект, идентификационную метку и текст, используемый для заполнения требования (см. рис. 22).

Рис. 22. Просмотр сведений о требовании

Создание диаграммы прецедента на основе требования

В предыдущем разделе вы узнали, как вручную создать диаграмму прецедента для использования с имеющейся моделью UML. Теперь необходимо добавить требование "Bid On Item" как элемент данной диаграммы прецедента.

Чтобы добавить требование в диаграмму:

1. Выберите диаграмму Bid On Item, чтобы открыть пустую диаграмму;
2. Выберите требование, которое вы хотите добавить в данную модель. В рамках данного примера вы создаете прецедент для "Bid On Item" в рамках своей диаграммы;
3. Перетащите прецедент "Bid On Item" из окна Requirements Explorer на диаграмму. При этом в рамках диаграммы на основе прецедента "Bid on Item" создается новый прецедент, который в свою очередь находится в рамках модели прецедента для проекта Auction. Полученная базовая диаграмма представлена на рисунке 23.

   

   Рис. 23. Создание новой диаграммы прецедента в модели Auction

Чтобы завершить диаграмму, добавьте два действующих лица (actors), которые относятся к данному прецеденту - Buyer (покупатель) и Seller (продавец). Далее необходимо создать отношения между ними и прецедентом. Чтобы добавить действующие лица:

1. На панели Palette нажмите Actor;
2. Нажмите кнопку мыши на одной из сторон диаграммы, чтобы создать новое действующее лицо, а затем переименуйте его в Buyer;
3. Повторите шаг 2, чтобы создать новое действующее лицо под именем Seller.

Полученная диаграмма представлена на рисунке 24.

Рис. 24. Диаграмма прецедента с действующими лицами

Теперь необходимо определить взаимосвязь между действующими лицами и прецедентом. На основной диаграмме объект Buyer состоит в отношении с прецедентом Bid on Item, который в свою очередь имеет связь с объектом Seller. При наведении мыши на объект диаграммы рядом с объектом появляются две пиктограммы (см. рис. 25): автоматические соединители для составления связей объекта. Перетащите метку From с объекта Buyer на прецедент Bid On Item, а затем снова перетащите ее с прецедента Bid On Item на объект Seller.

Рис. 25. Соединители объектов

В результате должна получиться диаграмма, представленная на рисунке 26. Это конечная диаграмма прецедента верхнего уровня "Bid On Item" на основе заявленных требований. (В этом примере отношению добавлены соответствующие описания).

Рис. 26. Конечная диаграмма прецедента

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

Отслеживание взаимосвязей

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

Чтобы выявить объект, который имеет соответствующий элемент в Rational Software Modeler, взгляните на пиктограмму элемента в рамках ракурсов Explorer. Объекты, имеющие определенные связи, помечаются небольшой стрелкой вокруг соответствующих пиктограмм (как показано на рисунке 27).

Рис. 27. Отслеживаемые объекты

Вы также можете нажать правую кнопку мыши на объекте, а затем выбрать в меню соответствующий элемент и просмотреть его свойства. Например, если вы нажмете правую кнопку мыши на объекте "Bid On Item", вы сможете выбрать просмотр требования в Requirement Explorer, при котором на экран будут также выведены свойства требования (см. рис. 28).

Рис. 28. Отслеживание связи требования

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

Отслеживание других элементов модели

До этого момента вы занимались объединением моделей прецедентов в Rational Software Modeler с прецедентами в Rational RequisitePro. В процессе разработки создаются другие элементы, которые вам необходимо связать с требованиями и проектом Rational RequisitePro.

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

Чтобы научиться создавать связь между объектами в Rational Software Modeler и Rational RequisitePro, создайте простую диаграмму классов:

1. В Explorer нажмите правую кнопку мыши на прецеденте Bid On Item, а затем выберитеAdd Diagram > Class Diagram;
2. В только что созданной диаграмме классов нажмите Class на панели Palette, а затем нажмите кнопку мыши в любой области диаграммы, чтобы создать новый класс;
3. В качестве имени класса введите Item.

С помощью этого объекта вы можете создать в Rational RequisitePro новое требование, связанное с данным классом. Чтобы создать связь и требование:

1. Нажмите правую кнопку мыши на классе Item в диаграмме классов или на панели Model Explorer, а затем выберите Requirement > Remember Element "Item";
2. В окне Requirement Explorer нажмите правую кнопку мыши на блоке для нового требования, а затем выберите Create Requirement from "Item".

Вы также можете перетащить объект с панели Model Explorer на Requirements Explorer. Тип созданного требования определяется свойствами проекта в рамках раздела Requirement Creation Policy в настройках RSM. По умолчанию, для объектов Class создается требование CLASS. (Обратите внимание на то, что на этом этапе не создается взаимосвязь между новым требованием и исходным прецедентом.) Чтобы сопоставить заданный объект с его исходным прецедентом, перетащите объект с панели Model Explorer на требование прецедента.

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

Матрица трассируемости для проектирования и требований

Финальная часть процесса интеграции заключается в мониторинге трассируемости компонентов проекта с исходными требованиями. Для этого в рамках Rational RequisitePro необходимо создать матрицу трассируемости. В этом процессе создается ракурс, сопоставляющий два типа требований и отображающий взаимосвязи между компонентами проекта и требованиями.

Чтобы создать матрицу трассируемости в Rational RequisitePro:

1. Нажмите правую кнопку мыши на блоке Use Cases, а затем выберите New > View;
2. В окне View Properties введите Requirements to Classes в качестве имени ракурса;
3. В ниспадающем списке View Type выберите Traceability Matrix (см. рис. 29);

   

   Рис. 29. Добавление нового ракурса

4. В ниспадающем списке Row Requirement выберите Use Case;
5. В ниспадающем списке Column Requirement Type выберите CLASS. (В крупномасштабном проекте можно ограничить ракурс, обеспечив отображение только свойств определенных прецедентов. Для этого необходимо нажать Query, чтобы указать, какие требования должны быть включены в ракурс.);
6. Нажмите OK, чтобы завершить ракурс. На экране должна появиться диаграмма, представленная на рисунке 30.

   

   Рис. 30. Завершенная матрица трассируемости

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

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

Раздел 7. Заключение

Rational RequisitePro - превосходный инструмент для записи требований к приложению. Rational Software Modeler идеально подходит для моделирования этих требований в рамках диаграмм прецедентов. Каждый из описанных продуктов полностью выполняет свои задачи в процессе разработки. Тем не менее, будучи объединенными, эти продукты предоставляют разработчикам и проектировщикам полноценный способ взаимодействия с руководителями проектов и, в конечном итоге, клиентами, которое необходимо для определения и создания запрашиваемого приложения.

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

Данное руководство представляет собой лишь первую часть большого материала. Для создания системы Auction вам необходимо выполнить еще целый ряд действий. На данном этапе готов список требований и сопоставленные модели UML в решениях Rational RequisitePro и Rational Software Modeler. В процессе создания приложения Auction, этапы которого описаны в последующих частях справочного материала, вы получите подробные сведения о том, как преобразовать свою модель в рабочий проект и программный код с помощью Rational Application Developer. Вы также научитесь выявлять и отслеживать дефекты и другие запросы на изменение с помощью IBM Rational RequisitePro. Кроме того, вы получите сведения о тестирующих продуктах Rational и их интеграции с другими компонентами в пакете программ Rational.

• Подробнее о продуктах IBM Rational
• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Приобрести продукты компании IBM Rational в электронном магазине ITShop.ru
• Курсы обучения по продуктам компании IBM Rational Software