Материал: Лабораторные_Архитерктура ИС
88
•
Класс
<<subsystem proxy>>
непосредственно
реализует
интерфейс
и
управляет
реализацией
его
операций
.
•
Все
интерфейсы
должны
быть
полностью
определены
в
процессе
проектирования
архитектуры
,
поскольку
они
будут
служить
в
качестве
точек
синхронизации
при
параллельной
разработке
.
Выделение
архитектурных
уровней
:
Application Layer –
содержит
элементы
прикладного
уровня
(
пользовательский
интерфейс
);
Business Services Layer –
содержит
элементы
,
реализующие
бизнес
-
логику
приложений
(
наиболее
устойчивая
часть
системы
);
Middleware Layer –
обеспечивает
сервисы
,
независимые
от
платформы
.
Пример
выделения
архитектурных
уровней
и
объединения
элементов
модели
в
пакеты
для
системы
регистрации
приведен
на
рис
. 3.
1
7.
Для
того
чтобы
поместить
класс
в
пакет
,
достаточно
просто
перетащить
его
в
браузере
на
нужный
пакет
.
Рис
. 3.
1
7.
Структура
логического
представления
модели
на
шаге
проектирования
89
Данное
представление
отражает
следующие
решения
,
принятые
архитектором
:
•
Выделены
три
архитектурных
уровня
(
созданы
три
пакета
со
стереотипом
<<layer>>);
•
В
пакете
Application
создан
пакет
Registration,
куда
включены
граничные
и
управляющие
классы
;
•
Граничный
класс
CourseCatalogSystem
преобразован
в
подсистему
(
пакет
CourseCatalogSystem
со
стереотипом
<<subsystem>>)
•
В
пакет
Business Services,
помимо
подсистемы
CourseCatalogSystem,
включены
еще
два
пакета
:
пакет
External
System Interfaces
включает
интерфейс
с
подсистемой
CourseCatalogSystem (
класс
ICourseCatalogSystem
со
стереотипом
<<Interface>>),
а
пакет
University Artifacts –
все
классы
-
сущности
.
Структура
и
диаграммы
пакета
(
подсистемы
) CourseCatalogSystem
показана
на
рис
. 3.
1
8 – 3.22.
Рис
. 3.
1
8.
Структура
пакета
CourseCatalogSystem
Рис
. 3.
1
9.
Зависимости
между
подсистемой
и
другими
пакетами
(
диаграмма
классов
CourseCatalogSystem Dependencies)
CourseCatalogSystem
<<subsystem>>
(from Business Services)
External System
Interfaces
(from Business Services)
University Artifacts
(from Business Services)
90
Чтобы
поместить
зависимость
между
пакетами
на
диаграмму
классов
:
1
.
Нажмите
кнопку
Dependency
панели
инструментов
.
2.
Проведите
линию
зависимости
от
зависимого
пакета
к
тому
,
от
которого
он
зависит
.
Рис
. 3.20.
Классы
,
реализующие
интерфейс
подсистемы
(
диаграмма
классов
ICourseCatalogSystem)
Класс
DBCourseOfferring
отвечает
за
взаимодействие
с
БД
каталога
курсов
.
Рис
. 3.2
1
.
Диаграмма
последовательности
ICourseCatalogSystem::getCourse
Offerings,
описывающая
взаимодействие
элементов
при
реализации
операции
интерфейса
getCourseOfferings
CourseCatalog
System Client
: CourseCatalog
System
: DBCourse
Offerring
:CourseOffering
:CourseOfferingList
1
: getCourseOfferings(Semester)
2: read(string)
4: new( )
Repeat these operations for each
element returned from the query.
The CourseOfferingList is loaded with
the data retrieved from the database.
The getData and setData operations
are called for each attribute in the
each retrieved class instance.
5: setData( )
Retrieve all available course
offerings for the current
semester
Create a list to hold all
retrieved course offerings
Add the retrieved course offering to
the list to be returned
3: new( )
6: add(CourseOffering)
CourseCatalogSystem
getCourseOfferings()
initialize()
<<subsystem proxy>>
ICourseCatalogSystem
getCourseOfferings()
initialize()
<<Interface>>
DBCourseOfferring
create()
read()
initialize()
9
1
Рис
. 3.22.
Диаграмма
последовательности
ICourseCatalogSystem:
:initialize,
описывающая
взаимодействие
элементов
при
реализации
операции
интерфейса
initialize
3.6.2.
Моделирование
распределенной
конфигурации
системы
Распределенная
конфигурация
системы
моделируется
с
помощью
диаграммы
размещения
.
Ее
основные
элементы
:
•
узел
(node) –
вычислительный
ресурс
(
процессор
или
другое
устройство
(
дисковая
память
,
контроллеры
различных
устройств
и
т
.
д
.).
Для
узла
можно
задать
выполняющиеся
на
нем
процессы
;
•
соединение
(connection) –
канал
взаимодействия
узлов
(
сеть
).
Пример
:
сетевая
конфигурация
системы
регистрации
(
без
процессов
).
Рис
. 3.23.
Сетевая
конфигурация
системы
регистрации
Registration
Server
Desktop PC
<<Campus LAN>>
Desktop PC
<<legacy>>
<<legacy>>
<<Campus LAN>>
<<Campus LAN>>
<<Campus LAN>>
CourseCatalogSystem
BillingSystem
: DBCourseOfferring
CourseCatalog
System Client
: CourseCatalogSystem
1
: initialize( )
2: initialize( )
92
Распределение
процессов
по
узлам
сети
производится
с
учетом
следующих
факторов
:
•
используемые
образцы
распределения
(
трехзвенная
клиент
-
серверная
конфигурация
, «
толстый
клиент
», «
тонкий
клиент
»,
равноправные
узлы
(peer-to-peer)
и
т
.
д
.);
•
время
отклика
;
•
минимизация
сетевого
трафика
;
•
мощность
узла
;
•
надежность
оборудования
и
коммуникаций
.
Пример
распределения
процессов
по
узлам
приведен
на
рис
. 3.24.
Рис
. 3.24.
Сетевая
конфигурация
системы
регистрации
с
распределением
процессов
по
узлам
Registration
Server
Desktop PC
<<Campus LAN>>
Desktop PC
<<legacy>>
<<legacy>>
<<Campus LAN>>
<<Campus LAN>>
<<Campus LAN>>
CourseCatalogSystem
BillingSystem
StudentApplication
RegistrarApplication
StudentApplication
RegistrarApplication
CourseCatalogSystemAccess
CourseRegistrationProccess
CloseRegistrationProccess
BillingSystemAccess