Лекционные материалы, страница 13

В открывшемся меню выберите пункт Navigable.84Чтобы создать рефлексивную ассоциацию:1. На панели инструментов диаграммы нажмите кнопку Association.2. Проведите линию ассоциации от класса до какого-нибудь меставне класса.3. Отпустите кнопку мыши.4.

Проведите линию ассоциации назад к классу.Создание агрегаций1. Нажмите кнопку Aggregation панели инструментов.2. Проведите линию агрегации от класса-части к целому.Чтобы поместить на диаграмму классов рефлексивную агрегацию:1. На панели инструментов диаграммы нажмите кнопку Aggregation.2. Проведите линию агрегации от класса до какого-нибудь меставне класса.3. Отпустите кнопку мыши.4. Проведите линию агрегации назад к классу.Создание обобщенийПри создании обобщения может потребоваться перенести некоторыеатрибуты или операции из одного класса в другой.

Если, например,понадобится перенести их из подкласса в суперкласс Employee, в браузередля этого достаточно просто перетащить атрибуты или операции из одногокласса в другой. Не забудьте удалить другую копию атрибута из второгоподкласса, если он имеется.Чтобы поместить обобщение на диаграмму классов:1. Нажмите кнопку Generalization панели инструментов.2. Проведите линию обобщения от подкласса к суперклассу.Спецификации связейСпецификации связей касаются имен ассоциаций, ролевых имена,множественности и классов ассоциаций.Чтобы задать множественность связи:1. Щелкните правой кнопкой мыши на одном конце связи.2. В открывшемся меню выберите пункт Multiplicity.3.

Укажите нужную множественность.4. Повторите то же самое для другого конца связи.85Чтобы задать имя связи:1. Выделите нужную связь.2. Введите ее имя.Чтобы задать связи ролевое имя:1. Щелкните правой кнопкой мыши на ассоциации с нужного конца.2. В открывшемся меню выберите пункт role Name.3. Введите ролевое имя.Чтобы задать элемент связи (класс ассоциаций):1. Откройте окно спецификации требуемой связи.2. Перейдите на вкладку Detail.3. Задайте элемент связи в поле Link Element.Задание для самостоятельной работыВыполнить анализ варианта использования Close Registration ипостроить соответствующие диаграммы взаимодействия и классов.3.6. Проектирование системы3.6.1.

Проектирование архитектурыЦели проектирования архитектуры системы:• анализ взаимодействий между классами анализа, выявлениеподсистем и интерфейсов;• уточнение архитектуры с учетом возможностей повторногоиспользования;• идентификацияархитектурныхрешенийнеобходимых для проектирования системы.Вводятся глобальные пакеты:и• базисные (foundation) классы (списки, очереди и т.д.);• обработчики ошибок (error handling classes);• математические библиотеки;• утилиты;• библиотеки других поставщиков.Определяются проектные классы (design classes):86механизмов,• класс анализа отображается в проектный класс, если он простойили представляет единственную логическую абстракцию;• сложный класс анализа может быть разбит на несколько классов,преобразован в пакет или в подсистему.Примеры возможных подсистем:• классы, обеспечивающие сложный комплекс услуг (например,обеспечение безопасности и защита);• граничные классы, реализующие сложный пользовательскийинтерфейс или интерфейс с внешними системами;• различныепродукты:коммуникационноеПО(middleware,поддержка COM/CORBA), доступ к базам данных, типы иструктуры данных (стеки, списки, очереди), общие утилиты(математические библиотеки), различные прикладные продукты.Принятие решения о преобразовании класса в подсистемуопределяется опытом и знаниями архитектора проекта.Соглашения по проектированию интерфейсов:• Имя интерфейса: короткое (одно-два слова), отражающее его рольв системе.• Описание интерфейса: должно отражать его обязанности (размер –небольшой абзац).• Описание операций: имя, отражающее результат операции,ключевые алгоритмы, возвращаемое значение, параметрыс типами.• Документирование интерфейса: характер использования операцийи порядок их выполнения (показывается с помощью диаграммпоследовательности), тестовые планы и сценарии и так далее.Вся эта информацияобъединяетсявспециальныйпакетсо стереотипом <<subsystem>>, который содержит элементы,образующие подсистему, диаграммы последовательности и/иликооперативныедиаграммы,описывающиевзаимодействиеэлементов при реализации операций интерфейса, и другиедиаграммы.87• Класс <<subsystem proxy>> непосредственно реализует интерфейси управляет реализацией его операций.• Все интерфейсы должны быть полностью определены в процессепроектирования архитектуры, поскольку они будут служитьв качестве точек синхронизации при параллельной разработке.Выделение архитектурных уровней:Application Layer – содержит элементы прикладного уровня(пользовательский интерфейс);Business Services Layer – содержит элементы, реализующие бизнеслогику приложений (наиболее устойчивая часть системы);MiddlewareLayer–обеспечиваетсервисы,независимыеот платформы.Пример выделения архитектурных уровней и объединения элементовмодели в пакеты для системы регистрации приведен на рис.

