1.3 Объектно-ориентированные информационные технологии

Интерес к объектно-ориентированным технологиям значительно возрос в последние годы прошлого десятилетия, когда в центре внимания разработчиков программного обеспечения оказались сложные системы, неподдающиеся программированию «в лоб». Создание подобных систем требует выполнения ряда этапов, предшествующих программированию. Традиционно проектирование сложных систем основывалось на декомпозиции систем, т. е. разбиении их на составные части, каждая из которых рассматривалась отдельно от других. Классический подход к разработке сложных систем представляет собой структурное проектирование, при котором осуществляется алгоритмическая декомпозиция системы по методу «сверху – вниз». Жизненный цикл разработки прикладной системы в этом случае складывается из этапов анализа, проектирования, программирования, тестирования и сопровождения, которые выполняются последовательно. Такой метод, называемый каскадным, имеет следующие отличительные особенности:

1. • линейность выполнения этапов жизненного цикла разработки;

2. • четкое разделение данных и процессов их обработки;

3. • использование процедурных языков программирования.

Недостатки каскадного метода очевидны. Главный из них – последовательное выполнение этапов. Например, программирование можно начать только по завершении анализа и проектирования. Это приводит к большим потерям времени, не позволяет быстро разрабатывать прототипы программной системы. Каскадный принцип не состыкуется с итеративным характером разработки программной системы, поскольку на последних этапах может выясниться необходимость внесения изменений в решения, принятые на предыдущих этапах. Для устранения этого недостатка Б. Боэм предложил спиральный подход. Он заключается в том, что разработка проекта ведется как бы по спирали, причем на каждом ее витке выполняются последовательно перечисленные выше этапы, на которых уточняется проект. Этот подход дополняет каскадный метод элементами итеративности. Но и для него характерен ряд существенных недостатков, к числу которых можно отнести:

1. • трудоемкость внесения изменений;

2. • большой объем документации по проекту, затрудняющий программирование;

3. • серьезные ограничения возможностей сборки системы из готовых компонентов;

4. • сложность переноса на другие платформы.

Для того чтобы раскрыть сущность объектно-ориентированного подхода к разработке приложений, рассмотрим главные особенности сложных систем, определяющие требования к методикам и инструментальным средствам, поддерживающим жизненный цикл их разработки. Описывая характерные черты сложных систем, особое внимание следует уделять их иерархическому характеру. Иерархическое построение таких систем облегчает понимание их человеком, возможности которого по восприятию информации весьма ограничены. В иерархических структурах человек может ограничиваться рассмотрением только определенного уровня, не вдаваясь в детали реализации. Для сложной системы целесообразно моделировать два типа иерархии – типовую и структурную. Типовая иерархия отражает взаимосвязи «общее – частное». При объектно-ориентированном подходе ей соответствует иерархия классов. Структурная иерархия показывает связи типа «часть – целое».

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

При разработке больших программных систем широко используется концепция сборочного проектирования, основанная на идее повторно используемых компонент. Сборка прикладной системы из готовых компонент позволяет значительно сократить время разработки. Современные интегрированные программные системы обычно используют в работе стандартные СУБД в основном реляционного типа, причем реализация таких систем обычно осуществляется в клиент-серверной среде. Интеграция прикладной системы с базой данных (БД) ставит перед разработчиками ряд дополнительных задач. Главной из них является преемственность, т.е. возможность использования в разрабатываемом приложении данных, накопленных ранее БД. Кроме того, при разработке приложение в большинстве случаев возникает необходимость проектирования логической структуры новой БД.

Для интегрированных систем с архитектурой клиент-сервер используются специальные инструментальные средства. Стремление избавиться от недостатков традиционного структурного подхода привело к развитию идей, основанных на объектной композиции. Такой подход к разработке программных систем получил название «объект и класс». В реальном мире, а точнее в интересующей разработчика проблемной среде в качестве объектов могут осматриваться конкретные предметы, а также абстрактные или реальные сущности. Например, объектами могут быть покупатель, фирма, производящая определенные товары, банк, заказ на поставку. Объект обладает индивидуальностью и поведением, имеет атрибуты, значения которых определяют его состояние. Так, конкретный пользователь, делая заказ, может оказаться в состоянии, когда денег на его счете не хватает для оплаты, а его поведение в этом случае заключается в обращении в банк за кредитом.

Каждый объект является представителем некоторого класса однотипных объектов. Класс определяет общие свойства для всех его объектов. К таким свойствам относятся состав и структура данных, описывающих атрибуты класса и соответствующих объектов, и совокупность методов – процедур, определяющих взаимодействие объектов этого класса с внешней средой. Например, описание класса «магазины» может включать такие атрибуты, как название и адрес, которые индивидуальны для каждого объекта этого класса – конкретного магазина; штата сотрудников; размера текущего счета, определяющего состояние объектов; методов: формирование заказов на поставку товаров, передача товара со склада в торговую секцию и т. д. Объекты и классы обладают характерными свойствами, которые активно используются при объектно-ориентированном подходе и во многом определяют его преимущества. Существует достаточно распространенное мнение, что объектно-ориентированный подход труден для понимания, поэтому переход на объектно-ориентированные технологии связан с большими затратами, которые не окупаются. В действительности дело обстоит по-другому.

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