|
|
|||||||||||||||||||||||||||||
|
Оптимизация разработки приложений. Часть 1: Упорядочивание требований к приложениюИсточник: IBM developerWorks Россия Мартин Браун (Martin C. Brown)
Раздел 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 Software Modeler и Rational Application Developer, а также пакет RUP, в который входит полная документация по техническим аспектам, методам и системам, составляющим основу методологии RUP. Также потребуется текстовый редактор Microsoft Word (как минимум - Word 97, однако рекомендуется Word 2000 или более поздние версии). Для прохождения этапов данного руководства вам потребуются следующие компоненты:
Раздел 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, имеют следующие области применения:
Приложение по ведению аукционаВо всех частях этого руководства в качестве примера предлагается создать приложение по ведению аукциона, моделью которого выступает приложение, используемое во множестве программных продуктов 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. Управление требованиями в методологии RationalRequisiteProВ рамках базовых понятий, требование представляет собой наиболее фундаментальную функциональность, которую приложение должно предоставлять пользователю. Требования должны быть максимально определенными и специализированными. Предположим, для системы ведения аукциона вы определили следующее требование "возможность покупать и продавать товары с помощью системы, похожей на аукцион" . На практике такое требование будет бесполезным, когда дело дойдет до разработки приложения. Необходимо указать специфику работы определенных частей проекта: например, как составляются и обрабатываются заявки, как происходит продажа, как информация о продуктах, выставленных на аукционе, становится доступной для просмотра. Требования поступают из разных источников, однако, основная их часть предъявляется различными лицами, заинтересованными в выполнении проекта. Как правило, в любой разработке основным заинтересованным лицом является клиент - его роль может выполнять внутренний отдел предприятия, внешняя компания или даже обычные пользователи. Проблема заключается в получении от заинтересованных лиц и последующем упорядочении этих требований в целях составления первоначального списка требований, который будет использоваться для запуска процесса разработки приложения. Эту задачу решает компонент Rational RequisitePro: он предоставляет механизм записи всех разнообразных требований, поступающих от разных групп, и создает окончательный список требований и их взаимоотношений. Эти требования могут указываться и определяться несколькими разными способами, включая основные утверждения и прецеденты. Система легко поддается настройке, при этом отдельные требования могут иметь неограниченное количество свойств (полей), используемых для хранения дополнительных сведений о каждом требовании. Усиление роли требований в процессе разработкиПосле надлежащей сортировки и обработки требования должны использоваться для повышения эффективности процесса разработки приложений. Теоретически, требования должны использоваться для ускорения всех операций в области разработки программного обеспечения. На практике, первоначальный набор требований только определяет функциональность проекта, а для поддержания окончательной версии приложения требования необходимо улучшить и расширить. Так сложилось, что трудности всегда возникают при передаче требований разработчикам, а затем при использовании требований для проектирования модели, написания программного кода и создания компонентов приложения, предоставляющих необходимую функциональность. К счастью, большую часть этих проблем решает интеграция Rational RequisitePro с Rational Software Modeler. Создание формальной связи между моделью (и, в конечном итоге, самим кодом) и требованием, обеспечивающим разработку определенного компонента, дает гарантию, что разрабатываемое приложение соответствует заявленным требованиям, не превышает их и, наконец, удовлетворяет потребности лиц, заинтересованных в проекте. Так как требования формируют основу разработки, необходимо следить, чтобы они всегда соответствовали текущей модели. Это позволит вам решить следующие вопросы:
Чтобы ответить на эти вопросы, необходимо сопоставить требования с компонентами модели. Краткий обзор прецедентовиспользоваться в создаваемом приложении. Теоретически, можно (но не рекомендуется) использовать RUP с другими типами требований. Однако это не приведет к нужному результату, а поток информации и описаний между различными компонентами будет также другим. Примечание: Если вы уже знакомы с прецедентами, можете пропустить данный раздел. При необходимости получить краткие сведения о структуре прецедентов и о том, как они помогают в разработке приложений, советуем продолжить чтение этого раздела. В прецеденте (use case) формулируется взаимосвязь между действующими лицами (пользователями или компонентами системы) и поведением компонента. Когда действующее лицо использует систему, эта система осуществляет прецедент. В нем также описывается поведение системы в разных ситуациях. В результате, создается определение, указывающее последовательность событий (от начала до конца), включая любые альтернативные последовательности, необходимые для достижения желаемого результата. С точки зрения формата, прецедент представляет собой текстовое описание, соответствующее этой основной модели в рамках RUP:
Например, в случае с приложением по ведению аукциона, речь может идти о представленном ниже примере последовательности, инициированной действующим лицом при подаче заявки в системе аукциона:
Альтернативные потоки операций могут описывать, что произойдет, если прием заявок будет прекращен до подачи предложения, если сумма заявки будет признана недействительной или покупатель не подтвердит подачу заявки. Прецеденты обеспечивают гибкое описание последовательности операций, но все же требуют структуризации и определенной записи, которые поддерживаются Rational RequisitePro. Интеграция Rational RequisiteProRational RequisitePro может интегрироваться с разными инструментальными средствами, которые основаны на технологиях Rational, а также с некоторыми внешними инструментами. Основная роль Rational RequisitePro на первых этапах разработки заключается в документировании требований. Процесс документирования требований осуществляется непосредственно в рамках Rational RequisitePro следующими способами:
Раздел 4. Составление спецификации требованийRational RequisitePro предоставляет пользователю систему записи и управления требованиями. В основе системы требований лежит гибкая структура базы данных, позволяющая использовать неограниченное количество типов требований, при этом каждый тип имеет неограниченное количество полей для отслеживания дополнительной информации о каждом требовании. Отдельное требование можно также связать и идентифицировать как отношение другого требования. Например, для системы безопасности определяется запрос высокоуровневых функций, в котором прецеденты определяют систему аутентификации и авторизации. Необходимо провести обратное прослеживание прецедентов, а значит и самих требований, используемых для определения функциональности, до исходных функций обеспечения безопасности. В решении Rational RequisitePro требования хранятся в базе данных. Тем не менее, их можно записывать и редактировать посредством связи с редактором Microsoft Word, что позволяет руководителям проектов и нетехническим специалистам составлять требования в рамках знакомого интерфейса, одновременно составляя и обновляя информацию в базе данных. В Rational RequisitePro накапливается информация, которую менеджеры проекта и руководители групп используют для определения проекта. После того как будет составлена первоначальная версия требований, разработчики уже могут использовать собранные сведения для создания приложения. В этом разделе вы познакомитесь с основами составления требований, которые можно использовать и интегрировать с другими инструментами Rational. Основные преимущества использования Rational RequisiteProОсновное преимущество Rational RequisitePro перед отдельной документацией заключается в управлении, которое обеспечивает исходная структурированная база данных. Структурированный формат данных позволяет составлять отчеты, создавать соединения с другими требованиями и записывать дополнительную информацию об этих требованиях. Такая функциональность намного шире, чем типовые возможности документов Microsoft Word. Другим преимуществом Rational RequisitePro является возможность записи и отслеживания изменений отдельных требований. Такая информация полезна даже в том случае, если работа над требованиями ведется изолированно - всего одним специалистом. Но особенную ценность она приобретает в тех ситуациях, когда требования используются, отслеживаются и обновляются группой пользователей. Появляется возможность проследить, какие изменения были внесены и по какой причине. Создание нового проектаЧтобы начать процесс составления требований, необходимо создать в рамках Rational RequisitePro новый проект:
После того как будет создан новый проект, на экране появится окно, схожее с окном, приведенным на рисунке 6. (Все элементы древовидной структуры в левой области окна развернуты в текущем проекте RequisitePro в целях просмотра: на этом этапе процесса элементы в правой области окна не отображаются.) Каждая папка в древовидной структуре (слева) называется блоком (package) , который логически объединяет документы и требования в целях организации элементов проекта. Рис. 6. Интерфейс проекта Rational RequisitePro Создание документов требованийВ рамках Rational RequisitePro требования можно создать тремя следующими способами: непосредственно в Rational RequisitePro, с помощью веб-интерфейса или путем использования специального расширения Microsoft Word, позволяющего создавать требования непосредственно в документе Microsoft Word, который в свою очередь в фоновом режиме обновляет базу данных. В результате, продолжая ориентироваться на базу данных, вы можете создавать на основе редактора Microsoft Word собственные документы требований, включая любой дополнительный описательный или сопроводительный текст. Прежде всего, необходимо создать новый блок, в котором будет размещаться информация для прецедента "Bid on Item":
Теперь в этом блоке можно указать определение прецедента "Bid on Item". Вы можете импортировать существующий документ, но в рамках данного руководства потребуется создать новый документ, который будет использоваться для определения прецедентов в отношении раздела системы ведения аукциона "Bid on Item".
Просмотрите шаблон. В документе представлен необходимый обзор той информации, которая может использоваться в прецеденте. Составление требованийВ рамках решения Rational RequisitePro требования упорядочиваются в привычной древовидной структуре (как файлы и папки в файловой системе). Таким образом, можно выделить первичный уровень прецедентов, который предоставляет основную информацию о данном разделе, при этом более подробные сведения указываются в дочерних (подчиненных) требованиях. Такая структура соответствует структуре документа прецедента в рамках методологии RUP. При редактировании документа Rational RequisitePro в редакторе Microsoft Word появляется дополнительная панель инструментов и меню (см. рис. 10). Они обеспечивают переход к системе Rational RequisitePro и позволяют создавать требования для проекта Rational RequisitePro непосредственно в документе Microsoft Word. Рис. 10. Панель инструментов Rational RequisitePro в редакторе Microsoft Word Чтобы создать требование в рамках документа Microsoft Word:
Выбранный в редакторе Microsoft Word текст документа будет заменен полем, содержащим текстовую информацию, только что введенную в базу данных Rational. Обратите внимание на то, что до того, как вы сохраните и закроете документ в Microsoft Word, данный элемент будет помечен как незаконченный (pending). В рамках процесса сохранения вся информация импортируется в базу данных Rational RequisitePro. Теперь необходимо повторить эту процедуру, чтобы добавить внутри прецедента "Bid on Item" дополнительную информацию, которая определяет отдельные этапы в рамках требования "Bid on Item". Расширение информации о требованияхВ предыдущем разделе были созданы требования, снабженные некоторой базовой информацией о прецеденте, которая необходима для ввода заявки в систему. Теперь можно приступить к добавлению других сведений, повышающих ценность рассматриваемых требований. В рамках Rational RequisitePro используются полностью настраиваемые типы требований. Стандартные поля применяются в типах требований, доступных в списке предварительно определенных типов проекта (примером служит используемый здесь шаблон Use-Case), но фактические поля обладают должной гибкостью и могут использоваться для хранения информации любого рода. Дополнительные поля могут принимать свободную или фиксированную форму, а также могут использовать специальные всплывающие списки. В рамках данного проекта вам необходимо добавить в тип прецедента исходное поле. Это позволит определить лицо, изначально ответственное за то или иное требование. Чтобы добавить поле в тип требования:
Теперь у вас есть свойство или поле, определенное в соответствии с основным типом требования Use Case. Это свойство можно снабдить информацией о том, кто первым представил данное требование. Ракурсы и отчетыВ Rational RequisitePro для отображения информации и отношений ракурсы используют стандартные методики запросов к базе данных требований. Каждый ракурс состоит из запроса, который инициирует отображение информации, и вида ракурса - одного из четырех предварительно определенных форматов просмотра данных. К этим видам ракурса относятся:
Матрица трассируемости будет использоваться далее в этом руководстве для сопоставления проектов модели Rational Software Modeler с предъявленными требованиями. Раздел 5. Моделирование приложений с помощью Rational Software ModelerRational 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Создайте новый проект, содержащий ваши модели:
На рисунке представлена базовая структура для проекта прецедента. Чтобы перейти к основной части прецедента Auction, закройте панель Instructions, нажав на вкладке кнопку X. Теперь можно приступать к заполнению модели, используя информацию, которая была создана в предыдущих разделах руководства, посвященных Rational RequisitePro. Создание новой диаграммы прецедентаДля моделирования прецедента необходимо создать новую диаграмму, в которой будут размещаться сведения о модели. Чтобы создать новую диаграмму:
Теперь все готово к добавлению объектов в диаграмму. Следует помнить о том, что основной причиной создания требований и утверждений прецедентов в 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" как элемент данной диаграммы прецедента. Чтобы добавить требование в диаграмму:
Чтобы завершить диаграмму, добавьте два действующих лица (actors), которые относятся к данному прецеденту - Buyer (покупатель) и 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, создайте простую диаграмму классов:
С помощью этого объекта вы можете создать в Rational RequisitePro новое требование, связанное с данным классом. Чтобы создать связь и требование:
Вы также можете перетащить объект с панели Model Explorer на Requirements Explorer. Тип созданного требования определяется свойствами проекта в рамках раздела Requirement Creation Policy в настройках RSM. По умолчанию, для объектов Class создается требование CLASS. (Обратите внимание на то, что на этом этапе не создается взаимосвязь между новым требованием и исходным прецедентом.) Чтобы сопоставить заданный объект с его исходным прецедентом, перетащите объект с панели Model Explorer на требование прецедента. Теперь в системе присутствуют проектные элементы и исходные требования. Вы можете использовать матрицу трассируемости для определения того, какие части требований были действительно спроектированы. Матрица трассируемости для проектирования и требованийФинальная часть процесса интеграции заключается в мониторинге трассируемости компонентов проекта с исходными требованиями. Для этого в рамках Rational RequisitePro необходимо создать матрицу трассируемости. В этом процессе создается ракурс, сопоставляющий два типа требований и отображающий взаимосвязи между компонентами проекта и требованиями. Чтобы создать матрицу трассируемости в Rational RequisitePro:
Стрелки показывают направление связи от требования к модели, что позволяет мгновенно определить, какие компоненты отвечают за ту или иную функциональность заявленных требований. Теперь, в целях описания приложения перед его непосредственной разработкой, в системе создана основная связь между исходными требованиями и разрабатываемой моделью. Продолжайте этот процесс, добавляя дополнительные требования и присоединяя к этим требованиям другие модели и элементы, тем самым выстраивая полное представление о системе. Раздел 7. ЗаключениеRational RequisitePro - превосходный инструмент для записи требований к приложению. Rational Software Modeler идеально подходит для моделирования этих требований в рамках диаграмм прецедентов. Каждый из описанных продуктов полностью выполняет свои задачи в процессе разработки. Тем не менее, будучи объединенными, эти продукты предоставляют разработчикам и проектировщикам полноценный способ взаимодействия с руководителями проектов и, в конечном итоге, клиентами, которое необходимо для определения и создания запрашиваемого приложения. При налаженной интеграции матрица трассируемости позволяет видеть, какие компоненты завершены или еще моделируются, а также какую часть требований необходимо переработать, чтобы создать и смоделировать приложение. При отсутствии такого уровня интеграции разработка приложения рискует отклониться от исходной спецификации. Данное руководство представляет собой лишь первую часть большого материала. Для создания системы Auction вам необходимо выполнить еще целый ряд действий. На данном этапе готов список требований и сопоставленные модели UML в решениях Rational RequisitePro и Rational Software Modeler. В процессе создания приложения Auction, этапы которого описаны в последующих частях справочного материала, вы получите подробные сведения о том, как преобразовать свою модель в рабочий проект и программный код с помощью Rational Application Developer. Вы также научитесь выявлять и отслеживать дефекты и другие запросы на изменение с помощью IBM Rational RequisitePro. Кроме того, вы получите сведения о тестирующих продуктах Rational и их интеграции с другими компонентами в пакете программ Rational. Ссылки по теме
|
|