Архитектура программы что это такое

Содержание

Архитектура программного обеспечения

Аннотация: Рассматривается понятие архитектуры ПО, влияние архитектуры на свойства ПО, а также методы оценки архитектуры. Рассказывается об основных элементах унифицированного языка моделирования UML.

Анализ области решений

Допустим, мы разобрались в предметной области , поняли, что требуется от будущей программной системы, даже зафиксировали настолько полно, насколько смогли, требования и пожелания всех заинтересованных лиц ко всем аспектам качества программы. Что делать дальше?

На этом этапе (а точнее, гораздо раньше, обычно еще в ходе анализа предметной области ) исследуются возможные способы решения тех задач, которые поставлены в требованиях. Не всегда бывает нужно специальное изучение этого вопроса — чаще всего имеющийся опыт разработчиков сразу подсказывает, как можно решать поставленные задачи. Однако иногда, все-таки, возникает потребность сначала понять, как это можно сделать и, вообще, возможно ли это сделать и при каких ограничениях.

10 минут, чтобы узнать о профессии архитектор

Таким образом, явно или неявно, проводится анализ области решений. Целью этой деятельности является понимание, можно ли вообще решить стоящие перед разрабатываемой системой задачи, при каких условиях и ограничениях это можно сделать, как они решаются, если решение есть, а если нет — нельзя ли придумать способ его найти или получить хотя бы приблизительное решение, и т.п. Обычно задача хорошо исследована в рамках какой-либо области человеческих знаний, но иногда приходится потратить некоторые усилия на выработку собственных решений. Кроме того, решений обычно несколько и они различаются по некоторым характеристикам, способным впоследствии сыграть важную роль в процессе развития и эксплуатации созданной на их основе программы. Поэтому важно взвесить их плюсы и минусы и определить, какие из них наиболее подходят в рамках данного проекта, или решить, что все они должны использоваться для обеспечения большей гибкости ПО .

Когда определены принципиальные способы решения всех поставленных задач (быть может, в каких-то ограничениях), основной проблемой становится способ организации программной системы, который позволил бы реализовать все эти решения и при этом удовлетворить требованиям, касающимся нефункциональных аспектов разрабатываемой программы. Искомый способ организации ПО в виде системы взаимодействующих компонентов называют архитектурой, а процесс ее создания — проектированием архитектуры ПО .

Архитектура программного обеспечения

Под архитектурой ПО понимают набор внутренних структур ПО , которые видны с различных точек зрения и состоят из компонентов , их связей и возможных взаимодействий между компонентами , а также доступных извне свойств этих компонентов [1].

Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО , который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает. Обычно при разработке ПО термин » компонент » (см. далее при обсуждении компонентных технологий ) имеет несколько другой, более узкий смысл — это единица развертывания, самая маленькая часть системы, которую можно включить или не включить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет некоторому набору правил, называемому компонентной моделью . Там, где возможны недоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции до обсуждения UML мы будем использовать преимущественно широкое понимание этого термина, а дальше — наоборот, узкое.

Архитектура ПО. Введение

В определении архитектуры упоминается набор структур, а не одна структура. Это означает, что в качестве различных аспектов архитектуры, различных взглядов на нее выделяются различные структуры, соответствующие разным аспектам взаимодействия компонентов. Примеры таких аспектов — описание типов компонентов и типов статических связей между ними при помощи диаграмм классов , описание композиции компонентов при помощи структур ссылающихся друг на друга объектов, описание поведения компонентов при помощи моделирования их как набора взаимодействующих, передающих друг другу некоторые события, конечных автоматов.

