Диаграммы

Диаграммы – это совокупности правил соединения различных символов языка моделирования. Диаграмма представляет собой связанный граф, вершинами которого являются сущности, а ребрами – отношения. Любая диаграмма представляет собой модель некоторого аспекта разрабатываемой системы. Предусмотрены следующие виды диаграмм (правил соединения символов):

Диаграмма вариантов использования/прецедентов (Use case diagram) – диаграмма поведения, показывающая функции моделируемой системы и ее связи с другими системами, т.е., в случае разработки программного обеспечения, требования пользователей. Диаграмма состоит из множества прецедентов, классов (акторов: пользователей или любых других внешних систем) и отношений между ними (рис. 4.9).

Проектирование системы осуществляется путем реализации на каждой итерации одного или нескольких вариантов использования. Данная диаграмма является основой для моделирования поведения и тестирования системы.

На данной диаграмме показаны следующие виды отношения между прецедентами: расширение и использование.

Связь типа «расширение» применяется в тех случаях, когда один вариант использования подобен другому, но несет несколько другую нагрузку и, в связи с этим, необходимо описать изменение в обычном поведении системы.

Связь типа «использование» применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования и нет смысла копировать его описание.

Диаграмма классов (Class diagram) – структурная диаграмма, показывающая структуру классов предметной области. Диаграмма состоит из классов, интерфейсов, коопераций и отношений между ними (рис. 4.10). Абстрактные классы, от которых не производятся экземпляры, помечаются курсивом.

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

Диаграмма объектов (Object diagram) – структурная диаграмма, показывающая объектную модель системы, состоящую из множества экземпляров классов (объектов) и отношений между ними.

Диаграмма взаимодействия – диаграмма поведения, показывающая взаимодействие нескольких объектов, например, в рамках одного варианта использования. Взаимодействия изображаются с помощью диаграммы последовательностей (Sequence diagram), подчеркивающей временную последовательность событий (рис. 4.11), или диаграммы кооперации (Collaboration diagram), подчеркивающей структурную организацию объектов, посылающих и принимающих сообщения (рис. 4.12).

Диаграмма состояний (Statechart diagram ) – диаграмма поведения, показывает поведение одного объекта в нескольких вариантах использования. Диаграмма представляет автомат, включающий в себя состояния, переходы, события и виды действий. Данная диаграмма акцентирует внимание на поведении объекта, зависящем от последовательности событий, и особенно важна при описании поведения классов, интерфейсов и коопераций.

Диаграмма деятельности (Activity diagram)– диаграмма поведения, показывающая поведение разрабатываемой системы вместе с управляющей структурой. Диаграмма представляет автомат и подчеркивает переходы потока управления от одной деятельности к другой (рис. 4.13). Может отображать несколько объектов в нескольких вариантах использования или реализацию метода. Позволяет определять параллельные процессы.

Сообщения: 1 – открыть сейф; 2 – деньги в первый мешок; 3 – деньги во второй мешок; 4 – деньги в третий мешок.

Диаграмма компонентов (Component diagram)– диаграмма, показывающая организацию совокупности компонент (файлов) и их зависимости.

Диаграмма развертывания (Deployment diagram)– диаграмма, показывающая узлы и отношения между ними (физическое размещение компонент в аппаратных средствах).

Применение языка UML существенно облегчается за счет следующих механизмов:

- спецификаций (specifications) – текстовых описаний синтаксиса и семантики соответствующих элементов модели (диаграммы);

- принятых делений (commondivisions) – в соответствии с дихотомией «класс/объект» и дихотомией «интерфейс/реализация»;

- механизмов расширения (extensibilitymechanisms) – обеспечивающих расширение синтаксиса и семантики языка.

Предусмотрены следующие механизмы расширения языка:

- стереотипы (stereotypes), позволяющие расширять словарь языка и представлять на основе существующих элементов новые специфичные для конкретных проблем элементы модели;

- помеченные значения (tagged values), позволяющие расширять свойства элементов языка и представлять новые атрибуты и новую информацию в спецификацию элемента;

- ограничения (constraint), позволяющие расширять семантику элементов языка и определить новые или изменить старые правила.

UML не зависит от процесса его использования или метода моделирования. Однако, лучше всего он поддерживает Рациональный Унифицированный Процесс (Rational Unified Process – RUP) изготовления программных продуктов.

В общих чертах процесс анализа и моделирования системы в терминах UML представляет собой последовательность следующих шагов:

- Анализ внешних по отношению к данной систем и формулирование требований к моделируемой системе с их точки зрения. Результаты этого шага представляются в виде диаграммы прецедентов.

- Уточнение потоков событий в прецедентах, например, в виде диаграммы деятельности или текстового документа.

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

- Декомпозиция моделируемой системы и представление ее модели в виде диаграммы кооперации (взаимодействия объектов).

Консорциум OMG начал разрабатывать UML 2.0, чтобы преодолеть существенные недостатки ранних версий. В число проблем, которые пытаются решить архитекторы стандарта UML 2.0, входит проблема разбухания ранних версий и недостатки в определении семантики. В процессе работы над новым стандартом возникла необходимость включить в него поддержку разработки на базе моделей (Model-Driven Development – MDD) и, в частности, подхода к такой разработке с позиций архитектуры на базе моделей (Model-Driven Architecture – MDA). В результате стандартизации языка моделирования общественными усилиями был разработан очень громоздкий и сложный вариант стандарта. По мнению известных экспертов [106, с. 34] «Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленные концепции моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в MDD»... «Язык UML 2.0 в некоторых отношениях превосходит предыдущие версии, но его громоздкость и сложность могут создать проблемы для пользователей, разработчиков инструментальных средств и рабочих групп OMG, развивающих этот стандарт».

4.1.4. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средства

В данном пункте представлено описание стандартного процесса объектно-ориентированной разработки информационного (программного) обеспечения бизнеса – Рационального Унифицированного Процесса – РУП (Rational Unified Process). Для его составления использованы работы [79 и 81].

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

Основанный на архитектуре и управляемый прецедентами процесс разработки ПО является итеративным и инкрементным. Таким образом, он, во-первых, подразумевает создание версий программной системы и, во-вторых – развитие системной архитектуры при выпуске новых версий. Этот пошаговый процесс, предполагает постепенное проникновение в суть проблемы с помощью последовательных уточнений, в котором ПО разрабатывается и реализуется по частям, путем получения все более емкого решения.

Таблица 4.1. Аспекты представления системной архитектуры.

Вид	Аспект представления	Диаграммы представления UML
Статики	Динамики
Прецедентов.	Варианты использования системы конечным пользователем, ее поведение.	Прецедентов.	Деятельности, состояний и взаимодействия.
Проектирования.	Поддержка функциональных требований. Словарь предметной области (классы, интерфейсы, кооперации).	Классов и объектов.	Последовательности и кооперации.
Процессов.	Процессы и потоки, с точки зрения производительности, пропускной способности, масштабируемости.	– «–	Деятельности, состояний и взаимодействия.
Реализации.	Компоненты и файлы с точки зрения сборки системы и управления конфигурацией версий.	Компонентов.	– «–
Развертывания.	Узлы физической системы с точки зрения распределения, поставки и установки.	Развертывания.	– «–

Данный эффект достигается вследствие того, что РУП состоит из фаз, в которых достигаются конкретные хорошо определенные цели и принимается решение о переходе к следующей фазе: начало, исследование, построение, внедрение. При этомкаждая фаза состоит из итераций, содержащих рабочие процессы, соответствующие этапам жизненного цикла ПО. В каждой фазе и на каждой итерации основные усилия сосредотачиваются на различных аспектах процесса разработки. В таблице 4.2 показан общий вид этого процесса.

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

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

Таблица 4.2. Фазы и рабочие процессы РУП.

Рабочие процессы:

Начало

Исследование

Построение

Внедрение

Моделирование бизнес-процессов

Требования

Анализ и проектирование

