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

0

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

Цель

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

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

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

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

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

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

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

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

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

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

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

•        

Модель проектирования

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

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

Модель анализа

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

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

Роль интерфейсов

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

Артефакты систем реального времени

Системы реального времени — это системы с требованиями своевременности или быстроты реагирования и (часто) жесткими ограничениями на максимальное время отклика. Такие системы находят применение в приложениях с жесткими требованиями к безопасности. Rational Unified Process описывает следующие дополнительные артефакты, удовлетворяющие требования разработки таких систем.

 

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

•       Протокол. Определяет способы сообщения портов, обмена сообщениями и упо
рядочения сообщений.

•       Событие. Это описание происшедшего в пространстве и времени или, менее
формально, появление чего-то, на что должна отреагировать система.

•       Сигнал. Это асинхронное событие, которое может вызвать смену состояний
конечного автомата или объекта.

Эти дополнительные артефакты являются стереотипами класса и частью модели проектирования. Они поддерживают подход к разработке систем реального времени, основанный на идеях, представленных в работе Real-Time Object-Oriented Modeling.

Модульное проектирование

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

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

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

Технологический процесс

На рис. 10.2 в форме диаграммы видов деятельности (как она определена в языке UML) показана отдельная итерация процесса анализа и проектирования. Каждый вид деятельности представляет элемент технологического процесса Rational Unified Process, например определение потенциальной архитектуры. В свою очередь, каждый элемент технологического процесса состоит из одного или нескольких видов деятельности. Некоторые элементы процесса зависят от фазы разработки: в итерациях фазы уточнения плана архитектура определяется и затем уточняется, после чего анализируются и проектируются более важные или рискованные области приложения.

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

1 Bran Selic, Garth Gullekson and Paul T. Ward. Real-Time Object-Oriented Modeling. New York: John Wiley & Sons, 1994.

Глава 10.           155

Элементы технологического процесса

Определение потенциальной архитектуры

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

•    Создать эскиз архитектуры системы путем определения:

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

-        первоначального набора механизмов анализа;

—  первоначального разбиения на уровни;

-     структуры системы;

—  реализаций прецедентов, которые будут произведены в текущей итерации.

•       Из архитектурно значимых прецедентов определить классы анализа.

•       Дополнить реализации прецедентов взаимодействиями классов анализа.
Уточнение архитектуры

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

•     Обеспечить естественный переход от действий, связанных с анализом, к дейст
виям, связанным с проектированием, определяя при этом

—  из элементов анализа — подходящие элементы проекта;

-     из механизмов анализа — подходящие механизмы проекта.

•     Поддержать непротиворечивость и целостность архитектуры, обеспечивая

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

—  максимальное повторное использование доступных компонентов и элемен
тов проекта.

•       Описать структуру рабочего цикла системы и архитектуры распространения.

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

Анализ поведения

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

 

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

Проектирование компонентов

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

•       Уточнить определение элементов проекта путем подробного описания того, I
как эти элементы реализовывают требуемое от них поведение.

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

•       Рецензировать проект по мере его развития.

В компонентах проекта полностью определяются характеристики и отношения I классов, интерфейсы подсистем и их реализации классами-контейнерами, а также I реализации прецедентов в терминах взаимодействий.

Проектирование компонентов реального времени

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

Проектирование базы данных

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

•       Определить постоянно хранимые классы.

•       Спроектировать структуру базы данных, подходящую для хранения постоянно
хранимых классов.

•       Определить механизмы и стратегии хранения и извлечения постоянно храни
мых данных, удовлетворяющие критериям производительности системы.

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

 

Инструментальная поддержка

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

Rational Unified Process предлагает инструментальные наставники, направляющие разработчиков, использующих UML и Rose. Средство Rose RealTime допускает прямую реализацию модели проектирования. SoDA позволяет автоматически создавать документы и отчеты, извлекая информацию из нескольких инструментальных средств, таких как Rose или RequisitePro, и форматируя ее.

Резюме

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

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

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

•       В некоторых случаях отдельная модель анализа может использоваться для
обзора или обобщения системы.

 

По теме:

  • Комментарии