Унифицированный процесс разработки программного обеспесчения

     Поэтому архитектура определяется в виде представлений всех моделей системы, которые в сумме представляют систему целиком. Это означает, что существуют архитектурные представления модели вариантов использования, модели анализа, модели проектирования, модели реализации и модели развертывания. Представление модели реализации включает в себя компоненты для доказательства того, что архитектура выполнима. В ходе этой фазы определяются наиболее критичные варианты использования. Результатом выполнения этой фазы является базовый уровень архитектуры.

     В конце  фазы проектирования   менеджер проекта  занимается   планированием действий  и подсчетом  ресурсов, необходимым  для завершения   проекта. Ключевым вопросом в этот момент будет следующий: достаточно ли проработаны варианты использования, архитектура и план, и взяты ли риски под контроль настолько, чтобы можно было давать контрактные обязательства выполнить  всю работу по разработке?

     В ходе фазы построения происходит создание продукта — к скелету (архитектуре) добавляются мышцы (законченные программы). На этой фазе базовый уровень архитектуры разрастается до полной развитой системы. Концепции развиваются до продукта, готового к передаче пользователям.  В ходе фазы разработки объем требуемых ресурсов  вырастает. Архитектура системы стабильна, однако, поскольку разработчики могут найти лучшие способы структурирования системы, от них могут исходить предложения о внесении в архитектуру системы небольших изменений. В конце этой фазы продукт включает в себя все варианты использования, которые руководство и заказчик договорились включить в текущий выпуск. Правда, они могут содержать ошибки. Большинство дефектов будут обнаружены и исправлены в ходе фазы внедрения. Ключевой вопрос окончания фазы: удовлетворяет ли продукт требованиям пользователей настолько, что некоторым заказчикам можно делать предварительную поставку?

     Фаза  внедрения охватывает период, в ходе которого продукт существует в виде бета-выпуска или бета-версии. Небольшое число квалифицированных пользователей, работая   с бета-выпуском   продукта, сообщает об обнаруженных   дефектах и недостатках. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения. Фаза внедрения включает в себя такие действия, как производство тиража, тренинг сотрудников заказчика, организацию поддержки по горячей линии и исправление дефектов, обнаруженных после поставки. Команда поддержки часто разделяет найденные дефекты на две категории: дефекты, оказывающие  настолько значительный эффект на работу с программой, что это оправдывает немедленный выпуск дельта-версии, и дефекты, исправление которых можно отложить до следующего выпуска.

7. Интегрированный процесс

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

2. Процесс, направляемый вариантами использования

     Задача  Унифицированного процесса — предоставлять разработчикам план эффективного создания и развертывания систем, удовлетворяющих требованиям пользователя. Эффективность при этом измеряется в понятиях стоимости, качества и затраченного времени. Путь от получения требований заказчика до реализации непрост. Проблемы начинаются с определения требований заказчиков. Этот процесс предполагает, что мы способны определить требования пользователей и довести их без ошибок до всех участников проекта. После этого мы должны быть в состоянии спроектировать работающую реализацию, которая выполняла бы эти требования. И наконец, мы должны протестировать созданную систему, чтобы удостоверится в том, что требования пользователей выполнены. Сложность процесса заставляет нас описывать его в виде серии рабочих процессов, последовательно создающих работающую систему.

     На  рис. 3.1 изображена последовательность рабочих процессов и моделей Унифицированного процесса. Разработчики начинают с определения требований заказчика в виде вариантов использования и формирования на их основе модели вариантов использования. Затем они анализируют и проектируют систему, осуществляющую эти варианты использования, строя сначала модель анализа, а затем модели проектирования и развертывания. После этого они реализуют систему, получая модель реализации, которая содержит весь код проекта в виде компонентов. В конце разработчики создают модель тестирования, которая позволяет им проверить, обеспечивает ли система функциональность, описанную в вариантах использования. Все модели связаны между собой зависимостями трассировки. Модель реализации наиболее формальна, а самая неформальная модель — это модель вариантов использования. Происходит это потому, что модель реализации создается на компьютерном языке, то есть части модели реализации после компиляции и компоновки превращаются в исполняемые файлы, тогда как в модели вариантов использования применяется в основном естественный язык.

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

     На  каждой итерации они направляют выполнение всех рабочих процессов, от определения  требований через анализ, проектирование и реализацию до тестирования. Таким образом они связывают различные рабочие процессы между собой.

