Как и модель данных, специфика-

ция пользовательского интерфейса всегда включает в себя некоторый

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

его от информации технического характера везде, где это возможно.

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

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

Контроль за изменениями

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

Для этого есть несколько способов. Первый - не исправлять документ непосредственно, а создать список изменений. Разумеется, это подойдет, если изменения не слишком значительны, в противном случае лучше исправить текст самого документа.

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

Но в большинстве случаев способ контроля не столь важен, сколь

сам его факт.

Специальные средства

Работать над документацией вам помогут два средства; Microsoft Visual SourceSafe и Microsoft Visual Component Manager. Visual SourceSafe создавался прежде всего как средство контроля за изменениями исход-

ЧАСТЬ 2 аттошт сйстем баз данных

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

Visual SourceSafe очень полезен, если над созданием системы работают несколько проектировщиков. Он исключает возможность уничтожения одним человеком изменений, внесенных остальными членами группы, и гарантирует, что все работают только с последней версией документа.

Visual Component Manager - клиентская часть Microsoft Repository. Он тесно связан с Enterprise Edition Microsoft Visual Studio и предназначен для администрирования документации и компонентов, открытых для общего пользования (а не для помоши в процессе разработки). Visual Component Manager позволяет создавать индивидуальные хранилища информации для каждого участника проекта. Это очень удобно, чтобы связать несколько документов на различных пользовательских компьютерах в одно целое.

Если проект разрабатывается с помощью Visual Studio, та же самая база данных может быть использована для контроля за версиями

разрабатываемых компонентов. К сожалению Visual Component Manager не интегрирован с Microsoft Access, хотя теоретически можно ввести в Repository такие возможности.

Итоги

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

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

ЧАСТЬ

Проектирование пользовательского интерфейса