1. Архитектура систем и средств, как внешнее их описание (reference model)

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

В связи с этим нужно уточнить представление об архитектуре систем и средств, как внешнем их описании (reference model) с точки зрения того, кто ими пользуется. Архитектура открытой системы, таким образом, оказывается иерархическим описанием ее внешнего облика и каждого компонента с точки зрения:

· пользователя (пользовательский интерфейс),

· проектировщика системы (среда проектирования),

· прикладного программиста (системы и инструментальные средства /среды программирования),

· системного программиста (архитектура ЭВМ),

· разработчика аппаратуры (интерфейсы оборудования).

Предлагаемый взгляд на архитектуру открытых систем вытекает из указанной выше необходимости комплексной реализации общих свойств открытости и является расширением принятого понятия об архитектуре ЭВМ поГ.Майерсу.

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

 

Таблица 1

Иерархия представления архитектуры системы обработки данных Уровень архитектуры системы обработки данных	Компоненты системы обработки данных
	Интерфейсы	Средства обработки данных	Представление и хранение данных	Коммуникации
Среда для конечного пользователя и инструментарий прикладного программиста	Генераторы форм и отчетов	Утилиты и библиотеки	Языки программирования 4GL	OSI. Прикладной уровень
	Языки программные и командные языки (оболочки)	Прикладные программы	Языки запросов СУБД	OSI. Уровни сессий ипредставительный
Операционная система	Средства оконного интерфейса	Верхний уровень ОС (организация процесса обработки)	Средства доступа к среде хранения	OSI. Транспортный уровень
	Драйверы	Ядро операционной системы	Файловая система	OSI. Сетевой уровень
Оборудование	Системные интерфейсы (в т.ч. организация ввода-вывода)	Процессоры (система команд)	Организация памяти	OSI. Уровень передачи данных
	Периферийные устройства	Системная шина	Шины (интерфейс) массовой памяти	OSI. Физический уровень

 

Уровень среды для конечного пользователя (user environment) характеризуется входными и выходными описаниями (генераторы форм и отчетов), языками проектирования информационной модели предметной области (языки 4GL), функциями утилит и библиотечных программ и прикладным уровнем среды коммуникаций, когда требуются услуги дистанционного обмена информацией. На этом же уровне определена среда (инструментарий) прикладного программирования (appliсation environment): языки и системы программирования, командные языки (оболочки операционных систем), языки запросов СУБД, уровни сессий и представительный среды коммуникаций.

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

На уровне оборудования легко видеть привычные разработчикам ЭВМ составляющие архитектуры аппаратных средств:

          система команд процессора (процессоров),

          организация памяти,

          организация ввода-вывода и т.д.,

 

а также физическую реализацию в виде:

          системных шин,

          шин массовой памяти,

          интерфейсов периферийных устройств,

          уровня передачи данных,

          физического уровня среды хранения.

 

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

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

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

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

2. Иерархия представления архитектуры системы обработки данных

См. пред ответ

3. Стандарты Открытых Систем. Профили стандартов Открытых Систем

В настоящее время в мире существует несколько авторитетных сообществ, занимающихся выработкой стандартов открытых систем. Однако исторически и, по-видимому, до сих пор наиболее важной деятельностью в этой области является деятельность комитетов POSIX. В этом разделе мы приведем краткий обзор этой деятельности.

Первая рабочая группа POSIX (Portable Operating System Interface) была образована в IEEE в 1985 г. на основе UNIX-ориентированного комитета по стандартизации /usr/group (ныне UniForum). Отсюда видна первоначальная направленность работы POSIX на стандартизацию интерфейсов ОС UNIX. Однако постепенно тематика работы рабочих групп POSIX (а со временем их стало несколько) расширилась настолько, что стало возможным говорить не о стандартной ОС UNIX, а о POSIX-совместимых операционных средах, имея в виду любую операционную среду, интерфейсы которых соответствуют спецификациям POSIX.

Сейчас функционируют и регулярно выпускают документы следующие рабочие группы POSIX.

POSIX 1003.0. Рабочая группа, выпускающая "Руководство по POSIX-совместимым средам Открытых Систем". Это руководство содержит сводную информацию о работе и текущем состоянии документов всех других рабочих групп POSIX, а также других тематически связанных организаций, связанных со стандартизацией интерфейсов Открытых Систем.

