Диплом К

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

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

4.2.3. Расчет ресурсов оперативной памяти.

Для своей работы каждый индекс занимает определенный объем оперативной па-

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

ся в расчете на максимальную высоту индекса. Формула для объема оперативной памя-

ти, требуемого при открытии одного индекса следующая:

где rmax – максимальное число уровней в индексе, Lк max – масксимально длинный ключ,

который может быть помещен в индекс, Lз max –максимально длинное значение, которое может быть помещено в индекс.

Графичекая зависимость объема требуемой оперативной памяти от размера блока индекса приведена на рисунке 32. Четко видна прямо пропорциональная зависимость от длины блока индекса.

5. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

5.1. Объект рассмотрения

Данный раздел посвящен анализу процессов создания сложных объектно-

ориентированных программных систем. Применяемая для этих целей объектно-

ориентированная технология разделяется на три большие раздела:

объектно-ориентированное программирование;

объектно-ориентированное проектирование;

объектно-ориентированный анализ.

Объектно–ориентированая технология применяется для создания программ высо-

кой степени сложности. В качестве объекта рассмотрения выбраны так называемые ин-

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

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

5.2. Сложность программных систем

Конечно, существует много прикладных программ, разработанных и сопровожда-

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

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

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

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

альных программных комплексов определяется четырьмя основными причинами:

сложностью решаемых проблем;

сложностью управления процессом разработки;

гибкостью создания программной системы;

сложностью описания поведения отдельных подсистем.

Рассмотрим эти причины подробнее.

5.2.1. Сложность решаемых проблем К элементам, входящим в состав разрабатываемых систем, часто предъявляются

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

внутреннюю сложность программной системы.

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

Кроме того, есть еще одна сложность: изменение требований к программной си-

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

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

Эволюция – это внесение изменений в систему в ответ на изменившиеся требования к ней.

5.2.2. Сложность управления процессом разработки Большое число требований к программной системе неизбежно приводит

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

тива разработчиков. При наличии коллектива возникают трудности с координацией хо-

да работ над системой, которые сильно возрастают с ростом числа разработчиков.

Главная проблема – сохранение основных идей в ходе разработки.

5.2.3. Гибкость программных систем Процесс создания программных систем обладает большой гибкостью. Разработчик

может реализовывать поставленную задачу многими разными способами. Дело услож-

няется тем, что в программировании еще практически нет стандартов на базовые эле-

менты (динамические массивы, списки, деревья и другие структуры данных) программ-

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

ты будущей системы.

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

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

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

5.3. Анализ сложных систем

5.3.1. Признаки сложных систем Согласно [9] выделяются следующие признаки сложной системы:

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

вен.

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

стемами. Взаимодействия внутри одной подсистемы происходят гораздо чаще, чем вза-

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

Количество типов подсистем, входящих в иерархию сложной системы ограниче-

но. Подсистемы более высоких уровней состоят из разнообразных комбинаций не-

скольких типов подсистем нижних уровней.

Разработка сложных систем остается серьезной проблемой. Главная причина этого

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

ных размеров. Это является главной причиной разработки новых методов проектирова-

ния сложных программных систем.

5.3.2. Общие принципы анализа сложных систем Наиболее часто используемым является принцип декомпозиции. Он гласит: при

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

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

Декомпозицию делят на два вида: процедурную и объектно–ориентированную.

При процедурной декомпозиции выделяют базовые процедуры, каждая из которых вы-

полняет один этап общего процесса. При объектно-ориентированной декомпозиции вы-

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

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

создать новый файл;

открыть файл;

закрыть файл;

удалить файл;

записать данные в заданный файл;

считать данные из заданного файла;

Структурная схема такой простейшей файловой системы приведена на рис. 33. Базовы-

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

О п ерация с ф айло м

Рис. 33. Пример файловой системы

При объектно-ориентированной декомпозиции выделим следующие объекты:

файл;

Çàï èñü

Рис. 34. Объекты файловой системы

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

Следующим является принцип абстракции. Он гласит: надо выделить только су-

щественные стороны анализируемой системы, чтобы не обрабатывать лишнюю инфор-

мацию, поступающую от нее, а концентрироваться на информации только о выделен-

ных сторонах.

Последним является принцип иерархии. Он утверждает, что поведение всех под-

систем одного типа одинаково.

5.4. Объектно-ориентированные методы проектирования

5.4.1. Цель и продукт проектирования Согласно [10], цель проектирования – создание программной системы, которая:

