Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Анализ

проектирование программного обеспечения 301

4c*Rdtional ftose

courserеа апа1у^8^ШШ1

fidft view Fgrmdfc grov^^e Bt'^p??»'!: loofs ^dd-Ins

low. Help

.^.й.^...'...;...^;....w,.,

.,: :. ,

.migJ.xl

^.^:..>^::::^f-,

^ЩгМ-Л±\':.:;

display schedule(Schedule)

request schedule delete confirmation()

: RegisterForCoursesForm

delete schedule)

confirm schedule^letion()

УУ^

get cunlent

\X 7:

delete current

scheduleO

: ReqistrationController

get schedule(forSemester)

Студент 8:

delete schedule|(forSemester)

Student

9://dHfe()

Schedule

10:

remove studefit(bchedule)

: CourseOfferIng

Рис.

4.10. Кооперативная диаграмма «Зарегистрироваться на курсы»

подчиненный поток «Удалить фафик»

302

Глава 4

'^ Rational йЬ^ё|уз|^Шг|р||||||Ш

Ul 01в Edifc

^law

Fgimtat

i'owse

^«porli: loofe Add*Ir«!

: ReqisterForCoursesForm

submit6cheduie()

sbbmit schedule()

Студент

8://any

conflic:ts?()

:з

: ReqistrationController

save()

4://submitn

Schedule

7://stlllopen?()

add student(Schedule)

Course Offering

has pre-ret}uisites(CourseOfferlng)

5://lsselected?()

10:

mark as enrolled

in()

Student

: PrimaryScheduleOfferlnglnfo

ii^

Рис. 4.11.

Кооперативная диаграмма «Зарегистрироваться на курсы»

—

под-

чиненный поток «Принять график»

классах

виде операций «анализа», которые появляются

там в

процессе построения диаграмм взаимодействия (соотнесения со-

Анализ и проектирование программного обеспечения

303

общений с операциями). Каждая операция «анализа» класса со-

ответствует некоторому сообщению, принимаемому объектами

данного класса. В процессе проектирования каждая операция

«анализа» преобразуется

одну или более операций класса, кото-

рые

дальнейшем будут реализованы в коде системы.

Так, диаграмма классов варианта использования «Зарегист-

рироваться на курсы» (см. рис. 4.6) после построения диафамм

взаимодействия должна принять следующий вид (рис. 4.12).

сош'&с^г¥!аяг}1^^ШШ:*1Ш^ШшШШШ№

i&^-m

»^ т^

iro**<* aspor* 'fiiMwy

х^ ш-^ т^ -Л ^'

«boundary»

RegisterForCoureesForm

// submit scheduleO

// display course offeringsQ

// update scheduleO

// delete scheduleO

// confirm schedule deletionO

// request schedule delete confirmationO

// display scheduleO

// register for coursesO

// display possible operatlonsO

// create scheduleO j

//select4 primary and 2 alternate offerlngsO

I// display blank scheduleO

// update offering selectionsQ j

«entity»

Student

// add scheduleO

// get scheduleO

|// delete scheduleO

//has pre-requisltesO

«entity»

CourseOfferIng

// add studentO

// remove studentO

//still open70

«control»

RegistrationController