POSIX 1003.1. Интерфейсы системного уровня и их привязка к языку Си. В документах этой рабочей группы определяются обязательные интерфейсы между прикладной программой и операционной системой. С выпуска первой версии этого документа началась работа POSIX, и он в наибольшей степени связан с ОС UNIX, хотя в настоящее время интерфейсы 1003.1 поддерживаются в любой операционной среде, претендующей на соответствие принципам Открытых Систем. Заметим, что несмотря на очевидную важность 1003.1, в документе отсутствуют спецификации многих важных интерфейсов, в частности, интерфейсы системных вызовов, обеспечивающих межпроцессные взаимодействия.

POSIX 1003.2. Shell и утилиты. Рабочая группа специфицирует стандартный командный язык shell, основанный главным образом на Bourne shell, но включающий некоторые черты Korn shell. Кроме того, в документах этой рабочей группы специфицировано около 80 утилит, которые можно вызывать из процедур shell или прямо из прикладных программ. В документах серии 1003.2a описываются дополнительные средства, позволяющие пользователям работать с системой с помощью только ASCII-терминалов.

POSIX 1003.3. Общие методы проверки совместимости с POSIX. Целью рабочей группы является разработка методологии проверки соответствия реализаций стандартам POSIX. Документы рабочей группы используются в различных организациях при разработке тестовых наборов.

POSIX 1003.4. Средства, предоставляемые системой для прикладных программ реального времени. В соответствии с определением 1003.4, системой реального времени считается система, обеспечивающая предсказуемое и ограниченное время реакции. Работа ведется в трех секциях: файловые системы реального времени, согласованные многопотоковые (multithread) архитектуры, а также в секции, занимающейся такими вопросами, как семафоры и сигналы.

POSIX 1003.5. Привязка языка Ада к стандартам POSIX. В документах этой рабочей группы определяются правила привязки программ, написанных на языке Ада, к системным средствам, определенным в POSIX 1003.1.

POSIX 1003.6. Расширения POSIX, связанные с безопасностью. Разрабатываемый набор стандартов базируется на критериях министерства обороны США и будет определять безопасную среду POSIX.

POSIX 1003.7. Расширения, связанные с администрированием системы. Стандарт, разрабатываемый рабочей группой, будет определять общий интерфейс системного администрирования, в частности, разнородных сетей. Отправной точкой является модель OSI.

POSIX 1003.8. Прозрачный доступ к файлам. Будут обеспечены интерфейсы и семантика прозрачного доступа к файлам, распределенным в сети. Работа основывается на анализе существующих механизмов: NFS, RFS, AFS и FTAM.

POSIX 1003.9. Привязка языка Фортран. Определяются правила привязки прикладных программ, написанных на языке Фортран, к основным системным средствам.

POSIX 1003.10. Общие черты прикладной среды суперкомпьютеров (Application Environment Profile - AEP).

POSIX 1003.11. Общие черты прикладной среды обработки транзакций (On-line Transaction Processing Application Environment - OLTP).

POSIX 1003.12. Независимые от протоколов коммуникационные интерфейсы. Разрабатываются два стандартных набора интерфейсов для независимых от сетевых протоколов коммуникаций "процесс-процесс". Результаты должны обеспечивать единообразную работу с TCP/IP, OSI и другими системами коммуникаций.

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

POSIX 1003.15. Расширения, связанные с пакетной обработкой. Определяются интерфейсы пользователя и администратора и сетевые протоколы для пакетной обработки.

POSIX 1003.16. Привязка языка Си. Задача проекта, выполняемого реально рабочей группой 1003.1, состоит в выработке правил привязки международного стандарта языка Си (ISO 9989) к независимым от языка интерфейсам, определяемым POSIX 1003.1-1990 (ISO 9945-1).

POSIX 1003.17. Справочные услуги и пространство имен. Задачей рабочей группы является анализ и выработка рекомендаций по работе со справочниками и пространством имен в контексте X.500.

POSIX 1003.18. Общие черты среды POSIX-платформы. В одном документе должны быть специфицированы основные характеристики интерактивной многопользовательской прикладной платформы, соответствующей стандартам POSIX. Работа выполняется группой 1003.1.

Профили стандартов Открытых Систем

Интеграция компонентов в открытой системе должна следовать профилям стандартов на интерфейсы этих компонент.

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

