24. Технологический процесс анализа и проектирования

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

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

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

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

Насколько стоит продумывать проект

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

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

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

Если степень полноты и точности проекта довольно высока — настолько, что ука­занное преобразование можно выполнять путем непосредственной интерпретации проекта или быстрого создания из проекта небольшого фрагмента кода,— то преоб­разование практически незаметно для разработчика, а проект можно считать "инструкцией к действию".

Исполнители и артефакты

• Архитектор Архитектор координирует технические виды деятельности и артефакты и руководит ими. Он определяет общую структуру каждого архитектурного пред­ставления: декомпозицию представления, группировку элементов и интерфей­сы между основными группами. В отличие от других исполнителей, архитектор скорее должен в общем представлять себе весь процесс, чем интенсивно участвовать в какой-то его части. Подробнее об этом в главе 5, "Процесс, осно­ванный на архитектуре".

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

В процессе анализа и проектирования могут участвовать и другие исполнители.

• Разработчик базы данных. Данный исполнитель необходим при наличии в разрабатываемой системе базы данных.

• Разработчик оболочки (для систем реального времени). Этот исполнитель отвечает за возможность системы своевременно реагировать на события. Для обеспечения этого используются методы параллельного проектирования.

• Рецензент архитектуры и рецензент проекта. Эти специалисты рецензируют ключевые артефакты, создаваемые в данном технологическом процессе.

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

• Модель проектирования — основной чертеж разрабатываемой системы

• Документ архитектуры программного обеспечения, в котором собраны различные архитектурные представления системы

• Процесс анализа и проектирования заполняет брешь между процессами управления требованиями и реализации. Этот процесс использует прецеденты для определения набора объектов, которые последовательно превращаются в классы, подсистемы и пакеты.

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

• В процессе анализа и проектирования создается модель проектирования, которую можно обобщить с использованием трех архитектурных представле­ний. Логическое представление отражает декомпозицию системы в набор логических элементов (классов, подсистем, пакетов и взаимодействий). Процедурное представление отображает эти элементы в процессы и подпроцессы (потоки) системы. Представление распространения отображает эти процессы в набор узлов, на которых они выполняются.