удовлетворяет заданным функциональным требованиям;

удовлетворяет требованиям по потреблению ресурсов и эксплуатационным каче-

ствам;

имеет приемлемую цену;

удовлетворяет критериям дизайна;

Продуктом проектирования являются модели, позволяющие понять структуру бу-

дущей системы, приступить к ее программированию и наметить схему ее применения.

5.4.2. Определение объектного подхода Объектный подход к проектированию сложных программных систем представляет

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

ектирования программ и на базе накопленного опыта в программировании, прежде все-

го объектно-ориентированном.

Объектно-ориентированное программирование – это методология программи-

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

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

вания к объектно-ориентированным языкам программирования: язык программирова-

ния является объектно-ориентированным тогда и только тогда, когда выполняются сле-

дующие условия:

есть поддержка объектов в виде структуры данных и операций над ними

введены типы объектов – классы

классы могут наследовать свойства других классов

Объектно-ориентированное проектирование – это методология проектирова-

ния на основе принципа объектно-ориентированной декомпозиции.

От процедурного проектирования объектно-ориентированное отличается приме-

нением именно объектно-ориентированной декомпозиции.

5.4.3. Компоненты объектно-ориентированного проектирования Объектно-ориентированное проектирование имеет четыре необходимых элемента:

Абстрагирование;

Ограничение доступа;

Модульность;

Иерархия.

Эти элементы являются необходимыми, в том смысле, что без любого из них про-

ектирование не будет объектно-ориентированным.

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

Абстрагирование. Абстракция – это существенные характеристики некоторого объекта, которые отличают его от всех других видов объектов.

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

Абстракции делят на статические и динамические. Статические остаются неиз-

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

Представителем абстракции в программной системе является класс.

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

стве выделенных абстракций.

Ограничение доступа. Ограничение доступа – процесс защиты отдельных эле-

ментов объекта, не затрагивающий существенных характеристик объекта, как цело-

го.

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

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

ничение доступа позволяет минимизировать затраты на внесение изменений в програм-

му, сохраняя ее надежность.

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

структуру данных и заголовки методов класса, а реализация – тела методов класса.

Модульность. Модульность – свойство системы, позволяющее разделить ее на ряд связанных модулей.

Этот принцип является расширением принципа ограничения доступа для про-

граммных систем, содержащих сотни классов. Для модуля, так же как и для класса, тре-

буется два раздела: интерфейс и реализация, служащих для аналогичных целей.

Главная особенность модулей, отличающая этот принцип от ограничения доступа

– это возможность раздельной компиляции модулей. Таким образом, модульность дает возможность размещать разные классы в разных файлах программы.

Результатом разбиения программы на модули является снижение затрат на созда-

ние системы, за счет независимой разработки и тестирования.

Иерархия. Иерархия – упорядоченная система классов, в которой классы-

потомки наследуют строение одного или нескольких классов-предков.

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

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

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

са-предка, а во втором – несколько классов-предков.

5.5. Классы и объекты

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

5.5.1. Объект

Объект – сущность (реальная или абстрактная), имеющая важное функциональ-

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

Состояние объекта – перечень всех возможных свойств данного объекта и текущих значений этих свойств. Перечень свойств объекта обычно постоянен,

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

ний.

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

Определенное воздействие одного объекта на другой называют операцией.

Индивидуальность – свойства объекта, отличающие его от всех других объектов системы. В основном это имена переменных, представляющих объекты в коде про-

граммы. Понятие индивидуальности вводится для различения объектов одного класса с одинаковым состоянием.

5.5.2. Отношения между объектами Функционирование программы представляет собой взаимодействие между объек-

тами. На момент взаимодействия объекты должны иметь доступ друг к другу ("видеть"

друг друга). Существует три способа реализации видимости объекта А объекту Б:

объект А находится в области объекта Б, тогда объект Б может напрямую обра-

щаться к А;

объект А передается как параметр какой-либо операции объекта Б;

объект А является полем объекта Б.

Отношения между объектами реализуются путем вызова операций – по сути это простой вызов подпрограммы. Выделяется два типа отношений между объектами:

отношение использования

отношение включения.

Отношение использования между двумя объектами означает возможность переда-

чи сообщений между ними, т.е. они могут как-то взаимодействовать.

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

class dsCache

{

public : dsCache (ѕ);

int Read (ѕ);

...

};

class dsPage

{