Материал: Лабораторные_Архитерктура ИС
68
3.
Перейдите
на
вкладку
файлов
.
4.
Щелкните
правой
кнопкой
мыши
на
белом
поле
и
из
открывшегося
меню
выберите
пункт
Insert File.
5.
Укажите
созданный
ранее
файл
и
нажмите
на
кнопку
Open,
чтобы
прикрепить
файл
к
варианту
использования
.
В
результате
представление
вариантов
использования
в
браузере
примет
следующий
вид
:
Удаление
вариантов
использования
и
действующих
лиц
Существует
два
способа
удалить
элемент
модели
–
из
одной
диаграммы
или
из
всей
модели
.
Чтобы
удалить
элемент
модели
из
диаграммы
:
1
.
Выделите
элемент
на
диаграмме
.
2.
Нажмите
на
клавишу
Delete.
3.
Обратите
внимания
,
что
,
хотя
элемент
и
удален
с
диаграммы
,
он
остался
в
браузере
и
на
других
диаграммах
системы
.
Чтобы
удалить
элемент
из
модели
:
1
.
Выделите
элемент
на
диаграмме
.
2.
Выберите
пункт
меню
Edit > Delete from Model
или
нажмите
сочетание
клавиш
CTRL + D.
69
3.5.
Анализ
системы
3.5.1.
Архитектурный
анализ
Принятие
соглашений
по
моделированию
Включает
:
•
Используемые
диаграммы
и
элементы
модели
;
•
Правила
их
применения
;
•
Соглашения
по
именованию
элементов
;
•
Организация
модели
(
пакеты
).
Пример
соглашений
моделирования
:
•
Имена
вариантов
использования
должны
быть
короткими
глагольными
фразами
.
•
Для
каждого
варианта
использования
должен
быть
создан
пакет
Use-Case Realization,
включающий
:
§
по
крайней
мере
одну
реализацию
варианта
использования
;
§
диаграмму
«View Of Participating Classes» (VOPC).
•
Имена
классов
должны
быть
существительными
,
соответствующими
,
по
возможности
,
понятиям
предметной
области
.
•
Имена
классов
должны
начинаться
с
заглавной
буквы
.
•
Имена
атрибутов
и
операций
должны
начинаться
со
строчной
буквы
.
•
Составные
имена
должны
быть
сплошными
,
без
подчеркиваний
,
каждое
отдельное
слово
должно
начинаться
с
заглавной
буквы
.
Реализация
варианта
использования
(Use-Case Realization):
Описывает
реализацию
конкретного
варианта
использования
в
терминах
взаимодействующих
объектов
и
представляется
с
помощью
набора
диаграмм
(
диаграмм
классов
,
реализующих
вариант
использования
,
и
диаграмм
взаимодействия
(
диаграмм
последовательности
и
кооперативных
диаграмм
),
отражающих
взаимодействие
объектов
в
процессе
реализации
варианта
использования
).
70
<<realizes>>
Use Case
Use-Case
Realization
Рис
. 3.3.
Реализация
варианта
использования
Идентификация
ключевых
абстракций
Заключается
в
предварительном
определении
классов
системы
(
классов
анализа
).
Источники
–
знание
предметной
области
,
требования
к
системе
,
глоссарий
.
Классы
анализа
для
системы
регистрации
показаны
на
рис
. 3.4:
Student
Professor
Schedule
Course
CourseOffering
Рис
. 3.4.
Классы
анализа
системы
регистрации
Упражнение
6.
Создание
структуры
модели
и
классов
анализа
в
соответствии
с
требованиями
архитектурного
анализа
Структура
логического
представления
браузера
должна
иметь
следующий
вид
:
7
1
Создание
пакетов
и
диаграммы
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
Register for Courses
<<use-case realization>>
(from Use-Case Realization - Register
for Courses)
Register for Courses
(from Use Case View)
<<realizes>>
Login
<<use-case realization>>
(from Use-Case Realization - Login)
Login
(from Use Case View)
<<realizes>>
Close Registration
<<use-case realization>>
(from Use-Case Realization -
Close Registration)
Close Registration
(from Use Case View)
<<realizes>>
72
Создание
классов
анализа
и
соответствующей
диаграммы
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)
–
представляют
собой
ключевые
абстракции
(
понятия
)
разрабатываемой
системы
.
Источники
выявления
классов
-
сущностей
:
ключевые
абстракции
,
созданные
в
процессе
архитектурного
анализа
,
глоссарий
,
описание
потоков
событий
вариантов
использования
.