Студопедия

КАТЕГОРИИ:

АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника


Проектирование архитектуры




Цели проектирования архитектуры системы:

· анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

· уточнение архитектуры с учетом возможностей повторного использования;

· идентификация архитектурных решений и механизмов, необходимых для проектирования системы.

Вводятся глобальные пакеты:

· базисные (foundation) классы (списки, очереди и т.д.);

· обработчики ошибок (error handling classes);

· математические библиотеки;

· утилиты;

· библиотеки других поставщиков.

Определяются проектные классы (design classes):

· класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;

· сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.

Примеры возможных подсистем:

· классы, обеспечивающие сложный комплекс услуг (например, обеспечение безопасности и защита);

· граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами;

· различные продукты: коммуникационное ПО (middleware, поддержка COM/CORBA), доступ к базам данных, типы и структуры данных (стеки, списки, очереди), общие утилиты (математические библиотеки), различные прикладные продукты.

Принятие решения о преобразовании класса в подсистему определяется опытом и знаниями архитектора проекта.

Соглашения по проектированию интерфейсов:

· Имя интерфейса: короткое (одно-два слова), отражающее его роль в системе.

· Описание интерфейса: должно отражать его обязанности (размер – небольшой абзац).

· Описание операций: имя, отражающее результат операции, ключевые алгоритмы, возвращаемое значение, параметры с типами.

· Документирование интерфейса: характер использования операций и порядок их выполнения (показывается с помощью диаграмм последовательности), тестовые планы и сценарии и так далее. Вся эта информация объединяется в специальный пакет со стереотипом <<subsystem>>, который содержит элементы, образующие подсистему, диаграммы последовательности и/или кооперативные диаграммы, описывающие взаимодействие элементов при реализации операций интерфейса, и другие диаграммы.

· Класс <<subsystem proxy>> непосредственно реализует интерфейс и управляет реализацией его операций.

· Все интерфейсы должны быть полностью определены в процессе проектирования архитектуры, поскольку они будут служить в качестве точек синхронизации при параллельной разработке.

Выделение архитектурных уровней:

Application Layer – содержит элементы прикладного уровня (пользовательский интерфейс);

Business Services Layer – содержит элементы, реализующие бизнес-логику приложений (наиболее устойчивая часть системы);

Middleware Layer – обеспечивает сервисы, независимые от платформы.

Пример выделения архитектурных уровней и объединения элементов модели в пакеты для системы регистрации приведен на рис. 3.17.

Для того чтобы поместить класс в пакет, достаточно просто перетащить его в браузере на нужный пакет.

 

Рис. 3.17. Структура логического представления модели на шаге проектирования

 

Данное представление отражает следующие решения, принятые архитектором:

· Выделены три архитектурных уровня (созданы три пакета со стереотипом <<layer>>);

· В пакете Application создан пакет Registration, куда включены граничные и управляющие классы;

· Граничный класс CourseCatalogSystem преобразован в подсистему (пакет CourseCatalogSystem со стереотипом <<subsystem>>)

· В пакет Business Services, помимо подсистемы CourseCatalogSystem, включены еще два пакета: пакет External System Interfaces включает интерфейс с подсистемой CourseCatalogSystem (класс ICourseCatalogSystem со стереотипом <<Interface>>), а пакет University Artifacts – все классы-сущности.

 
 

Структура и диаграммы пакета (подсистемы) CourseCatalogSystem показана на рис. 3.18 – 3.22.

 
 

Рис. 3.18. Структура пакета CourseCatalogSystem

Рис. 3.19. Зависимости между подсистемой и другими пакетами (диаграмма классов CourseCatalogSystem Dependencies)

Чтобы поместить зависимость между пакетами на диаграмму классов:

1. Нажмите кнопку Dependency панели инструментов.

2.

 
 

Проведите линию зависимости от зависимого пакета к тому, от которого он зависит.

Рис. 3.20. Классы, реализующие интерфейс подсистемы (диаграмма классов ICourseCatalogSystem)

 
 

Класс DBCourseOfferring отвечает за взаимодействие с БД каталога курсов.

Рис. 3.21. Диаграмма последовательности ICourseCatalogSystem::getCourseOfferings, описывающая взаимодействие элементов при реализации операции интерфейса getCourseOfferings

 
 

Рис. 3.22. Диаграмма последовательности ICourseCatalogSystem: :initialize, описывающая взаимодействие элементов при реализации операции интерфейса initialize


Поделиться:

Дата добавления: 2014-12-23; просмотров: 132; Мы поможем в написании вашей работы!; Нарушение авторских прав





lektsii.com - Лекции.Ком - 2014-2024 год. (0.007 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав
Главная страница Случайная страница Контакты