sdt-book-2006 (1133574), страница 13
Текст из файла (страница 13)
Также,возможно, происходит апробация выбранных технологий, чтобы убедиться в возможностидостичь целей с их помощью, и составляются предварительные планы проекта.36На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.Пример хода работ показан на Рис. 7.Инженер попроцессуПодготовка средыдля итерацийПрограммистыКонтроль иуправлениеУточнениезадач системыПоддержка средыОтработкаизмененийПланированиепроекта и итерацийАнализ возможныхархитектурСистемныйаналитикАрхитекторПОРуководительпроектаРазработкакомпонентовАнализ эффективноститестированияУточнениеархитектурыТестированиеи оценкаТестировщикиРуководительпроектаОценка результатовитерацийРисунок 8. Пример хода работ на фазе проектирования.2. Фаза проектирования (Elaboration)Основная цель этой фазы — на базе основных, наиболее существенных требованийразработать стабильную базовую архитектуру продукта, которая позволяет решатьпоставленные перед системой задачи и в дальнейшем используется как основа разработкисистемы.На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.Пример хода работ представлен на Рис.
8.Инженер попроцессуКонтроль иуправлениеПодготовка средыдля итерацийРазработкадокументацииПоддержка средыПланированиепроекта и итерацийОтработкаизмененийОценка результатовитерацийПрограммистыТестированиеи оценкаТестировщикиТехническийписательРуководительпроектаРуководительпроектаРазработкакомпонентовПодготовкаразвертыванияРуководительразвертыванияРисунок 9. Пример хода работ на фазе построения.3. Фаза построения (Construction)Основная цель этой фазы — детальное прояснение требований и разработка системы,удовлетворяющей им, на основе спроектированной ранее архитектуры. В результатедолжна получиться система, реализующая все выделенные варианты использования.37На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.Пример хода работ на этой фазе представлен на Рис. 9.4.
Фаза внедрения (Transition)Цель этой фазы — сделать систему полностью доступной конечным пользователям. Наэтой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование,подгонка мелких деталей под нужды пользователей.На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.Пример хода работ представлен на Рис. 10.Инженер попроцессуПодготовка средыдля итерацийПрограммистыКонтроль иуправлениеПоддержка средыРазработкадокументацииРаз/доработкакомпонентовНетПланированиепроекта и итерацийОтработкаизмененийТехническийписательТестированиеи оценкаРуководительпроектаИнтеграцияРуководительразвертыванияРуководительпроектаОценка результатовитерацийДаДостаточноекачество?ТестировщикиТестированиеи оценкаДостаточноекачество?НетДаСледующаяитерацияПодготовкапродуктаКонец проектаРисунок 10. Пример хода работ на фазе внедрения.Артефакты, вырабатываемые в ходе проекта, могут быть представлены в виде баз данных итаблиц с информацией различного типа, разных видов документов, исходного кода и объектныхмодулей, а также моделей, состоящих из отдельных элементов.
Основные артефакты и потокиданных между ними согласно RUP изображены на Рис. 11.Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающиеразличные аспекты будущей системы. Большинство моделей представляют собой наборыдиаграмм UML. Основные используемые виды моделей следующие.• Модель вариантов использования (Use-Case Model).Эта модель определяет требования к ПО — то, что система должна делать — в виде наборавариантов использования. Каждый вариант использования задает сценарий взаимодействиясистемы с действующими лицами (actors) или ролями, дающий в итоге значимый для нихрезультат.
Действующими лицами могут быть не только люди, но и другие системы,взаимодействующие с рассматриваемой. Вариант использования определяет основной ходсобытий, развивающийся в нормальной ситуации, а также может включать несколькоальтернативных сценариев, которые начинают работать только при специфическихусловиях.38Запросызаинтересованных лицКонцепцияСписок рисковБизнес планСловарьПлан разработкиПОПланразвертыванияМодель вариантовиспользованияОписаниеархитектуры ПОДополнительныетребованияМодельпроектированияМодель анализаПлантестированияМодельреализацииПроцессразработкиРисунок 11.
Основные артефакты проекта по RUP и потоки данных между ними.Модель вариантов использования служит основой для проектирования и оценки готовностисистемы к внедрению.Примером варианта использования может служить сценарий действий клиента Интернетмагазина по отношению к сайту этого магазина, в результате которых клиент заказываеттовар, например, книги. Такой вариант использования можно назвать «Заказ товара». Еслинас интересует сайт магазина только как программная система, результатом можно считатьто, что запись о сделанном заказе занесена в базу данных, а оператору заказов отправленоэлектронное письмо, содержащее всю информацию, которая необходима для того, чтобыможно было сформировать заказ. В нее входит контактная информация покупателя,идентификатор заказа и, например, список заказанных книг с их ISBN, их количество длякаждого наименования и номера партий для удобства их поиска на складе. При этомвыполнение остальной части варианта использования — это дело других составляющихсистемы под названием «Интернет-магазин».
Эта работа может включать звонок илиписьмо клиенту и подтверждение, что именно он сделал заказ, вопрос об удобных для негоформе, времени и адресе доставки и форме оплаты, формирование заказа, передача его длядоставки курьеру, доставка и подтверждение получения заказа и оплаты. В нашем примередействующими лицами являются клиент, делающий заказ, и оператор заказов.Альтернативные сценарии в рамках данного варианта могут выполняться, если, например,заказанного пользователем товара нет на складе или сам пользователь находится на плохомсчету в магазине из-за неоплаченных прежних заказов, или, наоборот, он являетсяпривилегированным клиентом или представителем крупной организации.39Заказ товараКлиентОператорзаказовРисунок 12.
Пример варианта использования и действующих лиц.•Модель анализа (Analysis Model).Она включает основные классы, необходимые для реализации выделенных вариантовиспользования, а также возможные связи между классами. Выделяемые классыразбиваются на три разновидности — интерфейсные, управляющие и классы данных. Этиклассы представляют собой набор сущностей, в терминах которых работа системы должнапредставляться пользователям. Они являются понятиями, с помощью которых достаточноудобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь вдетали.Интерфейсные классы (boundary classes) соответствуют устройствам или способамобмена данными между системой и ее окружением, в том числе пользователями. Классыданных (entity classes) соответствуют наборам данных, описывающих некоторыеоднотипные сущности внутри системы. Эти сущности являются абстракциямипредставлений пользователей о данных, с которыми работает система.
Управляющиеклассы (control classes) соответствуют алгоритмам, реализующим какие-то значимыепреобразования данных в системе и управляющим обменом данными с ее окружением врамках вариантов использования.В нашем примере с Интернет-магазином можно было бы выделить следующие классы вмодели анализа: интерфейсный класс, предоставляющий информацию о товаре ивозможность сделать заказ; интерфейсный класс, представляющий сообщение оператору;управляющий класс, обрабатывающий введенную пользователем информацию ипреобразующий ее в данные о заказе и сообщение оператору; класс данных о заказе.Соответствующая модель приведена на Рис. 13.Каждый класс может играть несколько ролей в реализации одного или несколькихвариантов использования. Каждая роль определяет его обязанности и свойства, тожеявляющиеся частью модели анализа.В рамках других подходов модель анализа часто называется концептуальной модельюсистемы.
Она состоит из набора классов, совместно реализующих все вариантыиспользования и служащих основой для понимания работы системы и объяснения ееправил всем заинтересованным лицам.КлиентИнтерфейсзаказа товараОбработчикзаказаИнтерфейс сообщенийОператороператорузаказовДанные заказаРисунок 13. Пример модели анализа для одного варианта использования.•Модель проектирования (Design Model).Модель проектирования является детализацией и специализацией модели анализа. Онатакже состоит из классов, но более четко определенных, с более точным и детальнымраспределением обязанностей, чем классы модели анализа. Классы модели проектированиядолжны быть специализированы для конкретной используемой платформы.
Каждая такая40•••платформа может включать операционные системы всех вовлеченных машин;используемые языки программирования; интерфейсы и классы конкретных компонентныхсред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использованиясистем управления базами данных, СУБД, например, Oracle или MS SQL Server;используемые библиотеки разработки пользовательского интерфейса, такие как swing илиswt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр.В нашем примере, прежде всего, необходимо детализировать классы, уточнить ихфункциональность.
Скажем, для того, чтобы клиенту было удобнее делать заказ, нужнопредоставить ему список имеющихся товаров, какие-то способы навигации и поиска в этомсписке, а также детальную информацию о товаре. Это значит, что интерфейс заказа товарареализуется в виде набора классов, представляющих, например, различные страницы сайтамагазина. Точно так же данные заказа должны быть детализированы в виде несколькихтаблиц в СУБД, включающих, как правило, данные самого заказа (дату, ссылку на данныеклиента, строки с количеством отдельных товаров и ссылками на товары), данные товаров,клиента и пр. Кроме того, для реляционной СУБД понадобятся классы-посредники междуее таблицами и объектной структурой остальной программы. Обработчик заказа можетбыть реализован в виде набора объектов нескольких классов, например, с выделеннымотдельно набором часто изменяемых политик (скидки на определенные категории товарови определенным категориям клиентов, сезонные скидки, рекламные комплекты и пр.) иболее постоянным общим алгоритм обработки.Далее, приняв, например, решение реализовывать систему с помощью технологий J2EE или.NET, мы тем самым определяем дополнительные ограничения на структуру классов, да ина само их количество.
О правилах построения ПО на основе этих технологийрассказывается в следующих лекциях.Модель реализации (Implementation Model).Под моделью реализации в рамках RUP и UML понимают набор компонентоврезультирующей системы и связей между ними. Под компонентом здесь имеется в видукомпонент сборки — минимальный по размерам кусок кода системы, который можетучаствовать или не участвовать в определенной ее конфигурации, единица сборки иконфигурационного управления.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
