Мониторинг обменных курсов валют
18c0693f

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


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

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

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



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



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

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

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



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

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


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

    Замечание:

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

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





Самый выгодный курс обмена валюты