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

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

Читайте также:
  1. Архитектура Беларуси в ХХ столетии. Эклектика, модерн, конструктивизм, неоклассицизм. Достижения современной белорусской архитектуры и градостроительства Беларуси.
  2. Архитектурные стили, понятие, признаки, виды. Основные стили белорусской архитектуры.
  3. Глава 7.3. Проектирование производственных систем.
  4. Диалоговое проектирование ТП
  5. Задание 10 (практическое занятие 6 по теме «Комплекс маркетинга: проектирование продукта»)
  6. Концепция микроядерной архитектуры ОС
  7. Лекция 21. Расчет и проектирование свайных фундаментов
  8. Макропроектирование ПС
  9. НИСХОДЯЩЕЕ ПРОЕКТИРОВАНИЕ
  10. Нисходящее проектирование
  11. ОРГАНИЗАЦИОННОЕ ПРОЕКТИРОВАНИЕ
  12. Организационное проектирование. Его сущность, цели, задачи.

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

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

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

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

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

· базисные (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


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)