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

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

Анализ Проектирование

о а с:

Модули

Рис. 15.2. Шаги, необходимые для выхода на этап проектирования модулей

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

Рис 15 3. Эффект лабиринта при отображении функций в модули

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

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

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

ограничения - для реализации правил обработки данных без процедурного кода;

триггеры базы данных - для процедурного ввода правил обработки данных для всех частей приложения;

хранимые процедуры - для инкапсуляции общих бизнес-функций;

идентичность SQL (лучще всего достигается с помощью хранимых процедур) - для использования разделяемой области SQL.

Не забудьте о системных модулях

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

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

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

диспетчер пакетных очередей/планировщик заданий; Л

диспетчер очередей на печать; т

средство доступа к данным или средство создания нерегламентированных запросов;

менеджер каталогов файловой системы;

интегратор меню/модулей;

процедуры автоматического резервного копирования;

процедуры автоматического восстановления;

средство предоставления доступа пользователям и аннулирования доступа;

средство настройки среды для нового пользователя;

средство, позволяющее пользователям изменять свой пароль;

средства управления приложениями.

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

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

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