Lecture03 (1133560), страница 2

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

Текст из файла (страница 2)

Пример хода работ на фазе внедрения.Артефакты, вырабатываемые в ходе проекта, могут быть представлены в виде баз данных итаблиц с информацией различного типа, разных видов документов, исходного кода и объектныхмодулей, а также моделей, состоящих из отдельных элементов. Основные артефакты и потокиданных между ними согласно RUP изображены на Рис. 11.Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающиеразличные аспекты будущей системы. Большинство моделей представляют собой наборыдиаграмм UML. Основные используемые виды моделей следующие.• Модель вариантов использования (Use-Case Model).Эта модель определяет требования к ПО — то, что система должна делать — в виде наборавариантов использования. Каждый вариант использования задает сценарий взаимодействиясистемы с действующими лицами (actors) или ролями, дающий в итоге значимый для нихрезультат.

Действующими лицами могут быть не только люди, но и другие системы,взаимодействующие с рассматриваемой. Вариант использования определяет основной ходсобытий, развивающийся в нормальной ситуации, а также может включать несколькоальтернативных сценариев, которые начинают работать только при специфическихусловиях.Запросызаинтересованных лицКонцепцияСписок рисковБизнес планСловарьПлан разработкиПОПланразвертыванияМодель вариантовиспользованияОписаниеархитектуры ПОДополнительныетребованияМодельпроектированияМодель анализаПлантестированияМодельреализацииПроцессразработкиРисунок 11.

Основные артефакты проекта по RUP и потоки данных между ними.Модель вариантов использования служит основой для проектирования и оценки готовностисистемы к внедрению.Примером варианта использования может служить сценарий действий клиента Интернетмагазина по отношению к сайту этого магазина, в результате которых клиент заказываеттовар, например, книги. Такой вариант использования можно назвать «Заказ товара». Еслинас интересует сайт магазина только как программная система, результатом можно считатьто, что запись о сделанном заказе занесена в базу данных, а оператору заказов отправленоэлектронное письмо, содержащее всю информацию, которая необходима для того, чтобыможно было сформировать заказ. В нее входит контактная информация покупателя,идентификатор заказа и, например, список заказанных книг с их ISBN, их количество длякаждого наименования и номера партий для удобства их поиска на складе.

При этомвыполнение остальной части варианта использования — это дело других составляющихсистемы под названием «Интернет-магазин». Эта работа может включать звонок илиписьмо клиенту и подтверждение, что именно он сделал заказ, вопрос об удобных для негоформе, времени и адресе доставки и форме оплаты, формирование заказа, передача его длядоставки курьеру, доставка и подтверждение получения заказа и оплаты. В нашем примередействующими лицами являются клиент, делающий заказ, и оператор заказов.Альтернативные сценарии в рамках данного варианта могут выполняться, если, например,заказанного пользователем товара нет на складе или сам пользователь находится на плохомсчету в магазине из-за неоплаченных прежних заказов, или, наоборот, он являетсяпривилегированным клиентом или представителем крупной организации.Заказ товараКлиентОператорзаказовРисунок 12.

Пример варианта использования и действующих лиц.•Модель анализа (Analysis Model).Она включает основные классы, необходимые для реализации выделенных вариантовиспользования, а также возможные связи между классами. Выделяемые классыразбиваются на три разновидности — интерфейсные, управляющие и классы данных. Этиклассы представляют собой набор сущностей, в терминах которых работа системы должнапредставляться пользователям. Они являются понятиями, с помощью которых достаточноудобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь вдетали.Интерфейсные классы (boundary classes) соответствуют устройствам или способамобмена данными между системой и ее окружением, в том числе пользователями.

Классыданных (entity classes) соответствуют наборам данных, описывающих некоторыеоднотипные сущности внутри системы. Эти сущности являются абстракциямипредставлений пользователей о данных, с которыми работает система. Управляющиеклассы (control classes) соответствуют алгоритмам, реализующим какие-то значимыепреобразования данных в системе и управляющим обменом данными с ее окружением врамках вариантов использования.В нашем примере с Интернет-магазином можно было бы выделить следующие классы вмодели анализа: интерфейсный класс, предоставляющий информацию о товаре ивозможность сделать заказ; интерфейсный класс, представляющий сообщение оператору;управляющий класс, обрабатывающий введенную пользователем информацию ипреобразующий ее в данные о заказе и сообщение оператору; класс данных о заказе.Соответствующая модель приведена на Рис.

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

Пример модели анализа для одного варианта использования.•Модель проектирования (Design Model).Модель проектирования является детализацией и специализацией модели анализа. Онатакже состоит из классов, но более четко определенных, с более точным и детальным••распределением обязанностей, чем классы модели анализа.

Классы модели проектированиядолжны быть специализированы для конкретной используемой платформы. Каждая такаяплатформа может включать операционные системы всех вовлеченных машин;используемые языки программирования; интерфейсы и классы конкретных компонентныхсред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использованиясистем управления базами данных, СУБД, например, Oracle или MS SQL Server;используемые библиотеки разработки пользовательского интерфейса, такие как swing илиswt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр.В нашем примере, прежде всего, необходимо детализировать классы, уточнить ихфункциональность.

