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

Классы анализа системы регистрацииАрхитектурные уровни образуют иерархию уровней представлениялюбой крупномасштабной системы. В практике разработки таких системсуществует ряд типовых решений [1] - архитектурных образцов, средикоторых наиболее распространенным является образец "Уровни" (Layers).Этот образец можно описать следующим образом:Наименование образца:"Уровни".Контекст:Крупномасштабные системы, нуждающиеся в декомпозиции.Проблема:Архитектура крупномасштабной системы должна удовлетворятьследующим требованиям:• компоненты системы должны иметь возможность замены;• изменения в одних компонентах не должны сильно затрагиватьдругие;• однородные функции должны группироваться вместе;108• размер компонентов не должен быть слишком большим.Решение:Предлагается базовый вариант, включающий следующие уровни(сверху вниз):• прикладной (Application Subsystems) - набор компонентов,реализующих основную функциональность системы, отраженную ввариантах использования;• бизнес-уровень(Business-specific)наборкомпонентов,специфичных для конкретной предметной области;• промежуточный (Middleware) - различные платформо-независимыесервисы (библиотеки пользовательского интерфейса, брокерызапросов и др.);• системный (System software) - ПО для вычислительной и сетевойинфраструктуры (ОС, сетевые протоколы и др.).Архитектурные уровни представляются в модели в виде пакетов состереотипом <<layer>>.

Количество и структура уровней зависят отсложности предметной области и среды реализации. В рамкахархитектурного анализа определяется начальная структура модели (наборпакетов и их зависимостей) и рассматриваются только верхние уровни(прикладной и бизнес-уровень).3.2. Анализ вариантов использованияАнализ вариантов использования выполняется проектировщиками ивключает в себя:• идентификацию классов, участвующих в реализации потоковсобытий варианта использования;• распределение поведения, реализуемого вариантом использования,между классами (определение обязанностей классов);• определение атрибутов и ассоциаций классов;• унификацию классов анализа.3.2.1.

Идентификация классов, участвующих в реализации потоковсобытий варианта использования.В потоках событий варианта использования выявляются классы трехтипов:Граничные классы (Boundary) - служат посредниками привзаимодействии внешних объектов с системой. Как правило, для каждойпары "действующее лицо - вариант использования" определяется один109граничный класс. Типы граничных классов: пользовательский интерфейс(обмен информацией с пользователем, без деталей интерфейса - кнопок,списков, окон), системный интерфейс и аппаратный интерфейс(используемые протоколы, без деталей их реализации).Классы-сущности (Entity) - представляют собой основные абстракции(понятия) разрабатываемой системы, рассматриваемые в рамкахконкретного варианта использования.

Источники выявления классовсущностей: основные абстракции, созданные в процессе архитектурногоанализа, глоссарий, описание потоков событий вариантов использования,сущности, описанные в модели бизнес-анализа (при наличии бизнесмодели).Управляющие классы (Control) - обеспечивают координациюповедения объектов в системе.

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

Совокупность классов анализапредставляет собой начальную концептуальную модель системы.Пример набора классов, участвующих в реализации вариантаиспользования "Зарегистрироваться на курсы", приведен на рис. 3.3.Рис. 3.3. Классы, участвующие в реализации варианта использования"Зарегистрироваться на курсы"1103.2.2. Распределение поведения, реализуемого вариантомиспользования, между классами.Квалифицированное распределение обязанностей между классамиявляется наиболее важной частью объектно-ориентированного анализа.Исходя из назначения трех выделенных типов классов, можно краткоохарактеризовать распределение обязанностей между ними:• граничные классы отвечают за взаимодействие с внешней средойсистемы (действующими лицами);• классы-сущности отвечают за хранение и манипулированиеданными;• управляющие классы координируют потоки событий вариантаиспользования.Более детальное распределение обязанностей (в виде операцийклассов) выполняется с помощью диаграмм взаимодействия (диаграммпоследовательности и кооперативных диаграмм).В процессе анализа конкретного варианта использования в первуюочередь строится диаграмма последовательности (одна или более),описывающая основной поток событий и его подчиненные потоки.

Длякаждого альтернативного потока событий строится отдельная диаграмма(из соображений простоты наглядного восприятия). Нецелесообразноописывать тривиальные потоки событий (например, в потоке участвуеттолько один объект).На рис. 3.4 – 3.8 приведены диаграммы последовательности икооперативные диаграммы для основного потока событий вариантаиспользования "Зарегистрироваться на курсы".На последней диаграмме (рис.

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

Каждая операция"анализа" класса соответствует некоторому сообщению, принимаемомуобъектами данного класса. В процессе проектирования каждая операция"анализа" преобразуется в одну или более операций класса, которые вдальнейшем будут реализованы в коде системы.111Рис. 3.4. Диаграмма последовательности "Зарегистрироваться на курсы" Основной поток событий112Рис. 3.5. Кооперативная диаграмма "Зарегистрироваться на курсы" подчиненный поток "Создать график"113Рис. 3.6.

Кооперативная диаграмма "Зарегистрироваться на курсы" подчиненный поток "Обновить график"114Рис. 3.7. Кооперативная диаграмма "Зарегистрироваться на курсы" подчиненный поток "Удалить график"115Рис. 3.8. Кооперативная диаграмма "Зарегистрироваться на курсы" подчиненный поток "Принять график"Так, диаграмма классов варианта использования "Зарегистрироватьсяна курсы" (рис. 3.3) после построения диаграмм взаимодействия должнапринять следующий вид (рис. 3.9).При построении диаграмм взаимодействия возникают проблемыправильного распределения обязанностей между классами.

Для ихрешения существует ряд образцов [9], некоторые из которых приведеныниже.116Рис. 3.9. Диаграмма классов с операциями "анализа"Образец "Information Expert"Проблема:Нужно определить наиболее общий принцип распределенияобязанностей между классами. В системе могут быть определены сотниклассов, выполняющие тысячи обязанностей. При правильном их117распределении система становится гораздо проще для понимания,сопровождения и развития. Кроме того, появляется возможностьповторного использования уже разработанных компонентов впоследующих приложениях.Решение:Следует назначить обязанность информационному эксперту - классу,у которого имеется информация, требуемая для выполнения обязанности.Пример:При выполнении подчиненного потока событий "Обновить график"варианта использования "Зарегистрироваться на курсы" (рис.

3.6) студентпользователь должен получить доступ к своему графику прежде, чемизменить его. Согласно образцу "Information Expert", нужно определить,объект какого класса содержит информацию, необходимую для доступа кграфику. На эту роль информационного эксперта, очевидно, претендуетобъект класса-сущности Student, поскольку график принадлежит именноему. Поэтому сообщение 3 "get schedule(forSemester)" должно бытьнаправлено от контроллера объекту класса Student. После того, какстудент получит график и внесет в него необходимые изменения, онидолжны быть зафиксированы в объекте Schedule. В данном случае уже самобъекте Schedule будет играть роль информационного эксперта, посколькуон непосредственно доступен контроллеру, и сообщение 10 "update withnew selections" будет направлено именно ему.Следствия:При распределении обязанностей образец Information Expertиспользуется гораздо чаще любого другого образца.

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

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