А.М. Вендров - Объектно-ориентированный анализ и проектирование с использованием языка UML и Rational Rose (1158631), страница 5
Текст из файла (страница 5)
Выбирается первый доступныйальтернативный курс. Если таких курсов нет, то никакое дополнение не происходит.4. Система закрывает все предлагаемые курсы. Если в каком-либо предлагаемом курсеоказывается менее трех студентов (с учетом добавлений, сделанных в п.3), системаотменяет его и исключает из каждого содержащего его графика.5.
Система рассчитывает плату за обучение для каждого студента в текущем семестре инаправляет информацию в расчетную систему. Расчетная система посылает студентамсчета для оплаты с копией их окончательных графиков.Альтернативные потоки:Курс никто не ведет:Если во время выполнения основного потока обнаруживается, что некоторый курс не ведетсяникаким профессором, то этот курс отменяется.
Система исключает данный курс из каждогосодержащего его графика.Расчетная система недоступна:Если невозможно установить связь с расчетной системой, через некоторое установленноевремя система вновь попытается связаться с ней. Попытки будут повторяться до тех пор, покасвязь не установится.Предусловия:Перед началом выполнения данного варианта использования регистратор должен войти всистему.Постусловия:Если вариант использования завершится успешно, регистрация закрывается. В противномслучае состояние системы не изменится.Упражнение 11. Прикрепление файла к варианту использования1.2.3.4.Щелкните правой кнопкой мыши на варианте использования.В открывшемся меню выберите пункт Open SpecificationПерейдите на вкладку файлов.Щелкните правой кнопкой мыши на белом поле и из открывшегося меню выберите пунктInsert File.5.
Укажите созданный ранее файл и нажмите на кнопку Open, чтобы прикрепить файл кварианту использования.2.9 Анализ системы2.9.1 Архитектурный анализАрхитектурный анализ выполняется архитектором системы и включает в себя:• утверждение общих стандартов (соглашений) моделирования и документированиясистемы;• предварительное выявление архитектурных механизмов (механизмов анализа);22••формирование набора основных абстракций предметной области (классованализа);формирование начального представления архитектурных уровней.Соглашения моделирования определяют:• используемые диаграммы и элементы модели;• правила их применения;• соглашения по именованию элементов модели;• организацию модели (пакеты).Пример набора соглашений моделирования:• Имена вариантов использования должны быть короткими глагольными фразами.• Имена классов должны быть существительными, соответствующими, по возможности,понятиям предметной области.• Имена классов должны начинаться с заглавной буквы.• Имена атрибутов и операций должны начинаться со строчной буквы.• Составные имена должны быть сплошными, без подчеркиваний, каждое отдельное словодолжно начинаться с заглавной буквы.• Все классы и диаграммы, описывающие предварительный системный проект,помещаются в пакет с именем Analysis Model.• Диаграммы классов, реализующих вариант использования, и диаграммы взаимодействия,отражающие взаимодействие объектов в процессе реализации сценариев вариантаиспользования, помещаются в кооперацию с именем данного варианта использования истереотипом «use-case realization».
Все кооперации помещаются в пакет с именем UseCase Realizations. Связь между вариантом использования и его реализацией изображаетсяна специальной диаграмме трассировки (рис. 2.6).Рис. 2.6. Фрагмент диаграммы трассировкиИдентификация основных абстракций заключается в предварительном определениинабора классов системы (классов анализа) на основе описания предметной области испецификации требований к системе (в частности, глоссария). Способы идентификации основныхабстракций аналогичны способам идентификации сущностей в модели ERM.Так, для системы регистрации идентифицировано пять классов анализа:• Student (Студент);• Professor (Профессор);• Schedule (Учебный график);• Course (Курс);• CourseOffering (Предлагаемый курс).23Классы анализа показаны на рис.
2.7.Рис. 2.7. Классы анализа системы регистрацииУпражнение 12. Создание структуры модели и классов анализа в соответствии стребованиями архитектурного анализаСоздание пакетов и диаграммы Traceabilities:1. Щелкните правой кнопкой мыши на пакете Design Model логического представлениябраузера.2. В открывшемся меню выберите пункт New > Package.3. Создайте пакет Use-Case Realizations, затем внутри него – пакеты Use-Case Realization Close Registration, Use-Case Realization – Login и Use-Case Realization - Register forCourses.4.
В каждом из пакетов типа Use-Case Realization создайте соответствующие кооперацииClose Registration, Login и Register for Courses (каждая кооперация представляет собойвариант использования со стереотипом «use-case realization», который задается вспецификации варианта использования).5. Создайте в пакете Use-Case Realizations новую диаграмму вариантов использования сназванием Traceabilities и постройте ее в соответствии с рис. 2.8.Создание классов анализа и соответствующей диаграммы Key Abstractions:1.
Щелкните правой кнопкой мыши на пакете Analysis Model.2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClassпоявится в браузере.3. Выделите его и введите имя Student.4. Создайте аналогичным образом классы Professor, Schedule, Course и CourseOffering.5. Щелкните правой кнопкой мыши на пакете Analysis Model.6. В открывшемся меню выберите пункт New > Class Diagram.7. Назовите новую диаграмму классов Key Abstractions.8. Чтобы расположить вновь созданные классы на диаграмме классов, откройте ее иперетащите классы на открытую диаграмму мышью. Диаграмма классов должнавыглядеть как на рис.
2.7.Архитектурные уровни представляются в модели (пакет Design Model) в виде пакетов состереотипом <<layer>>. Количество и структура уровней зависят от сложности предметнойобласти и среды реализации. В рамках архитектурного анализа определяется начальная структура24модели (набор пакетов и их зависимостей) и рассматриваются только верхние уровни(Application и Business Services).Рис. 2.8 Диаграмма Traceabilities2.9.2 Анализ вариантов использованияИдентификация классов, участвующих в реализациииспользованияпотоков событийвариантаВ потоках событий варианта использования выявляются классы трех типов:1.
Граничные классы (Boundary) – служат посредниками при взаимодействии внешнихобъектов с системой. Как правило, для каждой пары «действующее лицо - вариантиспользования» определяется один граничный класс. Типы граничных классов:пользовательский интерфейс (обмен информацией с пользователем, без деталейинтерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс(используемые протоколы, без деталей их реализации).2.
Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия)разрабатываемой системы. Источники выявления классов-сущностей: ключевыеабстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоковсобытий вариантов использования.253. Управляющие классы (Control) – обеспечивают координацию поведенияобъектов в системе. Могут отсутствовать в некоторых вариантах использования,ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, длякаждого варианта использования определяется один управляющий класс. Примерыуправляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.Пример набора классов, участвующих в«Зарегистрироваться на курсы», приведен на рис.
2.9.реализациивариантаиспользованияРис. 2.9. Классы, участвующие в реализации варианта использования «Зарегистрироватьсяна курсы»Упражнение 13. Создание классов, участвующих в реализации варианта использованияRegister for Courses, и диаграммы классов «View Of Participating Classes» (VOPC)1. Щелкните правой кнопкой мыши на пакете Analysis Model.2.
Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClassпоявится в браузере.3. Выделите его и введите имя RegisterForCoursesForm.4. Щелкните правой кнопкой мыши на классе RegisterForCoursesForm.5. В открывшемся меню выберите пункт Open Specification.6. В поле стереотипа выберите Boundary и нажмите на кнопку ОК.7. Создайте аналогичным образом классы CourseCatalogSystem со стереотипом Boundary иRegistrationController со стереотипом Control.8. Назначьте классам Schedule, CourseOffering и Student стереотип Entity.9.
Щелкните правой кнопкой мыши на кооперации Register for Courses в пакете Use-CaseRealization - Register for Courses.10. В открывшемся меню выберите пункт New > Class Diagram.11. Назовите новую диаграмму классов VOPC (classes only).12. Откройте ее и перетащите классы на открытую диаграмму в соответствии с рис. 2.9.Распределение поведения, реализуемого вариантом использования, между классами26Реализуется с помощью диаграмм взаимодействия (диаграмм последовательности икооперативных диаграмм). В первую очередь строится диаграмма (одна или более), описывающаяосновной поток событий и его подчиненные потоки.
Для каждого альтернативного потокасобытий строится отдельная диаграмма. Примеры:• обработка ошибок• контроль времени выполнения• обработка неправильных вводимых данныхНецелесообразно описывать тривиальные потоки событий (например, в потоке участвуеттолько один объект).Упражнение 14. Создание диаграмм взаимодействияСоздадим диаграммы последовательности и кооперативные диаграммы для основногопотока событий варианта использования Register for Courses.
Готовые диаграммыпоследовательности должны иметь вид, как на рис. 2.10 – 2.14.Рис. 2.10 Диаграмма последовательности Register for Courses - Basic Flow27Рис. 2.11 Диаграмма последовательности Register for Courses - Basic Flow (Create Schedule)Настройка1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
