|
||||||||||||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Проектирование архитектурыЦели проектирования архитектуры системы: · анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов; · уточнение архитектуры с учетом возможностей повторного использования; · идентификация архитектурных решений и механизмов, необходимых для проектирования системы. Вводятся глобальные пакеты: · базисные (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 Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |