Системная архитектура Copyright © Мухортов В. В., Няньчук-Татарский Н. А., 2001-2004 Copyright © ООО «Интекс», 2003-2004 Системная архитектура Архитектура – это совокупность существенных решений, которые определяют организацию программной системы. Архитектура задается на том уровне абстракции, когда возможен охват всей системы в целом Системная архитектура: подробнее Архитектура являет собой: набор структурных элементов системы спецификацию поведения этих элементов и отношения между ними структуру и поведение все более и более крупных подсистем, построенных на базе этих элементов общие соображения о построении системы, например способ объединения Системная архитектура: подробнее верхнеуровневое описание структуры системы, в котором: специфицируются компоненты системы в целом (модули, подсистемы, основные классы объектов и объекты, слои etc); специфицируются протоколы взаимодействия, синхронизации, доступа к данным etc; функциональность распределяется по компонентам; определяются требования к компонентам; определяется физическое распределение модулей; определяется композиция модулей (функциональность, предоставляемая одними модулями другим); решаются вопросы масштабируемости, производительности, безопасности, взаимодействия системы со своим окружением и другие вопросы, поставленные в требованиях к системе; производится выбор из альтернатив дизайна в соответствии с целями проекта. Цели Получить верхнеуровневое видение того, как будет устроена система На основе этого провести декомпозицию работ Обеспечить дальнейшую расширяемость системы и создание переиспользуемых компонент Системный Архитектор (Software Architect) Отвечает за: Технологическую сторону программного проекта Качество реализации программного продукта Специфицирование того, как будет построена система Архитектор «Идеальный архитектор должен быть писателем, математиком, знать историю, быть знатоком философии, понимать музыку, обладать знаниями в области медицины, юриспруденции и астрономии» Витрувий, 25 г до н.э. “Работа архитектора это серии суб-оптимальных решений, сделанных под давлением в обстановке неуверенности и нехватки информации”. Rational Unified Process Архитектурные проблемы Выбор архитектурных решений из альтернатив Выделение и композиция модулей, распределение функциональности Безопасность (security) Persistent objects (persistent layer) Физическое распределение (конфигурации) Масштабируемость (scalability) Производительность (performance) Уровень (Layer) - пакет, включающий другие пакеты некоторого уровня абстракции. UML: package со стереотипом <<layer>> Типичные уровни: •Application – набор специфичных для приложения подсистем •Business – подсистемы специфичные для данного типа бизнеса •Middleware – подсистемы c платформенно-независимыми сервисами •System – интерфейсы к аппаратуре, API операционной системы и т. д. Альтернативное разделение на уровни <<layer>> Presentation layer <<layer>> UI Logic <<layer>> Data Objects ( Persistence Layer) <<layer>> Business Logic <<layer>> Business Objects Альтернативное разделение на уровни Presentation layer – Уровень представления пользовательского интерфейса. UI Logic layer – реализует логику переходов между элементами пользовательского интерфейса Business Logic – реализует основной функционал приложения Business Objects – содержит объекты данных, специфичные для приложения Data Objects (Persistence Layer) – обеспечивает хранение данных Подсистема (subsystem) Реализует некоторую группу функциональности. Например: подсистема работы с почтой, подсистема работы с контактами. Как правило отделена от системы одним или несколькими интерфейсами (contracts), поэтому может переиспользоваться в нескольких системах. Может находиться на нескольких уровнях системы Другое название: модуль (module) системы Архитектура: модель 4+1 представления Описание View) Описание Описание View) Описание View) Описание логической структуры (Logical процессов (Process View) реализации (Implementation развертывания(Deployment сценариев (Scenario View) Модель 4+1 представления Logical View – диаграммы классов и пакетов Process View - диаграммы классов со стереотипами <<process>> и <<thread>> Implementation View – физическое разбиение системы на компоненты Deployment view – описание развертывания системы на узлах Scenario View – Use-case realizations, диаграммы взаимодействия, диаграммы деятельностей и состояния. Шаги Определить подсистемы и слои Определить интерфейсы между ними Составить диаграммы взаимодействий для проверки согласованности статической структуры. По необходимости детализировать структуру отдельных подсистем и слоев Определить физическую структуру системы и особенности развертывания Диаграммы компонентов Component Other Component зависимость компонента Стереотипы компонентов: <<JAR>>, <<EXE>>, <<DLL>>, <<EAR>> <<Assembly>> для указания особенностей развертывания <<Subprogram Specification>>, <<Subprogram Body>> - для различия определения и описания Для группировки компонентов применяются пакеты Архитектурные шаблоны • • • • • Layers/tiers Client/server architecture Peer-to-peer architecture Pipes and filters architecture ACL security Layered architecture Проблема: построить приложение, функциональность которого могла бы быть распределена по нескольким физическим узлам. Пример противоположного подхода: Draw UI with an interface building tool Write blocks of code, that execute application actions in response to user input Недостатки: • Отсутствует модульность • Низкая • Невозможно переиспользование масштабируемость • Сложность расширения • Низкая переносимость Layered architecture Возможное решение – layered architecture: Define use-cases Define use-cases’ realizations Divide use-cases’ realization objects (classes) into different communicating layers Data Layer Business Object Layer Business Logic Layer UI Logic Layer Presentation Layer Существенные черты: • каждый слой предоставляет сервисы следующему и использует сервисы предыдущего • взаимодействуют только соседние слои • каждый слой реализует четко определенную часть функциональности • Независимость от разбиения на модули Преимущества: • возможность независимой разработки • сужение набора необходимых для создания каждого слоя знаний Client/server architecture Иногда – two-tier architecture. 1 Server Client * Существенные черты: • наличие одного сервера, предоставляющего услуги многим клиентам • отсутствие прямого взаимодействия между клиентами Преимущества: • централизованное обслуживание Недостатки: • сервер – вероятный bottleneck Peer-to-peer architecture Participant Participant Participant Participant Существенные черты: • отсутствие центрального сервера • равные права участников Преимущества: • надежность Недостатки: • распространение изменений Pipes and filters architecture Filter Pipe Контекст: системы, обрабатывающие потоки данных Проблема: • система создается несколькими разработчиками • решение задачи естественно разбивается на несколько независимых шагов (этапов обработки) • задачи могут меняться, требуя декомпозиции шагов обработки Существенные черты: • фильтр – независимый блок, получающий на вход поток(и) данных и выдающий поток(и) данных • возможна достаточно простая переконфигурация системы фильтров (соединение их с помощью pipes) • фильтры работают параллельно ACL Subject 1 0..n Principal Resource 1 ACLEntry 0..n 1 1 ACL Subject – соответствует сессии пользователя Principal – некоторый идентификатор которому можно поставить в соответствие права доступа (например uid, gid, etc) Resource – ресурс, доступ к которому ограничен ACL – список principals, которым разрешен доступ к ресурсу При каждом обращении к ресурсу производится проверка, есть ли у обращающегося subject’а principal, которому разрешено данное действие