Скажем, для того, чтобы клиенту было удобнее делать заказ, нужнопредоставить ему список имеющихся товаров, какие-то способы навигации и поиска в этомсписке, а также детальную информацию о товаре. Это значит, что интерфейс заказа товарареализуется в виде набора классов, представляющих, например, различные страницы сайтамагазина. Точно так же данные заказа должны быть детализированы в виде несколькихтаблиц в СУБД, включающих, как правило, данные самого заказа (дату, ссылку на данныеклиента, строки с количеством отдельных товаров и ссылками на товары), данные товаров,клиента и пр. Кроме того, для реляционной СУБД понадобятся классы-посредники междуее таблицами и объектной структурой остальной программы. Обработчик заказа можетбыть реализован в виде набора объектов нескольких классов, например, с выделеннымотдельно набором часто изменяемых политик (скидки на определенные категории товарови определенным категориям клиентов, сезонные скидки, рекламные комплекты и пр.) иболее постоянным общим алгоритм обработки.Далее, приняв, например, решение реализовывать систему с помощью технологий J2EE или.NET, мы тем самым определяем дополнительные ограничения на структуру классов, да ина само их количество.

О правилах построения ПО на основе этих технологийрассказывается в следующих лекциях.Модель реализации (Implementation Model).Под моделью реализации в рамках RUP и UML понимают набор компонентоврезультирующей системы и связей между ними. Под компонентом здесь имеется в видукомпонент сборки — минимальный по размерам кусок кода системы, который можетучаствовать или не участвовать в определенной ее конфигурации, единица сборки иконфигурационного управления.

Связи между компонентами представляют собойзависимости между ними. Если компонент зависит от другого компонента, он не можетбыть поставлен отдельно от него.Часто компоненты представляют собой отдельные файлы с исходным кодом. Далее мыпознакомимся с компонентами J2EE, состоящими из нескольких файлов.Модель развертывания (Deployment Model).Модель развертывания представляет собой набор узлов системы, являющихся физическиотдельными устройствами, которые способны обрабатывать информацию — серверами,рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними,образованными различного рода сетевыми соединениями.

Каждый узел может бытьнагружен некоторым множеством компонентов, определенных в модели реализации.Цель построения модели развертывания — определить физическое положение компонентовраспределенной системы, обеспечивающее выполнение ею нужных функций в тех местах,где эти функции будут доступны и удобны для пользователей.В нашем примере Web-сайта магазина узлами системы являются один или несколькокомпьютеров, на которых развернуты Web-сервер, пересылающий по запросу пользователятекст нужной странички, набор программных компонентов, отвечающих за генерациюстраничек, обработку действий пользователя и взаимодействие с базой данных, и СУБД, врамках которой работает база данных системы.

Кроме того, строго говоря, в системувходят все компьютеры клиентов, на которых работает Web-браузер, делающийвозможным просмотр страничек сайта и пересылку кодированных действий пользователядля их обработки.•Модель тестирования (Test Model или Test Suite).В рамках этой модели определяются тестовые варианты или тестовые примеры (testcases) и тестовые процедуры (test scripts). Первые являются определенными сценариямиработы одного или нескольких действующих лиц с системой, разворачивающимися врамках одного из вариантов использования. Тестовый вариант включает, помимо входныхданных на каждом шаге, где они могут быть введены, условия выполнения отдельныхшагов и корректные ответы системы для всякого шага, на котором ответ системы можнонаблюдать. В отличие от вариантов использования, в тестовых вариантах четко определенывходные данные, и, соответственно, тестовый вариант либо вообще не имеетальтернативных сценариев, либо предусматривает альтернативный порядок действий в томслучае, если система может вести себя недетерминировано и выдавать разные результаты вответ на одни и те же действия.

Все другие альтернативы обычно заканчиваютсявынесением вердикта о некорректной работе системы.Тестовая процедура представляет собой способ выполнения одного или несколькихтестовых вариантов и их составных элементов (отдельных шагов и проверок). Это можетбыть инструкция по ручному выполнению входящих в тестовый вариант действий илипрограммный компонент, автоматизирующий запуск тестов.Для выделенного варианта использования «Заказ товара» можно определить следующиетестовые варианты:o заказать один из имеющихся на складе товаров и проверить, что сообщение об этомзаказе поступило оператору;o заказать большое количество товаров и проверить, что все работает так же;o заказать отсутствующий на складе товар и проверить, что в ответ приходит сообщение оего отсутствии;o сделать заказ от имени пользователя, помещенного в «черный список», и проверить, чтов ответ приходит сообщение о неоплаченных прежних заказах.RUP также определяет дисциплины, включающие различные наборы деятельностей, которые вразных комбинациях и с разной интенсивностью выполняются на разных фазах.

Характеристики

Список файлов лекций