Инкапсуляцией
 Скачать 0.92 Mb.
|
|
Уточнение В фазе уточнения проекта выполняются некоторое планирование, анализ и проектирование архитектуры. Следуя плану итерации, уточнение проводится для каждого варианта использования в текущей итерации. Уточнение включает в себя такие аспекты проекта, как кодирование прототипов (proofs-of-concept), разработка тестов и принятие решений по проекту. Основная задача фазы уточнения — детализация вариантов использования. В разделе "Основы Rose" главы 3 рассматривается, что может входить в детали вариантов использования. Предъявляемые к вариантам использования требования низкого уровня предусматривают описание потока обработки данных внутри них, выявление действующих лиц, разработку диаграмм Взаимодействия для графического отображения потока обработки данных, а также определение всех переходов состояний, которые могут иметь место в рамках варианта использования. Из требований, определенных в форме детализированных вариантов использования, составляется документ под названием "Спецификация требований к программному обеспечению" (Software Requirement Specification, SRS). SRS содержит детальное описание всех требований к системе. В фазе уточнения выполняются и такие задачи, как уточнение предварительных оценок, изучение SRS и модели вариантов использования с точки зрения качества проектируемой системы, анализ рисков. С помощью Rational Rose можно уточнить модель Вариантов Использования, а также разработать диаграммы Последовательности и Кооперативные диаграммы для графического представления потока обработки данных. Кроме того, в этой фазе проектируются диаграммы Классов, описывающие объекты, которые необходимо создать. Фаза уточнения завершается, когда варианты использования полностью детализированы и одобрены пользователями, прототипы завершены настолько, чтобы уменьшить риски, разработаны диаграммы Классов. Иными словами, эта фаза пройдена, когда система спроектирована, рассмотрена и готова для передачи разработчикам. Конструирование Конструирование - процесс разработки и тестирования программного обеспечения. Как и в случае уточнения, эта фаза выполняется для каждого набора вариантов использования на каждой итерации. Задачи конструирования включают в себя определение всех оставшихся требований, разработку и тестирование программного обеспечения (ПО). Так как ПО полностью проектируется в фазе уточнения, конструирование не предполагает большого количества решений по проекту, что позволяет команде работать параллельно. Это означает, что разные группы программистов могут одновременно работать над различными объектами ПО, зная, что по завершении фазы система "сойдется". В фазе уточнения мы проектируем объекты системы и их взаимодействие. Конструирование только запускает проект в действие, а новых решений по нему, способных изменить это взаимодействие, не принимается. Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rational Rose способна генерировать "скелетный код" системы. Для использования этой возможности следует разработать компоненты и диаграмму компонентов на раннем этапе конструирования. Генерацию кода можно начать сразу после создания компонентов и нанесения на диаграмму зависимостей «.тя ними. В результате будет автоматически построен код, который можно создать, основываясь а I проекте системы. Это не означает, что с помощью Rose можно получить любой код, реализующий 14-логику приложений. Результат сильно зависит от используемого языка программирования, но случае предполагает определение классов, атрибутов, областей действия (общих (public), закрытых (private) и защищенных (protected)), прототипов функций и операторов наследования. Это позволяет сэкономить время, так как написание кода вручную — довольно кропотливая и утомительная работа. Получив код, программисты могут сконцентрироваться на специфических аспектах проекта, связанных с бизнес-логикой. Еще одна группа разработчиков должна выполнить экспертную оценку кода, чтобы убедиться в его функциональности и соответствии стандартам и соглашениям по проекту. Затем объекты должны быть подвергнуты оценке качества. Если в фазе конструирования были добавлены новые атрибуты или функции или если были изменены взаимодействия между объектами, код следует преобразовать в модель Rose с помощью обратного проектирования (см. главы с 19 по 24). Конструирование можно считать завершенным, когда программное обеспечение готово и протестировано. Важно убедиться в адекватности модели и программного обеспечения; модель будет чрезвычайно полезна в процессе сопровождения ПО. Ввод в действие Фаза ввода в действие наступает, когда готовый программный продукт передают пользователям. Задачи в этой фазе предполагают завершение работы над финальной версией продукта, завершение приемочного тестирования, завершение составления документации и подготовку к обучению пользователей. Чтобы отразить последние внесенные изменения, следует обновить Спецификацию требований к программному обеспечению, диаграммы Вариантов Использования, Классов, Компонентов и Размещения. Важно, чтобы ваши модели были синхронизированы с готовым продуктом, поскольку они будут использоваться при его сопровождении. Кроме того, модели будут неоценимы при внесении усовершенствований в созданную систему через несколько месяцев после завершения проекта. В фазе ввода в действие Rational Rose не настолько полезна, как в других фазах. В этот момент приложение уже создано. Rose предназначена для оказания помощи при моделировании и разработке программного обеспечения и даже при планировании его размещения. Однако Rose не является инструментом тестирования и не способна помочь в планировании тестов или процедур, связанных с размещением ПО. Для этой цели созданы другие продукты. Итак, в фазе ввода в действие Rose применяется прежде всего для обновления моделей после завершения работы над программным продуктом. Rational Rose Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат. Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы Взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диаграммы Размещения применяют для визуализации проекта распределенных систем. Модель Rose — это картина системы. Она содержит все диаграммы UML, действующих лиц, варианты использования, объекты, классы, компоненты и узлы системы. Она детально описывает, что система содержит и как функционирует, поэтому разработчики могут использовать ее в качестве эскиза или чертежа создаваемой системы. Такой чертеж помогает решить старую проблему. Допустим, команда разработчиков обсудила с пользователями и документировала требования к приложению. Программисты готовы писать код. Один из них (назовем его Боб) берет часть требований, принимает определенные решения и пишет некоторый фрагмент кода. Другой (Джейн) тоже берет часть требований, принимает свои, совершенно отличающиеся от первого, решения по проекту и пишет другой код. Естественно ожидать различие в стилях программирования; получив одинаковый набор требований, 20 разработчиков создадут 20 различных систем. Таким образом, без подробного обсуждения работы с каждым участником проекта будет трудно понять, какие решения по проекту приняты, из каких элементов состоит система и что представляет собой ее общая структура. Не имея документированного проекта, трудно даже быть уверенным, что созданное приложение — это именно то, чего хотели пользователи. Традиционно процесс, которому мы следуем, выглядит следующим образом:  Хотя требования и были документированы, весь проект находится в голове Боба, и никто, кроме Боба, не понимает достаточно хорошо архитектуру системы. Когда Боб оставляет команду, информация уходит вместе с ним. Если вы оказывались в подобной ситуации, то согласитесь, как трудно бывает понять плохо документированную систему. Модель Rose предлагает совершенно другой подход:  В этом случае проект уже документирован. Разработчики могут собраться вместе и обсудить принимаемые по проекту решения до фактического написания кода. Вам не нужно больше беспокоиться, что каждый из них пойдет своим путем в проектировании частей одного и того же приложения Однако модели используют не только разработчики:
Итак, Rose — это средство, которое может быть использовано всеми участниками проекта. Это, фактически, хранилище информации о контексте и проекте системы, из которого каждый участник проекта извлекает то, что ему нужно. Помимо всего вышесказанного, Rational Rose позволяет генерировать "скелетный код" на большом количестве различных языков, включая C++, Java, Visual Basic и PowerBuilder. Более того, можно выполнять обратное проектирование кода и создавать таким образом модели уже существующих систем. Весьма выгодно иметь модели Rose для уже существующих приложений. Если сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Если же был изменен код, можно автоматически обновить соответствующим образом и модель. Благодаря этому удается поддерживать соответствие между моделью и кодом, уменьшая риск "устаревания" первой. Среду Rose можно расширить с помощью RoseScript, языка программирования, поставляемого вместе с ней. На RoseScript можно написать код для автоматического внесения изменений в модель, для создания отчетов и выполнения других задач. Знакомство с ROSE Элементы экрана Основными элементами интерфейса Rose являются браузер, окно документации, панели инструментов, окно диаграммы и журнал (log).
Панели инструментов
Пользователь может изменить и настроить любую панель инструментов. Для этого следует выбрать пункт меню Tools Options (Инструменты Параметры), затем вкладку Toolbars (Панели инструментов). ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ Диаграмма Вариантов Использования содержит некоторые варианты использования системы, некоторых действующих лиц и связи между ними. Вариант использования (use case) — это описание функциональности системы на "высоком уровне". Действующее лицо (actor) — это все, что взаимодействует с системой. На рис. 3.1 приведен пример диаграммы Вариантов Использования.  На этой диаграмме показаны три действующих лица: клиент, банковский служащий и кредитная система. Существуют также шесть основных действий, выполняемых моделируемой системой: перевести деньги, положить деньги на счет, снять деньги со счета, показать баланс, изменить идентификационный номер и произвести оплату. Одним из основных преимуществ применения диаграммы Вариантов Использования является то, что она предоставляет важную информацию. Взглянув на варианты использования, ваши клиенты поймут, какие функциональные возможности будут заложены в систему. Рассматривая действующих лиц, они выяснят, кто конкретно будет с ней взаимодействовать. Изучая все множество вариантов использования и действующих лиц, они определят сферу применения системы, что она должна будет делать. Это поможет им узнать также, что она не будет делать, и внести коррективы. Например, взглянув на диаграмму, пользователь может сказать: "Все это прекрасно, но я хочу иметь еще возможность получать отчет о десяти последних транзакциях для моего счета". Часто для одной системы создается несколько диаграмм Вариантов Использования. На диаграмме высокого уровня, называемой в среде Rational Rose Главной (Main), указываются только пакеты (группы) вариантов использования. Другие диаграммы описывают совокупности вариантов использования и действующих лиц. Может потребоваться также нанести на одну диаграмму все варианты использования и всех действующих лиц системы. Количество и состав создаваемых диаграмм Вариантов Использования полностью зависит от вас. Важно только, чтобы они содержали достаточно информации, чтобы быть полезными, но не слишком много, чтобы не привести в замешательство. Конкретная цель диаграмм Вариантов Использования — документирование вариантов использования (все входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы Вариантов Использования, старайтесь придерживаться следующих правил: Не моделируйте связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции. Для изучения коммуникации между действующими лицами применяется диаграмма потоков работ (workflow diagram). Не соединяйте стрелкой непосредственно два варианта использования (кроме случаев связей использования и расширения, рассматриваемых ниже). Диаграммы данного типа описывают только, какие варианты использования доступны системе, а не порядок их выполнения. Для отображения порядка выполнения вариантов использования применяются диаграммы Деятельностей. Каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Исключением являются рассматриваемые далее связи использования и расширения. Думайте о базе данных как о слое, находящемся под диаграммой. С помощью одного варианта использования можно вводить данные в базу, а получать их — с помощью другого. Для изображения потока информации не нужно рисовать стрелки от одного варианта использования к другому. |