1. Введение  в разработку управляемую  вариантами использования

     Определение требований преследует две цели: определить существенные требования и представить их в форме, удобной для пользователей, заказчиков и разработчиков. Под «существенными требованиями» мы понимаем те требования, реализация которых принесет пользователям ощутимый и значимый для них результат. Под «представлением в форме, удобной для пользователей, заказчиков и разработчиков» мы понимаем главным образом то, что итоговое описание требований должны понимать пользователи и заказчики. Это один из главных результатов рабочего процесса определения требований.

     Обычно  у системы имеется несколько категорий пользователей. Каждая категория пользователей представляется в виде актанта. Актанты используют систему, участвуя в вариантах использования. Вариант использования — это последовательность действий, которые система предпринимает для получения актантом ценного для него результата. Полный набор актантов и вариантов использования системы образует модель вариантов использования.

     В ходе анализа и проектирования модель вариантов использования преобразуется в модель анализа, а затем в модель проектирования. Если говорить коротко, и модель анализа, и модель проектирования — это структуры, построенные на основе классификаторов и набора реализаций вариантов использования, которые определяют, как эти структуры реализуют варианты использования. Классификаторы в основном представляют собой «классоподобные» сущности. Так, они содержат атрибуты и операции, их можно описывать с помощью диаграмм состояний некоторые из них допускают   создание экземпляров, они могут участвовать  в кооперациях и т. п. В UML существует множество типов классификаторов. Примерами классификаторов для этих моделей могут быть подсистемы, классы и интерфейсы. Актанты, варианты использования, компоненты и узлы также являются классификаторами.

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

     Модель  проектирования имеет следующие свойства:

• Модель проектирования имеет иерархическую структуру. Она также содержит отношения, наложенные поверх иерархии. Отношения — ассоциации, обобщения и зависимости (приложение А) — часто используются в UML.
• Реализации вариантов использования в модели проектирования — это стереотипы кооперации. Кооперация описывает, как классификаторы используются в каком-либо  виде деятельности, например реализации  варианта использования.
• Модель проектирования является чертежом реализации. Существует прямое отображение подсистем модели проектирования в элементы модели реализации.

     Разработчики  создают модель анализа, используя модель вариантов использования в качестве исходных данных. Каждый вариант использования из модели вариантов использования превращается в реализацию варианта использования модели анализа. Дуализм вариантов использования/реализаций вариантов использования позволяет соблюсти полное подобие  между определением требований и анализом. Прорабатывая варианты использования один за другим, разработчики идентифицируют классы, участвующие в реализации вариантов использования. Вариант использования Получить наличные, например, превращается в классы анализа Получение, Банковский счет, Устройство выдачи и еще несколько классов, которые мы пока идентифицировать не будем. Разработчики выделяют ответственности конкретных классов в ответственностях определенных в вариантах использования. В нашем примере класс Банковский счет будет нести ответственность за выполнение операции «Списать деньги со счета». Таким образом, мы можем убедиться в том, что получили набор классов, совместно реализующих варианты использования и действительно необходимых.

     Затем разработчики проектируют классы и  реализации вариантов использования для того, чтобы лучше понять, какие продукты и технологии следует использовать для построения системы (брокеры объектных запросов, библиотеки для создания графического интерфейса пользователя, СУБД). Классы проектирования собираются в подсистемы, и между этими подсистемами определяются интерфейсы. Разработчики также создают модель развертывания, которая определяет физическое распределение частей системы по узлам — отдельным компьютерам сети — и проверяют, могут ли варианты использования быть реализованы в виде компонентов, выполняемых на этих узлах. Далее, разработчики реализуют спроектированные классы в виде набора файлов с исходным текстом компонентов, из которых, если их скомпилировать и скомпоновать, можно получить исполняемый код — DLL, JavaBeans или ActiveX. Варианты использования помогают   разработчикам определить  порядок   создания компонентов и включения их в систему.

     И наконец, в ходе рабочего процесса тестирования тестеры проверяют, действительно ли система выполняет функции, определенные вариантами использования, и удовлетворяет требованиям к системе. Модель тестирования содержит тестовые примеры. Тестовый пример определяет набор исходных данных, условий выполнения и результатов. Множество тестовых примеров могут быть порождены прямо из вариантов использования, таким образом, мы можем говорить об отношении трассировки между тестовыми примерами и соответствующими вариантами использования. Это означает, что тестеры будут проверять, делает ли система то, чего хотят от нее пользователи, то есть выполняет ли она варианты использования. Каждый, тестировавший в прошлом программное обеспечение, фактически тестировал варианты использования, — хотя тогда это и называлось иначе. А вот что в Унифицированном процессе действительно изменилось, так это то, что теперь тестирование можно планировать гораздо раньше. Сразу же после определения вариантов использования можно начинать создание тестов вариантов использования   (тесты для «черного ящика») и задавать порядок их выполнения, включения в систему и тестирования. Позднее, после реализации вариантов использования в ходе проектирования, можно детализировать тесты вариантов использования (тесты для «белого ящика»). Каждый способ выполнения варианта использования, а значит, каждый путь реализации варианта использования, является кандидатом на тестовый пример.

2. Необходимость вариантов использования

     Существует  несколько объяснений удобства, популярности и повсеместного применения вариантов использования. Две основные причины таковы: