В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 14
Текст из файла (страница 14)
Каждый узел может бытьнагружен некоторым множеством компонентов, определенных в модели реализации.Цель построения модели развертывания — определить физическое положение компонентовраспределенной системы, обеспечивающее выполнение ею нужных функций в тех местах,где эти функции будут доступны и удобны для пользователей.В нашем примере 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)Задачи — подстройка процесса под конкретный проект, выбор и замена технологий иинструментов, используемых в проекте.Первые пять дисциплин считаются рабочими, остальные — поддерживающими.
Распределениеобъемов работ по дисциплинам в ходе проекта выглядит, согласно руководству по RUP, примернотак, как показано на Рис. 14.Рисунок 14. Распределение работ между различными дисциплинами в проекте по RUP.Напоследок перечислим техники, используемые в RUP согласно [3].• Выработка концепции проекта (project vision) в его начале для четкой постановки задач.• Управление по плану.• Снижение рисков и отслеживание их последствий, как можно более раннее начало работ попреодолению рисков.43•••••••••Тщательное экономическое обоснование всех действий — делается только то, что нужнозаказчику и не приводит к невыгодности проекта.Как можно более раннее формирование базовой архитектуры.Использование компонентной архитектуры.Прототипирование, инкрементная разработка и тестирование.Регулярные оценки текущего состояния.Управление изменениями, постоянная отработка изменений извне проекта.Нацеленность на создание продукта, работоспособного в реальном окружении.Нацеленность на качество.Адаптация процесса под нужды проекта.Экстремальное программированиеЭкстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционныйметод разработки ПО «снизу-вверх».
Этот подход является примером так называемого метода«живой» разработки (Agile Development Method). В группу «живых» методов входят, помимоэкстремального программирования, методы SCRUM, DSDM (Dynamic Systems DevelopmentMethod, метод разработки динамичных систем), Feature-Driven Development (разработка,управляемая функциями системы) и др.Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой»разработки [5], появившемся в 2000 году.• Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.• Работающая программа более важна, чем исчерпывающая документация.• Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.• Отработка изменений более важна, чем следование планам.«Живые» методы появились как протест против чрезмерной бюрократизации разработки ПО,обилия побочных, не являющихся необходимыми для получения конечного результатадокументов, которые приходится оформлять при проведении проекта в соответствии сбольшинством «тяжелых» процессов, дополнительной работы по поддержке фиксированногопроцесса организации, как это требуется в рамках, например, CMM.
Большая часть таких работ идокументов не имеет прямого отношения к разработке ПО и обеспечению его качества, апредназначена для соблюдения формальных пунктов контрактов на разработку, получения иподтверждения сертификатов на соответствие различным стандартам.«Живые» методы позволяют большую часть усилий разработчиков сосредоточить собственнона задачах разработки и удовлетворения реальных потребностей пользователей.
Отсутствие кипыдокументов и необходимости поддерживать их в связном состоянии позволяет более быстро икачественно реагировать на изменения в требованиях и в окружении, в котором придется работатьбудущей программе.Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широкоиспользуемое понимание «процесса разработки» как достаточно жесткой схемы действийпротиворечит самой идее «живости» разработки), приведенную на Рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