Для определенности рассмотрения интерфейсов компонент и проведения необходимых анализов их реализуемости можно использовать модель среды открытых систем MUSIC, разработанную центральным агентством по компьютерам и телекоммуникациям (ССТА) Великобритании. Эта модель используется в руководстве фирмы Digital Equipment по построению открытых систем. Модель MUSIC содержит пять групп компонентов, из которых строятся открытые системы:

• управление (Management) - функции системной администрации, безопасности, управления ресурсами, конфигурацией, сетевое управление;

• пользовательский интерфейс (User Interface) - интерфейс пользователя с прикладными программами и со средой разработки приложений;

• системные интерфейсы для программ (Service Interface for Programs) - интерфейсы между прикладными программами и между прикладными программами и операционной системой, в частности API (Application Programs Interface);

• форматы информации и данных;

• интерфейсы коммуникаций.

Европейская рабочая группа по открытым системам (EWOS) предложила шесть профилей стандартов составляющих среды открытых систем:

• среда рабочих станций,

• среда серверов процессов,

• среда серверов данных,

• среда транзакций,

• среда реального времени,

• среда суперкомпьютеров.

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

• интегрированные производственные системы,

• информационные системы (системы информационного обслуживания) с удаленным доступом к ресурсам,

• системы автоматизации учреждений,

• системы автоматизации банков,

• системы автоматизации научных исследований,

• системы передачи данных.

4. Понятие архитектуры информационной системы. Типовые варианты архитектуры информационных систем.

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

Классификация по архитектуре

По степени распределённости отличают:

настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

файл-серверные ИС (ИС с архитектурой «файл-сервер»);

клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

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

В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности — современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено — веб-сервер с соответствующим серверным программным обеспечением.

5. Понятие архитектуры информационной системы. Концепция корпоративного информационного портала.

Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

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

- Категоризация. Упорядочивание данных для осуществления удобной навигации по информационным ресурсам. Автоматизированные процедуры категоризации результатов индивидуального поиска.

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

- Публикация и распространение. Возможность публикации пользовательской информации для общекорпоративного доступа.

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

- Коллективная работа. Обеспечение режима командной работы, как в традиционном варианте «сотрудник-сотрудник», так и в режимах «сотрудник-партнер» и «сотрудник-клиент».

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

- Представление информации. Интеграция всех элементов информационных ресурсов понятном и логичном виде.

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

6. Многоуровневая архитектура информационной системы. Типы вычислений «Клиент-сервер».

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

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

Отсутствие дублирования кода программы-сервера программами-клиентами.

Так как все вычисления выполняются на сервере, то требования к компьютерам на которых установлен клиент снижаются.

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

Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

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

Недостатки

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

Поддержка работы данной системы требует отдельного специалиста — системного администратора.

Высокая стоимость оборудования.

7. Декомпозиция информационной структуры как основа разработки архитектуры. Декомпозиция данных.

Декомпозиция системы

1. Суть и назначение декомпозиции

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

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

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

2. Основные критерии декомпозиции

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

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

