ТРПО_Тимонов_М1_Системная архитектура

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
СИСТЕМНАЯ АРХИТЕКТУРА
Материал 1 Copyright © 2014
Тимонов В.С. (СибГУТИ)
2
Часть 1 - Системная архитектура

Архитектура – это совокупность существенных
решений, которые определяют организацию
программной системы.

Архитектура задается на том уровне абстракции,
когда возможен охват всей системы в целом

Архитектура пытается определить внутреннюю
структуру получаемой системы, задавая способ,
которым система организована или конструируется.
Виды архитектур
3






Архитектура программного обеспечения (Software);
Архитектура аппаратного обеспечения (Hardware), которое включает такие
элементы, как ЦПУ, память, жесткие диски, периферийные устройства,
например, принтер, а также элементы, используемые для их соединения;
Архитектура организации (Organization), которая включает элементы,
имеющие отношение к бизнес-процессам, структурам организации, ролям и
ответственности, а также основные области специализации организации;
Структура информации (Information), включающая структуры, которые
упорядочивают информацию;
Архитектура программного обеспечения, архитектура аппаратного
обеспечения, архитектура организации и архитектура информации, которые
являются подмножеством целостной архитектуры системы (System),
рассматривались ранее в данной статье;
Архитектура корпорации (Enterprise), которая похожа на архитектуру системы
тем, что тоже включает элементы, а именно: аппаратное и программное
обеспечение и людей. Однако архитектура корпорации более сильно связана
с бизнесом, так как она концентрируется на достижении бизнес-целей и
занимается такими объектами, как быстрое реагирование на возникающие
ситуации и эффективность организации. Архитектура корпорации может
выходить за границы компании.
Архитектура [Крачтен (Kruchten)]
4

Архитектура - это набор значимых решений по
поводу организации системы программного
обеспечения, набор структурных элементов и их
интерфейсов, при помощи которых компонуется
система, вместе с их поведением, определяемым
во взаимодействии между этими
элементами, компоновка элементов в постепенно
укрупняющиеся подсистемы , а также стиль
архитектуры который направляет эту организацию - элементы и их интерфейсы, взаимодействия и
компоновку.
Архитектура [Басс (Bass) и др.]
5

Архитектура программы или компьютерной
системы - это структура или структуры системы,
которые включают элементы программы,
видимые извне свойства
этих элементов и связи между ними.
Архитектура [UML 1.5]
6

Архитектура – это структура организации и
связанное с ней поведение системы.
Архитектуру можно рекурсивно разобрать на
части, взаимодействующие посредством
интерфейсов, связи, которые соединяют части,
и условия сборки частей. Части, которые
взаимодействуют через интерфейсы, включают
классы, компоненты и подсистемы.
Архитектура [Мак-Говерн (McGovern)]
7

Архитектура программного обеспечения
системы или набора систем состоит из всех
важных проектных решений по поводу структур
программы и взаимодействий между этими
структурами, которые составляют системы.
Проектные решения обеспечивают желаемый
набор свойств, которые должна поддерживать
система, чтобы быть успешной. Проектные
решения предоставляют концептуальную
основу для разработки системы, ее поддержки
и обслуживания.
Характеристики
8

Архитектура являет собой:
 набор
структурных элементов системы
 спецификацию поведения этих элементов и
отношения между ними
 структуру и поведение все более и более крупных
подсистем, построенных на базе этих элементов
 общие соображения о построении системы,
например способ объединения
Значимость
9






