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

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

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

Определение атрибутов и ассоциаций классов.Атрибуты классов анализа определяются, исходя из знаний опредметной области, требований к системе, глоссария и бизнес-модели. Впроцессе анализа атрибуты определяются только для классов-сущностей.Атрибуты должны быть простыми. Так, после определения атрибутов дляклассов-сущностей, показанных на рис. 3.9, они примут следующий вид(рис. 3.11).124Рис. 3.11. Классы с операциями "анализа" и атрибутамиСвязи между классами (ассоциации) определяются в два этапа:1. Начальный набор связей определяется на основе анализакооперативных диаграмм. Если два объекта взаимодействуют(обмениваются сообщениями), между ними на кооперативнойдиаграмме должна существовать связь (путь взаимодействия),которая преобразуется в двунаправленную ассоциацию междусоответствующими классами.

Если сообщения между некоторойпарой объектов передаются только в одном направлении, то длясоответствующей ассоциации вводится направление навигации.2. Анализируются и уточняются ассоциации между классамисущностями.Задаютсямощностиассоциаций,могутиспользоваться множественные ассоциации, агрегации, обобщенияи ассоциации-классы.Следует избегать использования избыточных ассоциаций исосредоточиться на тех ассоциациях, для которых данные о связи должнысохраняться в течение некоторого времени.125Результаты определения связей между классами, принимающимиучастие в реализации варианта использования "Зарегистрироваться накурсы", показаны на рис.

3.12 – 3.14.Рис. 3.12. Диаграмма классов-сущностейНа рис. 3.12 показаны только классы-сущности. Агрегация междуклассами Student и Schedule отражает тот факт, что каждый графикявляется собственностью конкретного студента, принадлежит только ему.Предполагается также, что в системе будет храниться не только графиктекущего семестра, а все графики студента за разные семестры.

Междуклассами Schedule и CourseOffering введено две ассоциации, посколькуконкретный курс может входить в график студента в качестве основного(не более четырех курсов) и альтернативного (не более двух курсов). Кклассу Student добавлены два новых подкласса - FulltimeStudent (студенточного отделения) и ParttimeStudent (студент вечернего отделения).На рис. 3.13 показаны ассоциации-классы, представляющие свойствасвязей между классами Schedule и CourseOffering. Ассоциация,связывающая график и альтернативный курс, имеет только один атрибут статус курса в конкретном графике (status), который может приниматьзначения "включен в график", "отменен", "внесен в список курса" и"зафиксирован в графике".

Если курс в процессе закрытия регистрациипереходит из альтернативного в основные, то к соответствующейассоциации добавляется атрибут "оценка" (grade). Таким образом,ассоциация-классPrimaryScheduleOfferingInfoнаследуетсвойстваассоциации-классаScheduleOfferingInfo(атрибутыиоперации,содержащиеся в этом классе, относятся как к основным, так и к126альтернативным курсам) и добавляет свои собственные (оценка иокончательное включение курса в график могут иметь место только дляосновных курсов), что и показано с помощью связи обобщения.Рис. 3.13.

Пример ассоциаций-классовНа рис. 3.14 показана полная диаграмма классов вариантаиспользования "Зарегистрироваться на курсы" (без атрибутов и операций).Ассоциации между граничными и управляющими классами, а также междууправляющими классами и классами-сущностями введены на основеанализа кооперативных диаграмм и, в отличие от устойчивых структурных(семантических) связей между сущностями, отражают связи, динамическивозникающие между соответствующими объектами в потоке управления (впроцессе работы приложения). Поскольку для ассоциаций это несвойственно, в дальнейшем (в процессе проектирования) они могут бытьпреобразованы в зависимости.127Рис.

3.14. Полная диаграмма классов (без атрибутов и операций)3.2.4. Унификация классов анализа.Унификация классов анализа заключается в проверке созданныхклассов на предмет выполнения следующих условий:• имя и описание каждого класса "анализа" должно отражатьсущность его роли в системе. Имена должны быть уникальными;• классы с одинаковым поведением, или представляющие одно и тоже явление, должны объединяться;128• классы-сущностисодинаковымиатрибутамидолжныобъединяться (даже если их поведение отличается). Объединенныйкласс будет обладать общим поведением.При обновлении классов должны, при необходимости, обновлятьсяописания вариантов использования.3.3.

Проектирование архитектуры системыПроектирование архитектуры системы выполняется архитекторомсистемы и включает в себя:• идентификациюархитектурныхрешенийимеханизмов,необходимых для проектирования системы;• анализ взаимодействий между классами анализа, выявлениеподсистем и интерфейсов;• формирование архитектурных уровней;• проектирование структуры потоков управления;• проектирование конфигурации системы.3.3.1. Идентификация архитектурных решений и механизмов.В процессе проектирования определяются детали реализацииархитектурных механизмов, обозначенных в процессе анализа. Посколькупрактически все механизмы - это некоторые типовые решения (образцы),они документируются в проекте (модели) с помощью кооперации состереотипом <<mechanism>>, при этом структурная часть механизмаописывается с помощью диаграмм классов, а поведение - с помощьюдиаграмм взаимодействия.В качестве примера рассмотрим механизм хранения данных в БД.Предположим, что в проекте системы регистрации в качестве языкапрограммирования используется Java.

