Реинжиниринг программного обеспечения (стр. 4 из 7)
Документ «Архитектура ПС», в котором собраны различные архитектурные представления ПС.
Модель данных – это описание структуры данных, хранимых в БД (например, реляционная модель данных).
Технологический процесс
Упрощенная схема деятельностей, выполняемых в отдельной итерации процесса анализа и проектирования, приведена на рис.2. Выполнение некоторых деятельностей зависит от фазы разработки, что показано в виде комментариев на диаграмме деятельностей.
Рис.2 Диаграмма деятельностей, описывающая процесс анализа и проектирования
Определение потенциальной архитектуры. Данная деятельность включает архитектурный анализ и анализ ВИ. Определяется первоначальный набор архитектурно значимых элементов и механизмов реализации, выполняется начальное разбиение на уровни, определяется структура системы, выбираются ВИ, которые будут реализовываться в первой итерации фазы развития проекта. В результате создается эскиз архитектуры ПС. На основе анализа архитектурно значимых ВИ определяются основные классы, которые включаются в модель анализа. В модель анализа включаются диаграммы, описывающие взаимодействие основных классов.
Уточнение архитектуры. Деятельность включает определение механизмов проектирования, элементов проекта, объединения существующих элементов проекта, описание архитектуры реального времени (если проектируемая ПС относится к этому классу). В результате выполнения этих работ достигаются следующие цели:
· Обеспечивается переход от анализа к проектированию путем определения из элементов и механизмов анализа элементов и механизмов проектирования;
· Поддерживается целостность и непротиворечивость архитектуры путем интеграции новых элементов проекта, определяемых в текущей итерации, с уже существующими и повторного использования доступных элементов проекта.
· Осуществляется плавный переход от проектирования к реализации;
Анализ поведения. Эта деятельность включает анализ ВИ, определение элементов проекта и обзор проекта. Эта деятельность имеет целью преобразование описаний поведения в виде ВИ в набор элементов проекта (классы, отношения, операции и др.).
Проектирование компонентов. Цели данной деятельности состоят в:
· Определении и уточнении элементов проекта путем подробного описания того, как эти элементы реализуют требуемое поведение.
· Определении и уточнении реализации ВИ на основе новых элементов проекта.
· Контроле и рецензировании проекта по мере его развития.
Проектируются ВИ, подсистемы, классы и компоненты ПС. Точно описываются интерфейсы компонентов и их реализация.
Проектирование БД. Данная деятельность выполняется для проектов, использующих базы данных. Она включает:
· Определение персистентных (постоянно хранимых) классов;
· Проектирование структуры БД для хранения таких классов;
· Определение механизмов и стратегий хранения и доступа к хранимым данным, удовлетворяющих требованиям к производительности и надежности ПС.
Анализ и проектирование связывает управление требованиями и реализацию. В этом технологическом процессе создается модель проектирования. Одно из ее представлений – логическая модель – отражает декомпозицию ПС в набор логических элементов (классы, подсистемы, взаимодействия). Процедурное представление отображает эти элементы в процессы и подпроцессы системы. Представление развертывания отображает эти процессы в набор узлов вычислительного комплекса, на которых они выполняются.
Реализация
Цели процесса реализации
Основные цели процесса можно сформулировать следующим образом:
· Определить структуру кода в виде уровней;
· Реализовать компоненты, классы и объекты;
· Провести блочное тестирование компонент;
· Интегрировать разработки, выполненные отдельными разработчиками, в единую исполняемую систему.
В процесс реализации не включено тестирование всей ПС, для которого в RUP предусмотрен отдельный процесс (см. следующую статью).
Особенности процесса реализации
RUP предполагает поэлементную интеграцию в течение всего жизненного цикла. Это означает, что коды пишутся небольшими блоками, после чего они объединяются в единое целое путем постепенного добавления блоков. Это упрощает процесс локализации ошибок. Предусмотрено два уровня интеграции – интеграция результатов работы группы разработчиков в подсистему и интеграция подсистем в ПС. Интеграция происходит в каждой итерации в соответствии с планом итерации, где определены ВИ, которые проектируются и реализуются в этой итерации. Таким образом, план итерации определяет классы, которые будут реализованы в этой итерации.
В фазе конструирования создается эволюционный прототип системы, который со временем развивается в конечную ПС. Это прототип используется для демонстрации фрагментов ПС заказчику и руководству. По результатам представления прототипа можно получить замечания, которые позволяют уточнить, изменить или дополнить требования к ПС. RUP декларирует возможность создания, помимо эволюционных, поведенческих одноразовых прототипов для проведения определенных исследований, касающихся функциональных возможностей системы.
В RUP декларируется необходимость соответствия модели и программного кода. При этом допускается возможность изменения кода с последующей переработкой модели, которая обеспечивала бы требуемое соответствие. Для этой цели используют инструментальные средства, включающие возможности автоматического реинжиниринга Методика реинжиниринга представлена в статье «Реинжиниринг программных систем».
Роли
Конструктор (кодировщик) разрабатывает компоненты и классы, выполняет блочное тестирование.
Системный интегратор выполняет интеграцию элементов в программные конструкции (систему и подсистемы).
Архитектор определяет структуру реализации (организацию уровней и подсистем).
Рецензент кода проверяет качество программного кода и его соответствие стандартам проекта.
Артефакты
Подсистема реализации - это набор компонент и других подсистем реализации, используемых для образования модели реализации. Это понятие позволяет иерархически представить модель реализации.
Компонент часть программного кода (см. статью «Компонентно-базированная разработка»).
План интеграции документ, определяющий порядок реализации компонентов и подсистем.
Процесс
Создание модели реализации. Эта деятельность выполняется в фазе развития. Целью ее является построение модели реализации, которая позволит наилучшим образом выполнить разработку и кодирование. При этом конечный продукт будет создаваться посредством последовательно укрупняющихся прототипов.
Планирование итерации. Для каждой итерации надо определить, какие подсистемы должны быть реализованы в этой итерации и порядок их интегрирования. За какую подсистему отвечает конкретный конструктор, определяющий порядок реализации классов.
Реализация компонентов. Выполняется написание исходных кодов программ, их компиляция, формирование исполняемого кода и блочное тестирование. Блочное тестирование выполняет сам кодировщик. Это, по сути, автономная отладка разработанных программ. При обнаружении ошибок в исходный код вносятся изменения, после чего указанные действия повторяются. После завершения блочного тестирования проверяется качество исходного кода и его соответствие принятым стандартам проекта.
Интеграция подсистем. Если подсистема разрабатывается группой исполнителей, выполняется интеграция компонентов, разработанных всеми членами группы. Интеграция подсистемы завершается созданием набора программных конструкций подсистемы, каждая из которых тестируется по отдельности.
Интеграция системы. Выполняется интеграция системы путем последовательного добавления в нее новых подсистем, созданных в рамках текущей итерации. Интеграция подсистемы завершается созданием набора программных конструкций подсистемы, каждая из которых тестируется по отдельности. Для тестирования системы в RUP предусмотрен отдельный процесс.
Тестирование – это процесс, позволяющий оценить качество производимого продукта. Качественный программный продукт должен отвечать предъявляемым к нему требованиям как функциональным, так и нефункциональным. ПС должна реализовывать все требуемые ВИ и не иметь дефектов – отличий реально существующих свойств или поведения от требуемых. Кроме того, ПС должна обладать свойствами надежности (должны отсутствовать зависания, аварийные отказы и пр.), безопасности, обеспечивать нужную производительность, быть удобной в эксплуатации, расширяемой и т. д. Таким образом, тестирование представляет собой процесс анализа ПС, направленный на выявление дефектов и на оценку свойств ПC.
Цели процесса тестирования
Целью тестирования является оценка качества программного продукта путем
· Проверки взаимодействия компонентов;
· Проверки правильности интеграции компонентов;
· Проверки точности реализации всех требований и выявления дефектов.
Особенности процесса тестирования в RUP
Тестирование – это итеративный процесс, выполняемый во всех фазах жизненного цикла. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. На каждую итерацию определяется цель тестирования и методы ее достижения. В конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, не следует ли изменить принципы и инструменты тестирования.
Каждый найденный дефект регистрируется в базе данных проекта с описанием ситуации, в которой он найден. Аналитик определяет, действительно ли это дефект и не является ли он повтором обнаруженного ранее дефекта. Найденному дефекту присваивается приоритет, определяющий важность исправления. Конструктор, ответственный за разработку подсистемы, компоненты или класса, или другой исполнитель, назначенный руководителем, приступает к устранению дефекта. Порядок исправления дефектов регулируется их приоритетами. Тестировщик повторяет выполнение тестов и убеждается (или не убеждается) в устранении дефекта.