Проектирование документов

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

Документ (система документов) содержит "пустой" программный проект. В большинстве случаев такие документы создают конечные пользователи, которые могут не иметь понятия о программировании и вообще не знать, что существует возможность присоединения программного проекта к документам Office 2000. В этом весьма типичном случае каждый документ представляет стандартный, предоставляемый по умолчанию документ Office 2000, без всякой его дополнительной настройки.
Документ служит обложкой для программного проекта. Такие документы создаются программистами. Это тоже возможная ситуация, когда программист хочет написать свое типично программистское приложение. Ему не требуются возможности офисной среды, все, что ему нужно, - это привычный язык VBA. Он мог бы написать это приложение на VB или другом языке программирования, но предпочитает оставаться в офисной среде.

Основная цель этой лекции рассмотреть, как связаны между собой программные проекты системы документов, какова структура программного проекта одного документа, его основные компоненты.

Но прежде, чем приступить к реализации этой цели, хочется рассмотреть хотя бы обзорно, некоторые, более общие вопросы, связанные с проектами и документами. Прежде всего, заметим, что " документ документу рознь". Одно дело, когда речь идет о настройке стандартного документа, придания ему некоторых дополнительных функций, совсем другое дело - разработка большой и сложной системы, затрагивающей многие службы офиса или предприятия. Считается, что Office 2000 - это масштабируемая среда разработки.
Это означает, что она подходит для решения небольших, простых задач, так и для решения сложных задач. К простым задачам относится создание отдельных, возможно и сложных документов, создание сравнительно небольшой системы документов. Сложными задачами могут быть, например:

Разработка клиентской части "клиент - серверных" приложений, рассчитанных на работу большого числа пользователей с серьезной базой данных, такой как Microsoft SQL Server или Oracle. Заметим, что в Office Developer 2000 включены специальные средства разработки, облегчающие создание подобных приложений.
Разработка документов для совместного использования в Интернете. Во многом сложность этой задачи объясняется ее новизной. Опять - таки, в Office 2000 включены новые средства, облегчающие создание таких документов.
Разработка большой системы документов, обеспечивающей "полную" автоматизацию деятельности офиса.

Есть еще одно измерение в разработке документов Office 2000. Оно связано с разработкой документов специального вида. Сюда относится разработка: шаблонов, Мастеров (Wizards), компонент, расширяющих функциональные возможности других документов. Эти компоненты могут быть двух видов - AddIns и ComAddIns. Дадим краткую характеристику этим видам документов:

Шаблоны - это наиболее простой из специальных случаев. Шаблоны являются заготовками, на базе которых можно создать семейство близких документов. Шаблон задает общие свойства семейства и требуется лишь сравнительно небольшая настройка для получения конкретного документа. Как правило, рекомендуется создавать шаблоны и открывать документы на основе того или иного шаблона. Типичным и хорошо известным является шаблон Normal.dot, на базе которого открываются стандартные документы Word.
Мастера обеспечивают некоторый пошаговый процесс достижения цели. Они "ведут" пользователя шаг за шагом, пока конечная цель не будет достигнута. На каждом шаге, пользователь в процессе диалога с Мастером, задает информацию, необходимую для перехода к следующему шагу.

Как правило, "хороший" Мастер облегчает и контролирует ввод данных, предоставляет необходимые справки, позволяет провести откат к предыдущему шагу, отменив ранее сделанные установки. Мастера широко используются в Office 2000 для решения тех или иных частных задач. Это средство становится привычным для любых офисных приложений. Мастера, которые решают общие задачи и могут быть полезными в разных документах, оформляются как компоненты.
AddIns являются компонентами, специфическими для того или иного приложения Office 2000. Один AddIn может использоваться, например, только в документах Word, другой - в документах Excel.
Com AddIns - то компоненты, которые могут использоваться в разных приложениях. Достаточно, чтобы эти приложения допускали использование Com - объектов, построенных на основе Com - модели компонентного программирования. Com AddIns отличается от ActiveX объектов тем, что с программной точки зрения представляет DLL - динамически загружаемую библиотеку, в то время как ActiveX - это исполняемые файлы. Заметим, что ранее эти компоненты не могли быть созданы в офисной среде, необходимо было использовать для их создания VC++, VB или другие языки программирования, допускающие создание подобных компонент. Теперь и в Office 2000 Developer включены средства, допускающие их разработку.

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

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

Проектирование <=> Разработка <=> Отладка <=> Развертывание и Сопровождение <=> Модификация

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

Уделите проектированию самое пристальное внимание. Успех дела во многом определяется первым этапом. Нет смысла торопиться с переходом на последующие этапы, пока не составлены ясные и четкие спецификации. Ошибки этого этапа самые дорогие и плохо исправляемые. Для большого проекта, который ведет коллектив исполнителей, должны быть предусмотрены специальные средства ведения проекта.
Еще одно важное правило этапа проектирования. Помните о тех, для кого разрабатывается программный продукт. Идите "в люди", чтобы понять, что нужно делать. Даже студент, выполняющий учебную работу должен знать вкусы преподавателя, которому он собирается эту работу сдавать. Что уж говорить о серьезных проектах.
Не начинайте разработку "с нуля". Офисная среда в этом отношении уникальна, она предоставляет разработчику уже готовые каркасы документов, если хотите, в принудительном порядке. Кроме того, Вы легко можете использовать в новых разработках, как свой собственный инструментарий, так и средства специальных фирм, производящих в большом числе различные шаблоны, Мастеров, AddIns, DLL, ActiveX и Com AddIns компоненты. Работая над одним проектом, думайте о будущем, - создавайте компоненты, допускающие их использование в других проектах.
Следующий важный этап - это отладка. Человек (коллектив), занимающийся отладкой, это оппонент разработчика. Даже, если всю работу ведет один человек, на этапе отладки он должен стать другим, поменять цель, - стараться разрушить проект, найти ситуации, в которых проект ведет себя не так, как это предусмотрено замыслами разработчика. Помните, не бывает проектов без ошибок и каждая последняя найденная ошибка является предпоследней.
Говоря об отладке, следует обратить Ваше внимание на то, что, зачастую, не так важно исправить найденную ошибку, как точно ее специфицировать. Знаете ли Вы "Закон Чечако", который гласит, что у "новичков" любая система работает неправильно, - или зависает или дает неверные результаты.

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

Замечание:

Хочу привести одно из свежих впечатлений о процессе отладки. Будучи бета - тестером Office 2000, я поразился, сколь мощной является построенная Microsoft система отладки своих продуктов. Специальный узел в Интернете для тестеров, конференции для них, удобный для тестеров способ публикации своих отчетов о найденных ошибках, практически моментальная реакция разработчиков на каждую из найденных ошибок.
Говоря о последующих этапах, замечу только, что в Office 2000 входят специальные средства для создания собственного Setup' а, что Администратору Office 2000 предоставляются специальные средства для развертывания Office 2000 в сети. В общем, сопровождение обеспечивает долгую жизнь программному продукту, так что этим этапам необходимо уделять немалое внимание. Ну и, конечно, особый вопрос это обеспечение безопасности, надежности и защиты данных от несанкционированного доступа.

Содержание раздела