А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 13

1.24. Диаграмма "Участники" для образца EmploymentСтатическая часть образца (диаграмма классов) показана на рис. 1.25.64<<business entity>>Employee ProfileNameAddressBirthdate+profile1..n<<business entity>>EmploymentStart dateEnd date<<busine ss entity>>Organization Profile1..n+employmentNameAddressPurpose+responsible forposition+based onemployment<<business entity>>Positi on Assignment1..n<<busine ss entity>>Positi on1..nРис.

1.25. Статическая часть образца EmploymentДостоинства применения образцов при проектировании ПОзаключаются в следующем:• Возможностьмногократногоиспользования.Повторноеиспользование решений из уже завершенных успешных проектовпозволяет быстро приступить к решению новых проблем иизбежать типичных ошибок. Разработчик получает прямую выгодуот использования опыта других разработчиков, избежавнеобходимости вновь и вновь "изобретать велосипед".• Применение единой терминологии. Профессиональное общение иработа в группе (команде разработчиков) требует наличия единогобазового словаря и единой точки зрения на проблему. Образцыпредоставляют подобную общую точку зрения как на этапеанализа, так и при реализации проекта.• Повышение эффективности труда отдельных исполнителей и всейгруппы в целом. Это происходит из-за того, что начинающие члены65группы видят на примере более опытных разработчиков, какобразцы проектирования могут применяться и какую пользу ониприносят.

Совместная работа дает новичкам стимул и реальнуювозможность быстрее изучить и освоить эти новые концепции.• Создание модифицируемого и гибкого ПО. Причина состоит в том,что образцы уже испытаны временем, поэтому их использованиепозволяет создавать структуры, допускающие модификацию вбольшей степени, чем это возможно в случае решения, первымпришедшего на ум.• Ограничение пространства решений. Использование образцовсоздает границы в рамках пространства решений проектирования иреализации. Таким образом, образец настоятельно рекомендуетпроектировщику границы, которых должна придерживатьсяреализация. Выход за эти границы нарушает строгое соблюдениеобразца и проектных решений и может привести к нежелательнымпоследствиям. Тем не менее, образцы не подавляют творчество.Напротив, они описывают структуру или форму на некоторомуровне абстракции. Проектировщики и разработчики все ещерасполагают многими возможностями для реализации образцов вэтих границах.1.6.

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

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

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

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

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

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

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

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