Сведения о языке UML (1183998), страница 13
Текст из файла (страница 13)
3.13. Классы с операциями «анализа» и атрибутамиСвязи между классами (ассоциации) определяются на основедиаграмм взаимодействия. Если два объекта взаимодействуют(обмениваются сообщениями), между ними должна существовать связь(путь взаимодействия). Для ассоциаций задаются множественность и,возможно, направление навигации. Могут использоваться множественныеассоциации, агрегации и классы ассоциаций.Упражнение 10. Добавление связейДобавим связи к классам, принимающим участие в вариантеиспользования Register for Courses. Для отображения связей между82классами построим три новых диаграмм классов в кооперации Register forCourses пакета Use-Case Realization – Register for Courses (рис.
3.14 – 3.16).<<entity>>StudentnameaddressstudentID 10..n0..4<<entity>> 0..n<<entity>>ScheduleCourseOffering+primaryCourses0..20..n+alternateCourses<<entity>>FulltimeStudentgradDate<<entity>>ParttimeStudentmaxNumCoursesРис.
3.14. Диаграмма Entity Classes (классы-сущности)Добавлены два новых класса – подклассы FulltimeStudent (студенточного отделения) и ParttimeStudent (студент вечернего отделения).<<entity>>PrimaryScheduleOfferingInfograde// is enrolled in?()// mark as enrolled in()// mark as committed()<<entity>>Schedule+primaryCourses0..n0..n0..4+alternateCourses0..2<<entity>>ScheduleOfferingInfostatus// mark as selected()// mark as cancelled()// is selected?()Рис. 3.15. Диаграмма CourseOfferingInfo83<<entity>>CourseOfferingНа данной диаграмме показаны классы ассоциаций, описывающиесвязи между классами Schedule и CourseOffering и добавлен суперклассScheduleOfferingInfo.
Данные и операции, содержащиеся в этом классе(status – курс включен в график или отменен), относятся как к основным,так и к альтернативным курсам, в то время как оценка (grade) иокончательное включение курса в график могут иметь место только дляосновных курсов.<<control>><<boundary>>RegisterForCoursesForm110..n0..10..1<<entity>>Student110..10..1+registrant<<boundary>>CourseCatalogSystemRegistrationController+currentSchedule<<entity>>Schedule<<entity>>PrimaryScheduleOfferingInfo0..n0..n0..n+primaryCourses0..4<<entity>>FulltimeStudent<<entity>>ParttimeStudent<<entity>>CourseOffering0..2<<entity>>ScheduleOfferingInfo+alternateCoursesРис.
3.16. Полная диаграмма классов VOPC (без атрибутов иопераций)Создание ассоциацийАссоциации создают непосредственно на диаграмме классов. Панельинструментов диаграммы классов содержит кнопки для создания как одно, так и двунаправленных ассоциаций. Чтобы на диаграмме классов создатьассоциацию:1. Нажмите на панели инструментов кнопку Association.2. Проведите мышью линию ассоциации от одного класса к другому.Чтобы задать возможности навигации по ассоциации:1. Щелкните правой кнопкой мыши на связи с того конца, на которомхотите показать стрелку.2.
В открывшемся меню выберите пункт 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показана на рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
