ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ОТКРЫТАЯ РАСПРЕДЕЛЕННАЯ ОБРАБОТКА. БАЗОВАЯ МОДЕЛЬ. ЧАСТЬ 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ. ГОСТ Р ИСО/МЭК 10746-1-2004 (утв. Постановлением Госстандарта РФ от 04.02.2004 n 51-ст)


Утвержден
Постановлением
Госстандарта России
от 4 февраля 2004 г. N 51-ст
Дата введения -
1 января 2005 года
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
ОТКРЫТАЯ РАСПРЕДЕЛЕННАЯ ОБРАБОТКА. БАЗОВАЯ МОДЕЛЬ
ЧАСТЬ 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ
Information technology. Open Distributed Processing.
Reference Model. Part 1. Overview
ГОСТ Р ИСО/МЭК 10746-1-2004
Предисловие
1. Разработан Государственным научно-исследовательским и конструкторско-технологическим институтом "ТЕСТ" Министерства Российской Федерации по связи и информатизации.
Внесен Министерством Российской Федерации по связи и информатизации.
2. Утвержден и введен в действие Постановлением Госстандарта России от 4 февраля 2004 г. N 51-ст.
3. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 10746-1-98 "Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения".
4. Введен впервые.
1. Область применения
Настоящий стандарт содержит:
- введение и обоснование открытой распределенной обработки (ОРО);
- обзор базовой модели открытой распределенной обработки (БМ-ОРО) и объяснение ее ключевых понятий;
- руководство по применению БМ-ОРО.
Настоящий стандарт содержит общий обзор и подробное объяснение ОРО и может использоваться различными способами в сочетании с другими стандартами данной серии:
а) при ограничении только настоящим стандартом для понимания значения ОРО для вашей организации следует прежде всего обратить внимание на раздел 6;
б) если вы намерены полностью изучить БМ-ОРО, то вам также следует ознакомиться с разделом 6 до перехода к ГОСТ Р ИСО/МЭК 10746-2 и ГОСТ Р ИСО/МЭК 10746-3;
в) при использовании ГОСТ Р ИСО/МЭК 10746-2 и ГОСТ Р ИСО/МЭК 10746-3 следует пользоваться разделами 7 - 10 настоящего стандарта, где даны разъяснения различных понятий;
г) после изучения ГОСТ Р ИСО/МЭК 10746-2 и ГОСТ Р ИСО/МЭК 10746-3 следует ознакомиться с разделами 11 и 12 настоящего стандарта, где обсуждается их использование в спецификациях систем ОРО и приведены некоторые примеры применения понятий ОРО для спецификации систем.
2. Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 7498-1-97. Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель
ГОСТ Р ИСО/МЭК 9646-1-93. Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования для ВОС. Часть 1. Общие принципы
ГОСТ Р ИСО/МЭК 10746-2-2000. Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 2. Модель
ГОСТ Р ИСО/МЭК 10746-3-2001. Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 3. Архитектура
ГОСТ Р ИСО/МЭК 10746-4-2004. Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика
ИСО/МЭК 10164-11-94 <*>. Информационная технология. Взаимосвязь открытых систем. Административное управление системами. Часть 11. Метрические объекты и атрибуты.
--------------------------------
<*> Международный стандарт - во ВНИИКИ Госстандарта России.
3. Определения
3.1. Определения настоящего стандарта
В настоящий стандарт не введены новые определения.
3.2. Определения из других стандартов
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10746-2:
- абстракция;
- действие;
- шаблон действия;
- деятельность;
- архитектура;
- элементарный(ая);
- базовый класс;
- поведение (объекта);
- поведенческая совместимость;
- связывание;
- связывающее поведение;
- цепочка (действий);
- класс;
- объект-клиент;
- коммуникация;
- согласованность;
- составной объект;
- композиция;
- конфигурация (объектов);
- точки соответствия;
- объект-потребитель;
- контракт;
- контрактный контекст;
- создание;
- данные;
- декомпозиция;
- удаление;
- производный класс;
- прозрачность распределения;
- категория;
- среда (объекта);
- контракт среды;
- ошибка;
- устанавливающее поведение;
- отказ;
- неисправность;
- идентификатор;
- информация;
- инициирующий объект;
- экземпляр;
- реализация;
- взаимодействие;
- интерфейс;
- сигнатура интерфейса;
- внутреннее действие;
- опорная точка взаимодействия;
- введение (<Х>);
- инвариант;
- положение в пространстве;
- информация (административного) управления;
- имя;
- разрешение имени;
- область наименования;
- уведомление;
- объект;
- обязательство;
- стандарт ОРО;
- система ОРО;
- воспринимаемая опорная точка;
- разрешение;
- постоянство;
- политика;
- переносимость;
- объект-создатель;
- программируемая опорная точка;
- запрещение;
- качество услуги;
- опорная точка;
- уточнение;
- отвечающий объект;
- роль;
- объект-сервер;
- состояние;
- подкласс;
- подтип;
- система;
- шаблон класса;
- завершающее поведение;
- связка;
- торг;
- тип;
- развязывание;
- точка зрения.
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10746-3:
- язык <точки зрения>;
- информация управления доступом;
- прозрачность доступа;
- объявление;
- базовый инженерный объект;
- связник;
- связывающий объект;
- капсула;
- менеджер капсулы;
- канал;
- контрольная точка;
- взятие контрольной точки;
- менеджер кластера;
- шаблон кластера;
- коммуникационный интерфейс;
- общность;
- составное связывающее действие;
- вычислительная точка зрения;
- деактивация;
- динамическая схема;
- инженерная точка зрения;
- предпринимательская точка зрения;
- явное связывание;
- прозрачность отказа;
- федерация;
- поток;
- сокрытие;
- неявное связывание;
- информационная точка зрения;
- пересечение;
- опрос;
- инвариантная схема;
- вызов;
- прозрачность размещения;
- миграция;
- прозрачность миграции;
- узел;
- ядро;
- функция ОРО;
- операционный интерфейс;
- сигнатура операционного интерфейса;
- прозрачность постоянства;
- элементарное связывающее действие;
- протокольный объект;
- реактивация;
- восстановление;
- прозрачность перемещения;
- релокатор;
- схема дублирования;
- прозрачность дублирования;
- уполномоченный по безопасности;
- область безопасности;
- сигнал;
- интерфейс сигнала;
- сигнатура интерфейса сигнала;
- статическая схема;
- интерфейс потока;
- сигнатура интерфейса потока;
- заглушка;
- цель;
- технологическая точка зрения;
- завершение;
- прозрачность транзакции;
- подтверждение.
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 9646-1:
- заявка о соответствии реализации;
- дополнительная информация о реализации для тестирования;
- пункт контроля и наблюдения.
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 7498-1:
- открытая система;
- абстрактный синтаксис;
- синтаксис передачи.
4. Сокращения
В настоящем стандарте использованы следующие сокращения:
АВУ - архитектура верхних уровней;
АТИС - архитектура телекоммуникационной информационной сети;
БИО - базовый инженерный объект;
БМ-ОРО - базовая модель открытой распределенной обработки;
ВОС - взаимосвязь открытых систем;
ВПК - вызов прикладной категории;
ВПП - вызов прикладного процесса;
ГИП - графический интерфейс пользователя;
ГУО - группа (административного) управления объектами;
ДИТР - дополнительная информация для тестирования реализации;
ЗСР - заявка о соответствии реализации;
ИТ - информационная технология;
ИЧК - интерфейс человек-компьютер;
КУ - качество услуги;
МИУ - модель информации (административного) управления;
ММО - метод моделирования объектов;
ММСК - мультимедийная система конференций;
МФО - методы формального описания;
ОПУ - объект прикладной услуги;
ОРО - открытая распределенная обработка;
П-профиль - прикладной профиль;
ПД - период дробления;
ПК - прикладная категория;
ПКН - пункт контроля и наблюдения;
ПОИУ - протокол общей информации (административного) управления;
ПП - прикладной процесс;
ППИ - прикладной программный интерфейс;
СОС - среда открытой системы;
СПУ - структура прикладного уровня;
Т-профиль - транспортный профиль;
УВП - удаленный вызов процедуры;
УДБД - удаленный доступ к базе данных;
УОИУ - услуга общей информации (административного) управления;
ФОП - Фонд открытого программного обеспечения;
Ф-профиль - профиль формата и представления;
ЯО - язык определений;
ЯОИ - язык определения интерфейсов;
ACID - Atomicity Consistency Isolation Durability (элементарная согласованная продолжительность изоляции);
CAD - Computer Aided Design (проектирование, основанное на компьютере);
CD - Compact Disk (компактный диск).
5. Соглашения
В настоящем стандарте используют следующие соглашения.
Термины, помеченные курсивом в официальном тексте документа, в электронной версии документа выделены прописными буквами. 1) Первое использование в разделах 7 и 8 формальных терминов, определенных в ГОСТ Р ИСО/МЭК 10746-2 и ГОСТ Р ИСО/МЭК 10746-3, выделено курсивом.
2) В примере раздела 12 использованы графические соглашения ММО по Rumbaugh 91 [1].
3) На диаграммах:
- объекты изображены как овалы и кружки;
¦
- символом "-+-" около объекта изображен интерфейс.
6. Стандартизация ОРО
6.1. Цели и причины
Целью стандартизации ОРО является разработка стандартов, позволяющих реализовать преимущества услуг распределенной обработки информации в среде неоднородных ресурсов ИТ и нескольких организационных областях. Эти стандарты направлены на ограничение спецификаций систем и обеспечение для них инфраструктуры, которая снимает трудности, унаследованные от проектирования и программирования распределенных систем.
Распределенные системы важны вследствие растущей потребности взаимодействия систем обработки информации. Эта необходимость возникает в связи с такими организационными тенденциями, как, например, уменьшение размеров организаций, что требует информационного обмена как между группами внутри организации, так и между взаимодействующими организациями. Достижения технологии делают такой обмен возможным, отвечая на новые требования развитием сетей информационных услуг и персональных рабочих станций и допуская конструкции приложений, распределенных по большой конфигурации взаимосвязанных систем.
Для того чтобы управлять распределенной системой и эксплуатировать ее (например, использовать ее потенциал для оптимизации доступности, производительности, надежности и стоимости), организации должны иметь дело с рядом ключевых характеристик распределения системы, таких как:
- удаленность. Компоненты распределенной системы могут быть широко распределены в пространстве; взаимодействие может быть локальным или удаленным;
- конкуренция. Любой компонент распределенной системы может работать параллельно с любыми другими компонентами;
- отсутствие глобального состояния. Глобальное состояние распределенной системы не может быть точно определено;
- частичные отказы. Любой компонент распределенной системы может отказать независимо от любых других компонентов;
- асинхронность. Коммуникационная деятельность и обработка не управляются едиными глобальными часами. Нельзя считать, что взаимосвязанные изменения в распределенной системе происходят как единый акт;
- неоднородность. Нет гарантий того, что компоненты распределенной системы построены по единой технологии, а набор различных технологий определенно будет меняться со временем. Неоднородность проявляется в разных местах: в технических средствах, операционных системах, коммуникационных сетях и протоколах, языках программирования, приложениях и т.п.;
- автономность. Распределенная система может быть поделена между несколькими автономными уполномоченными по административному управлению и контролю, без единого центра контроля. Степень автономности определяет, насколько ресурсы обработки и соответствующие устройства (принтеры, запоминающие устройства, графические дисплеи, аудиоустройства и т.п.) находятся под контролем отдельных организационных единиц;
- эволюция. В течение своего жизненного цикла распределенная система столкнется со многими изменениями, которые мотивируются техническим прогрессом, обеспечивающим лучшую производительность за лучшую цену, стратегическими решениями о новых целях, новыми типами приложений;
- мобильность. Источники информации, узлы обработки и пользователи могут перемещаться физически. Программы и данные также могут перемещаться по узлам, например для борьбы с физическими перемещениями или для оптимизации производительности.
Построение таких систем является непростой задачей. Ее решение требует определенной архитектуры и, так как единственное инженерное решение не может удовлетворить все требования, это должна быть гибкая архитектура. Более того, так как единственный поставщик не имеет ответов на все вопросы, то существенно, что архитектура и любые функции, необходимые для реализации архитектуры, определяются набором стандартов, и несколько поставщиков могут сотрудничать при обеспечении распределенных систем. Такие стандарты позволяют построить систему, которая:
- является открытой, обеспечивающей как переносимость (выполнение компонентов системы в разных узлах обработки без модификации), так и взаимодействие (осмысленное взаимодействие между компонентами, возможно, размещенными в разных системах);
- является интегрированной, включающей в себя различные системы и ресурсы в целом, без дорогостоящих доработок. В их число могут входить системы с различными архитектурами и различные ресурсы с разными возможностями. Интеграция помогает иметь дело с неоднородностью;
- является гибкой, способной как эволюционировать, так и приспосабливать существующие и продолжающиеся операции унаследованных систем. Открытая распределенная система должна быть в состоянии столкнуться с изменениями во времени, например она должна допускать динамическую переконфигурацию для приспособления к изменившимся обстоятельствам. Гибкость способствует мобильности;
- является модульной, допускающей автономность частей системы при сохранении их взаимосвязанности. Модульность является основой для гибкости;
- может быть включена в федерацию, что позволяет для достижения единой цели скомбинировать систему с другими системами из разных технических или административных областей;
- является управляемой, допускающей мониторинг, контроль и административное управление ресурсами системы для обеспечения конфигурации, КУ и политики учета;
- удовлетворяет требуемому КУ, обеспечивая, например, доступность и надежность в контексте удаленных ресурсов и взаимодействий и, одновременно, устойчивость к отказам, позволяя остальной части распределенной системы сохранять работоспособность при отказе некоторой ее части. Обеспечение устойчивости к отказам (и независимости в целом) необходимо в больших распределенных системах, где маловероятно, что все части системы всегда будут работать одновременно;
- является безопасной, гарантируя, что средства системы и данные защищены от неавторизованного доступа. Требованиям безопасности сложнее удовлетворить из-за удаленности взаимодействий и мобильности частей системы и ее пользователей;
- обеспечивает прозрачность, маскируя от приложений детали и различия в методах, которые используются для разрешения проблем, связанных с распределенностью системы. Это - центральное требование, возникающее из необходимости обеспечить конструкцию распределенных приложений. Аспекты распределения, которые должны быть замаскированы (в целом или частично), включают в себя: неоднородность поддерживающего программного и технического обеспечения, размещение и мобильность компонентов, методы достижения требуемого уровня КУ в случае отказов (например, дублирование, миграция, взятие контрольной точки и т.п.).
6.2. Реализация
Стандартизация ОРО имеет четыре основных составляющих:
- объекты, моделирующие подход к спецификации системы;
- спецификация системы в терминах отдельных, но взаимосвязанных спецификаций точек зрения;
- определение инфраструктуры системы, обеспечивающей прозрачность распределения для приложений системы;
- основные положения проверки соответствия системы.
6.2.1. Моделирование объектов
Моделирование объектов обеспечивает формализацию проверенной практики проектирования абстракций и инкапсуляций. Абстракция позволяет отделить описание функционирования системы от деталей ее реализации. Инкапсуляция позволяет скрыть от пользователей неоднородность, локализацию отказов, реализацию безопасности и методы предоставления услуг.
Понятия моделирования объектов охватывают:
- основные моделирующие понятия, обеспечивающие строгие определения минимального набора понятий (действие, объект, взаимодействие, интерфейс), которые образуют основу для описаний систем ОРО и применяются для всех точек зрения;
- специфицирующие понятия, относящиеся к таким терминам, как тип и класс, которые необходимы для утверждений о спецификациях и взаимосвязях между ними. Они обеспечивают общие средства проектирования и установления требований к языкам спецификаций;
- структурирующие понятия, построенные на основе моделирующих и специфицирующих понятий; они нацелены на рекуррентные структуры в распределенных системах и охватывают такие понятия, как политика, наименование, поведение, зависимость и коммуникация.
6.2.2. Спецификации точек зрения
Точка зрения (на систему) является абстракцией, которая позволяет связать спецификацию системы в целом с конкретным множеством понятий. Были выбраны пять точек зрения, которые, будучи простыми и полными, охватывают все области проектирования архитектуры. Этими точками зрения являются:
- предпринимательская точка зрения, которая сконцентрирована на целях, сфере применения и политике, управляющей деятельностью специфицируемой системы в организации, частью которой она является;
- информационная точка зрения, которая сконцентрирована на видах информации, обрабатываемой системой, и ограничениях на использование и интерпретацию этой информации;
- вычислительная точка зрения, которая сконцентрирована на функциональной декомпозиции системы на множество объектов, взаимодействующих через интерфейсы; такая декомпозиция нужна для распределения системы;
- инженерная точка зрения, которая сконцентрирована на инфраструктуре, требуемой для поддержки распределения системы;
- технологическая точка зрения, которая сконцентрирована на выборе технологии для поддержки распределения системы.
Для каждой точки зрения имеется соответствующий язык точки зрения, который может использоваться для выражения спецификации системы с этой точки зрения. Понятия моделирования объектов дают общий базис для языков точек зрения и делают возможной идентификацию взаимосвязей между спецификациями различных точек зрения и проверку соответствия между представлениями системы с разных точек зрения.
6.2.3. Прозрачность распределения
Прозрачности распределения позволяют скрыть от приложений сложность, связанную с распределением системы, если она не имеет отношения к задачам приложений. Например:
- прозрачность доступа маскирует различия между системами в представлении данных и методах вызова;
- прозрачность размещения маскирует необходимость приложению иметь информацию о размещении для вызова услуги;
- прозрачность перемещения маскирует от приложения перемещение услуги;
- прозрачность дублирования маскирует тот факт, что для обеспечения надежности и доступности может существовать несколько копий услуги.
Стандарты ОРО определяют функции и структуры для реализации прозрачностей распределения. Однако во многих случаях, по соображениям реализуемости и стоимости, будут использованы только некоторые выбранные виды прозрачности. Таким образом, соответствующая система ОРО должна реализовывать те прозрачности, которые она поддерживает в соответствии с нужными стандартами, но не обязана обеспечивать все прозрачности.
6.2.4. Соответствие
Основные характеристики неоднородности и эволюция системы подразумевают, что отдельные части распределенной системы могут быть приобретены по отдельности от разных поставщиков. Следовательно, для удовлетворения спецификациям системы важно, чтобы поведение разных частей системы было четко определено и чтобы было возможно установить ответственность за каждый отказ.
На эти вопросы ориентированы основные положения, определенные для оценки соответствия. Эти положения охватывают:
- идентификацию в наборе спецификаций точек соответствия, в которых может быть проведено наблюдение соответствия;
- определение классов точек соответствия;
- спецификация характера заявлений о соответствии, которые могут быть сделаны с каждой из точек зрения, и взаимосвязь между ними.
6.3. Стандарты
6.3.1. Базовая модель
БМ-ОРО обеспечивает основные положения для стандартизации ОРО. Она состоит из двух основных частей:
- ГОСТ Р ИСО/МЭК 10746-2, который определяет понятия и аналитические основы для описания распределенных систем обработки, включая основные положения для оценки соответствия;
- ГОСТ Р ИСО/МЭК 10746-3, который определяет как специфицируются системы ОРО и инфраструктуру, обеспечивающую прозрачности распределения.
ГОСТ Р ИСО/МЭК 10746-4 дополняет упомянутые выше части формальной интерпретацией моделирующих понятий и языков точек зрения в терминах существующих методов формального описания.
БМ-ОРО является родовой в том смысле, что не зависит от (а значит, и применима к) сферы применения, использующей или требующей технологии распределительных систем. В некоторых конкретных областях применения будет необходимо уточнить и специализировать БМ-ОРО для соответствия конкретным потребностям, разработав:
- специфичные базовые модели, которые охватывают отдельные виды деятельности, используя понятия и общие функции, определенные в БМ-ОРО, и определив дополнительные концептуальные детали и специфические функции; примером является архитектура телекоммуникационных информационных сетей (АТИС);
- стандарты для реализации специфических функций, необходимых для конкретных приложений и, возможно, идентифицированных в специфичной базовой модели; примером является интерфейс телефонного вызова.
Будучи родовой, БМ-ОРО позволяет интегрировать технологии распределенных систем в экономически эффективные технические решения для промышленных потребностей. В частности, в случае архитектур, опубликованных Фондом открытого программного обеспечения (ФОП) и Группой административного управления объектами (ГУО), для разъяснения, как специфицированные ими для поддержки распределенных систем функции работают совместно, подход ОРО использует такие понятия, как федерация, прозрачность и административное управление системой и, определяя тонкую структуру опорных точек, обеспечивает интеграцию функций разных источников.
6.3.2. Специфические стандарты
В рамках общего подхода БМ-ОРО идентифицированы следующие четыре категории стандартов:
- дополнительные архитектурные понятия, которые уточняют БМ-ОРО в таких конкретных областях, как наименование, безопасность и оценка соответствия;
- стандарты нотаций, которые определяют обозначения для выражения спецификаций различных аспектов интеграции и распределения системы, а также правила для взаимосвязи различных спецификаций;
- стандарты для компонентов, которые определяют отдельные функции ОРО и наборы тесно связанных функций, которые могут быть реализованы как единое программное или техническое средство;
- стандарты для композиции компонентов, которые определяют скоординированное использование нескольких компонентов для достижения некоторой цели системы в целом, такой как обеспечение конкретной прозрачности.
Примечание. Некоторые стандарты могут специфицировать как компоненты, так и их композицию (в таком случае нужная возможность может быть реализована непосредственно). Другие стандарты могут создавать основу для ряда стандартов на композиции компонентов, например на стандарт для релокатора ОРО могли бы ссылаться стандарты для композиций компонентов, обеспечивающих прозрачность положения или миграции.
БМ-ОРО предоставляет основу для стандартов на компоненты и их композиции, обеспечивающие функции ОРО, которые допускают различные подходы к их реализации. Такая гибкость необходима, если основные понятия должны иметь приемлемое время жизни, включая в себя новые разработки по мере их появления. Таким образом, может существовать специфический стандарт или набор стандартов, устанавливающий одно конкретное решение для обеспечения некоторого требования ОРО путем конкретного выбора, необходимого для реализации открытого продукта, и могут существовать несколько таких стандартов, соответствующих разным проектным решениям. Со временем, по мере появления новых технологий, могут появиться новые поколения стандартов в рамках той же самой БМ-ОРО.
7. Основные положения
В ГОСТ Р ИСО/МЭК 10746-2 определен набор понятий моделирования, которые обеспечивают основу для описания АРХИТЕКТУРЫ СИСТЕМ ОРО, установленной в ГОСТ Р ИСО/МЭК 10746-3. Эти понятия распадаются на три категории:
- базовые понятия моделирования, которые вводят общую объектно-ориентированную модель. В общем случае система ОРО может быть описана как совокупность связанных, взаимодействующих ОБЪЕКТОВ;
- понятия спецификаций, которые не являются внутренними для распределенных систем, но позволяют пользователю описывать и обсуждать спецификации систем ОРО. Они устанавливают требования к языку спецификаций, который используется для спецификации систем ОРО, а так как эти требования не зависят от языка, то они могут быть применены к любому языку спецификаций или программирования;
- организационные понятия, охватывающие организацию и свойства систем и объектов, ПОЛИТИКУ, НАИМЕНОВАНИЕ, ПОВЕДЕНИЕ и управление, которые соответствуют представлениям и структурам, применяемым в общем случае для проектирования и описания распределенных систем.
ГОСТ Р ИСО/МЭК 10746-2 обеспечивает также общую структуру для понимания СООТВЕТСТВИЯ в системах ОРО, выраженного в терминах общей объектной модели. Эта структура обсуждается в разделе 9.
7.1. Базовые понятия моделирования
7.1.1. Объекты
Спецификации систем ОРО формулируются в терминах объектов. Объект является представлением любой КАТЕГОРИИ реального мира. Он содержит ИНФОРМАЦИЮ и предоставляет услуги. Система строится из взаимодействующих объектов. Объект характеризуется тем, что отличает его от других объектов, а также ИНКАПСУЛЯЦИЕЙ, АБСТРАКЦИЕЙ и поведением.
Инкапсуляция является свойством, которое состоит в том, что информация, содержащаяся в объекте, доступна только через ВЗАИМОДЕЙСТВИЯ в ИНТЕРФЕЙСАХ, поддерживаемых объектом. Так как объекты инкапсулированы, то взаимодействия не имеют скрытых эффектов. Это означает, что взаимодействие с одним объектом не может повлиять на СОСТОЯНИЕ другого без какого-либо вторичного взаимодействия с этим объектом. Таким образом, любое изменение состояния объекта может произойти в результате ВНУТРЕННЕГО ДЕЙСТВИЯ объекта или взаимодействия объекта со СРЕДОЙ.
Абстракция подразумевает, что подробности внутреннего строения объекта скрыты от других объектов; она имеет существенное значение для работы в неоднородной среде, допуская, что различные услуги обеспечиваются разными путями, используя разные методы и технологии, допуская ПЕРЕНОСИМОСТЬ и возможность взаимодействия.
Абстракция также образует жесткое разделение объектов, позволяющее заменять и модифицировать их без изменения их среды при условии, что они продолжают обеспечивать услуги, ожидаемые их средой (т.е. они являются обратно совместимыми). Такой подход к расширению важен в больших, неоднородных, распределенных средах, которые по своей природе являются непрерывно эволюционирующими. Объектная модель обеспечивает модульность и возможность построения новых модулей из существующих: эти возможности существенны для построения гибких систем и поощрения повторного использования элементов для повышения производительности.
Объектная модель ОРО является общей и содержит минимальное количество допущений. Например:
- объекты могут быть произвольной сложности (например, большими, как телефонная сеть, или малыми, как целое число);
- объекты могут демонстрировать произвольное (инкапсулированное) поведение и иметь любой уровень внутреннего параллелизма;
- взаимодействия между объектами не ограничиваются и могут включать в себя, например, асинхронные и многоканальные синхронные взаимодействия.
7.1.2. Интерфейсы и точки взаимодействия
Объекты могут взаимодействовать только через интерфейсы, а интерфейс представляет часть поведения объекта, относящуюся к конкретному подмножеству его возможных взаимодействий. Каждый интерфейс идентифицируется набором взаимодействий, в которых может участвовать объект. Эти взаимодействия не обязательно происходят с другими объектами: объект может взаимодействовать сам с собой. Важной характеристикой понятия "объект" в ОРО является то, что объект может иметь несколько интерфейсов. Причиной рассмотрения кратных интерфейсов является функциональное разделение и распределение. Функциональное разделение может быть понято, например, в контексте административного управления системы, где управляющие и неуправляющие взаимодействия обычно разделены по разным интерфейсам. При работе с распределенными объектами разделение необходимо, когда интерфейсы образуют точки доступа к объекту, которые расположены в различных точках пространства.
Как следствие определения нескольких интерфейсов для объекта, на взаимодействие через любой из интерфейсов могут влиять взаимодействия через другие интерфейсы, которые не обязательно определены по отдельности.
Интерфейс существует в ТОЧКЕ ВЗАИМОДЕЙСТВИЯ, которая в любой момент времени связана с некоторой точкой в пространстве. Несколько интерфейсов могут существовать в данной точке взаимодействия, а точка взаимодействия может быть мобильной. Смысл точек в пространстве и времени (и способ, которым они представляются) зависит от языка, на котором написана спецификация.
7.1.3. Поведение и состояние
Поведение объекта является совокупностью ДЕЙСТВИЙ, в которых может участвовать объект, вместе с набором ограничений на то, когда эти действия могут происходить. Объектная модель не ограничивает вид и характер поведения объекта. Действия могут быть взаимодействиями объекта с его средой или внутренними действиями объекта.
Состояние и поведение являются взаимосвязанными понятиями. Состояние объекта является положением объекта в данный момент, которое определяет будущие потенциальные последовательности действий, в которых этот объект может участвовать. С другой стороны, действия приводят к изменениям состояния и, следовательно, текущее состояние объекта определяется его предшествующим поведением. Конечно, действия объекта, которые фактически будут предприняты, не полностью определяются его текущим состоянием; они зависят от того, какие действия подготовила среда для этого объекта.
7.2. Понятия спецификаций
7.2.1. Композиция и декомпозиция
КОМПОЗИЦИЯ и ДЕКОМПОЗИЦИЯ могут быть использованы для построения спецификации распределенной системы в виде набора спецификаций, каждая из которых относится к своему уровню абстракции. Это позволяет разделить спецификацию сложной распределенной системы на спецификации нескольких простых объектов, которые, в свою очередь, могут быть разделены на более низком уровне абстракции.
Процессы композиции и декомпозиции обеспечивают иерархическую спецификацию распределенного приложения. В этой иерархии композиций КЛАССЫ объектов на верхних уровнях собираются из КОНФИГУРАЦИЙ классов объектов-компонентов более низких уровней. Таким образом, композиция является мощным моделирующим понятием, которое позволяет рассматривать подсистему как единый объект высокого уровня.
Например, диаграмма на рисунке 1 (здесь и далее рисунки не приводятся) показывает композицию двух объектов: С и D. Для того чтобы образовать композицию С с D, поведение С должно быть определено таким образом, что он надлежащим образом взаимодействует с D. Интерфейс между С и D может быть простым, как единственное взаимодействие (например, передача информации от С к D), или может быть более сложным поведением (таким, как последовательность взаимодействий, при которых С вызывает операции с возвратом результатов). Если С и D объединяются в один объект, то взаимодействия между С и D оказываются скрытыми и становятся внутренними действиями составного объекта. Левый интерфейс на рисунке представляет интерфейс составного объекта.
Композиция объектов приводит к композиции состояний и поведений и, следовательно, можно говорить о составном поведении и составном состоянии.
Иерархия композиций ортогональна иерархии ПОДКЛАССОВ, обсуждаемой в 7.2.3, и их не следует путать. В общем случае нет связи иерархии подклассов между классами объектов-компонентов и классами составных объектов. Примером является случай, когда составной объект относится к подклассу класса, к которому относятся объекты-компоненты (в частности, когда объекты представляют коммуникационные услуги, а составной объект добавляет возможности одному из своих компонентов).
7.2.2. Поведенческая совместимость
Говорят, что один объект является поведенчески совместимым с другим в некоторой среде, если первый объект может заменить второй так, что среда не сможет выявить различие. Любая конкретная интерпретация ПОВЕДЕНЧЕСКОЙ СОВМЕСТИМОСТИ будет налагать ограничения на допустимое поведение среды. Общий подход заключается в принятии того, что среда ведет себя как тестер для исходного объекта. Это означает, что среда должна быть в состоянии полностью осуществить исходное поведение, но не более того. Такое предположение является существенным, когда нужно рассмотреть поведенческую совместимость в контексте некоторой неизвестной среды.
7.2.3. Тип и класс
Тип является предикатом (т.е. свойством или множеством свойств) совокупности (объектов, интерфейсов и пр.). Например, "является красным" - это тип. Говорят, что нечто удовлетворяет типу или относится к типу, если для него справедлив предикат. Элементы могут быть весьма различны, но будут удовлетворять одному и тому же типу; для этого они должны демонстрировать свойства, предписанные типом. Например, конкретный флаг, конкретный кирпичный дом и конкретный спортивный автомобиль могут быть красными.
Типы неявно подразделяют элементы на множества, называемые классами; класс является совокупностью элементов со свойствами, предписанными типом.
Понятие типа очень общее и может быть специализировано различными способами. Оно полезно в любом контексте, где необходимо рассматривать или проверять свойства элементов (например, при ТОРГЕ или СВЯЗЫВАНИИ).
Понятия типа и класса приводят к естественным иерархиям класс/подкласс и тип/подтип. Различие класс/подкласс соответствует интуитивному различию в теории множеств между множеством и подмножеством. Один класс является подклассом другого только в том случае, если первый является подмножеством последнего. Один тип является подтипом другого, если предикаты первого типа влекут за собой предикаты второго.
Подклассы и подтипы тесно связаны. Для каждого типа имеется соответствующий класс (который может быть пустым). Таким образом, если есть два типа Т1 и Т2, то должны быть и два соответствующих класса С1 и С2. Если Т1 является подтипом Т2, то С1 является подклассом С2.
7.2.4. Шаблоны
ШАБЛОН описывает совокупность элементов (объектов, интерфейсов и пр.) достаточно подробно для реализации из него нового элемента.
Когда шаблон описывает множество объектов, то он описывает такие характеристики, как параметры состояния, операции и поведение. Обычно РЕАЛИЗАЦИЯ объекта вызывает установку начального состояния, например объект "буфер" должен быть создан с пустым содержимым.
Понятие поведенческой совместимости применимо и к шаблонам объектов в том смысле, что имеется поведенческая совместимость между двумя шаблонами объектов, если объекты, реализованные по этим шаблонам, являются поведенчески совместимыми.
ТИП ШАБЛОНА является предикатом, определенным в шаблоне. Тип шаблона удовлетворяется всеми реализациями шаблона и в общем случае может удовлетворяться некоторыми другими элементами, если они удовлетворяют тем же требованиям, что и реализации. Например, тип шаблона может быть определен так, что объекты, реализованные из разных шаблонов, но удовлетворяющие этому типу шаблона, демонстрируют поведенческую совместимость.
Каждый тип шаблона приводит к возникновению КЛАССА ШАБЛОНОВ - множества ЭКЗЕМПЛЯРОВ типа шаблона. Классы шаблонов могут образовывать иерархии подклассов в соответствии с отношениями тип/подтип между типами шаблонов.
7.2.5. Роли
Роль идентифицирует в шаблоне для составного объекта поведение, которое должно быть связано с одним из объектов-компонентов.
Роль может соответствовать подмножеству полного поведения объекта-компонента. Когда объект рассматривается в терминах роли, то рассматриваются только действия указанного подмножества, абстрагируясь от других действий, возможно относящихся к другим ролям. Объект-компонент может иметь в данное время несколько ролей, в зависимости от его взаимодействий, и может иметь разные роли в разное время. Эти роли могут быть связаны с интерфейсами.
Например, объект может иметь обычное функционирование или порученную роль (т.е. его назначение), а для процесса административного управления может иметь роль административного управления (т.е. поведение, необходимое для мониторинга и управления поведением порученной роли). Каждая роль имеет свой собственный интерфейс; порученная роль связана с порученным интерфейсом, а роль административного управления связана с интерфейсом административного управления.
7.2.6. Базовые и производные классы
Понятия БАЗОВОГО и ПРОИЗВОДНОГО КЛАССА основаны на общем понятии изменения шаблонов, названном НАРАСТАЮЩЕЙ МОДИФИКАЦИЕЙ. Нарастающая модификация является получением нового шаблона путем изменения существующего. Новый шаблон называется производным, а исходный - базовым шаблоном. Экземпляры исходного и производного шаблонов называются, соответственно, базовым и производным классами.
В общем случае нарастающая модификация, в которой допустимы замены, приводит к иерархии, отличной от иерархии класс/подкласс.
Например, рассмотрим класс шаблонов С1 красных автомобилей, определенный шаблоном Temp1, который содержит строку:
ЦВЕТ = КРАСНЫЙ.
В классе шаблонов С2 эта строка заменена на
ЦВЕТ = СИНИЙ.
Класс шаблонов С2 является производным класса С1, но не является его подклассом.
В некоторых случаях реализация производного класса может быть основана на реализации базового класса. Тогда говорят о иерархии реализаций, которая позволяет совместно использовать исполняемый код программ. Однако в распределенной среде это может вызвать проблемы, так как изменение кода базового класса должно быть распространено для обновления всех реализаций производного класса; таким образом, в системах ОРО не требуется поддерживать иерархию реализаций.
7.3. Организационные понятия
7.3.1. Группы и области
ГРУППА является набором объектов, собранных вместе по организационным причинам или потому, что поведение объектов имеет общие характеристики (например, в репликационной группе они могут заменять друг друга, в коммуникационной группе они участвуют в одном и том же взаимодействии). Понятие группы является родовым и допускает спецификации различных видов групп, которые могут использоваться в распределенных системах для таких разных целей, как ОТКАЗОУСТОЙЧИВОСТЬ, доступность и поддержка приложения (например, в приложениях конференций).
ОБЛАСТЬ является конкретной формой группы, в которой конкретные аспекты поведения объектов управляются одним уполномоченным. Например, в ОБЛАСТИ БЕЗОПАСНОСТИ применяемая к поведению объектов политика безопасности устанавливается одним УПОЛНОМОЧЕННЫМ ПО БЕЗОПАСНОСТИ. Концепция области допускает введение в распределенных системах понятий автономности, контроля и уполномоченного. Концепция области перекрывает самые различные потребности, так как распределенные системы используют разные виды областей (например, области безопасности, административного управления, НАИМЕНОВАНИЯ).
7.3.2. Наименование
Наименование необходимо для различения компонентов распределенной системы и доступа к ним; следовательно, оно является фундаментальным элементом конструкции распределенной системы.
Для работы в условиях неоднородности, автономности и ФЕДЕРАТИВНОСТИ необходимы зависящее от контекста наименование и административное управление ИМЕНАМИ. Они обеспечивают гибкость и эволюционирование, допуская независимое развитие систем имен и их произвольных комбинаций, включая существующие независимые системы. Кроме того, они допускают неоднородность систем имен на нескольких уровнях, например формы имен, присваивания имен, политика наименования и стратегия РАЗРЕШЕНИЯ ИМЕНИ могут быть разными в разных системах.
Имена используются для указания категорий в данном контексте. Могут быть обстоятельства, при которых одно имя указывает на несколько категорий. Имя, которое недвусмысленно указывает на одну категорию, называется ИДЕНТИФИКАТОРОМ.
Концепция наименования в ГОСТ Р ИСО/МЭК 10746-2 не устанавливает полной схемы наименования в ОРО. Такая схема является предметом самостоятельной стандартизации.
7.3.3. Контракт
КОНТРАКТ является соглашением, которое управляет кооперацией между несколькими объектами и содержит ОБЯЗАТЕЛЬСТВО, РАЗРЕШЕНИЯ, ЗАПРЕЩЕНИЯ И ОЖИДАНИЯ, связанные с этими объектами. Таким образом, контракт является общим понятием для характеристики и регулирования кооперации между объектами.
Всякий раз, когда между объектами существует кооперация (взаимодействие), между ними существует некоторый контракт. В случаях, когда контракт в некоторый момент может быть согласован и позднее - завершен, имеется динамическая спецификация конфигурации объектов. Хотя кооперация между объектами возможна постоянно, правила, устанавливаемые контрактом, ограничивают возможную кооперацию некоторым текущим, временным поведением.
Часто контракты являются производными от правил ЯЗЫКА ТОЧКИ ЗРЕНИЯ и не обязательно должны быть выражены явно. Например, в случае вычислительного языка клиент обязан не вызывать операцию, которая не определена в интерфейсе сервера. Явно должны быть выражены только контракты, устанавливающие дополнительные ограничения.
Например, контракт может устанавливать:
- роли объектов и обязательства для этих ролей, т.е. ожидаемое кооперативное поведение;
- вопросы КАЧЕСТВА УСЛУГ (КУ) кооперации объектов (вопросы зависимости, корректности и пр.);
- виды поведения, НАРУШАЮЩИЕ контракт.
КОНТРАКТ СРЕДЫ является частным видом контракта между объектом и его средой. Этот контракт описывает требования, предъявляемые объектом к среде и средой к объекту. В частности, в нем рассматриваются ограничения КУ.
7.3.4. Взаимодействие и связывание
СВЯЗЫВАЮЩЕЕ ПОВЕДЕНИЕ устанавливает КОНТРАКТНЫЙ КОНТЕКСТ (связывание) между интерфейсами и позволяет объектам кооперироваться. Связывание может существовать на нескольких уровнях абстракции.
ВЗАИМОДЕЙСТВИЕ является взаимосвязью, которая существует между объектами, кооперированными на основе связывания. Когда имеет место взаимодействие, объекту известно, что другой объект взаимодействия подчиняется контракту. Объект может быть вовлечен одновременно в несколько взаимодействий; в этом случае для каждого из них имеется соответствующий контракт.
Примечание. В примере следующего абзаца операции Bind, BindResponse, Unbind и прикладной контекст используются в смысле ВОС.
Примером установления взаимодействия является связывающее поведение ассоциации ВОС. УСТАНАВЛИВАЮЩЕЕ ПОВЕДЕНИЕ обеспечивается операцией Bind, которая включает в себя отправку инициирующим прикладным объектом параметров контракта отвечающему прикладному объекту. ОТВЕЧАЮЩИЙ ОБЪЕКТ использует операцию BindResponse (возможно, с другими параметрами контракта), устанавливая тем самым взаимодействие. Контрактный контекст для взаимодействия задается прикладным контекстом, согласованным при обмене Bind и BindResponse. Когда стороны решат закончить взаимодействие, они инициируют ЗАВЕРШАЮЩЕЕ ПОВЕДЕНИЕ, вызвав операцию Unbind.
8. Архитектура
В ГОСТ Р ИСО/МЭК 10746-3 установлены требования, которые должны быть справедливыми для системы ОРО. В этом стандарте на основе понятий и терминологии ГОСТ Р ИСО/МЭК 10746-2 определены:
- основы архитектуры для построения спецификаций систем ОРО в терминах точек зрения, СПЕЦИФИКАЦИЙ ТОЧЕК ЗРЕНИЯ и ПРОЗРАЧНОСТЕЙ РАСПРЕДЕЛЕНИЯ;
- набор языков, в терминах которых могут быть выражены спецификации различных точек зрения;
- инфраструктура системы, обеспечивающая ПРОЗРАЧНОСТИ РАСПРЕДЕЛЕНИЯ для приложений системы.
8.1. Основы архитектуры
Распределенные системы могут быть очень большими и сложными, и самые различные влияющие на их проекты подходы могут быть отражены в спецификации, которая должна иметь структуру, допускающую успешное управление. Удачная структура должна позволять проектировать отдельные части системы независимо друг от друга, если они являются независимыми, но она же должна позволять четко идентифицировать те места, где разные аспекты проекта ограничивают друг друга. Для достижения этого в архитектуре ОРО используют два главных структурирующих подхода: определение точек зрения и определение прозрачностей.
8.1.1. Точки зрения
Точка зрения является частью спецификации всей системы, введенной для объединения конкретных порций информации, относящихся к некоторой конкретной области рассмотрения при проектировании системы. Система ОРО есть нечто, что может быть рассмотрено; таким образом, например, она может быть и системой обработки информации в некоторой организации, и конкретным компонентом (техническим или программным) такой системы. Точки зрения не являются абсолютно независящими друг от друга: ключевые элементы каждой из них идентифицируются как связанные с элементами других точек зрения. Однако точка зрения достаточно независима для того, чтобы упростить рассмотрение полной спецификации.
Каждая точка зрения может быть связана со всеми другими. Они не образуют фиксированной последовательности, как набор уровневых протоколов, и не задают фиксированного порядка, соответствующего некоторой методологии проектирования. Архитектура выражается в терминах полного набора взаимосвязанных точек зрения, без указания того, как должна строиться полная спецификация для данной системы.
В БМ-ОРО определены пять точек зрения на систему и ее среду:
а) предпринимательская точка зрения, которая сфокусирована на целях, области применения и политике системы;
б) информационная точка зрения, которая сфокусирована на семантике информации и осуществляемой обработке информации;
в) вычислительная точка зрения, которая допускает распределение путем функциональной декомпозиции системы на объекты, взаимодействующие через интерфейсы;
г) инженерная точка зрения, которая сфокусирована на методах и функциях, требуемых для обеспечения распределенного взаимодействия между объектами системы;
д) технологическая точка зрения, которая сфокусирована на выборе технологии в этой системе.
Для представления системы ОРО с конкретной точки зрения необходимо определить структурированный набор понятий, в терминах которого может быть выражено это представление (или спецификация). Такой набор понятий предоставляет язык для написания спецификаций систем с этих точек зрения, и спецификации образуют модель системы в терминах понятий. Термины каждого ЯЗЫКА ТОЧКИ ЗРЕНИЯ и правила применения этих терминов определены с помощью установленных в ГОСТ Р ИСО/МЭК 10746-2 моделирующих понятий. Каждый язык обладает достаточными выразительными средствами для спецификации с соответствующей точки зрения ФУНКЦИЙ ОРО, приложений и политики. Когда спецификации системы соответствуют этим языкам, проектируемая система является системой ОРО, по крайней мере с архитектурной точки зрения.
В БМ-ОРО разные языки точек зрения отличаются по строгости налагаемых ими ограничений. Языки тех точек зрения, сконцентрированных на организации распределения и обеспечении общих решений (вычислительная и инженерная точки зрения), устанавливают значительное количество ограничений, которые должны соблюдаться, и тем самым гарантируют взаимодействие (и переносимость) между компонентами. С другой стороны, так как БМ-ОРО является родовой, то в предпринимательском и информационном языках установлено всего несколько правил, и они ограничиваются набором основных понятий и руководств относительно области применения и информационного моделирования распределенных систем.
Более строгие ограничения для предпринимательского и информационного языков будут определены в последующих стандартах применительно к спецификациям систем с конкретными областями использования. Например, для любых систем торгов предпринимательская и информационная спецификации ограничиваются положениями стандартов по торгам.
8.1.2. Прозрачности распределения
При проектировании распределенной системы становится очевидной необходимость рассмотрения ряда вопросов, являющихся непосредственным результатом распределения: компоненты системы являются неоднородными, они могут отказывать независимо друг от друга, они находятся в разных и, возможно, изменяющихся местах и т.п. Эти вопросы могут быть решены либо непосредственно, как часть прикладного проекта, либо могут быть выбраны стандартные решения, основанные на хорошей практике.
Если выбран стандартный метод, то проектировщик приложения работает в среде, которая прозрачна относительно данного конкретного вопроса; говорят, что стандартный метод обеспечивает ПРОЗРАЧНОСТЬ РАСПРЕДЕЛЕНИЯ. Проектировщик приложения просто выбирает, какую он хочет принять прозрачность распределения и где в проекте она должна применяться.
Применение прозрачности распределения может непосредственно привести к повторному использованию программного обеспечения. Выбор прозрачностей распределения в спецификации системы может привести к автоматическому включению в систему хорошо проверенных реализаций стандартных решений с помощью используемых инструментов построения системы, таких как компиляторы, редакторы связей, менеджеры конфигурации. Проектировщик выражает системные требования в виде упрощенных утверждений системы и свойств прозрачности распределения, которые должны использоваться.
В БМ-ОРО определены следующие прозрачности распределения:
а) ПРОЗРАЧНОСТЬ ДОСТУПА, которая маскирует различия в представлении данных и методах вызова, обеспечивая взаимодействие между объектами. Она решает многие из проблем взаимодействия между неоднородными системами и, в общем случае, обеспечивается по умолчанию;
б) ПРОЗРАЧНОСТЬ ОТКАЗА, которая маскирует от объекта отказ и возможное ВОССТАНОВЛЕНИЕ других объектов (или его самого), обеспечивая отказоустойчивость. Когда она обеспечивается, проектировщик может работать в идеализированной среде, где соответствующие классы отказов не встречаются;
в) ПРОЗРАЧНОСТЬ ПОЛОЖЕНИЯ, которая маскирует использование информации о ПОЛОЖЕНИИ В ПРОСТРАНСТВЕ при идентификации и связывании с интерфейсами. Она обеспечивает логический вид наименования, не зависящий от фактического физического размещения;
г) ПРОЗРАЧНОСТЬ МИГРАЦИИ, которая маскирует от объекта возможности системы по изменению положения этого объекта. Миграция часто используется для достижения сбалансированности загрузки и уменьшения времени ожидания;
д) ПРОЗРАЧНОСТЬ ПЕРЕМЕЩЕНИЯ, которая маскирует перемещение интерфейса от других, связанных с ним интерфейсов. Перемещение позволяет продолжить операцию системы, даже когда миграция или перемещение некоторых объектов создает временную несогласованность в виде, в котором объекты представляются их пользователям;
е) ПРОЗРАЧНОСТЬ ДУБЛИРОВАНИЯ, которая маскирует использование для обеспечения интерфейса группы поведенчески взаимно совместимых объектов. Дублирование часто используется для повышения производительности и доступности;
ж) ПРОЗРАЧНОСТЬ ПОСТОЯНСТВА, которая маскирует от объекта ДЕАКТИВАЦИЮ и РЕАКТИВАЦИЮ других объектов (или его самого). Деактивация и реактивация часто используются для обеспечения ПОСТОЯНСТВА объекта, когда система не в состоянии непрерывно его обеспечивать обработкой, памятью или функциями коммуникации;
и) ПРОЗРАЧНОСТЬ ТРАНЗАКЦИЙ, которая для достижения согласованности маскирует координацию деятельностей в конфигурации объектов.
В любой спецификации системы определение прозрачности включает в себя как набор требований, так и прозрачность распределения, которая им удовлетворяет. Набор требований устанавливает, где необходима прозрачность распределения (т.е. на какие взаимодействия она влияет). Это может быть просто утверждение о том, что прозрачность применяется по всей системе, или это может быть более селективное утверждение, включающее в себя конкретные интерфейсы и определяющее, например, взаимодействия, которые образуют транзакцию на выбранных объектах и интерфейсах и должны обеспечиваться дублированием. Решение имеет вид набора правил для преобразования спецификации запрошенной прозрачности распределения в спецификацию, в которой выбранные объекты и интерфейсы расширяются для включения методов обеспечения прозрачности.
8.2. Предпринимательский язык
Предпринимательский язык вводит основные понятия, необходимые для представления системы ОРО в контексте предприятия, в которой она работает. Предпринимательская спецификация предназначена для выражения целей и ограничений политики рассматриваемой системы. Для этого система представляется одним или несколькими предпринимательскими объектами в изображающем предприятие СООБЩЕСТВЕ предпринимательских объектов и ролями, в которых эти объекты участвуют. Эти роли представляют, например, пользователей, владельцев и поставщиков информации, обрабатываемой системой. Создание отдельной точки зрения для выражения этой информации отделяет спецификацию задач системы от способа, которыми система эти задачи решает.
Одной из ключевых идей предпринимательского языка является идея контракта, связывающего исполнителей разных ролей в сообществе и выражающего их взаимные обязательства. Контракт может выражать общие цели и ответственность различных ролей в сообществе, таких как производитель и потребители, правительственная организация и ее клиенты.
При необходимости предпринимательская спецификация может формулировать вопросы владения ресурсами и ответственности (при оплате товаров и услуг) для идентификации, например, ограничений на методы учета и безопасности в инфраструктуре, которая поддерживает систему.
Конкретным видом сообщества является федерация, которая представляет собой собранные вместе несколько групп, отвечающих разным уполномоченным (и, следовательно, представляемых как разные области), для того, чтобы они могли скооперироваться для достижения некоторой цели. Так как эволюция распределенных систем будет быстро приводить к слиянию существующих раздельно управляемых подсистем для совместного использования информации или обеспечения коммерческих интересов, то спецификация СОЗДАНИЯ федераций и формулирование правил, по которым они управляются, образует важную часть спецификации системы с предпринимательской точки зрения.
Собранные в федерацию области могут быть административными (например, каждая из них управляется конкретным уполномоченным по безопасности или административному управлению) или технологическими (например, каждая из них является каким-то выбранным программным или техническим средством). Спецификация федерации включает в себя спецификации целей взаимодействия между разными областями и политики, управляющей этим взаимодействием.
Федерация административных областей относится к взаимодействию между областями в одном и том же или разных предприятиях с целью обеспечивать совместное использование, интеграцию или разделение ресурсов и приложений среди разных систем в ответ на потребности пользователя. Федерация технологических областей относится к интеграции различных системных архитектур и систем с разными ресурсами и возможностями; она обеспечивает модульность, которая позволяет наращивать систему, не отбрасывая существующие приложения. Эти два типа федерации часто совпадают, так как различия в администрировании могут привести к различию в выборе технологии.
Для административных областей один или оба администратора могут захотеть, в дополнение к контролю самими объектами, установить свой собственный контроль доступа для таких целей, как безопасность, учет или мониторинг. Административные границы также являются теми точками, где происходят изменения ответственности за административное управление такими вопросами, как распределение ресурсов и гарантии зависимости.
Политика, управляющая операциями федерации, включает в себя политику, управляющую взаимодействием. Таким образом, может оказаться необходимым, чтобы спецификация федерации была увязана со спецификацией возможностей ПЕРЕСЕЧЕНИЯ в инженерном описании, а цели и политика федерации устанавливали ограничения на возможности пересечения.
Предпринимательская спецификация устанавливает политику, управляющую поведением определяемых ею сообществ. Эта политика определяет действия предпринимательских объектов, составляющих сообщества, и сконцентрирована на установлении и выполнении обязательств (например, запроса доставки, осуществление доставки) и разрешении или запрещении действий (например, авторизируя или отвергая доступ к возможностям системы). Политика может относиться к следующему:
а) организации сообщества в терминах ролей и назначения ролей предпринимательским объектам. Например, правила сообщества могут устанавливать:
- назначение ролей и ответственности предпринимательским объектам внутри сообщества,
- то, как предпринимательские объекты связаны в структуре сообщества (например, иерархия или равноправие).
Предпринимательская спецификация может включать в себя коммерческие правила, которые выражают:
- предпринимательство как коммерческую категорию,
- требования учета,
- развитие бизнеса для достижения своих целей;
б) допустимым взаимодействиям между предпринимательскими объектами, играющими разные роли (т.е. к контролю доступа). Например, правила безопасности могут определять:
- взаимосвязи роль - ДЕЯТЕЛЬНОСТЬ - объект, требования целостности и конфиденциальности для деятельностей и объектов,
- правила для выявления угроз безопасности,
- правила защиты от угроз безопасности,
- правила для ограничения вреда, вызванного нарушением безопасности;
в) ответственности, делегируемой предпринимательским объектам. Например, правила описания уполномоченного используются для присвоения:
- привилегий предпринимательским объектам (доверение),
- разрешение или запрещение действий предпринимательских объектов;
г) учету использования ресурсов. Например, правила использования ресурсов определяют ограничения, которые могут быть внешним образом установлены для:
- регулирующих органов,
- рыночных запросов,
- среды,
в зависимости от того, используется ресурс:
- общедоступно,
- частно,
- третьей стороны;
д) владению ресурсами. Например, правила передачи могут устанавливать обмен владением и (или) ответственностью за ресурсы между предпринимательскими объектами;
е) членству в федерации. Например, предпринимательская спецификация может включать в себя правила области, которые устанавливают:
- правила членства в области,
- правила взаимодействия между областями одного типа,
- правила наименования областей.
Предполагается, что для выражения предпринимательских спецификаций для разных конкретных организационных структур и коммерческих задач будут существовать различные нотации. БМ-ОРО требует, чтобы соответствующая спецификация была создана, но устанавливает мало ограничений на то, как это должно быть сделано.
Оценка соответствия системы предпринимательской спецификации включает соответствующие требования (например, время ответа для выполнения обязательства), выраженные в спецификации для установления наблюдения поведения системы в ТОЧКАХ СООТВЕТСТВИЯ, идентифицированных в инженерной и технологической спецификациях, и оценку степени согласованности между требованиями и наблюдениями.
8.3. Информационный язык
Отдельные компоненты распределенных систем должны иметь общее понимание информации, которой они обмениваются при взаимодействии, иначе система не будет себя вести так, как ожидается. Некоторые из этих элементов информации могут тем или иным способом обрабатываться многими объектами системы. Для того чтобы гарантировать, что интерпретации этих элементов согласованы, информационный язык определяет понятия для спецификации смысла хранящейся в элементах информации и их обработки (системой ОРО) независимо от самих функций обработки информации, которые должны применяться.
Хранящаяся в системе ОРО информация о категориях реального мира, включая саму систему ОРО, представлена в информационной спецификации в терминах информационных объектов, из взаимосвязей и поведения. Основные информационные элементы представлены элементарными информационными объектами. Более сложная информация представлена составными информационными объектами, выражающими взаимосвязи в множестве составляющих информационных объектов.
Как и при обычном моделировании данных, информационная спецификация включает в себя набор взаимосвязанных схем, а именно ИНВАРИАНТНУЮ, СТАТИЧЕСКУЮ и ДИНАМИЧЕСКУЮ.
ИНВАРИАНТНАЯ СХЕМА выражает взаимосвязи между информационными объектами, которые почти всегда должны быть справедливыми при любом допустимом поведении системы. Например, инвариантная схема для банковского счета должна устанавливать, что баланс всегда должен быть неотрицательным, так как банк не позволяет превышать наличный счет.
СТАТИЧЕСКАЯ СХЕМА выражает утверждения, которые должны быть справедливы в один момент времени. Обычное использование статической схемы - спецификация начального состояния информационного объекта. Например, начальное состояние объекта "банковский счет" состоит из текущего баланса 0$ и суммы расходов за текущий день, которая также равна 0$. Другая статическая схема может быть использована для описания того, что сумма расходов за день равна 0$ каждую полночь; эта статическая схема не устанавливает ограничений на текущий счет в полночь.
ДИНАМИЧЕСКАЯ СХЕМА устанавливает, как может эволюционировать информация по мере работы системы. Например, для банковского счета требуются динамические схемы для депозита, расходов, оплаты и изменения вкладов. Динамическая схема может быть применена только при определенных обстоятельствах (которые могут быть специфицированы с помощью статической схемы). Например, динамическая схема для расхода N$ может устанавливать, что текущий счет уменьшается на N$ при условии,

ПРИКАЗ МПР РФ от 04.02.2004 n 89 О ПОРЯДКЕ И СРОКАХ ПРЕДСТАВЛЕНИЯ БУХГАЛТЕРСКОЙ ОТЧЕТНОСТИ ЗА 2003 ГОД ФЕДЕРАЛЬНЫМИ ГОСУДАРСТВЕННЫМИ УНИТАРНЫМИ ПРЕДПРИЯТИЯМИ, НАХОДЯЩИМИСЯ В ВЕДЕНИИ МПР РОССИИ  »
Постановления и Указы »
Читайте также