Рассмотрим перечень наиболее употребимых составных критериев (см. Лекция 1. "Критерии, применяемые в проектировании и реализации ПО" и "Критерии программной декомпозиции):

1. Критерий разбиения на функции системы (функциональный критерий или критерий декомпозиции прецедентов)

2. Критерий разбиения на подсистемы (модульный критерий)

3. Критерий разбиения на классы (критерий классификации)

4. Критерий разбиения на объекты (критерий объектной декомпозиции)

5. Критерий разбиения на состояния (критерий анализа автоматной модели)

6. Критерий разбиения на задачи (критерий синтеза асинхронной архитектуры)

7. Критерий определения интерфейсов (критерий композиции интерфейса)

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

1. Критерий пространственной декомпозиции (критерий распределенности или географичкеский критерий)

2. Критерий временной декомпозиции (темпоральный критерий)

3. Критерий логической декомпозиции (критерий обобщения/специализации)

Правила построения составных критериев:

1. Есть три базовые координаты: место в пространстве, место во времени и логическая связь со смежными сущностями (объектами предметной области)

2. В зависимости от того, какая проекция предметной области (системы) рассматривается, в составном критерии фигурирует тот или иной предельный критерий или критерии

3. К базовому критерию или критериям, образующим в проекцию, добавляется заданная специализация, отличающая один составной критерий от других

Связь проекций предметной области (системы) и составных критериев:

1. Функциональный критерий декомпозиции является логической проекцией рассматриваемой системы; состоит из критерия логической декомпозиции и специализирован рассмотрением функций системы

2. Модульный критерий является струкрурной проекцией системы; состоит из критериев логической, пространственной и временной декомпозиции, специализирован рассмотрением состава системы из замкнутых функциональных блоков

3. Критерий классификации является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением состава структуры системы из программных объектов

4. Критерий объектной декомпозиции является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением состава структуры системы из объектов, являющихся аналогами объектам предметной области

5. Критерий разбиения на состоания является темпоральной проекцией рассматриваемой системы (чаще объекта); состоит из критериев логической и временной декомпозиции, специализирован рассмотрением реакции системы на внешние события

6. Критерий разбиения на задачи является темпоральной проекцией рассматриваемой системы; состоит из критериев логической и временной декомпозиции, специализирован рассмотрением взаимодействия системы с другими системами

7. Критерий определения интерфейса является структурной проекцией системы; состоит из критерия логической декомпозиции, специализирован рассмотрением способов межобъектного взаимодействия в системе

3. Общие рекомендации по декомпозиции

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

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

Например, проводим декомпозицию до тех пор пока:

• Не пройдет отведенный промежуток времени

• Более менее станут понятны структура и поведение системы

• Будут достигнуты какие-то заданные количественные характеристики

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

Например, отличный кандидат на вынос в отдельный модуль следующая функциональность:

• Ввод/вывод в файловую систему

• Взаимодействие с базой данных

• Протоколирование работы системы

• Взаимодействие с удаленной системой посредством сети

Декомпозиция данных

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

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

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

2. Индивидуальные процессы независимо вводят подмножества своих данных из внешних устройств. Такой метод является значащим во многих случаях, но возможен только при поддержке услуг параллельного ввода/вывода.

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

Третий метод распределения индивидуальной рабочей нагрузки также придерживается динамической диспетчеризации для приложений, в которых межпроцессные взаимодействия в ходе вычислений редки или не существуют вообще. Однако нетривиальные алгоритмы обычно требуют непосредственных обменов значениями данных, и поэтому только изначальное назначение порций данных удовлетворяет таким схемам. Например, рассмотрим метод разбиения данных, изображенный на рис. 85. Чтобы умножить две матрицы A и B, в первую очередь порождается группа процессов - согласно парадигме ``ведущий-ведомый'' или ``только станции''. Этот набор процессов предназначен для формирования петли. Каждая подматрица матриц A и B помещается в соответствующий процесс с помощью одной декомпозиции данных и одной из перечисленных выше стратегий распределения рабочей нагрузки. В процессе вычисления подматрицы требуют передачи или обмена между процессами, тем самым преобразуя оригинальную карту распределения, как показано на рисунке. В конце вычисления, однако, подматрицы результирующей матрицы ``разбросаны'' по индивидуальным процессам в соответствии с занимаемой позицией в сети процессов и наполнены данными согласно карте разбиения результирующей матрицы C. Предшествующая дискуссия выявила основы декомпозиции данных. В следующем разделе будут представлены программы-образцы, выдвигающие на передний план подробности этого подхода. 

8. Декомпозиция информационной структуры как основа разработки архитектуры Декомпозиция процессов.

Декомпозиция процессов

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

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

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

Управлять сложным межфункциональным бизнес-процессом самостоятельно руководитель не в состоянии. Ему придется назначать заместителей и распределять между ними сегменты процесса, закрепляя ответственность за каждый сегмент за кем-то из них. Границы сегментов такого сквозного процесса могут не совпасть с границами функциональных подразделений. Сегментирование сквозного процесса и назначение заместителей его владельца приведет к созданию некоторой иерархии управления сквозным процессом. Если такие действия будут выполнены по всем сквозным процессам, то в организации будет создана сложная многоуровневая иерархия управления бизнес-процессами. Но в этом случае в организации появятся две параллельно существующие системы менеджмента, одна из них основана на существующей структуре подразделений и является традиционной и понятной всем. Другая система менеджмента - процессная. Она живет своей жизнью, обеспечивая «эффективность» процессов. Таким образом, в организации будут одновременно существовать две системы менеджмента, которые должны постоянно согласовывать свои действия. Целесообразность подобной практики вызывает сомнения.

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

9. Эталонная модель архитектуры открытой информационной системы (OSE/RM). Аппаратные компоненты информационной системы