Реализация

Тестирование

Развертывание

Управление конфигурацией и изменениями

Управление проектом

Рабочая среда

Вспомогательные процессы

Номер итерации ®

…

n

n+1

…

m

m+1

…

k

k+1

…

s

Таблица 4.3. Цикл разработки.

Наименование процесса:	Содержание процесса:
Моделирование бизнес-процессов	Описывается структура и динамика организации.
Требования	Описываются требования пользователей методом, основанным на прецедентах.
Анализ и проектирование	Описывается предметная область и различные виды архитектуры разрабатываемой системы.
Реализация	Разрабатывается программные модули, проводится автономное тестирование и их интеграция.
Тестирование	Описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок.
Развертывание	Осуществляется конфигурирование поставляемой системы.
Управление конфигурацией и изменениями	Управление изменениями и поддержание целостности проекта.
Управление проектом	Выработка и описание различных стратегий работы с итеративным процессом.
Рабочая среда	Рассмотрение вопросов инфраструктуры, необходимой для разработки системы.

Начальная фаза проекта (Inception)

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

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

Важнейшие цели:

- Определить функциональные возможности создаваемого ПО и его эксплуатационные свойства, а также критерии, по которым будет определяться его готовность.

- Определить наиболее трудоемкие и критичные варианты использования ПО и их сценарии.

- Проработать архитектуру ПО для таких сценариев.

- Оценить стоимость и сроки выполнения проекта.

- Дать обобщенную оценку потенциальных рисков.

- Определить инфраструктуру (рабочую среду) проекта.

Важнейшие действия:

- Анализ бизнес-процессов, для которых разрабатывается ПО.

- Описание контекста и наиболее важных требований к ПО.

- Оценка альтернатив по управлению рисками, по укомплектованности персоналом и другим ресурсам, по планированию процесса разработки.

- Оценка соотношения стоимости и доходности ПО.

- Выбор инструментов.

- Создание основного документа «Vision» (см. ниже в конце данного пункта).

Исследование (Elaboration)

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

В этой фазе следует дать ответы на следующие вопросы [81]:

- Что вы на самом деле собираетесь создать?

- Как вы собираетесь это сделать?

- Какую технологию вы собираетесь использовать?

Решая эти вопросы необходимо учитывать проблемы, которые могут быть присущи данному проекту. По мнению, например М. Фаулера, существуют четыре категорий проблем, которые он называет «рисками проекта»:

- Риски, связанные с требованиями. Самая большая опасность заключается в том, что построенная система не будет удовлетворять требованиям пользователей. Во время фазы исследования необходимо как следует разобраться с требованиями и их относительными приоритетами.

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

- Риски, связанные с квалификацией персонала. Имеются ли сотрудники с необходимым опытом и квалификацией?

- Политические риски. Существуют ли силы, которые могут оказаться на вашем пути и серьезно повлиять на проект?

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

Варианты использования не рекомендуется [81] чересчур детализировать, вполне достаточно текстового описания размером от одного до трех абзацев. Текст должен быть достаточно содержательным и для пользователей, чтобы они поняли основную идею, и для разработчиков, чтобы они хорошо представляли, что скрывается за этим описанием.

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

Модель предметной области строится, как правило, до определения любого варианта использования; ее назначение – исследование лексики предметной области в терминах, имеющих значение и смысл для экспертов (заказчиков). Модели предметной области и варианты использования охватывают функциональные требования к системе.

Команда, занимающаяся моделированием предметной области, должна представлять собой небольшую группу (от двух до четырех человек), в состав которой входят разработчики и эксперты предметной области. Минимально жизнеспособная команда – это один разработчик и один эксперт. Эксперт предметной области (и, желательно, разработчик тоже) должен пройти обучение использованию соответствующих диаграмм UML для концептуального моделирования [81].

Моделирование предметной области является весьма важным дополнением вариантов использования. Для выявления и описания вариантов использования модель предметной области следует показывать эксперту и определять по его реакции правильность сложившегося представления о бизнес-процессах. Для построения моделей предметной области наиболее важными являются следующие два инструмента UML [81]:

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

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

