Проектирование базы данных
Этот элемент технологического процесса является необязательным и используется только в том случае, если система включает значительный объем информации, помещенной в базу данных. Он состоит из следующих видов деятельности: проектирования базы данных, выполняемого разработчиком базы данных, проектирования класса, производимого разработчиком, и обзора проекта, выполняемого рецензентом проекта. Целью этого элемента является следующее. ■ Определить постоянно хранимые классы. ■ Спроектировать структуру базы данных, подходящую для хранения постоянно хранимых классов. ■ Определить механизмы и стратегии хранения и извлечения постоянно хранимых данных, удовлетворяющие критериям производительности системы. ВЫВОД: ■ Процесс анализа и проектирования заполняет брешь между процессами управления требованиями и реализации. Этот процесс использует прецеденты для определения набора объектов, которые последовательно превращаются в классы, подсистемы и пакеты. ■ Основные обязанности процесса анализа и проектирования ложатся на плечи архитектора (общие вопросы), разработчика (подробности) и разработчика базы данных (подробности, требующие специальных знаний по обработке постоянно хранимых объектов). ■ В процессе анализа и проектирования создается модель проектирования, которую можно обобщить с использованием трех архитектурных представлений. Логическое представление отражает декомпозицию системы в набор логических элементов (классов, подсистем, пакетов и взаимодействий). Процедурное представление отображает эти элементы в процессы и подпроцессы (потоки) системы. Представление распространения отображает эти процессы в набор узлов, на которых они выполняются. ■ В некоторых случаях отдельная модель анализа может использоваться для обзора или обобщения системы.
50. Технологический процесс реализации. Технологический процесс— это последовательность видов деятельности, дающих результат с очевидным значением. Существует четыре основные цели технологического процесса реализации. ■ Определить структуру кода через подсистемы реализации, организованные в уровни. ■ Реализовать классы и объекты через компоненты (исходные файлы, двоичные коды, исполняемые файлы и др.). ■ Провести блочное тестирование разработанных компонентов. ■ Интегрировать результаты отдельных конструкторов или команд в исполняемую систему. Основная работа по образованию структуры модели реализации выполняется на ранних этапах фазы уточнения плана. Целью этого вида деятельности является организация модели реализации, позволяющая максимально бесконфликтно выполнить разработку компонентов и процесс построения. Качественная модель предупредит возникновение проблем, связанных с управлением конфигурацией, и позволит создать продукт посредством последовательно укрупняющихся интеграционных конструкций. При каждой итерации необходимо обратить внимание на следующие моменты. ■ Необходимо запланировать, какие подсистемы должны быть реализованы, и определить порядок интеграции подсистем для текущей итерации. Все это выполняется при планировании итерации. ■ За каждую подсистему должен отвечать определенный конструктор, планирующий интеграцию этой подсистемы, т.е. определяющий порядок реализации классов. ■ Конструкторы также корректируют дефекты кода и выполняют блочное тестирование для проверки внесенных изменений. После этого код рецензируется — проверяется его качество и соответствие программным директивам. ■ Если несколько конструкторов (команда) работают над одной подсистемой реализации, то один из них должен отвечать за интеграцию в новую версию подсистемы новых компонентов и компонентов, измененных другими членами команды. Интеграция завершается созданием набора конструкций. После этого каждая конструкция тестируется испытателем интеграции. Последняя версия подсистемы должна быть готова к интеграции в систему.
Применительно к некоторым языкам программирования, инструментальным средствам, таким как Rational Rose, а также к некоторым типам приложений возможно использование циклического проектирования, позволяющего тесно связать проектирование и реализацию. Сотрудник, попеременно действующий как разработчик и конструктор, может либо видоизменять модель проектирования и создавать соответствующий код, либо видоизменять код реализации с последующей переработкой проекта, чтобы он соответствовал внесенному изменению. Такой подход позволяет избежать задержек в процессе производства и ошибок, возникающих при реализации проекта или потере синхронности между проектом и его реализацией (что, как правило, приводит к недоверию конструкторов к проекту). ВЫВОД: ■ Характерной особенностью Rational Unified Process является поэлементная интеграция в течение всего жизненного цикла. ■ В фазе построения создается эволюционный структурный прототип, со временем развивающийся в конечную систему. ■ Параллельно создается несколько одноразовых поведенческих прототипов для проведения определенных исследований (например, пользовательского интерфейса). ■ Циклическое проектирование – это технология, поддерживаемая таким инструментальным средством, как Rational Rose; она тесно связывает процессы проектирования и реализации.
51. Технологический процесс тестирования. Технологический процесс— это последовательность видов деятельности, дающих результат с очевидным значением. Целью тестирования является оценка качества продукта. Под этим подразумевается не только оценка окончательного продукта, но и оценка архитектуры с ранних этапов процесса и вплоть до окончательной передачи продукта заказчикам. Технологический процесс тестирования включает следующее. ■ Проверку взаимодействий компонентов ■ Проверку правильности интеграции компонентов ■ Проверку точности реализации всех требований ■ Выявление дефектов и принятие мер, необходимых для их устранения до развертывания программного обеспечения Типичный технологический процесс тестирования, его основные элементы и зависимости между ними показаны на рис. 12.3.
Рис.12.3 Технологический процесс тестирования
|