3.17.Для того чтобы поместить класс в пакет, достаточно простоперетащить его в браузере на нужный пакет.Рис. 3.17. Структура логическогопредставлениямоделинашагепроектирования88Данное представление отражает следующие решения, принятыеархитектором:• Выделены три архитектурных уровня (созданы три пакетасо стереотипом <<layer>>);• В пакете Application создан пакет Registration, куда включеныграничные и управляющие классы;• Граничный класс CourseCatalogSystem преобразован в подсистему(пакет CourseCatalogSystem со стереотипом <<subsystem>>)• ВпакетBusinessServices,помимоподсистемыCourseCatalogSystem, включены еще два пакета: пакет ExternalSystemInterfacesвключаетинтерфейссподсистемойCourseCatalogSystem (класс ICourseCatalogSystem со стереотипом<<Interface>>), а пакет University Artifacts – все классы-сущности.Структура и диаграммы пакета (подсистемы) CourseCatalogSystemпоказана на рис.

3.18 – 3.22.Рис. 3.18. Структура пакета CourseCatalogSystem<<subsystem>>CourseCatalogSystem(from Business Services)External SystemInterfaces(from Business Services)University Artifacts(from Business Services)Рис. 3.19. Зависимости между подсистемой и другими пакетами(диаграмма классов CourseCatalogSystem Dependencies)89Чтобы поместить зависимость между пакетами на диаграмму классов:1. Нажмите кнопку Dependency панели инструментов.2.

Проведите линию зависимости от зависимого пакета к тому,от которого он зависит.<<Interface>>ICourseCatalogSystem<<subsystem proxy>>CourseCatalogSystemgetCourseOfferings()initialize()getCourseOfferings()initialize()DBCourseOfferringcreate()read()initialize()Рис. 3.20. Классы, реализующие интерфейс подсистемы (диаграммаклассов ICourseCatalogSystem)Класс DBCourseOfferring отвечает за взаимодействие с БД каталогакурсов.CourseCatalogSystem Client: CourseCatalogSystem: DBCourseOfferring1: getCourseOfferings(Semester):CourseOfferingList :CourseOfferingCreate a list to hold allretrieved course offerings2: read(string)Retrieve all available courseofferings for the currentsemester3: new( )4: new( )5: setData( )Repeat these operations for eachelement returned from the query.The CourseOfferingList is loaded withthe data retrieved from the database.The getData and setData operationsare called for each attribute in theeach retrieved class instance.6: add(CourseOffering)Add the retrieved course offering tothe list to be returnedРис.

3.21. Диаграмма последовательности ICourseCatalogSystem::getCourseOfferings, описывающая взаимодействие элементов при реализацииоперации интерфейса getCourseOfferings90CourseCatalogSystem Client: CourseCatalogSystem1: initialize( ): DBCourseOfferring2: initialize( )Рис. 3.22. Диаграмма последовательности ICourseCatalogSystem::initialize, описывающая взаимодействие элементов при реализацииоперации интерфейса initialize3.6.2. Моделирование распределенной конфигурации системыРаспределенная конфигурация системы моделируется с помощьюдиаграммы размещения.

Ее основные элементы:• узел (node) – вычислительный ресурс (процессор или другоеустройство (дисковая память, контроллеры различных устройстви т. д.). Для узла можно задать выполняющиеся на нем процессы;• соединение (connection) – канал взаимодействия узлов (сеть).Пример: сетевая конфигурация системы регистрации (без процессов).Desktop PCDesktop PC<<Campus LAN>><<Campus LAN>>RegistrationServer<<Campus LAN>><<Campus LAN>><<legacy>><<legacy>>CourseCatalogSystemBillingSystemРис. 3.23.

Сетевая конфигурация системы регистрации91Распределение процессов по узлам сети производится с учетомследующих факторов:• используемыеобразцыраспределения(трехзвеннаяклиент-серверная конфигурация, «толстый клиент», «тонкий клиент»,равноправные узлы (peer-to-peer) и т.д.);• время отклика;• минимизация сетевого трафика;• мощность узла;• надежность оборудования и коммуникаций.Пример распределения процессов по узлам приведен на рис. 3.24.Desktop PCDesktop PCStudentApplicationRegistrarApplicationStudentApplicationRegistrarApplication<<Campus LAN>><<Campus LAN>>RegistrationServer<<Campus LAN>><<Campus LAN>>CourseCatalogSystemAccessCourseRegistrationProccessCloseRegistrationProccessBillingSystemAccess<<legacy>><<legacy>>CourseCatalogSystemBillingSystemРис.3.24.Сетеваяконфигурацияс распределением процессов по узлам92системырегистрацииУпражнение 11.

Создание диаграммы размещения системырегистрацииЧтобы открыть диаграмму размещения, надо дважды щелкнутьмышью на представлении Deployment View (представлении размещения)в браузере.Чтобы поместить на диаграмму процессор:1. На панели инструментов диаграммы нажмите кнопку Processor.2. Щелкните на диаграмме размещения в том месте, куда хотитеего поместить.3. Введите имя процессора.В спецификациях процессора можно ввести информацию о егостереотипе, характеристиках и планировании. Стереотипы применяютсядля классификациипроцессоров(например,компьютеровпод управлением UNIX или ПК).Характеристики процессора – это его физическое описание.