Все сущности, сохраняемые в хранилищах СУЭОД э(32) (классы э(11), дела э(34), разделы э(66), тома э(74) и официальные документы э(52) и др.) нуждаются в идентификаторах.  Эти идентификаторы нужны для того, чтобы:

    Разрешать программному обеспечению обрабатывать сущности; Разрешать пользователям э(68) извлекать, обращаться к, и использовать сущности.

MoReq2 использует следующую терминологию для описания этих идентификаторов:

    Идентификатор, требуемый для использования программного обеспечения, называется «Идентификатор системы». Он может использоваться как пользователями э(68),  так и программным обеспечением в некоторых случаях; Иерархический идентификатор, применяемый к сущностям в иерархии схемы классификации э(14) и предназначаемый для пользователей э(68), называется код классификации э(13); Другие идентификаторы называются по назначению, например, «идентификатор порядка хранения, отбора и передачи э(61)».

Разница между идентификаторами системы и кодами классификации э(13) проиллюстрирована в следующих трех диаграммах. К этим диаграммам также вернемся позже в этой главе.

Диаграмма 7.1 показывает часть вымышленной, но реалистичной схемы классификации э(14). В ней показано несколько классов э(11), у каждого класса э(11) есть название класса э(11) (как в требовании 3.2.4).

Диаграмма 7.1

К каждому классу э(11) отнесен системный идентификатор, как показано на диаграмме 7.2.

Диаграмма 7.2

Заметим, что системные идентификаторы, показанные здесь, короткие и простые только для иллюстрации. В реальности они, скорее всего, будут более длинными и более структурно сложными. В качестве иллюстрации, примером системного идентификатора основанного на алгоритме Всемирного уникального идентификатора (“Globally Unique Identifier”) является 0c7220e3-5646-44c4-82b0-67832c1efa1c.

НЕ нашли? Не то? Что вы ищете?

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

Диаграмма 7.3

Здесь для иллюстрации коды классификации э(13) также показаны достаточно простыми.

У каждого класса э(11) есть код классификации э(13), который может быть объединен с кодами классификации э(13) его родительских классов э(13) для создания «Полностью определяющего кода классификации э(13)». Так, например, полностью определяющий код классификации э(13) для класса э(11) «Восстановительные работы» – 001‑001‑003 (см. на диаграмме 7.3).  Он конструируется следующим образом:

    начинаем с кода классификации э(13) наиболее высокого родителя в иерархии (001, являющийся кодом классификации э(13) для класса э(11) «Направления деятельности»); добавляем код классификации э(13) следующего его родителя ниже в иерархии (001, являющийся Идентификатором дела класса «Непрерывность деятельности»), создавая 001‑001; повторяем предыдущий шаг до момента достижения ближайшего родительского класса э(11) (в данном простом примере нет повторов); добавляем код классификации э(13)  для класса э(11) ‑ 003, являющегося кодом классификации э(13)  для класса э(11) «Восстановительные работы», таким образом, создавая полностью определяющий код классификации э(13)  001‑001‑003.

Официальным документам э(52) и компонентам э(19) также назначены коды классификации э(13), чтобы они были уникальными для идентификации.

Предполагаемое использование определяет требуемую степень уникальности. Системные идентификаторы обычно должны быть уникальными внутри как минимум одной СУЭОД э(32) как «экземпляра» или «сетевого узла», но предпочтительно обеспечить уникальность во всей (глобальной) сети. Полностью определяющий код классификации э(13) должен быть уникальным внутри схемы классификации э(14), хотя поскольку он выстроен иерархически, индивидуальный код классификации э(13) может быть уникальным только внутри одного узла (например, класса э(11) или раздела э(66)) в иерархии.

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

Коды классификации

Требование

Тест

При создании нового экземпляра одного из следующих информационных объектов или его захвата э(8), СУЭОД э(32) обязательно должна назначить ему код классификации э(13):

    класс э(11), дело э(34); раздел э(66); том э(74); официальный документ э(52); компонент э(19).

Д

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

В

СУЭОД э(32) обязательно должна гарантировать, что все коды классификации э(13) и все полностью определяющие коды классификации э(13) сохраняют требуемую степень уникальности независимо от любого перемещения (см. требование 3.4.1).

Д

СУЭОД э(32) обязательно должна быть способной сохранять коды классификации э(13) как элементы метаданных э(40) сущностей, к которым они относятся.

Д

СУЭОД э(32) должна разрешать лицу, выполняющему роль администратора э(1), на этапе конфигурации э(20) указывать форматы кодов классификации э(13) и полностью определяющих кодов классификации э(13). Она должна разрешать определять следующие признаки кодов классификации э(13) для каждого уровня иерархии:

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

Д

Полностью определяющие коды классификации э(13) должны состоять из соединения кодов классификации э(13) разделенных символом-разделителем.

