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

2007 г

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

Версия 1.0
Старых В.А., Башмаков А.И.
ФГУ ГНИИ ИТТ «Информика»

8 Общая структура профиля и способ ее описания

8.1 Нормативно-технические документы и модели

НТД существенно различаются по диапазону представляемых в них вопросов. В локальных НТД описываются отдельные, относительно обособленные модели (аспекты предметной области). Другие НТД имеют комплексный характер и охватывают множество хоть и взаимосвязанных, но все же четко разграничиваемых групп вопросов. Примером локального НТД может служить стандарт ИСО 15836:2003¹ (набор элементов данных Дублинского ядра), примером комплексного НТД – SCORM [2].

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

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

Широкий диапазон вопросов, регламентируемых комплексными НТД, может привести к тому, что в структуре включающего их профиля все подобные НТД будут попарно связаны одним и тем же набором отношений (или близкими по составу типов отношений наборами). Полученное описание структуры будет ненаглядным и практически мало полезным. Для решения данной проблемы в структуре профиля отражаются составные части комплексных НТД, соответствующие их логической (главы, разделы, параграфы, пункты) или концептуальной (темы, понятия, вопросы) декомпозиции. Например, SCORM может быть представлен четырьмя книгами (Overview, Content Aggregation Model, Sequencing and Navigation, Run-Time Environment) или пятью технологическими направлениями, указанными в разд. 6.1 (см. с. 17).

В ряде случаев возникает обратная проблема: существует множество НТД, описывающих разные аспекты одного и того же вопроса, причем такой уровень детализации на данном этапе построения профиля является излишним. В подобной ситуации целесообразно выполнить концептуальное объединение соответствующих НТД и представить их в структуре профиля единым пакетом, который при необходимости может быть декомпозирован. Например, в информационной модели метаданных для ИР сферы образования LOM (Learning Object Metadata)² используются типы контента MIME (Multipurpose Internet Mail Extensions), определенные в спецификациях IETF RFC 2045, 2046, 2048, 2077, 2646, 3023 и др. В контексте раздела профиля, регламентирующего метаданные, соотношения между этими спецификациями не имеют существенного значения, поэтому в его структуре их можно представить интегральным пакетом "Типы контента MIME", указав входящие в него НТД.

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

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

Для описания структуры профиля в настоящей спецификации вводится графическая нотация, основанная на обозначениях диаграмм пакетов UML [11]. В рамках нее модели соответствует пакет. Для каждой модели должны быть определены НТД (или их части), которые она представляет. Их названия указываются на изображении пакета в квадратных скобках после имени модели (рис. 10). Имя должно быть уникальным (т.е. неповторяющимся) в рамках профиля.

Рис. 10. Обозначение модели – пакет с указанием названий соответствующих НТД

Возможные соотношения между НТД и моделями иллюстрируют схемы на рис. 11.

Если модель соответствует содержанию единственного НТД (см. рис. 11а), а ее имя совпадает с названием этого НТД, то оно может быть опущено (на изображении пакета указывается только название НТД в квадратных скобках).

8.2 Типы моделей

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

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

Рис. 11. Возможные соотношения между НТД и моделями

Таблица 1. Характеристики, определяющие тип модели

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

Тип модели обозначается кодом, включающим от одного до трех символов³:

["I"|"M"]["N"|"R"]"O"|"D"|"P".

Например:

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

Код записывается в правом нижнем углу пакета модели (рис. 12).

Рис. 12. Указание кода типа модели

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

8.3 Уровни моделей

Модели распределяются по пяти уровням (рис. 13): 1) БП, 2) приложения, 3) прикладные сервисы, 4) общие сервисы, 5) инфраструктура. Применительно к моделям программных компонентов уровни 2–5 соответствуют аналогичным уровням IAF.

По сравнению с IAF в структуре профиля предусмотрен уровень БП. На нем располагаются модели деятельности, реализуемой на основе ИОС, описываемые независимо от средств ее ИТ-поддержки (конкретных приложений ИОС и их пользовательского интерфейса). На эти модели не накладываются ограничения, связанные с уровнями 1 и 2 LTSA. Они имеют целостный характер и позволяют специфицировать организационные схемы и педагогические методы, включающие элементы, которые выполняются без помощи инструментов ИОС.

Наличие уровня БП создает условия для согласования организационных решений без рассмотрения технических аспектов их поддержки в ИОС. Модели этого уровня имеют еще одно важное назначение. Поскольку именно БП отражают потребности пользователей ИОС, они позволяют выявлять ее недостающие функции, которые соответствуют элементам деятельности, не имеющим инструментов ИТ-поддержки, а также связанные с ними компоненты нормативно-технического обеспечения. Таким образом, модели БП служат источниками для анализа и определения направлений развития профиля, включая формирование требований к моделям нижележащих уровней, что согласуется с аналогичной ролью уровней 1 и 2 LTSA.

