Программная инженерия

Лекция 8. Объектно-ориентированное проектирование программных средств

—объекты предоставляют сервисы (методы) другим объектам и со­ здаются в реальном времени на основе определения класса объектов;

—объекты могут быть реализованы последовательно и параллельно, параллельный объект может быть пассивным, у которого состояние изме­ няется только через его интерфейс, или активным, который может изме­ нять свое состояние без вмешательства извне;

—в процессе объектно-ориентированного проектирования возможно создание ряда различных моделей, которые можно разделить на статичес­ кие (модели классов, модели обобщения, модели агрегирования) и дина­ мические (модели последовательностей, модели конечного автомата);

—важным преимуществом объектно-ориентированного проектиро­ вания является то, что он упрощает процесс модификации системы.

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

Использование методов ООП строго регламентировано, поэтому:

—возрастает производительность труда разработчиков благодаря пе­ реходу к высокоэффективному методу — на базе предварительного анали­ за проекта;

—запросы и объекты реального мира проще моделируются путем концентрации внимания на классах, а не на алгоритмах их функциониро­ вания;

—компоненты системы легко изменяются и применяются повторно;

—требования проще отслеживаются;

—поддерживается эффективное прототипирование;

—разработка проекта отличается непрерывностью в представлении объектов — одни и те же типы диаграмм применяются как при анализе, так и на этапе разработки;

—работа по проектированию может осуществляться с помощью уни­ версальных технологических инструментов.

200

8.1. Задачи и особенности объектно-ориентированного проектирования...

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

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

—объектно-ориентированное проектирование — разработка моде­ ли системы ПС и системной архитектуры с учетом системных требований,

вкоторой определение всех объектов подчинено решению конкретной за­ дачи;

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

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

При ООП основное внимание уделяется тому, что следует делать, каким образом добиться цели, а процесс ее достижения целиком зависит

201

Лекция 8. Объектно-ориентированное проектирование программных средств

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

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

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

В программных средствах при ООП рекомендуется выделять три

уровня:

—уровень интерфейсов, который занимается всеми взаимодействи­ ями с другими частями системы и предоставлением внешних интерфейсов системы;

—уровень сбора данных, управляющий сбором информации из внеш­ ней среды и обобщающий данные перед отправкой их в систему построе­ ния обобщенных результатов;

—уровень объектов, в котором представлены и описаны все объек­ ты, используемые в процессе сбора исходных данных.

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

202

8.1. Задачи и особенности объектно-ориентированного проектирования...

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

Язык UML представляет набор разработанных инженерных задач

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

—поддержка на уровне пользователей готового к применению, вы­ разительного визуального языка моделирования, применяемого для разра­ ботки и обмена моделями;

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

—поддержка формального базиса для представления языка модели­ рования;

—поддержка высокоуровневых понятий, таких как компоненты, эле­ менты сотрудничества, каркасы и шаблоны;

—интеграция наилучшего опыта.

Разработчики UML установили, что даже при использовании совре­ менных передовых технологий, при сборе требований, анализе и разработ­ ке продолжается борьба с неадекватными и постоянно изменяющимися требованиями заказчиков (см. лекцию 6). Варианты использования пред-

203

Лекция 8. Объектно-ориентированное проектирование программных средств

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

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

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

программных средств

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

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

204

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

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

Таблица 8.1

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

Существует ряд подходов к определению классов объектов:

— использование грамматического анализа естественного языкового описания системы, объекты и атрибуты — это существительные, операции

205

Лекция 8. Объектно-ориентированное проектирование программных средств

И сервисы — глаголы, такой подход реализован в иерархическом методе объектно-ориентированного проектирования, который широко использу­ ется;

—использование в качестве объектов ПС событий, объектов и ситуа­ ций реального мира из области приложения (например самолетов, роле­ вых ситуаций менеджера) для реализации таких объектов, могут потребо­ ваться специальные структуры хранения данных (абстрактные структуры данных);

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

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

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

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

206

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

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

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

—материальный предмет (или индивидуум);

—выполняемая роль;

—событие;

—взаимодействие (контракт);

—операционная процедура (обзор);

—организационная единица;

—место (банк);

—структура.

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

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

207

Лекция 8. Объектно-ориентированное проектирование программных средств

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

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

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

208

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

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

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

—представление с помощью существительного;

—описание объекта в терминах реального времени;

—возможность служить индикатором состояния;

—обладание типом данных;

—идентичность для объектов одного класса — может отличаться по значению, но не по сути;

—возможность получения значения, определенного с помощью до­ мена пересчета (набор определенных значений).

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

—инкапсулирование внутри объекта;

—отклик на стимул- (сообщение);

—возможность действия, выполняемого объектом с помощью друго­ го объекта;

—возможность преобразования, которому подвергается объект. Метод является специфической реализацией операции. Операция (ме­

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

209