Поскольку существующая системакаталога курсов функционирует на основе реляционной СУБД, такиммеханизмом, обеспечивающим доступ к этой внешней базе данных,должен быть JDBC (Java Database Connectivity). На рис. 3.15 показанадиаграмма классов образца, описывающего JDBC.129Рис. 3.15. Диаграмма классов кооперации, описывающей JDBCВсе классы, изображенные на данной диаграмме, можно разделить надве группы:• Собственно классы JDBC (DriverManager, Connection, Statement,ResultSet), которые отвечают за реализацию запроса к БД(выполнение оператора SQL).

Эти классы принадлежат кархитектурному уровню Middleware и входят в соответствующийпакет.• Классы со стереотипом <<role>>, являющиеся "заполнителями"(placeholders) реальных классов, создаваемых разработчикомсистемы. Они выполняют следующее назначение:130o DBClass - отвечает за чтение и запись данных. Класс такоготипа создается для каждого устойчивого (persistent) класса,или, иначе говоря, класса, данные которого будут храниться внекоторой БД (в данном случае - в таблицах реляционнойБД). Например, в системе регистрации на курсы в процессеанализа в соответствии с образцом Information Expertопределено, что класс-сущность Course должен отвечать засохранение информации об учебных курсах в базе данных.Однако при этом, как было сказано в данном образце,возникает проблема перегруженности класса лишнимиобязанностями,посколькуклассCourseдолженнепосредственно содержать вызовы сервисов JDBC.Разделение основных функций системы на уровни(применение образца "Уровни") в данном случае означает,что обязанности взаимодействия с БД выносятся из классаCourse в класс DBCourse.o PersistencyClient - класс, запрашивающий создание, чтение,обновление или удаление данных.o PersistentClass - класс-сущность, объекты которого содержатнеобходимые данные.o PersistentClassListсписокобъектов,являющихсярезультатом запроса к БД -выполнения операцииDBClass.read().Выполнение операций, реализуемых механизмом JDBC (операцийкласса DBClass) документируется с помощью диаграмм взаимодействия.Одна из таких диаграмм - кооперативная диаграмма, показывающаявыполнение операции создания новых данных (create), приведена на рис.3.16.Из диаграммы на рис.

3.16 видно, что для создания новых данных(нового класса) объект PersistencyClient запрашивает DBClass. DBClassсоздает новый объект PersistentClass и загружает в него данные. ЗатемDBClass создает новый оператор SQL, используя операциюcreateStatement() класса Connection. В результате выполнения этогооператора данные помещаются в БД.131Рис. 3.16. Диаграмма выполнения операции create3.3.2. Выявление подсистем и интерфейсов.Декомпозиция системы на подсистемы реализует принципмодульности. Целями такой декомпозиции являются:• повышение уровня абстракции системы;• декомпозиция системы на части, которые могут независимо:o конфигурироваться или поставляться;o разрабатываться (при условии стабильности интерфейсов);o размещаться в распределенной среде;o изменяться без воздействия на остальные части системы;• разделение системы на части из соображений ограничения доступак основным ресурсам;• представление существующих продуктов или внешних систем(компонентов), которые не подлежат изменениям.Первым действием архитектора при выявлении подсистем являетсяпреобразование классов анализа в проектные классы (design classes).

Покаждому классу анализа принимается одно из двух решений:• класс анализа отображается в проектный класс, если он простойили представляет единственную логическую абстракцию;132• сложный класс анализа может быть разбит на несколько классов,преобразован в пакет или в подсистему.Объединение классов в подсистемы осуществляется, исходя изследующих соображений:• функциональная связь: объединяются классы, участвующие вреализации варианта использования и взаимодействующие толькодруг с другом;• обязательность:совокупностьклассов,реализующаяфункциональность, которая может быть удалена из системы илизаменена на альтернативную;• связанность: объединение в подсистемы сильно связанных классов;• распределение: объединение классов, размещенных на конкретномузле сети.Примеры возможных подсистем:• совокупность классов, обеспечивающих сложный комплексфункций (например, обеспечение безопасности и защиты данных);• граничные классы, реализующие сложный пользовательскийинтерфейс или интерфейс с внешними системами;• различные продукты: коммуникационное ПО, доступ к базамданных, общие утилиты (библиотеки), различные прикладныепакеты.При создании подсистем в модели выполняются следующиепреобразования:• объединяемые классы помещаются в специальный пакет с именемподсистемы и стереотипом <<subsystem>>;• спецификации операций классов, образующих подсистему,выносятся в интерфейс подсистемы - класс со стереотипом<<Interface>>;• описание интерфейса должно включать:o имя интерфейса, отражающее его роль в системе;o текстовое описание интерфейса размером в небольшой абзац,отражающее его обязанности;o описание операций интерфейса (имя, отражающее результатоперации, алгоритм выполнения операции, возвращаемоезначение, параметры с их типами);o характер использования операций интерфейса и порядок ихвыполнения документируется с помощью диаграммвзаимодействия, описывающих взаимодействие классовподсистемы при реализации операций интерфейса, которыевместе с диаграммой классов подсистемы объединяются вкооперацию с именем интерфейса и стереотипом <<interfacerealization>>;133• в подсистеме создается класс-посредник со стереотипом<<subsystem proxy>>, управляющий реализацией операцийинтерфейса.Все интерфейсы подсистем должны быть полностью определены впроцессе проектирования архитектуры, поскольку они будут служить вкачестве точек синхронизации при параллельной разработке системы.В качестве примера (для системы регистрации) приведем подсистемуCourseCatalogSystem, которая создана вместо граничного классаCourseCatalogSystem.