Процесс разработки программы и методология построения приложений для интернета

Создание технической спецификации

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

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

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

При построении технической спецификации следует руководствоваться той же стратегией нумерации, что и в функциональной спецификации (см. рис. 6.4) Лицевая страница технической спецификации во многом похожа на титульную страницу функциональной спецификации.

Шаблон технической спецификации

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

Введение

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

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

Объектная модель

• Результаты работы над фасадной частью.

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

Диаграмма классов

• Описание назначения каждого класса.M
• Взаимоотношения с другими классами (наследование, композиция и накопление).
• Функции в объекте (предназначение, описание интерфейса, параметры, типы данных).
• Параметры состояния инициализации, применяемые к решению и связанным с ним объектам.
• Псевдокод функций.

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

Диаграмма данных

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

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

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

• Описание тестовой структуры решения.
• Данные "крайнего случая", используемые при модульном тестировании кода.

В данном разделе приводится описание возможностей программного решения, если оно создано правильно. Здесь можно привести тест или набор тестов, которые нужно создать для проверки программного решения и заключения о правильности функционирования решения в процессе тестирования. В данном разделе необходимо описать данные, обеспечивающие условия "крайнего случая" для модульного тестирования. "Крайний случай" обычно представляет собой обработку строк, содержащих специальные символы, таких как ~ ` ! @ # $ % ^ & * ( ) _ + - { } [ ] \ | ; : ' " < > ? / .,.

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

Реализация

• Диаграмма реализации.
• Описание данных на узле (библиотеки, версии).
• Сценарий реализации (необходимые шаги, порядок выполнения, конфигурация узла).
• Подтверждение успешного проведения реализации.
• Шаги по деинсталляции.

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

Сценарии функционального тестирования

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

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

• Запись контроля изменений.
• Титульная страница с именем владельца и названием проекта.
• Нижний колонтитул с названием компании, сведениями о конфиденциальности документа и датой его печати.

Сценарий тестирования оформляется в виде таблицы со следующими полями.

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