Архитектура концентрируется на значимых элементах
Хотя архитектура определяет структуру и поведение, она определяет не все в структуре
и не все в поведении. Она занимается только такими элементами, которые
оцениваются как значимые.
Значимые элементы - это элементы, которые имеют продолжительное и устойчивое
действие, например, главные структурные элементы, элементы, связанные с основным
поведением и элементы, которые определяют значимые свойства, такие как
надежность и масштабируемость.
Архитектурную значимость можно также назвать экономической значимостью,
поскольку главный признак, по которому некоторые элементы оцениваются выше
остальных - это стоимость создания и стоимость изменения.
Стоит также отметить, что набор значимых элементов не является статичным и может
измениться с течением времени. Он может измениться при уточнении результата
требований, идентификации рисков, создании исполняемой программы. Однако
относительная стабильность архитектуры несмотря на изменения, в некоторой степени
является признаком хорошей архитектуры, хорошо отлаженного процесса разработки и
хорошего разработчика.
Если архитектура требует постоянного пересмотра при относительно небольших
изменениях, это плохой признак. Тем не менее, если архитектура относительно
стабильна, это утверждение справедливо.
Заинтересованные лица
10






В конечном итоге архитектура создается для удовлетворения
комплекса потребностей заинтересованного лица.
Часто невозможно выполнить все выраженные пожелания.
Заинтересованное лицо может попросить, чтобы некоторая
функциональность укладывалась в определенный временной
промежуток, но эти две потребности (функциональность и
промежуток времени) являются взаимоисключающими.
Можно либо уменьшить границы функции, чтобы она
соответствовала расписанию, либо предоставить полную
функциональность, но за более продолжительный отрезок времени.
Аналогично, различные заинтересованные лица могут иметь
противоречивые потребности и здесь должно быть достигнуто
определенное равновесие.
Поэтому принятие компромиссных решений является необходимым
аспектом процесса разработки архитектуры, а преодоление
трудностей - неотъемлемой чертой разработчика.
Заинтересованные лица
11







Конечный пользователь заинтересован в интуитивно понятном и корректном
поведении, производительности, надежности, удобстве использования,
доступности и безопасности;
Системный администратор заинтересован в интуитивно понятном
поведении, управлении и инструментах мониторинга;
Специалист по маркетингу заинтересован в конкурентноспособных функциях,
времени до выхода программы, позиционировании среди других продуктов
и в стоимости;
Клиент заинтересован в цене, стабильности и возможности планировать;
Разработчик заинтересован в понятных требованиях и простом и
непротиворечивом принципе проектирования;
Руководитель проекта заинтересован в предсказуемости хода
проектирования, планировании, продуктивном использовании ресурсов и
бюджета;
Специалист по сопровождению заинтересован в понятном,
непротиворечивом и документируемом принципе проекта, а также в
легкости, с которой можно вносить изменения.
Системный Архитектор (Software
Architect)
12

Отвечает за:
 Технологическую сторону
программного проекта
 Качество реализации программного продукта
 Специфицирование того, как будет построена
система
Цель и задачи
13



Получить верхнеуровневое видение того, как
будет устроена система
На основе этого провести декомпозицию работ
Обеспечить дальнейшую расширяемость
системы и создание переиспользуемых
компонент
Архитектурные проблемы
14
Выбор архитектурных решений из
альтернатив
 Выделение и композиция модулей,
распределение функциональности
 Безопасность (security)
 Физическое распределение (конфигурации)
 Масштабируемость (scalability)
 Производительность (performance)

Шаги
15
Определить подсистемы и слои
 Определить интерфейсы между ними
 Составить диаграммы взаимодействий для
проверки согласованности статической
структуры.
 По необходимости детализировать
структуру отдельных подсистем и слоев
 Определить физическую структуру системы
и особенности развертывания

Внешнее окружение
16


Система размещается в некотором окружении, и это окружение оказывает
влияние на архитектуру. Иногда это называют "архитектурой в контексте". В
основном, окружение определяет границы, в которых должна работать
система, а это, в свою очередь, влияет на архитектуру. Факторы окружения,
оказывающие влияние на архитектуру - это миссия бизнеса, которую будет
поддерживать архитектура, заинтересованные в системе лица, внутренние
технические ограничения (например, требование соответствовать
стандартам организации) и внешние технические ограничения (такие как
необходимость взаимодействовать с внешней системой или соответствовать
внешним регулятивным нормам).
Для того чтобы программа работала, ее запускают на некотором аппаратном
обеспечении. Поэтому результирующая система представляет собой
сочетание программного и аппаратного обеспечения, и именно это
сочетание позволяет добиться таких характеристик, как надежность и
производительность. Программное обеспечение не может достичь этих
характеристик без аппаратного обеспечения, на котором оно выполняется.
Влияние
17




Имеет смысл выровнять структуры групп разработчиков программного
обеспечения в соответствии с архитектурой после того, как она будет
определена.
Однако чаще встречается ситуация, когда первоначальная группа
разработчиков оказывает влияние на архитектуру, а не наоборот. Это
ошибка, которой следует избегать, поскольку в результате обычно получается
архитектура, далекая от идеала.
"Закон Конвея" утверждает, что "если у вас есть четыре группы, работающих
над компилятором, то вы получите четырехпроходный компилятор".
Практически мы часто непреднамеренно создаем архитектуры, которые
являются отражением организации, создающей архитектуру.
Однако так же справедливо будет сказать, что это несколько
идеализированное представление не всегда реально, поскольку, по
причинам чисто прагматичным, реальная структура коллектива и доступные
навыки представляют весьма ощутимое ограничение того, что могло бы
быть, и разработчику следует это учитывать.
Каждому по архитектуре
18




Следует также отметить, что каждая система имеет архитектуру, даже
если эта архитектура формально не документирована или система
слишком проста, и, скажем, состоит из одного элемента.
Обычно документирование архитектуры представляет собой очень
ценное средство. Документированные архитектуры имеют
тенденцию быть более продуманными - а, следовательно, более
эффективными - чем недокументированные, поскольку процесс
записи архитектуры естественным образом ведет к всестороннему
обдумыванию.
И наоборот, если архитектура не документируется, трудно (если не
невозможно) доказать, что она соответствует утвержденным
требованиям в терминах адресных характеристик, таких как удобство
обслуживания, заимствование передового опыта и так далее.
Архитектуры, которые не документировались, как, кажется,
большинство из тех, что существуют на сегодняшний день, имеют
тенденцию быть случайными, а не продуманными.
19
Часть 2 - Разделение на уровни
Уровень (Layer)
20


- пакет, включающий другие пакеты некоторого уровня абстракции.
 UML: package со стереотипом <<layer>>
Типичные уровни:
 Application – набор специфичных для приложения подсистем

Business – подсистемы специфичные для данного типа бизнеса

Middleware – подсистемы c платформенно-независимыми
сервисами

System – интерфейсы к аппаратуре, API операционной системы
и т. д.
Пример взаимодействия
21
<<layer>>
Presentation
layer
<<layer>>
UI Logic
<<layer>>
Data Objects (
Persistence Layer)
<<layer>>
Business Logic
<<layer>>
Business
Objects
Разделение на уровни
22





Presentation layer – Уровень представления пользовательского
интерфейса.
UI Logic layer – реализует логику переходов между элементами
пользовательского интерфейса
Business Logic – реализует основной функционал приложения
Business Objects – содержит объекты данных, специфичные для
приложения
Data Objects (Persistence Layer) – обеспечивает хранение
данных
Подсистема (subsystem)
23

Реализует некоторую группу
функциональности. Например: подсистема
работы с почтой, подсистема работы с
контактами.

Как правило отделена от системы одним или
несколькими интерфейсами (contracts),
поэтому может повторно использоваться в
нескольких системах.

Другое название: модуль (module) системы
Диаграммы компонентов
24
Component
Other
Component
зависимость
компонента

Стереотипы компонентов:



<<JAR>>, <<EXE>>, <<DLL>>, <<EAR>> <<Assembly>> - для
указания особенностей развертывания
<<Subprogram Specification>>, <<Subprogram Body>> - для различия
определения и описания
Для группировки компонентов применяются пакеты
25
Архитектура: модель 4+1
представления

Описание логической структуры (Logical View)

Описание процессов (Process View)

Описание реализации (Implementation View)

Описание развертывания(Deployment View)

Описание сценариев (Scenario View)
Модель 4+1 представления
26





