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

Диаграммы классов и взаимодействия, описывающиеданную подсистему и ее интерфейс, приведены на рис. 3.17 – 3.19. КлассыDBCourseOfferring и CourseOfferringList отвечают за взаимодействие с БДкаталога курсов в рамках JDBC. Объект CourseCatalogSystem Client на рис.3.19 может принадлежать либо классу CloseRegistrationController, либоклассу RegistrationController, в зависимости от того, в каком из вариантовиспользования запрашивается каталог курсов.3.3.3. Формирование архитектурных уровней.В процессе анализа было принято предварительное решение овыделении архитектурных уровней (в случае системы регистрации четырех уровней в соответствии с образцом "Уровни").

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

3.20.134Рис. 3.17. Контекст подсистемы CourseCatalogSystem с точки зренияархитектора135Рис. 3.18. Диаграмма классов подсистемы CourseCatalogSystem с точкизрения проектировщикаДанное представление отражает следующие решения, принятыеархитектором:• выделены три архитектурных уровня (созданы три пакета состереотипом <<layer>>);• в пакете Application создан пакет Registration, куда включеныграничные и управляющие классы;• граничныеклассыBillingSystemиCourseCatalogSystemпреобразованы в подсистемы;• в пакет Business Services, помимо подсистем, включены еще двапакета: пакет External System Interfaces включает интерфейсыподсистем (классы со стереотипом <<Interface>>), а пакетUniversity Artifacts - все классы-сущности.136Рис.

3.19. Кооперативная диаграмма, описывающая реализацию операцииинтерфейса getCourseOfferings3.3.4. Проектирование структуры потоков управления.Проектирование структуры потоков управления выполняется приналичии в системе параллельных процессов (параллелизма).

Цельпроектирования - выявление существующих в системе процессов,характера их взаимодействия, создания, уничтожения и отображения всреду реализации. Требование параллелизма возникает в следующихслучаях:• необходимо распределение обработки между различнымипроцессорами или узлами;• система управляется потоком событий (event-driven system);• вычисления в системе обладают высокой интенсивностью;• в системе одновременно работает много пользователей.137Рис. 3.20. Представление структуры модели в процессе проектированияНапример, система регистрации курсов обладает свойствомпараллелизма, поскольку она должна допускать одновременную работумногих пользователей (студентов и профессоров), каждый из которыхпорождает в системе отдельный процесс.Понятие процесс (process) трактуется следующим образом:• это ресурсоемкий поток управления, который может выполнятьсяпараллельно с другими процессами;• он выполняется в независимом адресном пространстве и в случаевысокой сложности может разделяться на два или более потоков;• объект любого класса должен существовать внутри хотя бы одногопроцесса.Поток (thread) - это облегченный поток управления, который можетвыполняться параллельно с другими потоками в рамках одного и того жепроцесса в общем адресном пространстве.

Необходимость создания138потоков в системе регистрации курсов диктуется следующимитребованиями:• если курс окажется заполненным в то время, когда студентформирует свой учебный график, включающий данный курс, то ондолжен быть извещен об этом (необходим независимый процесс,управляющий доступом к информации конкретных курсов);• существующая база данных каталога курсов не обеспечиваеттребуемуюпроизводительность(необходимпроцесспромежуточной обработки - подкачки данных).Реализация процессов и потоков обеспечивается средствамиоперационной системы.Для моделирования структуры потоков управления используются такназываемые активные классы [3] - классы со стереотипами <<process>> и<<thread>>.

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

Модель потоков управления помещается впакет Process View. В качестве примера на рис. 3.21 – 3.23 приведеныфрагменты диаграммы классов, описывающей структуру процессарегистрации студента на курсы. Активные классы, показанные на этихдиаграммах, выполняют следующее назначение:• StudentApplication - процесс, управляющий всеми функциямистудента-пользователя в системе. Для каждого студента,начинающего регистрироваться на курсы, создается один объектданного класса.• CourseRegistrationProcess - процесс, управляющий непосредственнорегистрацией студента.

Для каждого студента, начинающегорегистрироваться на курсы, также создается один объект данногокласса.• CourseCatalogSystemAccess - управляет доступом к системекаталога курсов. Один и тот же объект данного класса используетсявсеми пользователями при доступе к каталогу курсов.• CourseCache и OfferingCache используются для асинхронногодоступа к данным в БД с целью повышения производительностисистемы. Они представляют собой кэш для промежуточногохранения данных о курсах, извлеченных из БД.139Рис. 3.21. Процессы и потоки3.3.5. Проектирование конфигурации системы.Если создаваемая система является распределенной, то необходимоспроектировать ее конфигурацию в вычислительной среде, т.е., описатьвычислительные ресурсы, коммуникации между ними и использованиересурсов различными системными процессами.Распределенная сетевая конфигурация системы моделируется спомощью диаграммы размещения.

Пример такой диаграммы для системырегистрации (без процессов) приведен на рис. 3.24.140Рис. 3.22. Классы, связанные с процессамиРаспределение процессов, составляющих структуру потоковуправления, по узлам сети производится с учетом следующих факторов:• используемые образцы распределения (трехзвенная клиентсерверная конфигурация, "толстый" клиент, "тонкий" клиент,равноправные узлы (peer-to-peer) и т.д.);• время отклика;• минимизация сетевого трафика;• мощность узла;• надежность оборудования и коммуникаций.Пример распределения процессов по узлам системы регистрацииприведен на рис.

3.25.141Рис. 3.23. Классы, связанные с потоками3.4. Проектирование элементов системыПроектирование элементов системы выполняется проектировщикамии включает в себя:• уточнение описания вариантов использования;• проектирование классов;• проектирование баз данных.3.4.1. Уточнение описания вариантов использования.Уточнение описания вариантов использования заключается вмодификации их диаграмм взаимодействия и диаграмм классов с учетомвновь появившихся на шаге проектирования классов и подсистем, а такжепроектных механизмов.

Так, например, диаграммы взаимодействияварианта использования "Зарегистрироваться на курсы", изображенные нарис. 3.4 и 3.5, примут вид, показанный на рис. 3.26 и 3.27.Объект класса CourseRegBDManager на рис. 3.26 играет рольинтерфейса с объектной базой данных системы регистрации142(предполагается, что данные о студентах, графиках и профессорах будутхраниться в объектной БД).Рис. 3.24.

Сетевая конфигурация системы регистрации3.4.2. Проектирование классов.Проектирование классов включает следующие действия:• детализация проектных классов;• уточнение операций и атрибутов;• моделирование состояний для классов;• уточнение связей между классами.Детализация проектных классовКаждый граничный класс преобразуется в некоторый набор классов, взависимости от своего назначения. Это может быть набор элементовпользовательского интерфейса, зависящий от возможностей среды143разработки, или набор классов, реализующий системный или аппаратныйинтерфейс.Рис.