Эта книга посвящена проектированию баз данных — в частности, баз данных Oracle — и некоторых элементов кода, обеспечивающего доступ к ним. Качество проектирования оказывает огромное влияние на успех проекта. Производительность — главный фактор, определяющий эффективность компьютерной системы, а проектирование является основой хорошей производительности. Если база данных изначально спроектирована плохо, то приложения практически не смогут работать эффективно. Самые мощные аппаратные и программные средства, самый настроенный код не смогут скомпенсировать низкое качество проектирования и допущенные при этом просчеты. Проектирование повышает вероятность того, что система будет удовлетворять заданным требованиям с учетом ограничений, которые неизбежно имеют место. Наконец, хорошее проектирование существенно облегчает сопровождение приложений, внесение в них изменений и наделение их новыми возможностями.
Что такое проектирование?
Что такое проектирование и когда мы его выполняем? Проектирование охватывает три основные области:
1. Проектирование конкретных объектов, которые будут реализованы в базе данных. Для Oracle это такие объекты, как таблицы, представления, индексы и хранимые процедуры, а также функции и пакеты.
2. Проектирование конкретных экранных форм, отчетов и программ, которые будут сопровождать данные в базе данных и обеспечивать выполнение запросов к этим данным.
3. При определенных обстоятельствах в процессе проектирования также необходимо учитывать конкретную среду или технологию — например, топологию сети, конфигурацию аппаратных средств, использование архитектуры клиент/сервер, параллельной обработки или распределенной архитектуры базы данных.
В идеальном мире вы могли бы построить совершенно четкую и логичную структуру базы данных, которая позволила бы вашей системе достичь максимально возможной производительности. Но проектирование заключается в достижении компромиссов и строится на информированном принятии решений. Итак, мы можем сказать, что:
Проектирование — это поиск способа удовлетворения функциональных требований средствами имеющейся технологии с учетом заданных ограничений.
Что собой представляют эти ограничения? Для каждого проекта существует ряд абсолютных требований: как правило, это максимальное время, отпущенное на проект, и максимальное количество денег, которое может быть на него потрачено. Проект может сопровождаться массой других неудобных требований и ограничений. Ваша задача как проектировщика — максимально эффективно выполнить свою работу в рамках этих ограничений и указать, где можно пойти на компромисс, а где компромисс поставит под угрозу успех или качество проекта.
Хотя проектирование — жизненно важная задача, ему не всегда уделяют должное внимание. Одна из проблем заключается в том, что проектирование базы данных — не такая структурированная задача, как анализ требований к проекту или реализация приложения. По анализу и разработке проектов есть много книг, а вот по проектированию — очень мало. (Ничего, мы исправим это упущение!)
Говоря о проектировании, очень часто допускают неточность, описывая его как отдельный этап, расположенный между этапами анализа и реализации. Очень часто в книгах о разработке проектов приводится схема так называемого "метода водопада", подобная приведенной на рис. 1.1.
Рис. 1.1. Метод водопада
Однако в действительности проект нельзя разделить на части таким способом. Во-первых, различные этапы проекта существенно перекрываются. Во-вторых, проектирование не имеет столь явно выраженного начала и окончания; оно часто продолжается на этапах тестирования и реализации.
В следующем разделе мы исследуем реальный (но в значительной степени упрощенный) проект. Мы кратко рассмотрим каждый его этап (определение стратегии, анализ, проектирование, реализацию) и попутно введем некоторые важные термины и понятия. В следующих главах мы изучим их более подробно.
Исследование проблемы
В качестве примера рассмотрим фирму по прокату автомобилей, которая хотела бы реализовать новую ценовую политику с использованием скидок и премий за приверженность. Эксплуатируемая на фирме система на базе мэйнфрейма уже "трещит по швам", и дальнейшее ее расширение с целью выполнения новых функций невозможно. Новый проект, предполагающий замену устаревшей технологии базой данных Oracle и внешним графическим пользовательским интерфейсом, кажется хорошей идеей! Компания назначает руководителя проекта, и можно приступать к работе.
Определение стратегии
Первое, что делает руководитель нового проекта, — это организует обследование системы. Главные задачи такого обследования — оценка действительного объема и цели проекта, а также получение определений сущностей и функций на высоком уровне. Успешного результата при этом можно добиться лишь путем привлечения опытных, высококвалифицированных бизнес-аналитиков, имеющих постоянный доступ к высшему руководству фирмы. Именно высшее руководство будет утверждать фонды на последующие этапы проекта, поэтому необходимо тщательно фиксировать его требования к конечным результатам.
Этап определения стратегии предполагает тесное взаимодействие с основными пользователями и бизнес-экспертами, получение от них информации и возвращение ее в формализованном виде, обеспечивающем полное и однозначное понимание требований. Это может осуществляться самыми разными методами: в частности, с помощью ряда индивидуальных бесед и (или) семинаров. В нашем примере аналитики беседуют с главным исполнительным директором, вице-президентом по маркетингу, менеджером по обслуживанию клиентов и так далее, до служащего, принимающего посетителей. Они узнают о необходимости ввода специальных скидок для постоянных клиентов и создании четвертой категории сдаваемых напрокат автомобилей (микроавтобусы). Кроме того, они узнают о гибких схемах расчетов и специальных предложениях. Короче говоря, они выясняют суть данного бизнеса и перспективы его развития (в случае, если используемые компьютерные системы позволят ему развиваться).
По завершении основной стадии обследования системы технический специалист (или техническая бригада, хотя чаще всего это именно один человек) может приступать к выработке вероятного технического подхода и приближенному расчету затрат на аппаратные средства, программное обеспечение и разработку. Получив эту дополнительную информацию, руководитель проекта и его бригада могут вновь выйти на спонсоров проекта с результатами этапа определения стратегии.
Эти результаты представляют собой четко сформулированное заявление о том, что получат спонсоры, если согласятся на этот проект (объем), когда они это получат (график) и сколько это будет стоить. При этом должны быть количественно охарактеризованы не только затраты, но и выгоды ("данный проект окупится за полтора года"). Если этого не сделать (или, хуже того, если это сделать невозможно), то вполне может оказаться, что ощутимой выгоды нет и проект продолжать не стоит. Тем не менее, и такие проекты часто утверждаются.
В нашем сценарии с прокатом автомобилей высшее руководство фирмы одобряет сделанные выводы и говорит, что может подождать год и потратить на достижение поставленной цели 1,2 млн. долларов. Помимо всего прочего в отчете должны быть описаны:
• Ограничения, риски и критические факторы, влияющие на успешный результат. Так, критерии качества обслуживания, например, время ответа на заявку и возможности системы, оформленные в виде требований, а не как желательные элементы, являются заданными ограничениями. В случае с нашей прокатной фирмой график ввода новой системы цен — критический фактор успеха, так как сколько-нибудь значительное отставание от графика может означать утрату доли рынка. *
• Необходимые функции и будущие требования, например, возможность заказа автомобиля по World Wide Web.
• Сущности, необходимые для выполнения этих функций.
Здесь нужно также четко указать, какие элементы не будут реализованы в рамках проекта. Например, в нашем случае мы определяем, что создание управленческих отчетов по нашим данным не входит в наш проект и должно рассматриваться в рамках отдельного проекта.
Каков результат этапа определения стратегии, который мы только что рассмотрели в качестве примера? Вывод состоит в том, что мы собираемся продолжать разработку проекта. Если отказаться от продолжения работ, то данная организация не выживет, поскольку все конкуренты вводят более гибкие схемы ценообразования и таким образом повышают свою конкурентоспособность.
Теперь, когда у нас четко определены объем и смета, мы переходим к этапу анализа.
Анализ
Этап анализа — это подробное исследование бизнес-процессов (функций) и информации, необходимой для выполнения этих функций (сущностей с их атрибутами и отношениями). В данном разделе мы дадим краткий обзор этого этапа, а подробнее рассмотрим его в главе 3.
На этапе анализа важно четко сформулировать требования в общем. Говоря "в общем", мы не имеем в виду "туманно". Мы подразумеваем, что не нужно делать никаких предположений относительно компьютерной системы. Это сделать нелегко. Если вы (как и мы) в глубине души — разработчик или программист, то обнаружите, что вам трудно мыслить иначе, чем категориями "эта форма" или "эта таблица". Многим программистам совершенно непонятно, почему самые талантливые аналитики не способны писать программы (даже несмотря на то, что они обычно утверждают, что при необходимости смогут сделать это). Причина проста: их неспособность разработать программу обуславливается тем, что в процессе анализа они не тратят время и силы на выяснение того, как спроектировать систему.
Аналитики собирают и фиксируют информацию в двух разных, но взаимосвязанных формах. Это:
• функции — информация о событиях и процессах, которые происходят в бизнесе;
• сущности — информация о "вещах, имеющих значение для организации, о которых что-то известно".
Вот два вида классических результатов анализа:
• иерархия функций, которая разбивает процесс обработки на функции, или вещи, которые делаются;
• модель "сущность-отношение ", охватывающая все сущности, их атрибуты и отношения между ними.
На рис. 1.2 представлен пример функциональной декомпозиции, который иллюстрирует разбиение процесса составления счетов на ряд более мелких шагов до тех пор, пока их нельзя разбить далее без ущерба для смысла (в этой точке они считаются атомарными). Каждый из представленных на этом рисунке заголовков, как правило, должен сопровождаться кратким описанием функции. Атомарные функции обычно снабжают более подробным описанием их назначения.
Рис. 1.2. Пример функциональной декомпозиции
На рис. 1.3 представлена простая модель сущностей для нашей системы проката автомобилей, которая имеет вид диаграммы "сущность-отношение" (ER-диаграммы). Такие рисунки оказывают колоссальную помощь в понимании и документировании системы. Методы моделирования и условные обозначения, на которых построена эта схема, являются главной темой главы 3. В сложной системе ER-диаграмма всей модели по легкости чтения почти наверняка будет сопоставима с одностраничной картой с изображением всех звезд, видимых в северном полушарии! Рекомендуем разбить ее на несколько небольших диаграмм, каждая из которых описывает относительно автономную предметную область модели.
Рис. 1.3. Диаграмма "сущность-отношение"
Предупреждение
Мы часто сталкиваемся, с тем, что в структуре базы данных и коде имеют место серьезные упущения, вызванные тем, что проектировщики и программисты пользуются неполными диаграммами. Поэтому, если вы собираетесь использовать неполные диаграммы, обязательно определите межстраничные связи и не забудьте указать, куда они идут.
Каждая сущность должна сопровождаться описанием, набором атрибутов со свойствами и описаниями, а также уникальным идентификатором, по которому один экземпляр можно отличить от других.
Предупреждение
Показывать отношения между сущностями, не именуя их, опасно, поскольку читателям приходится самим делать предположения о характере отношений и они могут ошибиться. Для простоты мы назвали на рис. 1.3 только два отношения — те, которые связывают автомобиль с пунктом. В другой прокатной фирме, возможно, потребовалось бы показать и другие отношения между двумя этими сущностями, например, первоначально доставленный в ... и обычно базирующийся в ....
В процессе анализа необходимо также зафиксировать бизнес-правила.Это не функции как таковые, а, скорее, непреложные факты, которым всегда должна подчиняться система. В нашем примере можно сформулировать следующие бизнес-правила:
• Специальные скидки не распространяются на автомобили возрастом менее одного года.
• Общая сумма скидки (за приверженность плюс за объем заказа) не может превышать 40% чистой суммы, указанной в счете-фактуре.
К другим часто используемым результатам анализа относятся жизненные циклы сущностей (ЖЦС) и диаграммы потока данных (ДПД). Эти элементы вводят понятие последовательности, которое невозможно применить ни к иерархии функций,ни к модели "сущность-отношение". В частности, попытка показать жизненный цикл на модели сущностей — широко распространенный источник ошибок. Там, где не используются ЖЦС, можно для представления отсутствующей информации применять бизнес-правила, например:
• Контракт на прокат может заключаться только на автомобиль, который проверен и сертифицирован техником после последней поездки по открытой автостраде. (Это определение учитывает автомобили, используемые или перегоняемые из одного пункта в другой служащими или подрядчиками фирмы.)
На заключительной стадии этапа анализа бригада составляет план тестирования системы. На рис. 1.4 изображена диаграмма жизненного цикла сущности Rental Car ("Автомобиль напрокат").
Рис. 1.4. Жизненный цикл сущности Rental Car
Проектирование
Проектировщик (или бригада проектировщиков) берет выходные данные анализа и выдает:
• определение (или схему) базы данных — на основании модели сущностей, разработанной на этапе анализа;
• набор спецификаций модулей — построенных на базе моделей функций.
Здесь дается краткое описание этапа проектирования. Более подробно о том, что происходит на этом этапе, мы расскажем в разделах "Планирование этапа проектирования" и "Задачи проектирования".
Примечание
По поводу передачи результатов отметим, что в маленьком по масштабу проекте аналитики, проектировщики и разработчики могут быть одними и теми же лицами (или лицом). В этом случае необходимо соблюдать дисциплину и передавать результаты самому себе (в другой роли). Считайте, что передаете результаты кому-то, кто мало знает систему.
Схема базы данных содержит описания всех объектов базы данных: таблиц, представлений, столбцов, индексов, кластеров, ограничений, триггеров и т.д. На этапе проектирования создаются не только определения этих объектов, но и сами физические объекты, с которыми затем работают разработчики.
Эти спецификации должны быть достаточно подробными, чтобы разработчик мог взять их и превратить в рабочую программу, удовлетворяющую поставленным требованиям. Кроме того, на данном этапе придется уделить внимание тестированию и реализации. Это означает, что мы должны составить планы, обеспечивающие тщательное тестирование приложения и плавный переход к его промышленной эксплуатации.
Во многих проектах большинство результатов этапа проектирования оформляется в единый описательный документ, который иногда называют технической спецификацией. В этом документе также описывается принятый подход к решению сложных технических вопросов.
Проектировщики должны обеспечить согласованность схемы базы данных и модулей не только с результатами анализа, но и между собой. Например, таблица RENTAL__CARS, полученная из сущности Rental Car ("Автомобиль напрокат"), должна где-то иметь модуль, позволяющий вставлять в нее новые автомобили. Одна из ключевых целей проектирования — обеспечение хорошей работы системы после реализации с учетом ограничений, наложенных архитектурой целевой системы. По этой причине проектировщикам нужно тщательно изучить саму архитектуру. Например, требование к пропускной способности сервера базы данных может привести к рассмотрению возможности использования параллельной обработки. Можно выбрать и другие методы распределения обработки между клиентом и сервером. Мы подробно рассмотрим эти варианты в главе 14 и главе 11.
Как мы уже говорили, производительность является решающим фактором оценки любой системы. Чтобы добиться от данной системы максимально возможной производительности, нам, возможно, придется пойти на некоторые компромиссы. Для нашей прокатной фирмы одним из самых важных и критических факторов является способность быстро и точно определить минимально возможную для клиента цену контракта. Для одного контракта может существовать несколько тысяч возможных сочетаний цен и скидок. SQL-код, определяющий наилучшее сочетание, начинает выглядеть сложным и потенциально дорогим с точки зрения использования ресурсов центрального процессора. Поэтому мы принимаем следующее решение. Для целей сопровождения и подготовки отчетов мы будем хранить все цены и скидки в базе данных, а для определения цены контракта будем загружать их в память один раз в начале дня (в управляемый приложением кэш). Кроме того, алгоритм образования цены, работающий с данными кэша, будет полностью реализован на С (SQL мы использовать не будем).
В процессе проектирования мы ищем общие или схожие задачи в функциональных определениях и проектируем их в одном модуле. Мы определяем, имеет ли смысл реализовать общие модули и модули, определяющие бизнес-правила как хранимый код (триггеры и хранимые функции, процедуры и пакеты). Если при обработке интенсивно используется база данных, это имеет смысл. Эту часть кода лучше всего создать и протестировать в процессе проектирования и разместить в нужном месте до построения остальных модулей. В нашем случае мы создаем триггер на таблице RENTAL_CARS, чтобы предотвратить создание контракта со специальным тарифом для автомобиля, зарегистрированного менее года назад. Этот триггер реализует одно из бизнес-правил, которые мы упомянули выше
В нашем примере мы заменяем унаследованную систему, и поэтому нам приходится иметь дело с переносом данных. Как бы ни хотелось начать работу с пустой базы данных, это невозможно: в существующей системе есть масса полезных данных, как текущих, так и архивных, которые необходимо сохранить. Мы принимаем самое, на наш взгляд, разумное решение: старая система выдаст совокупность двумерных файлов данных, которые будут перенесены в новую систему. Спецификации форматов этих файлов мы составляем вместе с обслуживающими мэйнфрейм системными программистами, которым придется эти файлы создавать. Подробно вопросы переноса данных освещены в главе 8.
На этапе проектирования получают много результатов, и в каждом проекте они разные. Однако для каждого Oracle-проекта должна быть составлена схема базы данных (или схемы, если данные будут распределены), и почти для каждого — некоторые формальные спецификации модулей. Примеры приведены в табл. 1.1 и на рис. 1.5. Результаты анализа и проектирования показаны на рис. 1.6.
Таблица 1.1. Пример спецификации модуля
Спецификация модуля
Название Язык Сложность Интерфейс вызова Использование таблицы Описание
Volume Discount Calculation (B23478) Pro*C Средняя Командная строка: B23478 [Номер счета-фактуры] CUSTOMERS, INVOICES Вычислить общую стоимость счетов-фактур для данного клиента за последние шесть месяцев. Если это головная компания, включить данные по всем дочерним компаниям.
Рис. 1.5. Пример схемы базы данных и определения данных
Рис. 1.6. Результаты этапов анализа и проектирования
Реализация
По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и объектные модули, а также автономные тесты модулей. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию. Мы не будем рассматривать эти этапы, потому что к нашей основной теме — проектированию, они не относятся. Тем не менее, важно понимать, что вплоть до запуска системы в эксплуатацию вам придется постоянно возвращаться к этапу проектирования (и этапу анализа). Если тестирование проходит не совсем успешно (а это бывает очень часто), то проблемы, связанные с проектированием, будут возникать и на ранних стадиях промышленной эксплуатации.
Проект успешно завершен?
Есть один печальный, но реальный факт: не каждый проект доходит до этапа реализации. Наиболее распространенная причина этого — просто отказ делать то, что нужно, — описана в следующем разделе. Специалисты приводят разные данные, но некоторые из них полагают, что 40% проектов либо полностью прекращаются, либо значительно уменьшаются в объемах. Важнейший аспект проектирования, о котором мы лишь упомянули выше, — это необходимость выявления рисков и управления ими. Каждый проект сопряжен с риском; как проектировщики, мы должны сконцентрировать внимание на технических рисках и начать противодействовать им как можно раньше. Выявив эти риски, мы должны сформулировать их и составить план их устранения или минимизации.
Возвращаясь к нашему примеру, отметим, что система бухгалтерского учета, с которой предстоит интегрировать нашу систему, устарела. Она была написана какими-то сторонними специалистами, которые, к несчастью, прекратили свою деятельность. Документации на интерфейс нет, и все необходимые сведения придется черпать из системы, которую мы заменяем. Из этого положения можно выйти следующим образом:
1. Приобрести новый пакет бухгалтерского учета. К сожалению, существующим пакетом пользуются и другие системы фирмы, поэтомуэто само по себе будет серьезным проектом.
2. Взять интерфейсные модули бухгалтерского учета непосредственно из старой системы и максимально их использовать.
3. Разработать ПО промежуточного уровня, работающее между приложением и пакетом бухгалтерского учета. Прикладное ПО производит простые и четко определенные вызовы этого ПО, например, в виде PostDebit <счет><сумма>. ПО промежуточного уровня превращает такой вызов в вызов системы бухучета. Это ПО можно разработать отдельно от основного приложения. Если будет приобретен новый пакет бухгалтерского учета, нам придется лишь переписать программы промежуточного уровня, поскольку наши приложения полностью изолированы от внутренних механизмов бухгалтерских программ.
На наш взгляд, самый лучший вариант — третий, поэтому мы начинаем проектировать систему с ПО промежуточного уровня.
Журнал проектирования
Следует подчеркнуть важность регистрации всех вопросов, возникающих в процессе проектирования системы. Нужно регистрировать (где-нибудь, не важно, где именно) все обсуждаемые варианты, варианты, которые учитывались, и окончательные решения. Эту информацию можно хранить в CASE-репозитарии, в документах текстового процессора, в текстовых файлах и даже на бумаге. Самое главное — обязательно сохранить ее где-нибудь.
Почему мы акцентируем внимание на этом? Да потому, что имеем печальный опыт, когда наши проектировщики изменяли первоначальные решения. Это происходило, в частности, из-за того, что никто из участников проекта не мог объяснить, почему ранее принято то или иное решение, так как аргументы в его пользу были давно забыты. В некоторых случаях причина принятия первоначального решения становилась ясна несколько месяцев спустя, когда новый, как будто лучший, подход оказывался тупиковым.
Журнал проектирования — отличный материал для изучения новыми членами группы, будь то проектировщики, разработчики, тестировщики или руководители. Ознакомившись с ним, они быстро поймут технические особенности проекта.
Вот небольшой фрагмент журнала проектирования системы проката автомобилей:
Журнал проектирования
Раздел: распределение данных
Исходные предпосылки (7.02.95 г.). Существует общее мнение, что фирме следует перестать полагаться только на центральный мэйнфрейм. Нужно перейти на распределенную систему. Основные преимущества — более высокие производительность и устойчивость. Решить эти проблемы можно путем модернизации мэйнфрейм-системы и установки "горячей резервной" машины. Ввод распределенной архитектуры не позволит полностью устранить зависимость от центрального сервера, и группу проектировщиков все еще не убеждает теория о том, что в случае отказа центрального хоста его функции временно сможет принять на себя один из других серверов. Нас также волнует то, что в региональных офисах нет квалифицированного персонала для управления сервером, поэтому все обслуживание и администрирование придется осуществлять дистанционно.
…
Совещание с обслуживающим персоналом (7.09.95 г.).
Обслуживающий персонал счастлив, что дистанционное обслуживание проблемы не составит. Однако их волнует возможное влияние распределенной базы данных на линии между офисами; вероятно, придется увеличивать пропускную способность. Необходимо как можно быстрее организовать эталонное тестирование.
…
Совещание с представителями
Oracle (27.09.95 г.). Мы обсудили все возможности репликации, которые может обеспечить Oracle, и решили, что в основном будем использовать снимок с защитой от записи. Oracle организовала посещение эталонного узла, чтобы мы увидели, как он работает.
Альтернативные методы и подходы
В предыдущих разделах мы представили процесс проектирования баз данных довольно упрощенно. Действительно, ранее было отмечено, что проектирование обычно не выполняется "с первого захода". Однако в нашем примере с прокатом автомобилей мы описали его именно так. Где же в реальной жизни заканчивается анализ и начинается проектирование? Где заканчивается проектирование и начинается реализация? В большинстве случаев на эти вопросы нельзя ответить однозначно. Завершая отдельные стадии анализа и имея его результаты, проектировщики параллельно работают над решением первоочередных задач проектирования. Периоды, когда работа ведется параллельно, бывают весьма продолжительными. Аналогично, программисты, не дожидаясь завершения отдельных стадий проектирования, могут работать над компоновкой модулей. Это имеет смысл особенно при наличии общих модулей, которые должны часто вызываться в приложении.
Конечные пользователи и руководство нередко полагают, что процесс проектирования не дал никаких результатов, так как нет законченных компонентов приложений, которые они могли бы "пощупать". Конечно, им можно объяснить, почему так происходит. Однако следует учитывать, что такая реакция может иметь серьезные последствия для всего проекта. Давайте рассмотрим методы, которые используются для того, чтобы успокоить заказчиков.
Ускоренная и совместная разработка приложений
Одна из причин, по которой многие проекты завершаются неудачей, состоит в том, что они не обеспечивают потребностей пользователей и бизнеса. Часто бывает, что потребности пользователей не совсем совпадают с тем, что нужно для бизнеса, и проект, не обеспечивая ни то, ни другое, обречен на неудачу. Где-то на этапах анализа, проектирования и реализации нарушается связь между руководством компании и проектировщиками, и некоторые требования либо не учитываются, либо трактуются неверно.
Имеют место случаи давления со стороны спонсоров проекта или распорядителей бюджета, которые направлены на досрочное проведение этапа реализации, с тем чтобы получить какой-то результат и как можно скорее продемонстрировать его. Во многих случаях, когда анализ и проектирование урезаются, избираются подходы, представляемые как ускоренная разработка приложений (УРП) или совместная разработка приложений
(CPU). Мы скептически относимся к этим методам. Начнете ли вы строить мост или изготавливать машину, не закончив проектирование? Наверное, нет. Так почему же такие методы считаются приемлемыми при разработке информационных технологий? Так быть не должно.
При использовании УРП и СРП проектировщик и компоновщики системы вместе с пользователями разрабатывают систему следующим методом. Проектировщик разрабатывает рабочий прототип и демонстрирует его пользователям. Пользователи говорят, что им нравится, а что нет. Проектировщик принимает эти замечания к сведению, уходит и дорабатывает прототип, после чего вновь демонстрирует его пользователям. Этот итеративный процесс продолжается до тех пор, пока пользователям не понравится то, что они видят, и прототип не "станет" действующим приложением. Обычно устанавливается лимит времени или количества итераций, иначе пользователи будут совершенствовать проект вечно!
Теоретически пользователи должны получить при этом именно ту систему, которую они хотят. Однако на практике этот подход сопряжен с рядом серьезных проблем:
• Все концентрируют свое внимание на содержимом экранных форм. То, что происходит "за экраном", структура базы данных и проектирование ее схемы остаются без внимания.
• Часто допускают ошибку, полагая, что раз окончательный вариант прототипа согласован, то модуль готов. На самом же деле все обстоит совершенно не так: модуль может и не взаимодействовать с другими модулями или даже с базой данных, а лишь создавать при помощи нескольких "фиктивных" подпрограмм красивую картинку на экране.
• Проектирование модулей в полной изоляции их друг от друга ведет к несогласованности и противоречиям, которые проявляются при окончательной стыковке модулей на этапе тестирования всей системы в целом.
• Поскольку функциональные возможности наращиваются параллельно в нескольких направлениях, необходимо жестко контролировать структуру базы данных, которая будет поддерживать эти возможности. УРП может превратиться во всеобщую свалку, где таблицы сколачиваются на скорую
руку, а столбцы лепятся друг к другу без какого-либо положительного эффекта, В итоге получаются базы данных, которые содержат избыточные или противоречивые данные и работают очень плохо.
• При разработке методом УРП легко забыть о необходимости подготовки документации.
Методы УРП и СРП использовать можно, но, наш взгляд, только в тех случаях, если:
• Объем проекта и требования с точки зрения бизнеса четко определены.
• Проект относительно невелик и независим. Под этим мы подразумеваем, что количество внешних интерфейсов, с которыми придется иметь дело, мало.
• Система ориентирована на экран, и удобство использования экранных форм входит в число пяти важнейших факторов успеха проекта.
• Пользователи хорошо знают компьютер, знакомы с принципами разработки информационных технологий и положительно оценивают идею новой системы.
Если не все из этих условий выполняются, то метод УРП использовать можно, однако следует ограничить его применение какой-то частью приложения.
Moscow-анализ
Независимо от того, какой метод применяется при разработке проекта, всегда полезно иметь под рукой какое-нибудь средство для экстренных случаев. В процессе анализа и проектирования необходимо классифицировать планируемые функции системы по степени важности. Один из форматов, который нам нравится, — это MoSCoW (термин позаимствован у Клегга и Баркера). **
Эта аббревиатура расшифровывается следующим образом:
Must have (необходимые функции)
Should have (желательные функции)
Could have (возможные функции)
Won't have (отсутствующие функции)
Последняя категория, вероятно, самая важная: необходимо честно признаться, что мы не можем или не собираемся реализовывать.
Функции категории необходимые обеспечивают возможности, которые являются критическими для успешной работы системы (она должна рассчитывать сумму арендной платы, отвечать на запрос о цене не позже, чем через 5 секунд в 95% случаев, работать 20 часов в сутки и т.д.).
Реализация остальных функций (желательных и возможных) ограничена временными или финансовыми рамками. Цикл реализации проекта определяется графиком или сметой. Мы разработаем функции категории необходимые и максимально возможное (в порядке приоритета) число функций категории желательные и возможные, соответствующее отпущенным на это средствам или времени.
Применим Moscow-метод к нашей прокатной фирме. Приведенный в качестве примера список намеренно противоречив.
Необходимо обеспечить:
• Время обработки запроса о цене в 95% случаев — 5 секунд.
• Бесшовную интеграцию с бухгалтерским ПО третьих фирм.
• Поддержку четвертой категории автомобилей.
• Поддержку скидок за приверженность и скидок за объем заказов.
• Экранные формы с поддержкой ввода всех данных.
• Перенос всех справочных и транзакционных данных из унаследованной системы.
• Полный аудиторский контроль всех транзакций.
Желательно обеспечить:
• Создание управленческих отчетов.
• Поддержку изменяющихся уровней пользовательского доступа и безопасности.
• Поддержку пользователей, входящих в систему из дома по коммутируемым линиям.
• Экранные формы для запросов.
Можно обеспечить:
• Ввод новых схем скидок.
• Поддержку специальных серий счетов-фактур для одного клиента.
• Настройку счетов-фактур в соответствии с требованиями клиентов.
Отсутствующие возможности:
• Поддержка архивов старых данных.
• Специальные возможности при подготовке отчетов.
Планирование этапа проектирования
Ранее мы привели краткое описание этапов определения стратегии, анализа, проектирования и реализации. В данном разделе мы предлагаем дополнительные сведения об этапе проектирования.
Тщательное планирование существенно важно для любого проекта и любого этапа проекта. Планирование этапа проектирования, как правило, является обязанностью руководителей проекта и главного или ведущего проектировщика (если такой у вас есть). Несмотря на то, что выгоды планирования должны быть очевидны всем, давайте их все-таки перечислим. Итак, планирование позволяет:
• разбить глобальную задачу на маленькие, независимые, управляемые и (помимо всего прочего) реализуемые шаги;
• поставить кратко- и долгосрочные цели и вехи, которые могут служить для оценки фактических результатов и сравнения их с планом. Это позволяет заранее обнаружить возможное отставание от плана;
• выявить зависимости между задачами (т.е. какие задачи должны быть завершены до выполнения других задач);
• определить узкие места, т.е. ресурсы (обычно это отдельноелицо или бригада), от которых план зависит сильнее всего;
• спрогнозировать потребности в кадрах для проекта;
• получить четкое представление о том, когда можно начинать этап реализации.
Между двумя последними пунктами существует сложная взаимосвязь. Если на этапе проектирования добавить персонал, то, вероятно, можно будет приблизить дату реализации. На практике же этими двумя параметрами редко удается манипулировать, потому что хотя бы один из них "задан". Например, смета может определять кадровые возможности или дата сдачи проекта диктовать самую позднюю дату начала этапа реализации. Если ограничения установлены как по смете и кадрам, так и по срокам сдачи, то планирование на данном этапе будет играть существенную роль в деле обеспечения выполнения проекта.
Перепланирование
Спонсоры проектов всегда хотят, чтобы планы были незыблемыми, однако опыт показывает, что такие планы попросту нереальны. В процессе проектирования созревают идеи и совершенствуются приемы, и мы узнаем о системе все больше и больше. Поэтому очень важно периодически проводить обзорно-перепланировочные мероприятия. Работать по устаревшему и в силу этого невыполнимому плану гораздо хуже, чем работать вообще без плана. По крайней мере, если плана нет, то каждый знает об этом!
В нашей системе проката автомобилей у руководителя проекта есть набросок плана проекта, рассчитанного на год. Этап проектирования по этому плану длится три месяца с привлечением трех штатных проектировщиков. Один проектировщик будет работать главным образом над базой данных, второй — отвечать за экранные формы, отчеты и процессы, а третий — за интерфейсы. В данный момент из плана видно, что ответственный за код (экранные формы, отчеты и процессы) находится на критическом пути сетевого графика работ и в работе над процессами может участвовать проектировщик интерфейсов.
Такое распределение обязанностей является одним из вариантов решения кадровой проблемы. Второй вариант — разделение работы по функциональным (бизнес-функциональным) областям. Оба варианта имеют преимущества и недостатки. Как бы ни была распределена работа, необходимо обеспечить тесную связь между проектировщиками. Для этой цели руководитель проекта организует еженедельные совещания по проектированию для решения возникших вопросов путем мозговой атаки.
Две стадии проектирования
В более традиционных моделях разработки систем проектирование иногда разбивают на две стадии: высокоуровневое и низкоуровневое, или детальное. Это более характерно для больших проектов. Высокоуровневое проектирование направлено на решение общих вопросов и создание основы. Его может заменить стадия создания технической архитектуры этапа определения стратегии. Детальное проектирование — это стадия, на которой создаются первые варианты физической базы данных и пишутся спецификации отдельных модулей. В нашей книге мы, как правило, рассматриваем проектирование как одноэтапный процесс. Однако изложенные здесь приемы в равной степени применимы к любой из этих методик.
Задачи проектирования
Теперь составим черновой список задач проектирования, решение которых в совокупности позволит получить результаты, определенные нами для этого мифического зверя, типичного проекта на базе Oracle. В этом разделе мы представляем их в приблизительно хронологическом порядке, но точную последовательность указать трудно, потому что не все задачи предполагают предварительное завершение других задач. Некоторые из затронутых в этом разделе вопросов раскрываются в следующих главах, но, на наш взгляд, полезно осветить их и здесь, чтобы создать общую картину процесса проектирования.
Очевидно, время, затраченное на каждую задачу, будет меняться от проекта к проекту, а в очень маленьких проектах некоторые задачи вообще будут отсутствовать. Большинство этих задач будут указаны в плане проекта отдельными пунктами и будут описаны в технической спецификации (в которой должны быть изложены принятые вами решения). При этом за примерами мы вновь обратимся к нашему приложению для фирмы проката автомобилей.
Проектирование: ранние стадии
Существуют определенные решения и задачи, которым мы должны уделить внимание в самом начале этапа проектирования. Сделать это очень важно, так как откладывание их "в долгий ящик" может повлиять на уже достигнутые результаты проектирования. Эти задачи в основном касаются согласования стратегии и методики проектирования, а также обеспечения необходимой инфраструктуры.
Рассмотрение и принятие результатов анализа
Это — процесс передачи. Здесь мы проверяем полноту анализа и пригодность его результатов для проектирования. На практике этот процесс часто носит итеративный характер; проектировщики возвращаются с вопросами к аналитикам, начиная понимать поставленные требования. Главным образом здесь следует убедиться, что результаты анализа показывают проектировщикам, что должно делать данное приложение, но не каким образом оно должно это осуществлять (последнее — это уже задача проектировщиков, и аналитики не должны вторгаться на чужую территорию).
Как проектировщики, мы не можем проверить, охватывает ли анализ все бизнес-области системы. Нам просто приходится принять это на веру. Что мы можем проверить, так это некоторые общие концепции и аксиомы. Вот несколько примеров:
• Имеет ли каждая сущность уникальный идентификатор и хотя бы один неключевой атрибут?
• Имеет ли каждая сущность хотя бы одну функцию, создающую ее экземпляры, и хотя бы одну функцию, которая ссылается на нее?
• Имеет ли каждый атрибут "создателя" и "читателя"?
Если результаты анализа хранятся в CASE-репозитарии, то проверку такого рода обычно можно выполнить автоматически.
В нашем приложении-примере анализ проводится средствами Designer/2000. Запуская некоторые из окончательных отчетов, мы обнаруживаем отсутствие функции, которая создавала бы новые экземпляры сущности Rental Car. Мы сообщаем об этом аналитику, и он создает новую функцию. Мы замечаем также, что в некоторых функциях реализованы наброски структуры экранных форм. Мы их не отклоняем, поскольку из них можно получить кое-какую полезную информацию, но даем понять, что не можем гарантировать, что формы, которые мы спроектируем, будут похожи на эти оригиналы.
Семинары и проверка того, как проектировщики понимают результаты анализа
Если вы начнете проектировать систему, не разобравшись полностью в требованиях, то вас постигнет неудача, да еще и какая!
Читать горы бумаг или листать на экране страницы определений в CASE-системе — весьма утомительный и непродуктивный путь к пониманию требований, поставленных перед создателями системы. Объем информации, которую можно таким образом впитать, невелик. Семинары, проводимые аналитиками, — гораздо лучший способ ознакомления проектировщиков с поставленными требованиями. Такие семинары должны быть посвящены одной части системы, длиться не более часа и проводиться не чаще, чем через день. Семинары — очень эффективное средство для быстрого понимания назначения систем, они часто вызывают очень информативные дискуссии.
Ранние стадии проектирования неизменно сопряжены с тяжелой утомительной работой. После чтения документации, даже с учетом проведения семинаров, остается неясной суть многих требуемых функциональных возможностей. Как проектировщики, мы будем поддаваться желанию побыстрее сформировать представление о том, как будет выглядеть система. Это может привести к недоразумениям, которые очень трудно устранить.
Нужно остановиться, вернуться на шаг назад и убедиться, правильно ли мы понимаем назначение системы. Хороший способ сделать это — взять несколько сценариев, которые характерны для данного бизнеса, и "прогнать" их через спланированную систему. Это можно сделать в форме простой диаграммы потока данных, блок-схемы или общего описания основных шагов. Необходимо указать не только функции системы, но и ручные процедуры и методику работы.
Давайте вернемся к нашему примеру с прокатом автомобилей. Мы проводим с аналитиками ряд семинаров, посвященных сложному механизму скидок, который предусмотрен в системе. Мы рассматриваем несколько сценариев разной степени сложности, а затем проверяем их на нашей модели "сущность-отношение" и определениях функций.
Вот простой сценарий, с помощью которого мы проверяем, правильно ли поняты назначение и функции системы:
Клиент подходит к дежурному и спрашивает, можно ли взять напрокат машину, у которой рычаг переключения передач установлен на полу (stick shift).
Служащий использует CRTS0301 — Query cars in stock (запрос машин в наличии) и дает простой запрос, указывая в нем "stick shift". Запрос выполняется по сущности RENTAL CAR, ограниченной определенным населенным пунктом (SITE).
При поиске обнаруживается, что в данном пункте таких автомобилей сейчас нет. Клиент выражает готовность подождать 30 минут, если мы сможем доставить нужный ему автомобиль.
Поиск расширяется путем указания близлежащего населенного пункта в CRTS3010 и повторного запуска запроса. Это нужно делать для каждого пункта; поиск "по близости" не предусмотрен.
При поиске автомобиль нужного типа обнаруживается в одном из близлежащих пунктов, и клиент решает взять его.
Автомобиль можно заказать лишь в случае, если он находится в пункте, где сделан заказ, или перегоняется в этот пункт. Служащий нажимает в экранной форме кнопку Request Transit. Это действие удаляет связь сейчаснаходится в между RENTAL CAR и старым SITE и заменяет ее связью впроцессе переезда в с нашим пунктом. В офис, расположенный в пункте, где есть нужный автомобиль, посылается предупреждение (в форме срочного электронно-почтового сообщения) о том, что нужно перегнать автомобиль.
Заказав автомобиль и его перегон, служащий может обработать условия проката и оплаты.
Этот клиент уже обращался в фирму, поэтому служащий с помощью CTRS0430 сверяет данные его водительского удостоверения с хранящимися в системе; при этом также проверяется, имеет ли клиент право на скидку за приверженность фирме.
Определение критических участков
Здесь имеются в виду так называемые критические факторы успеха (КФУ) проекта. Например, важна ли производительность? (И если важна, то определена ли она в функциональном выражении, например, как длительность временного интервала, необходимого пользователю для создания заказа, а не просто как время ответа на рабочей станции?)
Какой смысл мы вкладываем в слово "критические"? Обычно критические участки изучаются при первом анализе системы, однако затем акцент на них часто не делается. Термин "критические" может означать как "жизненно важные для приемки и успешной реализации проекта", так и "критические с точки зрения бизнеса или функциональности". Участки системы, определенные как критические, — хорошие кандидаты на макетирование. Макеты помогают проектировщику лучше понять поставленные требования. Кроме того, они помогают доказать, что требования, связанные с критическим участком, могут быть выполнены. Во многих случаях полезно макетировать несколько подходов к решению проблемы и сравнить полученные результаты.
Часто на этапе проектирования возникают новые критические участки. Некоторые функции или участки модели, которые легко определить в логических терминах в процессе анализа, могут стать пугающе сложными для поддержки, когда в процессе проектирования их начинают рассматривать с более "физической" точки зрения.
Между критическими факторами успеха проекта и его рисками существует тесная связь. Очевидно, что если мы не учтем один из таких факторов, то возникнет риск неудачи проекта. Требуется также выявить и другие риски, не обязательно непосредственно связанные с критическими факторами успеха. Риски могут быть связаны с чем угодно — начиная с форсирования технологии (например, разработки на базе бета-версий ПО) и кончая кадровыми рисками (например, риском невозможности набора достаточного числа сотрудников необходимой квалификации).
Одним из критических факторов успеха системы проката автомобилей является маленький временной интервал для прогона программы составления и выдачи счетов. Эту проблему мы решаем путем разработки данной программы на ранней стадии проекта, чтобы осталось побольше времени для тестирования, оптимизации и настройки. Мы знаем, что время ответа приложения, работающего в диалоговом режиме, является определяющим фактором — обычно клиент спешит, и довольно часто в офисе стоит очередь. Мы согласны с пользователями, что для 80% всех поэкранных транзакций необходимо обеспечить время ответа в пределах секунды. Еще один важнейший критерий — пропускная способность, так как прогон программы оформления счетов-фактур должен длиться не более 6 часов, а за один прогон может обрабатываться до 500000 операций со счетами. На наш взгляд, следует использовать средства параллельной обработки Oracle в сочетании с симметричной многопроцессорной системой. Кроме того, мы рассмотрим вопросы создания распределенной базы данных, охватывающей удаленные офисы.
Оценка системных ограничений
Все разрабатываемые системы каким-либо образом ограничены. Мы уже упоминали о том, что могут быть жестко установлены смета и (или) срок реализации. Могут существовать и другие бизнес-ограничения, например необходимость проверки допусков персонала к секретным работам перед началом выполнения какого-нибудь важнейшего проекта оборонного характера. Могут приниматься (причем необратимо) решения иного плана, например, относительно выбора аппаратной платформы, программного обеспечения, совместимости с унаследованными системами и т.д. и т.п. Если проект представляет собой расширение существующей системы, то число унаследованных ограничений может быть очень большим. Вы должны проверить осуществимость поставленных при анализе требований в свете всех этих ограничений (и увидеть, что собираетесь решить воистину невыполнимую задачу!).
В системе проката автомобилей мы ограничены жесткими временными рамками. Кроме того, установлены ограничения на время реакции экранных форм и производительность программы создания счетов-фактур и расчета стоимости заказа. Мы полагаем, что все эти критерии достижимы, и будем решать каждую из проблем в процессе проектирования в индивидуальном порядке.
Определение целевой архитектуры
Что мы имеем в виду под словом "архитектура"? Конечно, нам необходимо выбрать аппаратную платформу (или платформы). Обратите внимание на то, что мы говорим "платформы". В системе может работать несколько компьютеров, относящихся к разным платформам; весьма вероятно, что у нас будет именно такая ситуация. Поэтому нам дополнительно потребуется решить следующее:
• Будет ли это система клиент/сервер?
• Будет ли база данных распределенной или реплицированной? Если да, то все базы данных будут продуктами Oracle или же это будет неоднородная сеть?
• Может быть, для обработки требуемой нагрузки или достижения заданной пропускной способности нам понадобится Oracle Parallel Server?
Эти решения часто принимают до этапа проектирования. Поэтому в процессе проектирования полезно опять рассмотреть причины, по которым были приняты такие решения. Довольно часто возникают препятствия, которые не были предусмотрены. Предположим, вы решили спроектировать удобную для пользователя систему клиент/сервер с графическим пользовательским интерфейсом. Однако затем вы узнали, что доступ к этой системе необходим еще одной группе пользователей, у которых есть только текстовые терминалы VT100. В этом случае можно выбрать один из следующих вариантов: создать общие приложения и не использовать некоторые возможности архитектуры клиент/сервер и графического пользовательского интерфейса или разработать два комплекта прикладного программного обеспечения.
Если в среде используется сеть, то в плане необходимо предусмотреть ряд дополнительных задач. Вам понадобится определить требуемые уровни сервиса сети и изучить либо спроектировать ее топологию. Именно на этом этапе следует определить экстренные действия и запланировать меры на случай выхода из строя сети. Если вы планируете использовать существующую сеть, необходимо путем мониторинга убедиться в том, что она имеет достаточный резерв полосы пропускания для поддержки нового приложения.
В системе проката автомобилей запланировано использование технологии клиент/сервер. Внешний интерфейс основан на Microsoft Windows 95, а серверные машины — на базе Unix. Эти серверы будут симметричными многопроцессорными системами, что позволит оптимизировать пропускную способность при обработке больших пакетных заданий. Мы будем использовать распределенную базу данных, и в каждом пункте проката будет локальная база данных.
Выявление потенциальных узких мест в предлагаемой системе
Если вам вдруг кто-нибудь скажет, что производительность не имеет никакого значения для компьютерной системы, примите это замечание с юмором или истолкуйте его следующим образом: время ответа не является критическим фактором успеха системы. Лучше всего попросите объяснить, что конкретно значит это замечание и почему время реакции не важно. Попробуйте дать количественную оценку: приемлемо ли время ответа на запрос, равное 1 часу?
Производительность всегда является важным фактором в любой системе. В каждой системе где-нибудь да есть узкое место. Жизнь такова, что устранив одно узкое место, вы натолкнетесь на следующее. Если последовательно устранять их, то в конце концов вы добьетесь (если удача вам сопутствует) приемлемого результата.
Диапазон узких мест достаточно широк: от неприемлемой нагрузки на сервер в результате слишком большого числа пользователей, дающих сложные запросы, до ограничений на количество пакетных потоков, что лимитирует возможности обработки заданий по вечерам. Процесс выявления потенциальных узких мест можно упростить, начертив график нагрузок на определенный период времени — день, неделю или месяц.
В системе проката автомобилей уже имеются признаки того, что транзакции, которые нужно распределить по базам данных, будут основным источником узких мест. Необходимо секционировать и фрагментировать данные в сети таким образом, чтобы число распределенных транзакций было минимальным.
Обзор продуктов третьих фирм
Иногда разработчики и проектировщики набрасываются на проектирование и реализацию сломя голову, желая побыстрее выдать какой-нибудь результат. При этом не всегда уделяется должное внимание уже имеющимся средствам. Между тем на рынке появляется все больше и больше продуктов третьих фирм, которые работают с базами данных Oracle. Номенклатура их велика: от комплектов приложений, например, Oracle Financials и SAP, до маленьких утилит, таких как инструментальные средства администрирования БД, планировщики пакетных заданий, дополнительные модули безопасности и т.д.
Не жалейте времени на объективную оценку готовых продуктов и сравнение их друг с другом и с вашим доморощенным решением. В приложении А мы подробно расскажем о том, с какими проблемами вам, может быть, придется столкнуться при работе с покупным ПО. Если вас жестко ограничивают сроки и смета, то покупное ПО может несколько ослабить напряжение (а может и усилить его).
В нашей системе проката автомобилей мы решаем оценить программы планирования пакетных заданий, которые обеспечивают большую гибкость, чем стандартные Unix-утилиты сrоп и at. В частности, нас интересуют продукты, которые позволяют сохранять информацию о заданиях и выполнениях в таблицах Oracle. Мы сможем с их помощью написать собственные отчеты и программно запускать запросы путем простой вставки в таблицу.
Согласование стандартов проектирования и реализации
Вам понадобится система стандартов, регламентирующих такие вещи, как правила именования объектов базы данных, стандарты проектной документации, механизмы инициирования изменений в программах и т.д. Кроме того, понадобятся стандарты, определяющие правила использования языков SQL и PL/SQL, и отдельный стандарт на каждый инструмент или продукт, используемый для разработки.
Перед тем как тратить время на изобретение собственных стандартов, выясните, есть ли в вашей организации система стандартов, и спросите, какие стандарты использовались в предыдущих проектах. В мире стандартов постоянно изобретается колесо, причем не одно. Если вы примете систему существующих стандартов, обязательно проанализируйте их и адаптируйте к конкретным потребностям своего проекта. Вам разрешается изобрести (или, по крайней мере, усовершенствовать) небольшую часть колеса!
В нашем примере продукты Oracle в данной организации еще не использовались, поэтому нам придется разрабатывать стандарты с нуля. Впрочем, мы нашли в Internet несколько стандартов, которые распространяются как условно-бесплатное ПО, и использование их в качестве отправной точки позволит избежать массы тяжелой работы.
Рассмотрение возможности использования CASE-средств
На данном этапе можно рассмотреть возможность инсталляции инструментального средства автоматизированной разработки систем (CASE). Однако если анализ систем выполнялся не в такой программе, то нужно будет взвесить преимущества использования CASE, положив на другую чашу весов ненавистную задачу преобразования текущих результатов анализа в формат этого CASE-продукта. Некоторые CASE-продукты позволят непосредственно перейти к проектированию и путем "обратного проектирования" вернуться к анализу.
Несмотря на популярность CASE, у нас есть серьезные практические и теоретические замечания относительно преимуществ обратного проектирования определения физической базы данных. Этот метод создает неудачную иллюзию того, что данные анализа регистрируются, тогда как в действительности это почти наверняка не происходит, поскольку содержащаяся в спроектированной структуре информация отличается отданных анализа. Это несколько напоминает заявления о способности описать личность человека путем исследования его гардероба; некоторые полезные указатели вы получите, но полную картину вряд ли построите.
В нашей системе-примере анализ проводился средствами Oracle Designer/2000, и мы будем продолжать пользоваться этим продуктом при проектировании.
Свидание инфраструктуры проектирования и полной среды реализации
Для проведения проектирования и реализации необходимы аппаратные и программные ресурсы. Кроме того, нужен механизм, позволяющий контролировать всю создаваемую документацию и код. Рекомендуем решить эти вопросы на ранних стадиях проекта, чтобы эти средства были доступны по мере необходимости. Вопросы контроля исходного кода рассматриваются в главе 15.
Проектирование базы данных
Задачи, изложенные в этом разделе, касаются проектирования реальной базы данных. Именно на этом этапе мы проектируем определения физических таблиц и столбцов, индексы или кластеры для их поддержки, ограничения и триггеры, которые вводят определенные правила, и элементы управления целостностью, а также некоторую часть резидентного кода базы данных.
Построение согласованной, реализуемой и нормализованной информационной модели
Работа проектировщиков базы данных очень зависит от того, насколько точна информационная модель. Модель, созданная на этапе анализа, не должна содержать никаких непонятных конструкций, которые нельзя реализовать в базе данных Oracle7 (подробнее об этом в главе 3). Эта модель должна быть полностью преобразована в третью нормальную форму (3НФ) или в нормальную форму Бойса-Кодда (НФБК). Четвертая и пятая нормальные формы (они также описываются в главе 3) вам не нужны.
Построение логической и физической модели данных
Это основной этап той части процесса проектирования, которая касается непосредственно базы данных. Полученная в процессе анализа концептуальная модель сначала преобразуется в логическую структуру, а затем в физическую. После этого для целей разработки создается пробная база данных. Логическая модель развивается и совершенствуется до самого конца этапа проектирования — по мере принятия новых решений и внесения изменений. К моменту перехода от проектирования к реализации модель данных должна стать более устойчивой, поскольку "физические" вопросы (индексы, размещение файлов и выбор размеров) уже решены.
Помните, что проектирование базы данных не может происходить в отрыве от проектирования приложений и модулей. Это особенно характерно для Oracle7, где бизнес-правила могут создаваться как ограничения и другие резидентные объекты базы данных, например, как хранимые процедуры.
В следующем перечне представлены основные задачи, которые необходимо решить при создании рабочей базы данных. Для каждого пункта списка мы указываем главу нашей книги, в которой данный предмет рассматривается подробно.
• Выявить нереализуемые и необычные конструкции данных в модели "сущность-отношение" и в определениях сущностей (глава 3).
• Разрешить все дуги, супертипы и подтипы (глава 3).
• Изучить все первичные и внешние ключи (главы 3 и 6).
• Спроектировать и реализовать денормализацию базы данных с целью ускорения обработки запросов во всех критичных по времени приложениях (глава 4).
• Определить, какие прикладные процессы необходимо реализовать в схеме базы данных как хранимые процедуры (глава 16).
• Выявить и реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных (главы 15 и 16).
• Спроектировать и сгенерировать триггеры для реализации всех централизованно определенных правил для данных и правил целостности данных, которые не могут быть заданы как ограничения (глава 15).
• Разработать стратегию индексирования и кластеризации (глава 6).
• Выполнить оценку размеров всех таблиц, кластеров и индексов (глава 9).
• Определить уровни доступа пользователей, разработать и внедрить правила обеспечения безопасности и аудита. Создать роли и синонимы для обеспечения многопользовательского доступа с согласованными уровнями полномочий доступа (глава 10).
• Разработать сетевую топологию базы данных и механизм бесшовного доступа к удаленным данным (реплицированная или распределенная база данных) (глава 12).
Создание базы данных для разработки
Чаще всего этим занимается администратор базы данных, отвечающий за разработку, если он у вас есть. В противном случае это приходится делать проектировщику. Разработчикам нужна физическая база данных, с которой они могут работать; проектировщикам такая база нужна для проверки своих идей и теорий. В процессе реализации проекта обычно создается несколько "поколений" базы данных, и ее нужно жестко контролировать. Вопросы управления исходным кодом и версиями освещаются в главе 15.
Для нашей системы проката автомобилей мы создаем экземпляры DEV1, DEV2 и DEV3. Они будут циклически использоваться для обозначения версий разрабатываемой базы данных. Такой "карусельный" подход гарантирует, что разработчики, находящиеся на полпути в разработке модуля, не будут сбиты с толку новой редакцией базы данных. Мы создаем еще один экземпляр, SYS_TEST.
Проектирование процессов и кода
Параллельно с проектированием модели данных вам потребуется выполнять проектирование процессов (и, в конечном итоге, разработать спецификации своих модулей). Эти две задачи тесно переплетены между собой. Разделительная линия особенно неуловима в Oracle7, потому что эта версия СУБД Oracle допускает наличие обрабатывающей логики в базе данных.
Главная цель проектирования процессов заключается в отображении определений функций, полученных на этапе анализа, в модули, которые будут реализованы как отдельная единица исходного кода (возможно, с применением совместно используемых файлов, таких как файлы-заголовки С). Определения модулей затем раскрываются в спецификации программ. В этом разделе описываются основные задачи, которые необходимо выполнить для достижения этой цели.
Перед тем как рассматривать перечень задач, необходимо уяснить, что некоторые атомарные функции, полученные при анализе, вообще не будут отображены в модули. Они будут преобразованы в ручные процедуры или принципы работы, т.е. в нечто, находящееся вне компьютерной системы. Такие процедуры должны документироваться в руководствах пользователя, и ни в коем случае нельзя пренебрегать ими во время проектирования. В большинстве случаев эти процедуры представляют собой задачи, которые нельзя реализовать в рамках компьютерной системы. Однако в некоторых случаях в процессе проектирования мы будем использовать те или иные принципы работы для реализации чего-то, чего можно достичь в этой системе. Это может делаться для удобства или просто для экономии времени.
Выбор инструментов для реализации
Подойдя вплотную к этапу проектирования, проектировщик часто обнаруживает, что не представляет, какие инструменты нужно использовать при реализации. Если это так, составьте краткий перечень имеющихся продуктов и оцените каждый из них. Откладывание этого решения "на потом" может серьезно повлиять на проектирование модулей и даже на проектирование модели данных. Некоторые наиболее популярные инструментальные средства разработки графического пользовательского интерфейса, экранных форм, отчетов и нерегламентированных запросов рассматриваются в главе 19.
Отображение функции в модули
Мы должны разработать перечень функций, которые будем реализовывать при помощи модулей. Никакого однозначного соответствия здесь нет и быть не может, потому что функции организованы по бизнес-категориям, а мы реорганизуем их для упрощения разработки. Это означает объединение некоторых функций, обладающих общими или похожими возможностями, а в некоторых случаях — разбиение функции, которая чересчур сложна и имеет (что обнаруживается в процессе ее проектирования) общие черты с другой функцией. Процесс отображения подробно рассматривается в главе 15.
В нашей системе проката автомобилей имеется функция для составления счета для отдельного клиента и функция для ежемесячного составления счетов. Эти задачи имеют много общего, поэтому мы создадим модуль под именем Calculate bill for Customer (составить счет для клиента), который будет непосредственно вызываться из экранной формы или программы ежемесячного создания счетов. В этот модуль передается идентификатор клиента и пара дат, а возвращает он сумму, которую клиент должен уплатить за данный период.
У нас также есть несколько интерфейсных функций, которые берут данные из внешних систем, читая двумерные файлы. Каждая из этих функций должна открывать файлы, управлять этими файлами и читать их, а также регистрировать ошибки. Для решения этих общих задач мы решаем написать универсальные модули.
Обеспечение перемещения по программам
В процессе проектирования модулей мы делаем разметку меню и определяем механизмы на базе горячих клавиш, позволяющие переходить непосредственно из одного приложения в другое. Существует два вида непосредственного перемещения: с контекстом и без контекста. Перемещение с контекстом означает, что целевая экранная форма автоматически наполняется данными, связанными с теми, которые находятся в исходной форме. Перемещение без контекста означает, что целевая форма может не содержать никаких данных или содержать данные, не связанные с исходными.
В нашей системе проката автомобилей мы строим гибкий механизм перемещения. Например, мы позволяем пользователю искать в одном окне запись клиента, а в другом — свободный автомобиль; оба эти элемента можно копировать в "контекстную область". Когда пользователь открывает экранную форму Rent Car, данные об автомобиле и клиенте автоматически переносятся туда из контекстной области. Альтернативный метод: пользователь может сразу перейти к экранной форме Rent Car без контекста и выполнить поиск, в результате которого данные будут "втянуты" в эту форму.
Создание определении или спецификации модулей
Это основная часть функционального этапа проектирования. На этой стадии необходимо:
• преобразовать функциональные определения анализа в реализуемые модули;
• написать спецификацию, выражающую функциональные возможности в физических категориях;
• определить инструментарий для создания кода приложений и назначить инструменты для отдельных функций.
Для каждого модуля или единицы кода необходимо разработать спецификацию, по которой его можно будет сгенерировать. Спецификации значительно различаются по степени детализации и содержанию не только в разных проектах, но даже в рамках одного проекта. Спецификация модуля для программы, ориентированной на базу данных, должна как минимум содержать перечень таблиц, к которым производится доступ, с указанием типа (типов) доступа (вставка, удаление, запрос, обновление, ссылка). Рекомендуемое содержание спецификации модуля рассматривается в главе 15.
Для нашей системы проката автомобиля мы выбрали в качестве инструментария следующие средства: Pro*C, PL/SQL, Oracle Forms и Oracle Reports. Мы отображаем бизнес-функции в модули. Например, Check for cars requiring service (Проверить наличие автомобилей, требующих обслуживания) становится модулем CRB0110: Produce a report of cars requiring service, который классифицируется как простой отчет, полученный при помощи Oracle Report. Благодаря своей простоте этот модуль имеет минимальную спецификацию, и, по нашим расчетам, его можно спроектировать, сгенерировать и автономно протестировать за четыре дня.
Разработка метрик для проектирования и реализации
Метрики — это просто шаблоны, позволяющие оценить, сколько времени займет создание модуля кода. Они подробно рассматриваются в главе 17.
Рассмотрение возможности применения генераторов
Генераторы кода экономят время и повышают уровень согласованности модулей. Если вам предстоит разработать большое количество относительно несложных модулей и вы ограничены во времени, то генератор кода может оказать существенную помощь. Этот несколько противоречивый вопрос рассматривается в главе 15.
Разработка шаблонов кода
Шаблон кода — это средство, позволяющее устранить из разработки модулей некоторые рутинные, тупые операции. Мы используем как основу для всего нового кода готовый модуль, в который уже встроены некоторые типовые функциональные возможности. Этот прием также описан в главе 15.
Заключительные стадии проектирования
В этом разделе мы опишем некоторые задачи, которые можно отложить на заключительные стадии этапа проектирования. В частности, мы обратим внимание на планирование испытаний системы, прием внешних данных и некоторые сервисные задачи, которые нам, возможно, придется определить.
Проектирование процесса тестирования
Сформулируем общую стратегию тестирования, в которой определяются типы испытаний и сроки их проведения. Как правило, по завершении создания отдельного модуля выполняется автономный тест, затем связанные модули проходят тесты связей, а весь комплект приложений подвергается жесткому системному тесту, за которым следуют пользовательские приемо-сдаточные испытания.
Проектировщик должен обеспечить соответствие системы критериям приемо-сдаточных испытаний, установленным при анализе, и гарантировать проведение испытаний системы в объеме, достаточном для подтверждения ее устойчивости и пригодности к промышленной эксплуатации. Методы испытаний рассматриваются в главе 15.
В нашей системе проката автомобилей мы планируем испытания системы на реальных сценариях. Они могут быть как очень простыми (клиент берет автомобиль напрокат), так и очень сложными (клиент, пользующийся скидкой за приверженность фирме, хочет взять напрокат два автомобиля особо малого класса, но у нас в данном пункте на текущий момент есть только автомобили среднего и спортивного классов).
Экранные формы мы разрабатываем в системе Oracle Forms и создаем план автономных тестов с перечнем стандартных контрольных точек, которые обеспечивают согласованность. Например:
• В каждом блоке перейти в последнее поле и нажать клавишу следующего поля. Курсор должен переместиться в первое поле следующего блока или (если это последний блок) в первое поле первого блока.
• Нажать клавишу справки (F1) из любого поля ввода и проверить, вызывается ли соответствующая контекстная справка.
Исследование внешних и унаследованных систем и механизмов подачи данных
Как много новых баз данных Oracle начинается с совершенно чистого листа? В скольких случаях первый день их реализации начинается с ввода данных? На эти вопросы почти наверняка можно ответить, что таких случаев очень и очень мало, если они вообще бывают. В большинстве организаций уже есть данные, важные для их деятельности, и они хотят, чтобы новое приложение либо обращалось к этим данным, либо принимало их для использования. Прием данных может быть разовым процессом, т.е. таким, в котором данные принимаются из унаследованной системы, выводимой из эксплуатации, и загружаются в новую. Это может быть и такой процесс передачи данных, когда пересылка осуществляется периодически. Механизмы подачи данных — один из основных компонентов приложения хранилища данных. Этот предмет более подробно рассматривается в главе 8.
Система проката автомобилей заменяет систему на базу мэйнфрейма, и в ней предусмотрен разовый прием большого массива данных. Этот прием реализован посредством ряда операций загрузки данных в виде двумерных файлов. Поставлено также требование о постоянном сопряжении с системой бухгалтерского учета. Эта задача будет решаться с помощью набора интерфейсных таблиц, которые загружаются из внешних файлов или выгружаются во внешние файлы для пересылки между системами. Этот интерфейс необходимо максимально автоматизировать.
Формулирование требовании по безопасности, доступу и обслуживанию
Каждая система имеет свои требования к безопасности, аудиту, резервному копированию и восстановлению, регистрации событий, архивации и так далее. На стадии анализа эти требования очень часто не учитываются, так как их считают "физическими" атрибутами системы. Однако на этапе проектирования необходимо четко сформулировать эти требования и определить механизмы их реализации. Требования такого типа (общие для всей системы) — идеальные кандидаты на реализацию в виде объектов базы данных Oracle7 (триггеров, хранимых процедур и т.д.).
Определяя требования к безопасности системы, обязательно нужно указать существующие на данный момент классы конечных пользователей.
Эти вопросы подробно обсуждаются в главе 10.
В системе проката автомобилей поставлено следующее требование: каждая финансовая операция должна регистрироваться. Мы решим эту задачу путем занесения деталей операции в таблицу аудита, используя триггеры на таблицах, содержащих финансовые данные. Некоторые операции, например возврат переплаченной суммы, должны будут утверждаться уполномоченным на это сотрудником. Передача их в систему бухгалтерского учета будет возможна только после утверждения. Мы введем правило, по которому пользователи должны будут изменять свой пароль через каждые четыре недели. Эта функция будет реализована в рамках процесса регистрации в системе.
Резервное копирование является в нашем случае проблемой, так как во многих отделениях нашей компании есть серверы, а обслуживающего персонала нет. Мы принимаем решение вложить средства в приобретение программ резервного копирования, позволяющих автоматизировать этот процесс так, чтобы вмешательство оператора требовалось только для ежедневной смены лент.
Составление функциональной и технической спецификации
Многие результаты этапа проектирования объединяются в документ, называемый функциональной спецификацией. Этот документ объясняет проектировщикам требования к системе и содержит предложения по поводу того, что система должна делать. Основное его назначение — получить санкцию пользователя на завершение проектирования. По этой причине не нужно включать в этот документ много технических деталей, которые пользователь не сможет охватить или даже понять. В спецификации должны быть отражены основные проектные решения и дан обзор базы данных и модулей.
Если функциональная спецификация предназначена для пользователя, то техническая спецификация системы — это аналогичный документ для разработчиков. Он также представляет собой совокупность результатов проектирования, но содержит больше деталей.
Если используется CASE-технология, то техническая спецификация может состоять из ряда отчетов из репозитария.
Обеспечение полноты проектирования
Перед переходом к реализации, нужно убедиться в том, что проектирование завершено полностью, причем с качеством, необходимым для проекта. На этом этапе следует выполнить целый ряд проверок. Полезная отправная точка — матрица использования таблиц по модулям.
К этапу реализации и дальше
Как только начинается реализация, проектировщики могут приводить в порядок свои столы, выходить из системы и уходить с сознанием хорошо сделанной работы. Так? А вот и нет, к сожалению. Работа проектировщика часто продолжается и на этапе реализации, а во многих случаях — и после нее. Что же делают проектировщики?
Выше мы отмечали, что проектирование — это максимально эффективное использование технологии. По этой причине проектировщикам нужен практический опыт работы с современными аппаратными и программными средствами. Большинство хороших проектировщиков любят участвовать в проектах как разработчики и входят в состав группы разработчиков. Часто они занимают и более высокие посты, например, становятся руководителями групп.
Ниже описано, какую помощь могут оказать проектировщики на этапе реализации.
• Когда модуль передается разработчику для кодирования, полезно, чтобы проектировщик, написавший спецификацию этого модуля, провел "бумажный" семинар по нему и продемонстрировал необходимые прототипы.
• После написания кода проектировщик может участвовать в его пересмотре, выполняя роль полиции стандартов и агентства по контролю за выполнением проектных решений!
• Большинство проектов с целью повышения управляемости разбивается на этапы, поэтому выполнение крупных проектов длится годами без каких-либо результатов. Когда начинается реализация очередного этапа, вполне вероятно, что после этого последуют новые этапы анализа и цикл начнется заново. Появляются новые ограничения, которые следует учесть на текущем этапе, и вам потребуется выполнить дополнительные работы по планированию перехода от этого этапа к следующему... Может быть, когда-нибудь вы и выберетесь из этой ситуации!
* Последнее замечание, касающееся временных ограничений, весьма актуально. Руководители проектов, связанных с 2000-м годом, могут рассказать вам очень много о графиках, которые невозможно сдвинуть!
** Clegg, Dai and Richard Barker, Case Method Fast-Track. A PAD Approach, Addison-Wesley, 1994.
Знаете ли Вы, что компонентное сборочное программирование - это объектно-ориентированное сборочное программирование, основанное на распространении классов в бинарном виде и предоставление доступа к методам класса через строго определенные интерфейсы. Компонентное сборочное программирование поддерживают технологические подходы COM, CORBA, .Net.
