27.2. Разработка проектной документации
После создания документа со спецификациями требований необходимо принять решение о разработке проектной документации. В случаях, когда над небольшим проектом работают несколько разработчиков, это не обязательно. Но можно пойти по пути создания полного пакета проектных документов.
В первой части проекта должна описываться архитектура системы. Система разбивается на части, соответствующие функциональным группам. Web-приложение, предназначенное для управления проектами, может быть разбито на несколько модулей: модуль обработки проектной информации, модуль работы с пользователями и модуль обработки графиков выполнения работ. Информационный Web-узел может быть разбит на вторичные страницы, т.е. страницы, на которые можно перейти с помощью одного щелчка с главной страницы Web-узла. Так, раздел "О нас" может информировать посетителей о самой компании, в то время как "Каталог" - о товарах, продаваемых компанией. В зависимости от типа Web-узла необходимо выбрать такой тип диаграмм, который бы отображал подсистемы и их взаимосвязь. Такие диаграммы называются диаграммами "объекты-отношения". Нелишним будет создать схему последовательности страниц. Каждый узел в графе является страницей, которая появляется перед пользователем. Линии, отображающие связи, определяют связи страниц с другими страницами Web-узла. Полезной также представляется схема, отображающая связи между таблицами базы данных. Узлами в ней являются таблицы, кроме того, в квадратах, обозначающих таблицы, можно перечислить поля, входящие в состав таблиц. Таблицы соединяются линиями, отображая соответствие полей. Кроме того, очень полезно использовать свойства связи между таблицами "один к одному" или "один ко многим".
Следующая фаза проекта заключается в спецификации интерфейса. На этом этапе определяется взаимодействие подсистем. Достаточно представить перечень URL для каждой страницы. Если Web-узел имеет формы, то каждое поле должно быть пронумеровано. Если необходимо отслеживать сеансы пользователей, нужно определить, как это будет выполняться: с помощью файлов cookie или переменных. Определите приемлемые значения для идентификаторов сеансов. Если Web-узел будет обмениваться данными с файлами или базой данных, на этом этапе определяются имена файлов или информация о регистрации баз данных.
Самой большой частью проектного документа является детальное описание работы каждого модуля. В этом месте можно точно определить метод реализации модуля. Например, можно определить, что список товаров в каталоге представляется тегом ul, но, с другой стороны, это не существенно, поэтому это можно не детализировать. У программиста для решения этой проблемы могут быть идеи и получше.
Я предлагаю руководство по стилю, которое может быть составной частью проектного документа или быть совершенно отдельным документом. Этим документом определяется стиль программного кода проекта. Его пример вы найдете в приложении Ж, "Руководство по стилю написания PHP-сценариев". Но сейчас к нему обращаться не следует. Руководство по стилю посвящается, например, вопросам присвоения имен переменным и размещению квадратных скобок. Многие из этих проблем таковыми не являются, но очень важно, чтобы такое решение было принято и соблюдалось. Большой фрагмент кода проще воспринимается, если код отформатирован в соответствии с определенными стандартами.
Последующий материал этой главы излагается в соответствии с идеями проектирования, которые могут оказаться полезными и для читателя. Динамическая природа PHP позволяет применять структурированный подход к проектированию, который совершенно невозможен при работе с обычным HTML-кодом. И будет совершенно непростительно не использовать функциональные возможности PHP как более быструю альтернативу CGI-интерфейса. Хочется поддержать стремление читателя использовать PHP в качестве средства, которое позволит создать целиком динамические Web-узлы.