ЧАСТЬ эляци нных систем баз данных

сора. Помните: если клиенту будет хоть что-нибудь непонятно, то

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

Концептуальная модель данных

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

В этой части документации никак нельзя избежать таб-

лиц. И вашим читателям, хотят они этого или нет, придется с ними

ознакомиться. Единственное, чем вы можете облегчить их долю -

попытайтесь сделать этот процесс менее утомительным.

Во-первых, используйте минимум технической терминологии.

Таблица , иоле и запись - по-видимому, неизбежное зло. Атер-минов отношение и атрибут лучше избегать, хотя,

конечно, они более точны с технической точки зрения. Убедитесь, что объяснили значение технических терминов (только не пытайтесь прочесть краткий курс по базам Не так уж это и сложно:

скажите, что таблица представляет в данных нечто из предметной области (например, счет покупателя), а поле содержит значение

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

Если документ должен содержать и чисто техническую специ-предназначенную для разработчиков, опишите эти детали отдельно, в качестве приложения к спецификации Сове-

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

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

Схема базы данных

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

ГЛАВА 11 Сотруднячесгео при [хектровании

Схема базы данных представляет интерес для разработчиков, о ней

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

Интерфейс пользователя

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

Даже если вы не собираетесь разрабатывать интерфейс отдельно

от остальной части проекта, неплохо все же показать заказчику сколько примеров пользовательских форм, назвав их черновика.ми*, Такие примеры помогут ему лучше представить себе внешний вид Но начеку: после этого от вас будут ожидать именно

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

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

Функции, от которых отказались . В этом же разделе следует дать объяснение причин отказа.

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

Прототип интерфейса

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

ЧАСТЬ 2 Проващшант раяяционнь!;* сметем Ш данных

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

циональность. При выборе тех или иных пунктов меню на экран выдаются стандартные сообщения, например: команда выполнять то-то и Она не реализована в

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

Для создания прототипов подойдут те же инструменты, что и для

реальной разработки. Это очень удобно, но и у такого метода есть

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

Очень трудно не поддаться соблазну и не использовать ототип в качестве скелета системы. В конце концов, если все меню и ные формы уже не переписывать же их заново? Но экран-

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

обошли, создавая примитивное приложение-прототип.

Поэтому многие архитекторы рекомендуют эк-

ранных форм с дизайнерских систем, а не средств разра-

ботки типа Microsoft Access или Visual Basic. Используйте средства, наиболее удобное для вас. Для меня таковыми являются тальные средства разработки. Вы можете применить дизайнерские системы или даже системы создания презентаций наподобие Microsoft PowerPoint. Просто помните о том, что создаете не саму систему, а

пример, демонстрирующий ее внешний вид. Спецификации интерфейса

Итак, создание прототипа - замечательный способ согласовать с

пользователем внешний вид системы. Но возможности прототипа в

части функциональности весьма ограничены. По этой причине он не способен заменить спецификации интерфейса. А вот обратное

неверно: тщательно подготовленные спецификации могут заменить прототип.