Д

СУЭОД э(32) должна разрешать выбирать символы-разделители для полностью определяющих кодов классификации э(13) как минимум, из:

    « »  (пробел); « - » (черточка); « / » (косая черта); « . » (точка).

Д

Например, код классификации э(13)  001‑001‑003 (как сказано выше во введении) мог быть представлен как любая из последовательностей, в зависимости от установок, сделанных на этапе конфигурации э(20):

    1 001 003; 001-001-003; 1/1/3; 001.001.003..

Помня, что требование 3.2.7 разрешает глобальные приставки и расширения, они могут быть показаны, как:

    корпоративный/1/1/3; 001.001.3.pt.

СУЭОД э(32) обязательно должна разрешать лицу, выполняющему роль администратора э(1), указывать при создании нового класса э(11), будут ли его дочерние сущности иметь коды классификации э(13), генерированные СУЭОД э(32) автоматически, или будут вводится пользователем э(68) либо внешним приложением. СУЭОД э(32) должна либо:

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

или:

    разрешать уполномоченному пользователю э(6) или внешнему приложению формировать код классификации э(13), но в последствии не позволять изменять.

В

В качестве примера для первого выбора: – если новый класс э(11), озаглавленный «Управление инцидентами» добавляется под классом э(11) «Непрерывность деятельности» в примере, показанном на диаграмме 7.3; в данном примере ему будет назначен код классификации э(13) – 004, как показано в диаграмме 7.4.

Диаграмма 7.4

Второй выбор применим в сфере управления структурированной деятельностью.

Если СУЭОД э(32) генерирует новый код классификации э(13) автоматически (первая опция в 7.1.8), она должна генерировать следующий порядковый номер, принимая во внимание:

    Последний использовавшийся на данный момент код классификации э(13) в схеме классификации э(14) или (для первого на данный момент) стартовое значение; Указанное приращение, смотри э7.1.5.

Д

Смотри диаграмму 7.4 для примера.

Принимая код классификации э(13) от пользователя э(68) или от внешнего приложения, СУЭОД э(32) должна подтвердить его уникальность внутри его родителя.

Д

Системные идентификаторы

Требование

Тест

Всякий раз, при создании нового экземпляра одного из следующих информационных объектов, СУЭОД э(32) обязательно должна назначить ему системный идентификатор:

    схема классификации э(14); класс э(11); дело э(34); раздел э(66); том э(74); официальный документ э(52); выписка из официального документа э(55); порядок хранения и уничтожения э(61); документ э(26).

Д

СУЭОД э(32) обязательно должна гарантировать, что все системные идентификаторы уникальны в пределах иерархии схемы классификации э(14) и в пределах экземпляра СУЭОД э(32).

Н

Заметим, что данное требование распространяется на все территориально разобщенные объекты, где внедрена распределенная схема классификации э(14) и на все схемы классификации э(14), если внедрены более, чем одна схема классификации э(14).

СУЭОД э(32) обязательно должна быть способной хранить системные идентификаторы как элементы метаданных э(40) соответствующих сущностей, к которым они обращаются.

Д

СУЭОД э(32) должна устанавливать системные идентификаторы, которые будут глобально уникальными.

Н

«Глобально уникальный» означает, что системный идентификатор назначен с использованием алгоритма, который гарантирует, что никакой другой системный идентификатор не может иметь те же значения, независимо от того, когда или в какой СУЭОД э(32) он был создан.

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

СУЭОД э(32) должна использовать алгоритм UUID  (как указано в ISO/IEC 9834-8 и ITU-T Rec. X.667) для генерирования глобально уникальных системных идентификаторов.

В

Этот алгоритм, который зачастую называют просто GUID (Globally Unique ID), может быть использован для гарантии уникальности.

Другие подходы к генерации уникальных идентификаторов, которые могут использоваться, включают Digital Object Identifier System (DOI®),the Uniform Resource Name (URN) scheme and the Archival Resource Key (ARK).

СУЭОД э(32) не должна требовать от пользователей э(68) вводить или использовать системные идентификаторы для каждой функции СУЭОД э(32).

В

Это требование включено в связи с тем, что глобально уникальные идентификаторы имеют тенденцию быть длинными и неприветливыми по отношению к пользователям э(68). Однако допустимо, чтобы пользователям э(68) разрешалось использовать системные идентификаторы, если они это выберут.

ПОИСК, ИЗВЛЕЧЕНИЕ И ПРЕДСТАВЛЕНИЕ

Данная глава в разделе 8.1 содержит перечень требований к поиску и извлечению. Требования, относящиеся к представлению э(50), разделены на три раздела: раздел 8.2 содержит требования по визуализации на экране компьютера, раздел 8.3  устанавливает требования к печати и раздел 8.4 посвящен представлению э(50) официальных документов э(52), которые не могут быть напечатаны.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44