Logical View – диаграммы классов и пакетов
Process View - диаграммы классов со стереотипами
<<process>> и <<thread>>
Implementation View – физическое разбиение системы на
компоненты
Deployment view – описание развертывания системы на узлах
Scenario View – Use-case realizations, диаграммы
взаимодействия, диаграммы деятельностей и состояния.
27
Архитектурные шаблоны
Layers
 Client/server
 Peer-to-peer
 Pipes and filters
 ACL security

Layered architecture
28
Data Layer
Business Object
Layer
Business Logic
Layer
Существенные черты:





UI Logic Layer
Presentation
Layer

каждый слой предоставляет сервисы следующему и использует сервисы
предыдущего
взаимодействуют только соседние слои
каждый слой реализует четко определенную часть функциональности
Независимость от разбиения на модули
Преимущества:


возможность независимой разработки
сужение набора необходимых для создания каждого слоя знаний
Client/server architecture
29
Server
Client
*

Существенные черты:



наличие одного сервера, предоставляющего услуги многим клиентам
отсутствие прямого взаимодействия между клиентами
Преимущества:


1
централизованное обслуживание
Недостатки:

Проблема “бутылочного горлышка” на сервере
Client/server architecture
30

Несколько моделей клиент-серверного
взаимодействия:


"Толстый" клиент. Наиболее часто встречающийся
вариант реализации архитектуры клиент-сервер в уже
внедренных и активно используемых системах. Такая
модель подразумевает объединение в клиентском
приложении как PL, так и BL. Серверная часть, при
описанном подходе, представляет собой сервер баз
данных.
"Тонкий" клиент. Активно используется в корпоративной
среде в связи с распространением Internet-технологий и, в
первую очередь, Web-браузеров. В этом случае
клиентское приложение обеспечивает реализацию PL, а
сервер объединяет BL и AL.
Client/server architecture
31


Модели, основанные на Internet-технологиях и
применяемые для построения
внутрикорпоративных систем получили
название intranet.
Браузер не обязательно является HTML"окном", но, в не меньшей степени,
представляет собой универсальную среду
загрузки объектных приложений/компонент Java или ActiveX.
Архитектура точка-точка - P2P
32
Participant
Participant
Participant
Participant

Существенные черты:
отсутствие центрального сервера
 равные права участников


Преимущества:


надежность
Недостатки:

распространение изменений
Архитектура “Трубы и фильтры” – P&F
33
Filter
Pipe
Назначение: системы, обрабатывающие потоки данных
 Проблема:




система создается несколькими разработчиками
решение задачи естественно разбивается на несколько независимых шагов (этапов
обработки)
задачи могут меняться, требуя декомпозиции шагов обработки
Существенные черты:



фильтр – независимый блок, получающий на вход поток(и) данных и выдающий
поток(и) данных
возможна достаточно простая переконфигурация системы фильтров (соединение
их с помощью pipes)
фильтры работают параллельно
Списки контроля доступа - ACL
34
Списки контроля доступа используются в системах с избирательным
управлением доступа.
Subject
1
0..n
Principal
Resource
1
ACLEntry 0..n

1
1
ACL
ACL (Access Control List — список контроля доступа, поанглийски произносится «экл») — определяет, кто или что
может получать доступ к конкретному объекту, и какие
именно операции разрешено или запрещено этому
субъкту проводить над объектом.
Списки контроля доступа - ACL
35





ACL – список principals, которым разрешен
доступ к ресурсу
При каждом обращении к ресурсу производится
проверка, есть ли у обращающегося subject’а
principal, которому разрешено данное действие
Subject – соответствует сессии пользователя
Principal – некоторый идентификатор которому
можно поставить в соответствие права доступа
(например uid, gid, etc)
Resource – ресурс, доступ к которому ограничен
36
Выводы

Задача накладывает свои требования на
выбор системной архитектуры;

Выбор системной архитектуры
определяет возможности и ограничения
проектируемой системы.
37
Использованные материалы
1.
2.
"The Process of Software Architecting"
http://www.ibm.com/developerworks/ru/library/eeles/
Лекции В. Мухортова.