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

Определение модели

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

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

Что такое фасад?

Фасад в данном контексте не является объектно-ориентированным методом программирования. Этот элемент можно назвать ограниченным прототипом или креативной экспериментальной моделью с небольшой степенью реальности. Определение фасада позволяет владельцу представить себе программное решение перед получением окончательного продукта. Фасад демонстрирует программное решение в действии в окне браузера.

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

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

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

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

Совместные усилия по программированию правил функционирования, сценариев и источников данных приводят к созданию документов XML, необходимых логике представления для получения конечного результата. Перед построением источников данных или программы разработчик создает техническую спецификацию, устанавливающую метод, согласно которому функционируют данные элементы, включая создаваемый код XML. Это означает, что код XML моделируется перед построением программы. Следует проверить модель XML перед построением источника данных или программы, применяющей правила функционирования. Необходимо написать файлы сценариев, используемые для применения логики представления, и это можно сделать перед созданием программы поддержки (или после). При изменении требований корректировка файла сценария логики представления потребует меньших усилий, чем изменение скомпилированного кода бизнес-объекта. Если логика представления оформлена в виде XSL, XSLT или другой технологии представления (например, веб-форм ASP.NET), то для тестирования файла сценария логики представления используются статические документы XML.

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

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

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

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