Архитектура программной системы похожа на набор карт некоторой территории. Карты имеют разные масштабы, на них показаны разные элементы (административно-политическое деление , рельеф и тип местности — лес , степь, пустыня, болота и пр., экономическая деятельность и связи), но они объединяются тем, что все представленные на них сведения соотносятся с географическим положением. Точно так же архитектура ПО представляет собой набор структур или представлений , имеющих различные уровни абстракции и показывающих разные аспекты (структуру классов ПО , структуру развертывания, т.е. привязки компонентов ПО к физическим машинам, возможные сценарии взаимодействий компонентов и пр.), объединяемых сопоставлением всех представленных данных со структурными элементами ПО . При этом уровень абстракции данного представления является аналогом масштаба географической карты.

Рассмотрим в качестве примера программное обеспечение авиасимулятора для командной тренировки пилотов. Задачей такой системы в целом является контроль и выработка необходимых для безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываются навыки поведения в особых ситуациях, связанных с авариями, частичной потерей управления самолетом, тяжелыми условиями полета, и т.д.

Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие:

Скоростной и высотный режим полета, запас горючего, их изменения со временем.
Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды.
Погода за бортом и ее изменения со временем.
Рельеф и другие особенности местности в текущий момент, их изменения со временем.
Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними.
Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем.
Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики.
Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и «смерть» отдельных членов экипажа.

