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

Для нашей системы проката автомобиля мы выбрали в качестве инструментария следующие средства: Рго*С, PL/SQL, Oracle Forms и Oracle Reports. Мы отображаем бизнес-функции в модули. Например, Check for cars requiring service (Проверить наличие автомобилей, требующих обслуживания) становится модулем CRB0110: Produce а report of cars requiring service, который классифицируется как простой отчет, полученный при помощи Oracle Report. Благодаря своей простоте этот модуль имеет минимальную спецификацию, и, по нашим расчетам, его можно спроектировать, сгенерировать и автономно протестировать за четыре дня.

Разработка метрик для проектирования и реализации

Метрики - это просто шаблоны, позволяющие оценить, сколько времени займет создание модуля кода. Они подробно рассматриваются в главе 17.

Рассмотрение возможности применения генераторов

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

Разработка шаблонов кода

Шаблон кода - это средство, позволяющее устранить из разработки модулей некоторые рутинные, тупые операции. Мы используем как основу для всего нового кода готовый модуль, в который уже встроены некоторые типовые функциональные возможности. Этот прием также описан в главе 15.

Заключительные стадии проектирования

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

Проектирование процесса тестирования

Сформулируем общую стратегию тестирования, в которой определяются типы испытаний и сроки их проведения. Как правило, по завершении

46 А: Or

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

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

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

Экранные формы мы разрабатываем в системе Oracle Forms и создаем план автономных тестов с перечнем стандартных контрольных точек, которые обеспечивают согласованность. Например:

В каждом блоке перейти в последнее поле и нажать клавишу следующего поля. Курсор должен переместиться в первое поле следующего блока или (если это последний блок) в первое поле первого блока.

Нажать клавишу справки (F1) из любого поля ввода и проверить, вызывается ли соответствующая контекстная справка.

Исследование внешних и унаследованных систем и льеханизмов подачи данных

Как много новых баз данных Oracle начинается с совершенно чистого листа? В скольких случаях первый день их реализации начинается с ввода данных? На эти вопросы почти наверняка можно ответить, что таких случаев очень и очень мало, если они вообще бывают. В большинстве организаций уже есть данные, важные для их деятельности, и они хотят, чтобы новое приложение либо обращалось к этим данным, либо принимало их для использования. Прием данных может быть разовым процессом, т.е. таким, в котором данные принимаются из унаследованной системы, выводимой из эксплуатации, и загружаются в новую. Это может быть и такой процесс передачи данных, когда пересылка осуществляется периодически. Механизмы подачи данных - один из основных компонентов приложения хранилища данных. Этот предмет более подробно рассматривается в главе 8.

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

Формулирование требовании по безопасности, доступу и обслуживатио

Каждая система имеет свои требования к безопасности, аудиту, резервному копированию и восстановлению, регистрации событий, архивации и так далее. На стадии анализа эти требования очень часто не учитываются, так как их считают физическими атрибутами системы. Однако на этапе проектирования необходимо четко сформулировать эти требования и определить механизмы их реализации. Требования такого типа (общие для всей системы) - идеальные кандидаты на реализацию в виде объектов базы данных Oracle? (триггеров, хранимых процедур и т.д.).

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

Эти вопросы подробно обсуждаются в главе 10.

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

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

Составление функциональноИ и технической спецификации

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

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