В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 14
Текст из файла (страница 14)
Управляющиеклассы (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 понимают набор компонентоврезультирующей системы и связей между ними.
Под компонентом здесь имеется в видукомпонент сборки — минимальный по размерам кусок кода системы, который можетучаствовать или не участвовать в определенной ее конфигурации, единица сборки иконфигурационного управления. Связи между компонентами представляют собойзависимости между ними. Если компонент зависит от другого компонента, он не можетбыть поставлен отдельно от него.Часто компоненты представляют собой отдельные файлы с исходным кодом.
Далее мыпознакомимся с компонентами J2EE, состоящими из нескольких файлов.Модель развертывания (Deployment Model).Модель развертывания представляет собой набор узлов системы, являющихся физическиотдельными устройствами, которые способны обрабатывать информацию — серверами,рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними,образованными различного рода сетевыми соединениями. Каждый узел может бытьнагружен некоторым множеством компонентов, определенных в модели реализации.Цель построения модели развертывания — определить физическое положение компонентовраспределенной системы, обеспечивающее выполнение ею нужных функций в тех местах,где эти функции будут доступны и удобны для пользователей.В нашем примере Web-сайта магазина узлами системы являются один или несколькокомпьютеров, на которых развернуты Web-сервер, пересылающий по запросу пользователятекст нужной странички, набор программных компонентов, отвечающих за генерациюстраничек, обработку действий пользователя и взаимодействие с базой данных, и СУБД, врамках которой работает база данных системы.
Кроме того, строго говоря, в системувходят все компьютеры клиентов, на которых работает Web-браузер, делающийвозможным просмотр страничек сайта и пересылку кодированных действий пользователядля их обработки.Модель тестирования (Test Model или Test Suite).В рамках этой модели определяются тестовые варианты или тестовые примеры (test41cases) и тестовые процедуры (test scripts). Первые являются определенными сценариямиработы одного или нескольких действующих лиц с системой, разворачивающимися врамках одного из вариантов использования.
Тестовый вариант включает, помимо входныхданных на каждом шаге, где они могут быть введены, условия выполнения отдельныхшагов и корректные ответы системы для всякого шага, на котором ответ системы можнонаблюдать. В отличие от вариантов использования, в тестовых вариантах четко определенывходные данные, и, соответственно, тестовый вариант либо вообще не имеетальтернативных сценариев, либо предусматривает альтернативный порядок действий в томслучае, если система может вести себя недетерминировано и выдавать разные результаты вответ на одни и те же действия. Все другие альтернативы обычно заканчиваютсявынесением вердикта о некорректной работе системы.Тестовая процедура представляет собой способ выполнения одного или несколькихтестовых вариантов и их составных элементов (отдельных шагов и проверок).
Это можетбыть инструкция по ручному выполнению входящих в тестовый вариант действий илипрограммный компонент, автоматизирующий запуск тестов.Для выделенного варианта использования «Заказ товара» можно определить следующиетестовые варианты:o заказать один из имеющихся на складе товаров и проверить, что сообщение об этомзаказе поступило оператору;o заказать большое количество товаров и проверить, что все работает так же;o заказать отсутствующий на складе товар и проверить, что в ответ приходит сообщение оего отсутствии;o сделать заказ от имени пользователя, помещенного в «черный список», и проверить, чтов ответ приходит сообщение о неоплаченных прежних заказах.RUP также определяет дисциплины, включающие различные наборы деятельностей, которые вразных комбинациях и с разной интенсивностью выполняются на разных фазах.
В документациипо процессу каждая дисциплина сопровождается довольно большой диаграммой, поясняющейдействия, которые нужно выполнить в ходе работ в рамках данной дисциплины, артефакты, скоторыми надо иметь дело, и роли вовлеченных в эти действия лиц.• Моделирование предметной области (бизнес-моделирование, Business Modeling)Задачи этой деятельности — понять предметную область или бизнес-контекст, в которыхдолжна будет работать система, и убедиться, что все заинтересованные лица понимают егоодинаково, осознать имеющиеся проблемы, оценить их возможные решения и ихпоследствия для бизнеса организации, в которой будет работать система.В результате моделирования предметной области должна появиться ее модель в виденабора диаграмм классов (объектов предметной области) и деятельностей(представляющих бизнес-операции и бизнес-процессы). Эта модель служит основоймодели анализа.• Определение требований (Requirements)Задачи — понять, что должна делать система, и убедиться во взаимопонимании по этомуповоду между заинтересованными лицами, определить границы системы и основу дляпланирования проекта и оценок затрат ресурсов в нем.Требования принято фиксировать в виде модели вариантов использования.• Анализ и проектирование (Analysis and Design)Задачи — выработать архитектуру системы на основе требований, убедиться, что даннаяархитектура может быть основой работающей системы в контексте ее будущегоиспользования.В результате проектирования должна появиться модель проектирования, включающаядиаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействиймежду объектами в ходе реализации вариантов использования, диаграммы состояний дляотдельных объектов и диаграммы развертывания.42•Реализация (Implementation)Задачи — определить структуру исходного кода системы, разработать код ее компонентови протестировать их, интегрировать систему в работающее целое.• Тестирование (Test)Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценитьее качество в целом, оценить выполнены или нет гипотезы, лежащие в основепроектирования, оценить степень соответствия системы требованиям.• Развертывание (Deployment)Задачи — установить систему в ее рабочем окружении и оценить ее работоспособность натом месте, где она должна будет работать.• Управление конфигурациями и изменениями (Configuration and Change Management)Задачи — определение элементов, подлежащих хранению в репозитории проекта и правилпостроения из них согласованных конфигураций, поддержание целостности текущегосостояния системы, проверка согласованности вносимых изменений.• Управление проектом (Project Management)Задачи — планирование, управление персоналом, обеспечение взаимодействия на благопроекта между всеми заинтересованными лицами, управление рисками, отслеживаниетекущего состояния проекта.• Управление средой проекта (Environment)Задачи — подстройка процесса под конкретный проект, выбор и замена технологий иинструментов, используемых в проекте.Первые пять дисциплин считаются рабочими, остальные — поддерживающими.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