Не рекомендуется слишком заботиться о строгости и пытаться зафиксировать каждую деталь. При этом может быть построено множество несвязанных диаграмм. Тем не менее, такой процесс достаточно быстро приводит к пониманию проблемы. Благодаря этому пониманию можно легко идентифицировать варианты использования для различных пользователей. После этого с помощью одного или двух экспертов следует объединить различные диаграммы в единую согласованную модель предметной области, которая будет удовлетворять всем требованиям, зафиксированным в более ранних разрозненных моделях. Эта модель может затем использоваться в качестве отправной точки для построения классов и более тщательного проектирования классов в фазе построения. Если эта модель велика, то, используя пакеты (packages), ее можно разделить на составные части.

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

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

Чтобы лучше понять требования к системе, рекомендуется построить прототип любых более или менее сложных вариантов использования. Прототипирование – это хороший способ для достижения наилучшего понимания динамики функционирования системы. Для выделения частей системы, которые нуждаются в прототипировании, используют модель предметной области.

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

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

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

Можно достаточно хорошо разбираться в C++ и в реляционных базах данных, однако применение одновременно того и другого может оказаться не таким уж простым делом. Именно поэтому рекомендуется на ранней стадии процесса создания системы совместно испытать все средства, которые будут использоваться в дальнейшем.

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

- Что случится, если какие-то технологические элементы не будут работать?

- Что, если не удастся соединить между собой два фрагмента мозаики?

- Какова вероятность возникновения незапланированных трудностей? Если они все-таки возникнут, каким образом мы могли бы с ними справиться?

Как и модель предметной области, необходимо внимательно анализировать варианты использования по мере их появления, чтобы оценить, нет ли в них чего-либо, что может привести в негодность разрабатываемый проект.

Простейшим способом, позволяющим устранить риски, связанные с квалификацией персонала, является обучение. Тем не менее, самой распространенной ошибкой при выполнении объектно-ориентированной разработки по мнению, М. Фаулера, является недостаточное внимание, уделяемое обучению.

Обучение – это способ избежать ошибок, поскольку учителя их уже сделали. Ошибки отнимают время, а время стоит денег. Таким образом, не обучившись, вы понесете те же расходы, только проектирование при этом продлится дольше, чем нужно. При этом необходимо иметь в виду, что небольшой формальный курс обучения может быть полезным, но это всего лишь начало. Он даст общее представление о том, что необходимо знать, но не может дать квалификации, необходимой для выполнения серьезных проектов [81].

Если планируется пройти небольшой курс обучения, рекомендуется уделить серьезное внимание выбору преподавателя. Рекомендуется потратить больше денег на преподавателя, который способен доходчиво донести свои знания до слушателей и, таким образом, обеспечить хорошее понимание процесса. Кроме того, курсы следует проводить именно по тем проблемам, которыми вы в настоящее время занимаетесь. Если вы не примените свои знания на практике сразу после окончания курса, то скоро все забудете.

Для приобретения практических навыков применения объектно-ориентированного подхода рекомендуется воспользоваться помощью опытного наставника, под руководством которого команда будете работать над проектом в течение достаточного периода времени. Такой наставник покажет, как делаются те или иные вещи, будет наблюдать за тем, что делается, и давать по ходу дела полезные советы и рекомендации. Наставник вникает в специфику проекта и знает, какие навыки и когда лучше использовать. На ранних стадиях проекта он является одним из участников команды разработчиков, помогая принимать правильные решения. Со временем команда приобретает необходимый опыт, и наставник станет скорее наблюдать, чем делать что-либо. Рекомендуется найти такого наставника, который не только сам обладает знаниями, но и может передать их другим. Выбор хорошего наставника может оказаться самым важным фактором успеха проекта; не рекомендуется экономить на качестве.

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

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

Одним из самых важных результатов фазы исследования является базовая архитектура разрабатываемой системы. Эта архитектура включает:

