Конспект лекций, страница 16

Взаимодействие с нейосуществляется через объект-посредник класса BillingSystem, реализующего интерфейсiBillingSystem. На диаграмме показаны внешние связи подсистемы.<<entity>>Student(from University Artifacts)Следующим этапом является формирование архитектурных уровней. В ходе анализабыло принято предварительное решение о выделении архитектурных уровней. В ходепроектирования все проектные элементы системы должны быть распределены по даннымуровням. С точки зрения модели это означает распределение проектных классов, пакетови подсистем по пакетам со стереотипом «layer», соответствующим архитектурнымуровням.Пример формирования архитектурных<<layer>>уровней (система регистрации на курсы):ApplicationRegistration выделены 2 архитектурных уровня (пакетасо стереотипом <<layer>>); на уровень Application (Приложение)помещен пакет Registration, куда включеныграничные и управляющие классы; граничныеклассыBillingSystemи<<layer>>Business ServicesCourseCatalogSystem преобразо-ваны вExternal Systemподсистемы уровня бизнес-логики BusinessInterfacesServices; в слой Business Services, помимо подсистем,University Artifactsвключены еще два пакета: пакет ExternalSystem Interfaces включает интерфейсы6подсистем (классы со стереотипом <<Interface>>), а пакет University Artifacts – всеклассы-сущности.Следующий этап – проектирование структуры потоков управления.

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

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

Активный классвладеет собственным процессом или потоком и может инициировать управляющиевоздействия. Связи между процессами моделируются как зависимости. Потоки могутсуществовать только внутри процессов, поэтому связи между процессами и потокамимоделируются как композиции. Модель потоков управления помещается в пакет ProcessView (представление процессов – одно из архитектурных представлений в модели «4+1»).В качестве примера приведена<<process>>диаграммаклассов,StudentApplicationописывающаяструктурупроцесса регистрации студентана курсы. Обратите внимание,что все классы на ней являются<<process>>активными (выделены жирнымиCourseRegistrationProcessграницами).Активныеклассы,<<thread>>OfferingCacheпоказанные на этих диаграммах,выполняютследующее1<<process>>назначение:1CourseCatalogSystemAccess• StudentApplication – процесс,управляющий всеми функциями<<thread>>1CourseCacheстудента-пользователяв1системе.

Для каждого студента,7начинающего регистрироваться на курсы, создается один объект данного класса.• CourseRegistrationProcess – процесс, управляющий непосредственно регистрациейстудента. Для каждого студента, начинающего регистрироваться на курсы, такжесоздается один объект данного класса.• CourseCatalogSystemAccess – управляет доступом к системе каталога курсов. Один и тотже объект данного класса используется всеми пользователями при доступе к каталогукурсов.• CourseCache и OfferingCache используются для асинхронного доступа к данным в БД сцелью повышения производительности системы.

Они представляют собой кэш дляпромежуточного хранения данных о курсах, извлеченных из БД.Создание потоков во время инициализации приложения моделируется с помощьюдиаграмм взаимодействия. Объекты любого проектного класса или подсистемы должнысуществовать внутри по крайней мере одного процесса. Связи между процессами ипроектными классами моделируются на диаграммах классов. Ниже приведены примерыдля системы регистрации:: RegisterForCoursesForm: MainStudentForm: RegistrationController: ICourseCatalogSystem: Student1: Startup2: createThread3: createThread4: createThreadОбратите внимание, что на следующей диаграмме зависимости между процессамисоответствуют ассоциациям и зависимостям между классами, экземпляры которыхсодержатся в процессах.<<process>>StudentApplication<<process>>CourseRegistrationProcess11<<process>>CourseCatalogSystemAccess111MainStudentForm<<subsystem proxy>>CourseCatalogSystem(from Registration)(from CourseCatalogSystem)10..11<<boundary>>RegisterForCoursesForm(from Registration)11<<control>>RegistrationController(from Registration)ICourseCatalogSystem(from External System Interfaces)8Следующий этап – проектирование конфигурации.

