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

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

Знание среды функционирования помогает определить список внешних интерфейсов. MySQL работает по технологии клиент/сервер . ККлиенты подключаются по протоколам TCP/IP, через UNIX-сокеты или именованные каналы. СУБД может создавать на диске журнальные файлы и образы таблиц. Опишите потоки данных в системе. Лучше всего сделать это с помощью диаграмм.

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

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

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

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

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

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

Спецификация проекта 87

Спецификация проекта

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

Ниже приведен перечень свойств, которыми должна обладать хорошая спецификация проекта:

1) должно быть упомянуто каждое исходное требование;

2) должны быть определены возможные варианты реализации;

3) спецификация должна легко модифицироваться;

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

5) спецификация должна придерживаться простых решений;

6) связи между модулями должны быть слабыми.

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

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

В основном разработчик решает, как, собственно, создавать систему. Конкретные детали реализации оставляются на усмотрение программистов, а в проектной части описываются принципы реализации. Нет необходимости указывать имя каждой переменной, достаточно задать правила выбора имен. Язык программирования, СУБД и другие структурные компоненты выбираются на этапе проектирования.

Проектирование- это итерационный процесс, поэтому проектная спецификация должна быть такой, чтобы изменения было легко вносить. Разбейте документ на логические разделы и пронумеруйте их. Существуют программы, предназначенные для построения проектных диаграмм. Среди них отметим открытый пакет Dia (www.lysator.liu. se/alla/dia).

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

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

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

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

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

В спецификации проекта должны присутствовать четыре важных раздела:

1) стратегия;

2) архитектура;

3) правила;

4) детали проекта.

В разделе стратегии описаны внешние компоненты и средства, которые должны быть использованы в процессе последующей реализации. Сюда входят операционная система, СУБД и другие программные платформы. Их выбор влияет на архитектуру. Рассмотрите основные методы решения главных проблем.

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

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

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

Составление схемы базы данных

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

Существуют два основных типа диаграмм: диаграммы потоков данных и диаграммы отношений объектов (entity relationship, ER). На примере первых демонстрируются функциональные преобразования, претерпеваемые данными при переходе из