- перечень вариантов использования, определяющих требования к системе;

- модель предметной области, которая отражает понимание бизнеса разработчиком и служит отправным пунктом для формирования основных классов предметной области;

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

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

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

- Пользователи должны указать уровень приоритетности для каждого варианта использования. Три уровня: «Эта функция абсолютно необходима для любой реальной системы»; «Какое-то небольшое время я смогу прожить без этой функции»; «Эта функция важна, но пока я могу обойтись и без нее».

- Разработчики должны принимать во внимание «архитектурный» риск, связанный с каждым вариантом использования, который заключается в следующем: если реализацию данного варианта использования отложить на слишком долгое время, то вся выполненная до этого работа может потребовать значительной переделки. Три категории оценки: а) высокая степень риска, б) возможно, но маловероятно и в) маленький риск.

- Разработчики должны оценить степень своей уверенности относительно объема работы, требуемого для реализации каждого варианта использования. Это называется риском планирования. Три уровня: «Я абсолютно уверен в том, сколько времени потребуется на реализацию»; «Я могу оценить время только с точностью до человеко-месяца»; «У меня нет никаких соображений по этому поводу».

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

Оценку должны выполнять разработчики, а не менеджеры. При этом, разумеется, нужно быть уверенным, что разработчик, оценивающий данный вариант использования, разбирается в этом наилучшим образом [81].

После выполнения таких оценок рекомендуется выделить те варианты использования, которые обладают высоким риском планирования. Если с этими вариантами связана большая часть проектного времени или высокая степень «архитектурного» риска, то необходимо выполнить дальнейшее исследование.

Следующий шаг заключается в определении длительности итерации. Рекомендуется, чтобы длина итерации была фиксированной на протяжении всего проекта, тогда можно будет получать результаты с заданной регулярностью. Итерация должна быть достаточно длительной для того, чтобы успеть реализовать некоторое количество вариантов использования. В частности, при применении C++ – от шести до восьми недель.

Теперь рекомендуется рассмотреть трудоемкость каждой итерации. Например, эффективность работы разработчиков составляет в среднем 50%, т.е. на реализацию вариантов использования они расходуют половину своего рабочего времени. Следует умножить длительность итерации на количество разработчиков и на 0,5. В результате получится трудоемкость каждой итерации. Например, если имеется восемь разработчиков и продолжительность итерации составляет три недели, то на каждую итерацию потребуется 12 человеко-недель (8х3х0,5).

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

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

На внедрение (тонкую настройку и компоновку конечного продукта) рекомендуется отвести от 10% до 35% времени построения. (Если нет опыта выполнения этих операций в данной среде, то времени отводится еще больше.)

Затем рекомендуется добавить фактор случайности – от 10% до 20% времени построения, в зависимости от степени риска. Воздействие этого фактора обычно ощущается в конце фазы внедрения. Для разработчиков выход конечного продукта планируется без учета этой случайности, однако внешний план для пользователей должен ее учитывать.

После выполнения всех перечисленных рекомендаций будет создан план, в котором для каждой итерации указаны реализуемые варианты использования. Этот план отражает согласованное мнение разработчиков и пользователей, его вполне можно назвать согласованным планом. Такой план не является чем-то застывшим – разумеется, вполне возможно, что по ходу проекта он будет изменяться. Однако поскольку этот план согласованный, постольку изменения в него должны вноситься совместно разработчиками и пользователями.

Итак, как можно видеть из предыдущего обсуждения, варианты использования служат основой для планирования проекта, и именно поэтому в UML им уделяется такое серьезное внимание.

Основными признаками завершения фазы уточнения являются два события:

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

- Идентифицированы все наиболее серьезные риски, и самые важные из них осознаны настолько, что известно, как с ними справиться.

Важнейшие цели:

- Гарантировать устойчивость (стабильность) требований, архитектуры и планов.

- Смягчить риски.

- Создать прототип.

- Обосновать соответствие архитектуры требованиям и трудоемкость (стоимость, сроки) разработки.

