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

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

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

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

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

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

3 Объектная модель вполне естественна, т.к. ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

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

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

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

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

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

Другая форма проявления взаимосвязи - интег­рация объектной и реляционной технологий. Реляционные СУБД являются основным средством реализации крупномасштабных баз данных и хранилищ данных. Реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляцион­ных системах.

Объектно-ориентированное проектирование имеет точки сопри­косновения с реляционным проектированием. Классы в объектной модели могут некоторым обра­зом соответствовать сущностям. Такое соответ­ствие имеет место только на стадии формирования требований к системе. В дальнейшем цели объектно-ориентированного проектирования и разработки реляционной БД расходятся. Единственно возможным средством преодоления данного разрыва является построение отображения между объектно-ориентированной и реляционной технологиями, которое в основ­ном сводится к отображению между диаграммами классов и реляци­онной моделью.