|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Архитектурный анализПринятие соглашений по моделированию Включает: · Используемые диаграммы и элементы модели; · Правила их применения; · Соглашения по именованию элементов; · Организация модели (пакеты).
Пример соглашений моделирования: · Имена вариантов использования должны быть короткими глагольными фразами. · Для каждого варианта использования должен быть создан пакет Use‑Case Realization, включающий: § по крайней мере одну реализацию варианта использования; § диаграмму «View Of Participating Classes» (VOPC). · Имена классов должны быть существительными, соответствующими, по возможности, понятиям предметной области. · Имена классов должны начинаться с заглавной буквы. · Имена атрибутов и операций должны начинаться со строчной буквы. · Составные имена должны быть сплошными, без подчеркиваний, каждое отдельное слово должно начинаться с заглавной буквы.
Реализация варианта использования (Use-Case Realization): Описывает реализацию конкретного варианта использования в терминах взаимодействующих объектов и представляется с помощью набора диаграмм (диаграмм классов, реализующих вариант использования, и диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм), отражающих взаимодействие объектов в процессе реализации варианта использования). Рис. 3.3. Реализация варианта использования
Идентификация ключевых абстракций Заключается в предварительном определении классов системы (классов анализа). Источники – знание предметной области, требования к системе, глоссарий. Классы анализа для системы регистрации показаны на рис. 3.4: Рис. 3.4. Классы анализа системы регистрации
Упражнение 6. Создание структуры модели и классов анализа в соответствии с требованиями архитектурного анализа Структура логического представления браузера должна иметь следующий вид:
Создание пакетов и диаграммы Traceabilities: 1. Щелкните правой кнопкой мыши на логическом представлении браузера. 2. В открывшемся меню выберите пункт New > Package 3. Назовите новый пакет Design Model. 4. Создайте аналогичным образом пакеты Use-Case Realizations, Use-Case Realization – Close Registration, Use-Case Realization – Login и Use-Case Realization – Register for Courses. 5. В каждом из пакетов типа Use-Case Realization создайте соответствующие кооперации Close Registration, Login и Register for Courses (каждая кооперация представляет собой вариант использования со стереотипом «use-case realization», который задается в спецификации варианта использования). 6. Создайте в пакете Use-Case Realizations новую диаграмму вариантов использования с названием Traceabilities и постройте ее в соответствии с рис. 3.5. Рис. 3.5. Диаграмма Traceabilities Создание классов анализа и соответствующей диаграммы Key Abstractions: 1. Щелкните правой кнопкой мыши на пакете Design Model. 2. Выберите в открывшемся меню пункт New > Class. Новый класс под названием NewClass появится в браузере. 3. Выделите его и введите имя Student. 4. Создайте аналогичным образом классы Professor, Schedule, Course и CourseOffering. 5. Щелкните правой кнопкой мыши на пакете Design Model. 6. В открывшемся меню выберите пункт New > Class Diagram. 7. Назовите новую диаграмму классов Key Abstractions. 8. Чтобы расположить вновь созданные классы на диаграмме классов, откройте ее и перетащите классы на открытую диаграмму мышью. Диаграмма классов должна выглядеть как на рис. 3.4. 3.5.2. Анализ вариантов использования Идентификация классов, участвующих в реализации потоков событий варианта использования
В потоках событий варианта использования выявляются классы трех типов: 1. Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо – вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса – кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации). 2. Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования. 3. Управляющие классы (Control) – обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.
Пример набора классов, участвующих в реализации варианта использования Register for Courses, приведен на рис. 3.6. Рис. 3.6. Классы, участвующие в реализации варианта использования Register for Courses
Упражнение 7. Создание классов, участвующих в реализации варианта использования Register for Courses, и диаграммы классов «View Of Participating Classes» (VOPC) 1. Щелкните правой кнопкой мыши на пакете Design 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-Case Realization – Register for Courses. 10. В открывшемся меню выберите пункт New > Class Diagram. 11. Назовите новую диаграмму классов VOPC (classes only). 12. Откройте ее и перетащите классы на открытую диаграмму в соответствии с рис. 3.6.
Распределение поведения, реализуемого вариантом использования, между классами Реализуется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм). В первую очередь строится диаграмма (одна или более), описывающая основной поток событий и его подчиненные потоки. Для каждого альтернативного потока событий строится отдельная диаграмма. Примеры: · обработка ошибок; · контроль времени выполнения; · обработка неправильных вводимых данных. Нецелесообразно описывать тривиальные потоки событий (например, в потоке участвует только один объект).
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.006 сек.) |