- Обеспечить инфраструктуру (рабочую среду) проекта.

Важнейшие действия:

- Определение и согласование архитектуры ПО и планов на фазу построения.

- Доработка документа «Vision» (см. в конце данного пункта).

- Создание инфраструктуры (рабочей среды) проекта.

- Отбор готовых компонентов для повторного использования.

Построение (Construction)

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

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

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

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

Рекомендуется очень серьезно относиться к тестированию. Объем написанного разработчиком кода тестов должен быть по меньшей мере равен объему кода самого программного продукта. Тестирование должно быть непрерывным процессом. Не рекомендуется писать программный код до тех пор, пока не известно, как его тестировать. Как только написан код, сразу же пишите для него тесты. Пока все тесты не отработают, нельзя утверждать, что написание кода завершено [81].

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

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

Итерации на стадии конструирования являются одновременно инкрементными (наращиваемыми) и повторяющимися.

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

- Они являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода заново переписывается с целью сделать его более гибким. В этом процессе очень часто используется метод реорганизации (см. далее). Рекомендуется внимательно наблюдать за тем, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение.

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

В рамках каждой итерации рекомендуется заниматься более детальным планированием. Самой важной частью любого плана являются меры, которые нужно предпринимать, если что-то происходит не так, как было запланировано. Главная особенность итеративной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализации каких-либо вариантов использования на более позднюю итерацию по соглашению с заказчиком. Смысл таких ограничений – поддерживать строгую дисциплину разработки и не допускать переноса сроков. Если, например, слишком много вариантов использования перенесено на более поздний срок, то пора корректировать план, пересмотрев при этом оценку трудоемкости реализации вариантов использования. На этой стадии разработчики должны иметь более глубокое представление о такой оценке.

На стадии построения полезными являются все методы UML.

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

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

Диаграммы взаимодействия полезны для представления взаимодействия классов, в котором выражается реализация варианта использования. Если поведение класса в течение его жизненного цикла достаточно сложно описать, рекомендуется использовать диаграмму состояния.

Рекомендуется ограничить документацию теми случаями, когда она действительно помогает. Если обнаруживается, что от документации нет никакого толку, это верный признак, что что-то идет не так. Документация в нормальном случае должна содержать три основных элемента:

- одну или две страницы с описанием нескольких классов, присутствующих на диаграмме классов;

- несколько диаграмм взаимодействия, показывающих, как классы взаимодействуют между собой;

- небольшое текстовое описание, связывающее диаграммы воедино.

Важнейшие цели:

- Завершить анализ, проектирование, кодирование и тестирование всех вариантов использования (функциональных возможностей).

- Создать готовый к использованию продукт.

- Добиться надлежащего качества и полезности версий.

- Оценить готовность к развертыванию.

- Уменьшить затраты на разработку, оптимизируя продукт и используемые ресурсы.

Важнейшие действия:

- Управление ресурсами.

- Контроль качества и оптимизация.

- Разработка компонент, автономное тестирование.

- Интеграция и системное тестирование.

- Определение готовности ПО с учетом критериев его приемки.

Внедрение (Transition)

На стадии внедрения продукт не дополняется никакой новой функциональностью (кроме, разве что, самой минимальной и абсолютно необходимой). Здесь только исправляют ошибки, настраивают систему и передают ее пользователю. Хорошим примером для фазы внедрения может служить период времени между выпуском бета-версии и появлением окончательной версии продукта.

Важнейшие цели:

- Отрекламировать и сбыть продукт.

- Завершить бета-тестирование.

- Согласовать разработанный продукт с унаследованным ПО.

- Адаптировать базы данных и знаний.

- Обучить пользователей.

- Повысить работоспособность.

- Поддержать пользователей.

Важнейшие действия:

- Выполнение плана развертывания.

- Тестирование поставляемого продукта.

- Настройка поставляемого продукта.

- Сопровождение продукта у пользователя.

- Обеспечение обратной связи с пользователем.

- Обеспечение доступности продукта для пользователей.

Дата добавления: 2014-12-27