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

Разработка фасада

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

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

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

• Одна или несколько спецификаций XML "крайнего случая" для каждого окна, определенного в функциональной спецификации.
• Код логики представления для каждого окна функциональной спецификации.

Разработчик пользовательского интерфейса выполняет большую часть работы, напрямую связанную с этим этапом, создавая требуемый пользовательский интерфейс, указанный в функциональной спецификации. На данном этапе бизнес-аналитик выполняет минимальный объем работы. Роль аналитика заключается в уточнении спецификации и ее проверке. Разработчик объектов проверяет существующее решение на наличие источников XML, несущих в себе объекты или данные, определяемые как содержимое документа XML "крайнего случая". В этот поиск можно включить классы .NET Framework, если технология .NET Framework входит в программное решение. Если разработчик пользовательского интерфейса хорошо знаком с результирующими XML, то можно начать создание основного кодf или провести анализ выполняемости компонентов нового решения.

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

Представление фасадной части

Представление фасада разработчику требует возможности отображения окна в браузере. Microsoft Internet Explorer версии 5.5 и выше преобразует XML в HTML при помощи XSL и XSLT. IE является самой подходящей платформой для представления фасадной части на компьютере с любой версией операционной системы Windows. Представление фасадной части происходит обычно на рабочем месте владельца, где возможно отсутствие связи интернетом. Фасадную часть можно установить на сервере, преобразующим XML и XSL/XSLT, однако использование браузера для выполнения преобразования всегда позволит просмотреть результат работы.

Для осуществления преобразования XML в HTML с помощью XSL или XSLT в IE добавьте инструкцию обработки (см. листинг 6.1) над остальным кодом XML. Документ XML, содержащий инструкцию обработки, будет преобразован с помощью таблицы XSL с именем MyXSLSheet.xsl. При поступлении документа XML от веб-сервера указанная таблица XSL должна поступать оттуда же. В листинге 6.1 показано, что файл MyXSLSheet.xsl располагается в том же каталоге, что и сам файл XML.

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="MyXSLSheet.xsl" ?>

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

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

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

Зачем создается фасадная часть

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

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

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

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

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