{// get course offeringsO

[// get current scheduleO

delete current scheduleO

//submit scheduleO

j//

is registration open?0

// create schedule with offeringsO

// update schedule with new selectionsO

«boundary>>

CourseCatalogSystem

// get course offeringsO

«entity»

Schedule

// deleteO

// submitO

// saveO

// any conflicts?0

// create with offeringsO

// update with new selectionsO

Ж1^^^Ш^^^^^Ш2

;i.^aj

Рис. 4.12.

Диафамма

классов

операциями «анализа»

304 Глава 4

При построении диаграмм взаимодействия возникают проб-

лемы правильного распределения обязанностей между классами.

Для

их

решения существует

ряд

образцов^ некоторые из них при-

ведены ниже.

Образец «Information Expert»

Проблема:

Нужно определить наиболее общий принцип распределения

обязанностей между классами.

системе могут быть определены

сотни классов, выполняющие тысячи обязанностей. При пра-

вильном их распределении система становится гораздо проще

для понимания, сопровождения и развития. Кроме того, появля-

ется возможность повторного использования уже разработанных

компонентов в последующих приложениях.

Решение:

Следует назначить обязанность информационному эксперту

—

классу, у которого имеется информация, требуемая для выпол-

нения обязанности.

Пример:

При выполнении подчиненного потока событий «Обновить

график» варианта использования «Зарегистрироваться на курсы»

(рис.

4.9) студент-пользователь должен получить доступ к своему

графику прежде, чем изменить

его.

Согласно образцу «Information

Expert», нужно определить, объект какого класса содержит инфор-

мацию, необходимую

для

доступа к фафику

На эту роль

информа-

ционного эксперта, очевидно, претендует объект класса-сущности

Student, поскольку фафик принадлежит именно ему Поэтому со-

общение 3 «get schedule(forSemester)» должно быть направлено от

контроллера объекту класса Student.

После

того,

как студент полу-

чит фафик и внесет в него необходимые изменения, они должны

быть зафиксированы в объекте Schedule.

данном случае уже сам

объект Schedule будет ифать роль информационного эксперта,

поскольку он непосредственно доступен контроллеру, и сообще-

ние

«update with new selections» будет направлено именно ему

Следствия:

При распределении обязанностей образец Information Expert

используется гораздо

чаще любого другого

образца. Большинство

^ Ларман

К.

Применение

UML и

шаблонов проектирования.

—

2-е изд.:

Пер.

англ.

—

М.:

Вильяме, 2002.

Анализ и проектирование программного обеспечения 305

сообщений на приведенных выше диаграммах взаимодействия

соответствуют данному образцу. В нем определены основные

принципы, которые уже давно используются в объектно-ориен-

тированном анализе и проектировании. Образец Information

Expert не содержит неясных или запутанных идей и отражает

обычный интуитивно понятный подход. Он заключается в том,

что объекты осуществляют действия, связанные с имеющейся у

них информацией. Если информация распределена между раз-

личными объектами, то при выполнении общей задачи они

должны взаимодействовать с помощью сообщений.

Образец Information Expert, как

многие другие понятия объ-

ектной технологии, имеет соответствующую аналогию в реаль-

ном мире. Например, в организации обязанности обычно рас-

пределяются между теми служащими, у которых имеется необхо-

димая для выполнения поставленной задачи информация. Ответ-

ственность за создание отчета о прибыли и убытках должен нес-

ти тот из служащих, кто имеет

доступ

ко всей информации, необ-

ходимой для создания такого отчета. Возможно, лучше всего для

выполнения этой обязанности подойдет руководитель финансо-

вого отдела предприятия. Профаммные объекты взаимодейству-

ют между собой и обмениваются информацией так

же,

как люди.

Начальник финансового отдела компании может запросить тре-

буемые данные у бухгалтеров, работающих со счетами по деби-

торской и кредиторской задолженности, чтобы составить отдель-

ные отчеты по кредиту и дебету.

В некоторых ситуациях применение образца Information

Expert нежелательно. Например, в системе регистрации нужно

определить, какой объект должен отвечать за сохранение инфор-

мации об учебных курсах в базе данных. Информация, подлежа-

щая сохранению, «известна» объекту Course, а значит, согласно

образцу Information Expert, на класс Course следует возложить

обязанность по сохранению. Логическим следствием такого рас-

суждения является вывод

том, что каждый объект должен отве-

чать

за сохранение себя

в базе

данных.

Однако при этом возника-

ет проблема перегруженности класса лишними обязанностями,

поскольку класс Course должен содержать методы обращения к

базе данных, т.е. должен быть связан с вызовом операторов язы-

ка SQL или сервисов JDBC (Java Database Connectivity). Тогда

этот класс не будет относиться к предметной области и модели-

ровать учебные

курсы.

Кроме

того,

подобные действия будут

дуб-

306 Глава 4

лироваться во многих других классах, информация которых под-

лежит постоянному хранению.

Все эти проблемы приводят к нарушению основного архитек-

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

функций системы на уровни, отраженного в образце «Уровни».

Разнородные функции не должны реализовываться в одном и

том же компоненте. С этой точки зрения класс Course

не

должен

отвечать за сохранение информации в базе данных.

Основное достоинство образца Information Expert

—

поддерж-

ка инкапсуляции. Для выполнения требуемых задач объекты ис-

пользуют собственные

данные.

Необходимое поведение системы

обеспечивается несколькими классами, содержащими требуемую

информацию. Это приводит к определениям классов, которые

гораздо проще понимать и поддерживать.

Образец «Creator»

Проблема:

Нужно определить, кто должен отвечать за создание нового

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

ектно-ориентированной системе является одним из стандартных

видов деятельности. Следовательно, при назначении обязаннос-

тей,

связанных

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

некоторым основным принципом.

Решение:

Следует назначить классу

обязанность создавать экземпля-

ры класса

А,

если выполняется одно из следующих условий:

• класс

афегирует, содержит или активно использует объек-

ты класса Д;

• класс В обладает данными инициализации, которые будут

передаваться объектам класса А при их создании (т.е. класс

является информационным экспертом).

Класс

при этом определяется как создатель (creator) объек-

тов класса А.

Если несколько классов удовлетворяют этим условиям, то

предпочтительнее использовать в качестве создателя класс, агре-

гирующий или содержащий класс А.

Пример:

При выполнении подчиненного потока событий «Создать

фафик» варианта использования «Зарегистрироваться на курсы»

(см.

рис. 4.8) необходимо решить, кто должен отвечать за созда-

Анализ и проектирование программного обеспечения

307

ние нового графика в системе. На рис. 4.13 показаны два возмож-

ных варианта решения этой задачи.

•ф

Rational

Ш>Ш;ШшШШ^^^^Ш^^т

в^

^^шщ f^mal:^

Ш^ст$&

geport loob

Вариант 1

: RegistrationController

adcTschedulefSchedule)

create with jiff^ngs

\ \

Schedule

: Student

Вариант2

Re g istrati о n Co ntro Her

create with offerings

Student

create and ^dd schedule

Schedule

5'-

шшяк

Рис.

4.13.

Два варианта создания графика

308 Глава 4

В диаграмме на рис. 4.8 выбран вариант 1. Однако согласно

образцу «Creator» наилучшим решением является вариант 2 (но-

вый объект класса Schedule создается классом Student, а не

RegistrationController, поскольку именно Student удовлетворяет

первому из перечисленных выше условий).

Следствия:

Образец «Creator» определяет способ распределения обязан-

ностей, связанный с процессом создания объектов. В объектно-

ориентированных системах эта задача является одной из наибо-

лее распространенных. Основным назначением образца Creator

является выявление объекта-создателя, который при возникно-

вении любого события должен быть связан со всеми созданными

им объектами. При таком подходе обеспечивается низкая сте-

пень связанности объектов.

В некоторых случаях в качестве создателя выбирается класс,

который содержит данные инициализации, передаваемые объек-

ту во время его создания. На самом деле это пример использова-

ния образца Information Expert. В процессе создания инициали-

зирующие данные передаются с помощью метода инициализа-

ции некоторого вида, такого, как конструктор языка профамми-

рования.

В некоторых сложных случаях вместо данного образца пред-

почтительнее использовать известный образец Factory (Фабри-

ка)^

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

тельному классу.

Образец

«Low

Coupling»

Проблема:

Нужно распределить обязанности между классами таким об-

разом, чтобы снизить взаимное влияние изменений в них и по-

высить возможность повторного использования.

Решение:

Следует распределить обязанности таким образом, чтобы

обеспечить слабую связанность.

Связанность

(coupling)

—

это ме-

ра, определяющая насколько жестко один элемент связан с дру-

гими элементами, или каким количеством данных о других эле-

Приемы объектно-ориентированного проектирования. Патгерны про-

ектирования / Э. Гамма, Р. Хелм,

Р.

Джонсон, Дж. Влиссидес: Пер. с англ.

—

СПб.:

Питер, 2001.

Анализ и проектирование программного обеспечения 309

ментах он обладает. Элемент со слабой связанностью зависит от

небольшого числа других элементов. Класс с сильной связан-

ностью зависит от множества других классов. Наличие таких

классов нежелательно, поскольку оно приводит к возникнове-

нию следующих проблем.

• Изменения в связанных классах приводят к локальным из-

менениям

данном классе.

• Затрудняется понимание каждого класса в отдельности.

• Усложняется повторное использование, поскольку для это-

го требуется дополнительный анализ классов, с которыми

связан данный класс.

Пример:

Рассмотрим подчиненный поток событий «Создать график»

варианта использования «Зарегистрироваться на курсы» (см. рис.

4.8).

На

данной диафамме при создании нового фафика

систе-

ме выбран вариант

(рис. 4.13). Однако согласно образцу «Low

Coupling» наилучшим решением является вариант 2, поскольку

при этом

класса RegistrationController будет на одну связь мень-

ше (т.е. будет обеспечена более слабая связанность).

Следствия:

Образец Low Coupling поддерживает независимость классов,

что,

в свою очередь, повышает возможности повторного исполь-

зования и обеспечивает более высокую эффективность приложе-

ния. Его нельзя рассматривать изолированно

от

других образцов,

таких как Information Expert

High Cohesion. Он также обеспечи-

вает выполнение одного из основных принципов проектирова-

ния, применяемых при распределении обязанностей.

Не существует абсолютной меры для определения слишком

сильной связанности. Важно лишь понимать связанность объек-

тов и не упустить тот момент, когда дальнейшее повышение свя-

занности может привести к возникновению проблем. В целом

следует руководствоваться таким принципом: классы, которые

являются достаточно общими по своей природе и с высокой ве-

роятностью будут повторно использоваться

дальнейшем, долж-

ны иметь минимальную связанность

другими классами.

Крайним случаем при реализации образца

Low

Coupling явля-

ется полное отсутствие связывания между классами. Такая ситуа-

ция тоже нежелательна, поскольку основная идея объектного

подхода выражается в системе связанных объектов, которые «об-

щаются» между собой посредством передачи сообщений. При

310 Глава 4

слишком частом использовании принципа слабого связывания

система будет состоять из нескольких изолированных сложных

активных объектов, самостоятельно выполняющих все опера-

ции, и множества пассивных объектов, основная функция кото-

рых сводится к хранению данных. Поэтому при создании объект-

но-ориентированной системы должна присутствовать некоторая

оптимальная степень связывания между объектами, позволяю-

щая выполнять основные функции посредством взаимодействия

этих объектов.

Не следует применять данный образец, когда создаются связи

с устойчивыми элементами. Сильная связанность с такими эле-

ментами не представляет проблемы. Например, приложение Java

2 Етефпзе Edition можно жестко связать с библиотеками Java,

поскольку они достаточно стабильны.

Сильная связанность сама по себе не является проблемой.

Проблемой является жесткое связывание с неустойчивыми эле-

ментами. Важно понимать, что без убедительной мотивации не

следует во что бы то ни стало бороться за уменьшение связаннос-

ти объектов.

Образец «High Cohesion»

Проблема:

Нужно распределить обязанности между классами таким об-

разом, чтобы каждый класс не выполнял много разнородных

функций или несвязанных между собой обязанностей. Такие

классы создавать нежелательно, поскольку они приводят к воз-

никновению таких же проблем, как у классов с сильной связан-

ностью.

Решение:

Следует распределить обязанности таким образом, чтобы

обеспечить сильное сцепление.

терминах объектно-ориентиро-

ванного проектирования сцепление (cohesion) - это мера связан-

ности и непротиворечивости обязанностей класса. Считается,

что элемент обладает сильным сцеплением, если его обязанности

тесно связаны между собой, и он не выполняет излишнего объе-

ма работы. В роли таких элементов могут выступать классы, под-

системы, модули и т.д.

Классы со слабым сцеплением, как правило, выполняют обя-

занности, которые можно легко распределить между другими

классами.