Модели, расположенные на смежных уровнях, связывают отношения использования. Реализация модели i-го уровня использует реализации моделей нижележащего ((i+1)-го) уровня и, в свою очередь, используется реализациями моделей вышележащего ((i–1)-го) уровня. Для моделей программных компонентов ИОС эти отношения соответствуют отношениям использования–предоставления услуг:

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

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

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

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

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

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

8.3.1 Уровень бизнес-процессов

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

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

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

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

Для описания моделей БП следует применять стандартные средства: IDEF0, IDEF3, диаграммы вариантов использования UML и т.д.

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

8.3.2 Уровень приложений

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

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

Сформулированный принцип позволяет идентифицировать устойчивые сочетания прикладных сервисов, соответствующие типовым компонентам ИОС. Например, к числу таких компонентов относятся портал и автоматизированная система управления образовательным учреждением, каталог и хранилище ИР, СУУП, электронная библиотека и др. Совокупность отношений между этими компонентами, пользователями ИОС и внешними системами образует обобщенную архитектуру ИОС. Аналогично LTSA такая архитектура будет обладать предсказательной функцией, т.е. позволит выявлять ключевые интерфейсы, обеспечивающие согласованность и интероперабельность компонентов ИОС. Возможность описания и анализа архитектуры ИОС и ее подсистем – важная сторона назначения данного уровня профиля.

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

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

8.3.3 Уровень прикладных сервисов

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

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

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

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

8.3.4 Уровень общих сервисов

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

Модели общих сервисов аналогичны моделям прикладных сервисов. Они описывают стандартные технические решения для общих сервисов и образующих их компонентов (в терминологии UML).

В качестве источников наполнения рассматриваемого уровня могут использоваться базовые профили общих web-сервисов IMS [8].

8.3.5 Уровень инфраструктуры

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

При наполнении данного уровня следует опираться на Государственный профиль взаимосвязи открытых систем России и Профиль переносимости прикладных программ.

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

уровням эталонной модели взаимосвязи открытых систем [6];
категориям интерфейсов между компонентами среды открытых систем [3] – API, связывающие прикладное программное обеспечение с прикладной платформой, и интерфейсы с внешней средой (External Environment Interface – EEI), поддерживающие взаимодействие прикладной платформы с внешней средой (другой прикладной платформой, пользователем, периферийным устройством), а также взаимодействие между приложениями, выполняемыми на одной и той же платформе;
видам предоставляемых услуг (сервисов), выделенным в эталонной модели среды открытых систем [3] (услуги операционной системы, интерфейса "человек–компьютер", разработки программного обеспечения, административного управления данными, обмена данными, защиты информации, административного управления, графические услуги, сетевые услуги).

8.4 Отношения между моделями в рамках уровня

8.4.1 Группы моделей и их иерархия

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

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

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

Отношения между группой и ее компонентами обозначаются стандартными средствами UML (рис. 14).

Рис. 14. Обозначение отношений включения в группу (представление состава группы):
а) внутри пакета группы размещаются пакеты ее компонентов; б) пакеты группы и ее компонентов связываются линиями с использованием соответствующих обозначений

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

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

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

Рис. 15. Варианты представления в профиле комплексного НТД (на примере SCORM)

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

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

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

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

8.4.2 Прочие формальные отношения в рамках уровня

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

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

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

Рис. 17. Определение отношений в рамках уровня

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

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

Для упрощения графического описания структуры профиля отношения могут отображаться не на общей диаграмме моделей уровня, а на отдельных диаграммах, содержащих пакеты-корреляты и их ближайшее окружение (рис. 18). Пакет, участвующий в отношении, может быть показан вне группы (составной модели), в которую он входит. При этом его имя должно фиксировать "путь" в иерархии моделей уровня до данного пакета, т.е. включать последовательность имен всех подчиняющих его структурных единиц, записанных через косую черту. Например, пакет модели 8 на рис. 18а изображен дважды: один раз – в составе подчиняющей его группы F, второй – вне ее для представления отношения с моделью 2.

Рис. 18. Представление отношений на диаграммах

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

1. Отношение обобщения (модель–метамодель)

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

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

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

Отношение обобщения является антирефлексивным и антисимметричным. Его обозначение и пример представлены на рис. 19.

Рис. 19. Отношение обобщения

2. Отношение ассоциации

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

Обозначения отношения ассоциации и его пример показаны на рис. 20. Ассоциация между информационными моделями LOM и манифеста дистрибутивного пакета ОО (рис. 20в) фиксирует связь метаданных LOM, представляющих общие сведения об ИР, с манифестом. Экземпляры метаданных могут быть приписаны манифесту верхнего уровня (т.е. ОО в целом), единицам логической структуры контента, единицам физической структуры, отдельным файлам и вложенным манифестам. Соответствующие блоки метаданных могут содержаться в манифесте или храниться отдельно от него (во втором случае в манифесте размещаются ссылки на них). Формально информационные модели метаданных LOM и манифеста не зависят друг от друга.

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