Если создаваемая системаявляется распределенной, то необходимо спроектировать ее конфигурацию ввычислительной среде, т. е., описать вычислительные ресурсы, коммуникации междуними и использование вычислительных ресурсов различными системными процессами.Распределенная сетевая конфигурация системы моделируется с помощьюдиаграммы размещения. Диаграмма размещения – это единственная диаграмма, входящаяв состав представления размещения – одного из архитектурных представлений, входящихв модель «4+1» Основные элементы диаграммы размещения: узел (node) – вычислительный ресурс (процессор или другое устройство: дисковаяпамять, контроллеры различных устройств и т.д.). Для узла можно задатьвыполняющиеся на нем процессы. соединение (connection) – канал взаимодействия узлов (сеть).Распределение процессов, составляющих структуру потоков управления, по узламсети производится с учетом следующих факторов: используемые образцы распределения (трехзвенная архитектура клиент-сервер,«толстый клиент», «тонкий клиент», «точка-точка» и т.

д.); время отклика; минимизация сетевого трафика; мощность узла; надежность оборудования и коммуникаций.Пример – диаграмма размещения для системы регистрации на курсы:Desktop PCDesktop PC<<Campus LAN>>StudentApplicationRegistrarApplication<<Campus LAN>>RegistrationServer<<Campus LAN>><<legacy>>CourseCatalogSystemStudentApplicationRegistrarApplication<<Campus LAN>>CourseCatalogSystemAccessCourseRegistrationProcessCloseRegistrationProcessBillingSystemAccess<<legacy>>BillingSystemСледующий этап – уточнение реализаций вариантов использования. Уточнениезаключается в модификации диаграмм взаимодействия и диаграмм классов с учетом вновьпоявившихся на шаге проектирования классов и подсистем, а также проектныхмеханизмов.

Вносятся изменения в описания потоков событий вариантов использования(с помощью скриптов и примечаний). Производится унификация классов и подсистем последующим правилам: Имена элементов модели должны отражать их функции. Следует избегать подобныхимен и синонимов. Элементы модели, реализующие сходное поведение или представляющие одно и то же9явление, должны объединяться. Классы, представляющие одно и то же понятие или имеющие одинаковые атрибуты,должны объединяться, даже если их поведение различно. Для абстрактных элементов модели должно использоваться наследование,повышающее гибкость модели. При обновлении элемента модели должны обновляться соответствующие реализациивариантов использования.Следующий этап – проектирование подсистем, осуществляемое разработчиками.Оно включает в себя следующие действия: Распределение поведения подсистемы по ее элементамo документирование взаимодействия элементов подсистемы в виде коопераций(«реализаций интерфейса»);o построение одной или более диаграмм взаимодействия для каждой операцииинтерфейса подсистемы/ Документирование элементов подсистемы (в виде диаграмм классов). Описание зависимостей между подсистемами.Пример:CourseCatalogSystem Client: CourseOfferingList6: new( )10: add(CourseOffering)1: getCourseOfferings(Semester): ResultSet8: getString( )2: read(string): CourseCatalogSystem: DBCourseOfferring7: new( )9: setData( )4: executeQuery(String):CourseOffering3: createStatement( ): Connection:Statement5: // executeQuery( ): Course CatalogРис.Диаграмма кооперации, описывающая реализацию интерфейсной операцииgetCourseOfferings() в подсистеме CourseCatalogSystem.Заметим, что реализация подсистемы CourseCatalogSystem выполнена созданиемэкземпляра механизма JDBC, т.

е. подстановкой класса DBCourseOffering вместо ролиDBClass, CourseOffering – вместо PersistentClass, CourseOfferingList – вместоPersistentClassList, CourseCatalogSystem вместо PersistencyClient. То есть, беретсяшаблонная диаграмма взаимодействия из модели механизма и уточняется подстановкойконкретных классов. Аналогично будет получена диаграмма классов, описывающаяструктурные связи подсистемы.Еще одним важным моментом является использованное на диаграмме соглашениемоделирования: Вызов операции getCourseOfferings(), реализацию которой мы описываем,10производится клиентским объектом (названным CourseCatalogSystemClient) не имеющимуказания класса.

В самом деле, подсистема ничего не знает о своих клиентских классах,так что указать класс невозможно. По смыслу на месте объекта CourseCatalogSystemClientможетбытьлибоэкземплярRegistrationController,либоэкземплярCloseRegistrationController.DBClassDBCourseOfferringPersistency - RDBMS - JDBCPersistencyClientPersistentClassListPersistentClassCourseOfferingList<<subsystem proxy>>CourseCatalogSystemCourseOfferingРис. Связывание образца JDBC с конкретными классами системыПосле проектирования подсистем производится проектирование классов, котороевключает следующие действия:1) детализация проектных классов;2) уточнение операций и атрибутов;3) моделирование состояний для классов;4) уточнение связей между классами.Каждый граничный класс преобразуется в некоторый набор классов, в зависимостиот своего назначения.