А.М. Вендров - Объектно-ориентированный анализ и проектирование с использованием языка UML и Rational Rose, страница 7

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

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

Задайте элемент связи в поле Link Element.Задание для самостоятельной работыВыполнить анализ варианта использования Close Registration и построить соответствующиедиаграммы взаимодействия и классов.2.10 Проектирование системыЦелью объектно-ориентированного проектирования является адаптация предварительногосистемного проекта (набора классов «анализа»), составляющего стабильную основу архитектурысистемы, к среде реализации с учетом всех нефункциональных требований.Объектно-ориентированное проектирование включает два вида деятельности:• проектирование архитектуры системы;• проектирование элементов системы.2.10.1 Проектирование архитектуры системыПроектирование архитектуры системы выполняется архитектором системы и включает всебя:•••••идентификацию архитектурных решений и механизмов, необходимых дляпроектирования системы;анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;формирование архитектурных уровней;проектирование структуры потоков управления;проектирование конфигурации системы.Первым действием архитектора при выявлении подсистем является преобразование классованализа в проектные классы (design classes).

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

Структура и диаграммы пакета(подсистемы) CourseCatalogSystem (диаграммы классов и взаимодействия, описывающие даннуюподсистему и ее интерфейс), приведены на рис. 2.20 – 2.23. Классы DBCourseOfferring иCourseOfferringList отвечают за взаимодействие с БД каталога курсов в рамках JDBC.

ОбъектCourseCatalogSystemClientнарис.2.23можетпринадлежатьлибоклассуCloseRegistrationController, либо классу RegistrationController, в зависимости от того, в каком извариантов использования запрашивается каталог курсов.38Рис. 2.20 Структура пакета CourseCatalogSystemРис. 2.21. Контекст подсистемы CourseCatalogSystem с точки зрения архитектора39Рис. 2.22. Диаграмма классов подсистемы CourseCatalogSystem с точки зрения проектировщикаФормирование архитектурных уровнейВ процессе анализа было принято предварительное решение о выделении архитектурныхуровней.

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

2.24.40Рис. 2.23. Кооперативная диаграмма, описывающая реализацию операции интерфейсаgetCourseOfferingsДанное представление отражает следующие решения, принятые архитектором:• выделены три архитектурных уровня (созданы три пакета со стереотипом <<layer>>);• в пакете Application создан пакет Registration, куда включены граничные и управляющиеклассы;• граничные классы BillingSystem и CourseCatalogSystem преобразованы в подсистемы;• в пакет Business Services, помимо подсистем, включены еще два пакета: пакет ExternalSystem Interfaces включает интерфейсы подсистем (классы со стереотипом<<Interface>>), а пакет University Artifacts – все классы-сущности.2.10.2 Моделирование распределенной конфигурации системыРаспределенная конфигурация системы моделируется с помощью диаграммы размещения.Ее основные элементы:• узел (node) - вычислительный ресурс (процессор или другое устройство (дисковаяпамять, контроллеры различных устройств и т.д.).

Для узла можно задатьвыполняющиеся на нем процессы;• соединение (connection) - канал взаимодействия узлов (сеть).Пример: сетевая конфигурация системы регистрации (без процессов) (рис. 2.25).41Рис. 2.24. Представление структуры модели в процессе проектированияРаспределение процессов по узлам сети производится с учетом следущих факторов:• используемые образцы распределения (трехзвенная клиент-серверная конфигурация,«толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);• время отклика;• минимизация сетевого трафика;• мощность узла;• надежность оборудования и коммуникаций.Пример распределения процессов по узлам приведен на рис.

2.26.42Рис. 2.25 Сетевая конфигурация системы регистрацииРис. 2.26 Сетевая конфигурация системы регистрации с распределением процессов по узлам43Упражнение 17. Создание диаграммы размещения системы регистрацииЧтобы открыть диаграмму размещения, надо дважды щелкнуть мышью на представленииDeployment View (представлении размещения) в браузере.Чтобы поместить на диаграмму процессор:1. На панели инструментов диаграммы нажмите кнопку Processor.2.

Щелкните на диаграмме размещения в том месте, куда хотите его поместить.3. Введите имя процессора.В спецификациях процессора можно ввести информацию о его стереотипе, характеристикахи планировании. Стереотипы применяются для классификации процессоров (например,компьютеров под управлением UNIX или ПК).Характеристики процессора - это его физическое описание. Оно может, в частности,включать скорость процессора и объем памяти.Поле планирования (scheduling) процессора содержит описание того, как осуществляетсяпланирование его процессов:• Preemptive (с приоритетом).

Высокоприоритетные процессы имеют преимуществоперед низкоприоритетными.• Non preemptive (без приоритета). У процессов не имеется приоритета. Текущий процессвыполняется до его завершения, после чего начинается следующий.• Cyclic (циклический). Управление передается между процессами по кругу. Каждомупроцессу дается определенное время на его выполнение, затем управление переходит кследующему процессу.• Executive (исполнительный). Существует некоторый вычислительный алгоритм,который и управляет планированием процессов.• Manual (вручную). Процессы планируются пользователем.Чтобы назначить процессору стереотип:1. Откройте окно спецификации процессора.2. Перейдите на вкладку General.3. Введите стереотип в поле Stereotype.Чтобы ввести характеристики и планирование процессора:1. Откройте окно спецификации процессора.2.

Перейдите на вкладку Detail.3. Введите характеристики в поле характеристик.4. Укажите один из типов планирования.Чтобы показать планирование на диаграмме:1. Щелкните правой кнопкой мыши на процессоре.2. В открывшемся меню выберите пункт Show Scheduling.Чтобы добавить связь на диаграмму:1. На панели инструментов нажмите кнопку Connection.2. Щелкните на узле диаграммы.3. Проведите линию связи к другому узлу.Чтобы назначить связи стереотип:1. Откройте окно спецификации связи.2. Перейдите на вкладку General.3. Введите стереотип в поле Stereotype (Стереотип).Чтобы добавить процесс:1.