3. Отношение эквивалентности

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

Рис. 20. Отношение ассоциации

На диаграммах эквивалентность обозначается как ассоциация, помеченная стереотипом "is equal to" (рис. 21а). Другой способ ее указания состоит в записи имен эквивалентных моделей, разделенных символом равенства, в рамках одного пакета (рис. 21б). Пример отношения эквивалентности показан на рис. 21в.

4. Отношение зависимости

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

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

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

Рис. 21. Отношение эквивалентности

Рис. 22. Отношение зависимости

Следующие четыре базовых типа отношений являются бинарными разновидностями отношения зависимости.

5. Отношение использования

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

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

На диаграммах данное отношение помечается стереотипом "use" (рис. 23а). Его примеры показаны на рис. 23б.

Рис. 23. Отношение использования

6. Отношение уточнения

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

Модель A, специфицирующая уточнения, зависит от базовой (уточняемой) модели B в том смысле, что A создана в расчете на B и определена в ее терминах. Без B модель A не существует.

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

Отношение уточнения является антисимметричным. На диаграммах оно имеет стереотип "refine". Его обозначение и пример представлены на рис. 24.

Рис. 24. Отношение уточнения:
а) обозначение (модель A определяет уточнения для модели B);
б) пример

7. Отношение расширения

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

На диаграммах отношение расширения помечается стереотипом "extend". На рис. 25 показаны его обозначение и пример

8. Отношение привязки

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

Рис. 25. Отношение расширения:
а) обозначение (модель A расширяет модель B);
б) пример

Привязка – антисимметричное отношение. На диаграммах оно имеет стереотип "is a binding of". Обозначение и пример данного отношения приведены на рис. 26.

Рис. 26. Отношение привязки:
а) обозначение (модель A определяет привязку модели B к определенной технологии реализации);
б) пример

Привязку следует отличать от отношения связывания, помечаемого в UML стереотипом "bind" и фиксирующего значения параметров шаблона (параметризованного класса).

8.5 Межуровневые отношения

Структурные единицы профиля (модели, группы и составные модели), расположенные на смежных уровнях, связывают отношения использования (см. разд. 8.3). Данные отношения описываются матрицами инцидентности смежных уровней. Всего в рамках профиля определяются 5 таких матриц (соответствуют двойным стрелкам на рис. 13, 16):

БП – приложения;
приложения – прикладные сервисы;
прикладные сервисы – общие сервисы;
прикладные сервисы – компоненты инфраструктуры;
общие сервисы – компоненты инфраструктуры.

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

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

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

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

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

Иными словами, на диаграмме, представляющей структуру данного уровня, имя пакета, привязанного к другому уровню, соответствует формату⁴:

<ПУ>":"[<ИП>"/"[<ИП>"/"…]]<ИМ>,

где <ПУ> – префикс уровня (табл. 2);

<ИП> – имя подчиняющей структурной единицы;

<ИМ> – основное имя модели.

Таблица 2. Префиксы уровней моделей

Уровень Префикс

Бизнес-процессы БП

Приложения П

Прикладные сервисы ПС

Общие сервисы ОС

Инфраструктура И

Пример диаграммы, специфицирующей фрагмент структуры уровня прикладных сервисов и межуровневые отношения, в которых участвует модель "XML-привязка LOM, описанная на языке XML Schema", показан на рис. 27. Модели "XML 1.1" и "XML Schema" определены на уровне инфраструктуры, а модель "Формат vCard" – на уровне общих сервисов. Имена групп, фигурирующие в именах пакетов этих моделей, имеют условный характер и приведены в иллюстративных целях.

8.6 Распределение моделей по уровням и группам

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

Рис. 27. Пример описания межуровневых отношений

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

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

Общую структуру профиля иллюстрирует рис. 28. Характеристика образующих ее отношений дана в табл. 3.

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

Рис. 28. Общая структура профиля

Таблица 3. Система отношений между компонентами профиля

Назад Оглавление Вперёд

1 ISO 15836:2003. Information and documentation – The Dublin Core metadata element set.

2 IEEE 1484.12.1-2002. Learning Object Metadata standard. – New York: IEEE, 2002.

3 Символы, выражающие значения фасетных признаков, приведены в кавычках, а необязательные компоненты кода – в квадратных скобках. Кавычки и скобки в код не включаются.

4 Обязательные компоненты указаны в угловых скобках, необязательные – в квадратных. Сами эти скобки в имя не включаются.