Структурного и объектно-ориентированного подходов

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

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

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

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

Буч отметил также ряд следующих преимуществ ООП:

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

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

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

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

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

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

Таким образом, структурный подход по-прежнему сохраняет спою значимость и достаточно широко используется на практике. На примере языка UML хорошо видно, что его авторы заимство­вали то рациональное, что можно было взять из структурного подхода: элементы функциональной декомпозиции в диаграммах вариантов использования, диаграммы состояний, диаграммы де­ятельности и др. Очевидно, что в конкретном проекте сложной системы невозможно обойтись только одним способом декомпо­зиции. Можно начать декомпозицию каким-либо одним спосо­бом, а затем, используя полученные результаты, попытаться рас­смотреть систему с другой точки зрения.

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

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

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

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

! Следует запомнить

1. Главным способом преодоления сложности разработки больших систем ПО является правильная декомпозиция.

2. Сущность структурного подхода к разработке ПО заключа­ется в его декомпозиции (разбиении) в соответствии с вы­полняемыми функциями.

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

Основные понятия

Модель, архитектура.

Внешняя сущность, процесс, накопитель данных, поток дан-11 i.ix, сущность, связь, атрибут.

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

Стереотип, образец, кооперация.

? Вопросы для самоконтроля

1. В чем заключаются основные принципы структурного под­хода?

2. Что общего и в чем различия между методом SADT и моде­лированием потоков данных?

3. В чем заключаются достоинства и недостатки структурного подхода?

4. В чем заключаются основные принципы объектно-ориен­тированного подхода?

5. В чем состоят достоинства и недостатки объектно-ориен­тированного подхода?

6. Чем язык UML принципиально отличается от моделей SADT, DFD и ERM?

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

ГЛАВА 3