06-SystemArchitecture

Системная архитектура
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, которому
разрешено данное действие