При этом вся совокупность условий должна быть непротиворечивой, выглядеть и развиваться подобно реальным событиям. Некоторые условия, например, погода, должны изменяться достаточно медленно, другие события — происходить внезапно и приводить к связанным с ними последствиям (нарушение герметичности корпуса может сопровождаться поломками каких-то элементов системы мониторинга или «смертью» одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны, через некоторое время летчики должны увидеть грозу за бортом и она может начать оказывать влияние на условия полета.

Понятно, что одним из элементов симулятора служит система визуализации обстановки за бортом — она показывает пилотам «вид за окнами». Пилоты в ходе полета ориентируются по показателям огромного количества датчиков, представленных на приборной панели самолета. Вся их работа тоже должна симулироваться.

Зачем нужна архитектура ПО

Первые разработчики создавали программное обеспечение без архитектуры. Сначала это казалось удобным: никаких издержек, связанных с планированием, и ускоренное прототипирование. Но мере усложнения ПО теряло гибкость и управляемость, а каждое новое изменение обходилось все дороже. Это мешало развивать проект за границы, определенные изначально. Такая система получила название Большой комок грязи (Big Ball of Mud).

За годы развития ПО разработчикам удалось придумать надежные подходы, чтобы устранить недостатки проектирования без архитектуры. Ниже представлены некоторые из самых известных.

Многослойная архитектура (Layered Architecture).
Многоуровневая архитектура (Tiered Architecture).
Сервис-ориентированная архитектура (Service Oriented Architecture — SOA).
Микросервисная архитектура (Microservice Architecture).

Подробно рассмотрим каждую из них.

Многослойная архитектура

Этот подход работает по принципу разделения ответственностей. ПО разделено на слои, лежащие друг на друге, и каждый из них выполняет определенную обязанность.

Архитектура делит ПО на следующие слои.

Слой представления (Presentation Layer) содержит пользовательский интерфейс и отвечает за обеспечение хорошего пользовательского опыта.
Слой бизнес-логики (Business Logic Layer), как следует из названия, содержит бизнес-логику приложения. Он отделяет UI/UX от вычислений, связанных с бизнесом. Это позволяет с легкостью изменять логику в зависимости от постоянно меняющихся бизнес-требований, никак не влияя на другие слои.
Слой передачи данных (Data Link Layer) отвечает за взаимодействие с постоянными хранилищами, такими как базы данных, и прочую обработку информации, которая не связана с бизнесом.

Данные и элементы управления проходят через каждый слой в дизайне и передаются от одного к другому. Эта система также повышает уровень абстракции и в некоторой степени даже стабильность ПО.

Преимущества

Более простая реализация по сравнению с другими подходами.
Предлагает абстракцию благодаря разделению ответственностей между уровнями.
Изолирование защищает одни слои от изменений других.
Повышает управляемость программного обеспечения за счет слабой связанности.

Недостатки

Не предлагает большой масштабируемости.
ПО, созданное с таким подходом, будет иметь монолитную структуру, усложняющую внесение модификаций.
Данные должны проходить по каждому слою, даже если нет необходимости передавать их с определенных слоев.

Многоуровневая архитектура

Этот архитектурный подход разделяет комплекс ПО на уровни по принципу взаимодействия “клиент-сервер”. Архитектура может иметь один, два и больше уровней, разделяющих ответственности между поставщиком данных и потребителем.

Этот подход использует шаблон Request Response для связи между уровнями. В отличие от многослойной архитектуры, он предлагает масштабируемость, которая может быть как горизонтальной (масштабирование сети с помощью высокопроизводительных узлов), так и вертикальной (масштабирование каждого узла путем повышения его производительности).

Одноуровневая система

В данном подходе единая система работает как на стороне сервера, так и клиента. Это обеспечивает простоту развертывания и отличную скорость связи, а также устраняет необходимость межсистемного взаимодействия (Inter-system communication — ISC).

Такая система подходит только для небольших однопользовательских приложений.

Двухуровневая система

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

Клиент содержит слои презентации, бизнес-логики и передачи данных.
Сервер включает хранилища и базы данных.

Трехуровневая и n-уровневая системы

Такие архитектуры обладают высокой масштабируемостью как по горизонтали, так и по вертикали. Реализация n-уровневой системы, как правило, обходится дороже, но обеспечивает высокую производительность. Поэтому она обычно применяется в крупных и комплексных программных решениях.

Этот подход можно сочетать с современной сервис-ориентированной архитектурой, чтобы создавать сложнейшие модели. Поскольку реализация может оказаться дорогостоящей с точки зрения времени и ресурсов, рекомендуется использовать его для сложных ПО, требующих производительности и масштабируемости.

Сервис-ориентированная архитектура (SOA)

Эта архитектурная модель состоит из компонентов и приложений, которые связываются друг с другом с помощью четко определенных сервисов.

Она состоит из 5 элементов:

сервисы (Services);
сервисная шина (Service Bus);
сервисный репозиторий (Service Repository catalogue of services );
безопасность SOA (SOA Security);
управление SOA (SOA Governance).

Клиент отправляет запрос с использованием стандартного протокола и формата данных по сети. Этот запрос обрабатывается ESB (enterprise service bus — сервисная шина предприятия), которая считается сердцем сервис-ориентированной архитектуры и отвечает за оркестровку и маршрутизацию. С помощью сервисного репозитория ESB направляет запрос в специальный сервис, который может взаимодействовать с другими сервисами и базами данных, чтобы составить полезную нагрузку (данные) ответа.

Полный вызов ответа на запрос согласуется с правилами управления и безопасности SOA для выполнения безопасной и корректной транзакции.

Как правило, сервисы делятся на два вида.

Атомарные сервисы (Atomic services) предоставляют функциональности, которые не подлежат дальнейшей декомпозиции.
Композиционные сервисы (Composite services) сочетают в себе несколько атомарных сервисов, чтобы предоставлять сложную составную функциональность.

Типы сервисов

Организационные сервисы (Entity service).
Доменные сервисы (Domain Service).
Вспомогательные сервисы (Utility Service).
Интегрированный сервис (Integrated Service).
Сервис приложений (Application Service).
Сервис безопасности (Security Service).

Mикросервисная архитектура

При таком подходе приложение разрабатывается как набор небольших сервисов, каждый из которых работает в собственном процессе и связывается с легковесными механизмами, обычно API для HTTP-ресурса.

Эти сервисы основываются на бизнес-возможностях и могут развертываться независимо друг от друга с помощью полностью автоматизированного механизма.
Централизованное управление между сервисами минимально. Они могут быть написаны на разных языках, использовать разные технологии хранения данных.

Архитектура работает по принципу компонентизации сервисов. Она разделяет программное обеспечение на различные изолированные компоненты (сервисы), каждый из которых несет единую ответственность. Изменения в одной сервисе не должны затрагивать другие.

Состав микросервисов

Архитектура состоит из изолированных компактных микросервисов, способных расширяться независимо друг от друга. Она включает 5 следующих компонентов:

сервисы (Services);
сервисная шина (Service Bus);
внешняя конфигурация (External configuration);
шлюз API (API Gateway);
контейнеры (Containers).

Характеристики микросервисов

Микросервисная архитектура должна включать следующие характеристики.

Компонентизация через сервисы.
Организация вокруг бизнес-возможностей.
Ориентирована на продукты, а не проекты.
Умные конечные точки и глупые каналы (Smart endpoints and dumb pipes).
Децентрализованное управление.
Децентрализованное управление данными.
Автоматизация инфраструктуры.
Защита от сбоев.
Эволюционное проектирование.

Рекомендуется развивать каждый микросервис отдельно под управлением разных команд. Поскольку передача данных происходит по стандартному протоколу и формату данных, структура одного сервиса не затронет функциональность сопутствующих.

Преимущества

Предлагает слабую связанность благодаря высокой степени изоляции.
Повышает модульность.
Сбой в одном сервисе не затронет всю систему, поскольку они изолированы.
Предлагает высокую гибкость и масштабируемость.
Простота модификации может ускорить итерации.
Позволяет реализовать улучшенную систему обработки ошибок.
Решает проблемы с потоками данных, которые бывают у многослойной архитектуры.

Недостатки

Повышенный риск сбоя при обмене данными между сервисами.
Большим количеством сервисов трудно управлять.
Требует решения таких проблем, как задержки в сети, балансировка нагрузки и прочих трудностей, свойственных распределенной архитектуре.
Нуждается в комплексном тестировании в распределенной среде.
На реализацию потребуется гораздо больше времени.

Мы снова написали самый быстрый JS-фреймворк UI
3 совета, как стать мастером Йода по JavaScript
10 полезных инструментов для фронтенд-разработчика

Источник: medium.com

Это должен знать каждый разработчик: зачем нужна архитектура ПО и какие проблемы она решает

Разбираться в архитектуре хотя бы на базовом уровне нужно каждому разработчику. Пусть моя статья станет отправной точкой в изучении этой темы. Я расскажу, какие проблемы в разработке решает правильно подобранная архитектура, а также опишу ее реализацию с помощью портов и адаптеров.

Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага

В процессе разработки программного обеспечения вы можете столкнуться с разными трудностями. Их можно разделить на несколько категорий:

Скорость. Разработку замедляют темпы тестирования, добавление новых фич, изменение существующего функционала и т.д.

МЕНЕДЖЕР ПО РОБОТІ З КЛІЄНТАМИ
Ставайте затребуваним фахівцем та отримуйте свій офер мрії.

manager

Причина — код становится слишком связанным, как клубок нитей. Удачно подобранная архитектура поможет избежать подобных проблем. Для упрощения ситуации следует именно на уровне архитектуры «распутать» этот клубок.

Следовательно, упомянутые трудности делятся на следующие группы:

Отражают бизнес разрабатываемого продукта. Политика решает проблемы пользователя и говорит, что и когда должно происходить. Именно для этого создается конечный продукт.

Говорят о том, как должно происходить задуманное на уровне политики. Детали могут описывать получение данных из репозитория, отображение таблиц, отправку мейлов и т.д.

Архитектура по своей сути сконцентрирована именно на распределении политик и деталей.

Чтобы определить, к какой группе принадлежит код, подумайте: диктует ли код правила, как что-то в приложении должно работать? Если да, то это политика. Если код — просто реализация того, что должно работать, это детали . К ним относятся, например, фреймворки NestJS и Express.js или библиотеки npm типа Redux.

Многоуровневая архитектура

В такой архитектуре обычно есть две зоны ответственности, которые не пересекаются.

Доменный уровень

Здесь сосредоточены политики:

бизнес-логика;
правила;

В отличие от библиотек, они неизменны в программном обеспечении. То есть их нельзя заменить на что-то другое, не изменив суть самого продукта.

Инфраструктурный уровень

Эта прослойка архитектуры предназначена для деталей.

контроллеры;
роуты;
базы данных;
кэш;

Именно они заставляют код работать так, как того требуют политики. Детали на этом уровне можно заменять аналогами.

Для базового понимания принципа построения архитектуры разберем простой пример. На изображенной ниже диаграмме обратите внимание на полушария , которые расположены на пересечении между уровнями. Эти элементы предназначены для написанных на доменном уровне интерфейсов, которые должны быть реализованы на уровне инфраструктуры. Эти полушария — порты и адаптеры, и помогают соблюдать правила зависимости.

Правило зависимости

Следующая схема отражает путь запроса по всем уровням: от инфраструктурного до доменного и наоборот. Может показаться, что инфраструктура зависит от домена, а домен от инфраструктуры. Но это не так.

Все дело в правиле зависимости: что-то объявленное во внешнем круге не должно упоминаться в коде внутренним кругом. Это правило сохраняется и при большем количестве уровней.

В любом случае код должен указывать только внутрь диаграммы с внешних уровней на внутренние. Таким образом код доменного уровня не может зависеть от кода инфраструктуры. При этом код инфраструктурного уровня может зависеть от кода домена.

Порты и адаптеры

По сути правило зависимости следует правилу инверсии зависимостей. Но вполне реально обойти зависимость инфраструктуры от домена. Для этого нам нужны порты с адаптерами. В таком случае на внутреннем уровне мы создаем порты в виде интерфейсов и абстрактных классов, которые используют эти же интерфейсы.

Параллельно на внешнем уровне создаем адаптеры или конкретные классы и реализации, используя те же интерфейсы. Остается только соединить все это на внешнем уровне. Рассмотрим пример, как это сделать.

Предположим, что вам нужно создать механизм для отправки пользователю мейлов после регистрации. Конфигурация письма и условие его отправки находятся на доменном уровне. Эти параметры касаются того, что и когда должно произойти. Сама же реализация относится к инфраструктурному уровню. В этом случае мы описываем, как должна происходить отправка письма:

В результате можно написать интерфейс для сервиса. Он будет использовать только интерфейс, и реализации на этом уровне нигде не будет. Интерфейс можно представить в качестве одного фрагмента мозаики:

Далее описываем, как отправляется письмо с помощью определенной библиотеки. Каждую такую реализацию тоже можно представить как кусок мозаики:

Затем соединяем эти фрагменты в цельную картину. Для этого можно отправить в сервис любую реализацию, имплементирующую интерфейс. Они идеально подходят друг другу, благодаря чему появляются два инстанса. Каждый будет делать то же самое, но созданы они с помощью разных реализаций:

Что нам дает правильно подобранная архитектура

Простота тестирования

При правильном подходе к построению архитектуры тестировать код не сложно. Если соблюдать правила зависимости, у кода доменного уровня будет ноль зависимостей и он будет работать с абстракциями. За счет этого его можно полностью проверить.

Но перед тем, как заходить слишком далеко, спросите себя: сможете ли «поиздеваться» над написанным кодом? Если вы ссылаетесь на интерфейсы, следите за кодом и делаете его по всем принципам и архитектуре, то ответ «да». А ведь код легко протестировать. В противном случае ответ будет отрицательным.

Код доменного уровня прост в тестировании. Вы можете создавать моки, реализуя интерфейсы с замоканными классами. При этом у вас не будет зависимостей.

Код инфраструктурного уровня использует веб-сервисы, хранилища объектов, кэши. А это все усложняет тестирование. Хотя за счет удобства проверки доменного уровня вы сэкономите часть времени на тестах.

Гибкость кода

В случае изменения политики можно влиять на детали, ведь они зависят от политики. Но изменение деталей никогда не должно влиять на политику.

Код должен оставаться гибким, чтобы вы могли быстро менять детали без вмешательства в главную логику программы. Чем выше гибкость, тем выше надежность самого ПО.

Еще на начальной стадии создания приложения подумайте о механизмах гибкости. Когда продукт станет большим и нагруженным, ввести их будет гораздо сложнее. Вам ведь придется менять очень много элементов кода.

Совет напоследок — всегда ищите баланс. Если вы, например, создаете простой скрипт для парсинга одной новостной страницы, вряд ли вам понадобится гибкость архитектуры в полном объеме. Написание таких механизмов займет больше времени, чем работа над скриптом.

Лекция 6. Архитектура программного средства

Архитектура ПС  это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонент.

Основные задачи разработки архитектуры ПС:

Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;
определение способов взаимодействия между выделенными программными подсистемами.

6.2. Основные классы архитектур программных средств

Различают следующие основные классы архитектур программных средств [6.1]:

цельная программа;
комплекс автономно выполняемых программ;
слоистая программная система;
коллектив параллельно выполняемых программ.

Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не представляется слишком сложной. Естественно, что такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутствия какого-либо внешнего взаимодействия программы, кроме как взаимодействия ее с пользователем, а последнее описывается в документации по применению ПС). Комплекс автономно выполняемых программ состоит из набора программ, такого, что:

любая из этих программ может быть активизирована (запущена) пользователем;
при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
все программы этого набора применятся к одной и той же информационной среде.

Таким образом, программы этого набора по управлению не взаимодействуют  взаимодействие между ними осуществляется только через общую информационную среду. Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:

на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев;
каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определенный интерфейс, ничего не зная о внутреннем строении всех предшествующих слоев;
каждый слой располагает определенными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции.

Таким образом, в слоистой программной системе каждый слой может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями. В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [6.2]. Эта операционная система состоит из четырех слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение центрального процессора программам (процессам) в пакетном режиме. Только этот уровень осведомлен о мультипрограммных аспектах системы. На первом слое осуществляется управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не страничная) память. На втором слое осуществляется связь с консолью (пультом управления) оператора. Только этот слой знает технические характеристики консоли. На третьем слое осуществляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные программы не знают технических характеристик устройств ввода и вывода. Прикладные программы 3: Управление входными и выходными потоками данных 2: Обеспечение связи с консолью оператора 1: Управление памятью 0: Диспетчеризация и синхронизация процессов Компьютер Рис. 6.1. Архитектура операционной системы THE. Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путем передачи друг другу некоторых сообщений. Простейшей разновидностью такой архитектуры является конвейер. Возможности для организации конвейера имеются, например, в операционной системе UNIX [6.3]. Конвейер представляет собой последовательность программ, в которой стандартный вывод каждой программы, кроме самой последней, связан со стандартным вводом следующей программы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступает на ввод первой программе, которая переработанное сообщение передает следующей программе, а сама начинает обработку очередного сообщения потока. Таким же образом действует каждая программа конвейера: получив сообщение от предшествующей программы и, обработав его, она передает переработанное сообщение следующей программе и приступает к обработке следующего сообщения. Последняя программа конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из n программ, может одновременно находиться в обработке до n сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение). Рис. 6.2. Конвейер параллельно действующих программ. В общем случае коллектив параллельно действующих программ может быть организован в систему с портами сообщений. Порт сообщений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выдавать очередное сообщение другой программе по ее требованию. Сообщение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и использовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в порядке очереди не будет передано какой-либо программе по ее запросу. Таким образом, программа, передающая сообщение не будет находиться в стадии ожидания пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен принимающий порт). Пример программной системы с портами сообщений приведен на рис. 6.3. Порт U может рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W  как порт выводных сообщений для этого коллектива программ. Порт U Порт W Порт V