Страница 8: ДСТУ 4071-2001. Інформаційні технології. Архітектура відкритого розподіленого керування та підтримка загальної архітектури брокера об’єктних запитів (CORBA) (61988)

Далі наведено визначення термінів, перелік яких вказано у розділі 3 цього стандарту, а самі визначення запозичені з ISO/IEC-стандартів, для яких відсутні згармонізовані ДСТУ.

абстрагування чи абстракція (Abstraction)

Процес усування несуттєвих деталей для визначання спрощеної моделі або результату цього процесу

дія (Action)

Яка-небудь чинність. Кожна дія, яка є цікавою для моделювання, зв’язана, принаймні, з одним об’єктом. У наборі дій, пов’язаних з об’єктом, виділяють внутрішні дії та взаємодії. Внутрішня дія завжди відбувається без участі навколишнього середовища об’єкта. Взаємодія здійснюється за участю навколишнього середовища об’єкта.

Примітка 1. Дія означає виконання дії. Залежно від контексту деталізація може вказати, що дія вже відбулася, зараз відбувається або лише може відбутися.

Примітка 2. Рівень модульності дій залежить від конкретного проекту. Дія може не бути миттєвою. Дії можуть накладатися.

Примітка 3. Взаємодію можна тлумачити у термінах причини та наслідку відношень між об'єктами, що взаємо­діють.

Примітка 4, Об’єкт може взаємодіяти сам з собою. У цьому випадку розглянуто, принаймні, дві його ролі у взає­модії. У цьому контексті об’єкт можна розглядати як частину власного навколишнього середовища.

Примітка 5. Залучення навколишнього середовища сприяє спостережності. Таким чином, за взаємодіями мож­на спостерігати, тоді як за внутрішніми діями не можна спостерігати через інкапсуляцію об’єктів

активність (Activity)

Однокорінний, направлений, неперіодичний граф дій, у якому здійснення кожної дії стало мож­ливим завдяки здійсненню всіх безпосередньо попередніх до нього дій (тобто всіма суміжними дія­ми, найближчими до розглянутої)

архітектура (Architecture)

Набір правил для визначання структури системи і взаємозв’язків між її частинами

поведінка (Behavior) об’єкта

Сукупність дій з набором обмежень на можливість виконання. Конструкціями використовуваної мови визначають обмеження, які таким чином можна виразити. Обмеження можуть містити, наприк­лад, послідовність, недетермінізм чи паралелізм обмежень реального часу. Поведінка може долу­чати внутрішні дії. Дії, що фактично наявні, обмежені середовищем, у якому міститься об’єкт.

Примітка 1. Композицію сукупності об'єктів цілком заміняють еквівалентним об'єктом, що задає композицію. Поведінку цього об’єкта часто згадують просто як поведінку сукупності об'єктів.

Примітка 2. Дія й активність — вироджені випадки поведінки.

Примітка 3. Загалом кілька епізодів взаємодії сумісні з певною поведінкою

зв’язування (Binding)

Договірний контекст, що випливає з конкретної встановленої поведінки. Встановлення поведін­ки, договірний контекст і допустима поведінка можуть містити два і більше інтерфейсів об’єкта. Об’єкт, що ініціює встановлення поведінки, може брати або не брати участі у наступній поведінці, що до­пускається. Допустима поведінка (за аналогією договірний контекст) може бути однорідна (тобто кожен об'єкт, що бере участь, може робити те саме, що й інші) або неоднорідною (тобто роль деякого об'єкта, що бере участь, відрізняється від ролі іншого об’єкта, як клієнт і сервер). Немає жодної потреби у відповідності між об’єктом, який ініціює встановлення поведінки, і приватною роллю в неоднорідній допустимій поведінці (наприклад, у клієнт-серверному договірному контексті, будь-який об’єкт може обґрунтовано ініціювати встановлення поведінки)

клас <Х> (Class of <X>'s)

Набір усіх <Х>, що задовольняють тип. Елементи набору співвідносяться як члени класу.

Примітка 1. Клас може не мати членів.

Примітка 2. Чи згодом зміниться розмір набору, залежить від визначання типу

клієнтський об’єкт (Client object)

Об’єкт, що запитує виконання функції іншим об’єктом

зв’язок (Communication)

Передача інформації між двома чи більше об’єктами в результаті однієї або більше взаємодій, можлива, тільки з деякими проміжними об’єктами.

Примітка 1. Зв’язок можна визначати в термінах причини і наслідку взаємозв'язку між об’єктами-учасниками.

Примітка 2. Кожна взаємодія є прикладом зв’язку

погодженість (Compliance)

Вимога необхідної сумісності одного елемента родини ODP-стандартів з іншим (типу RM-ODP), визначена у процесі стандартизації. Підтримка таких вимог зветься погодженістю. Якщо технічні вимоги сумісні, безпосередньо чи опосередковано, з деякими іншими стандартами, то пропозиції, істинні в цих стандартах, — також є істинними в сумісній реалізації технічних вимог

композиція (Composition)

1. (об’єктів) — сукупність двох і більше об’єктів призводить до появи нового об’єкта на різних рівнях абстракції. Характеристики нового об’єкта визначені поєднуваними об’єктами і їхнім об’єднан­ням. Поведінка складеного об’єкта — відповідна композиція поведінки складових об’єктів.

2. (поведінки) — комбінація двох і більше варіантів поведінки призводить до появи нової пове­дінки. Характеристики підсумкової поведінки визначено поєднуваними варіантами поведінки і їхнім об’єднанням.

Примітка 1. Приклади комбінаційних методів — послідовна і паралельна композиція, черговість, вибір і прихо­вування дії. Ці загальні визначання завжди використовують в певному сенсі, ідентифікуючи специфічні засоби комбінації.

Примітка 2. У деяких випадках композиція поведінки може призводити до появи виродженої поведінки, тобто тупиків через обмеження вихідної поведінки

конфігурація об’єктів (Configuration of objects)

Сукупність об'єктів, здатних взаємодіяти за допомогою інтерфейсу. Конфігурація визначає набір об’єктів, задіяних у кожній взаємодії. Специфікації конфігурації можуть бути статичні чи задаватися в термінах динамічних механізмів, що змінюють конфігурацію, тип прив’язки й відв’язки.

Примітка. Конфігурацію можна висловити в термінах паралельної композиції. Процес композиції генерує еквіва­лентні конфігурації об'єкта на іншому рівні абстракції

контракт (Contract)

Угода, керівна частина колективної поведінки набору об’єктів. Контракт визначає зобов’язання, дозвіл і заборону для долучених об'єктів. Технічні вимоги контракту можуть охоплювати:

• технічні вимоги різних ролей, що можуть приймати долучені до контракту об’єкти, і інтер­фейсу, зв'язаного з цими ролями;

• якість атрибутів обслуговування;

• свідчення тривалості або періодів законності (обґрунтованість);

• свідчення поведінки, що позбавляє контракт законної сили;

живучість і умови безпеки.Примітка 1. Об’єкти в контракті не повинні бути ієрархічно зв’язані, але можуть бути зв'язані на основі одноран- говості . Вимоги в контракті не обов’язково однаково застосовні до всіх об’єктів-учасників контракту.

Примітка 2. Контракт можна застосовувати в заданій контрольній точці системи. У цьому випадку він визначає поведінку, яка може очікуватися в контрольній точці.

Примітка 3. Шаблон об’єкта забезпечує простий приклад контракту. Цей шаблон визначає поведінку, загальну для сукупності об’єктів. Також визначено, ідо середовище будь-яких таких об’єктів можна брати до уваги, розглядаючи їхню поведінку. Зазначено, що для часткових технічних вимог шаблон об’єкта залишає невизначеним поведінку об’єкта за деяких станів навколишнього середовища (наприклад, специфічні взаємодії); контракт поширюється лише на зазначе­ну поведінку

створення <Х> (Creation of an <Х>)

Ілюстрація прикладами <Х>, що досягнуті діяльністю об’єктів у складі моделі. <Х> може бути будь-чим, що може ілюструватися прикладами приватних об’єктів та інтерфейсу.

Якщо <Х> — інтерфейс, то він створений для узгодження у процесі створювання певного об’єкта або як додатковий інтерфейс до створюваного об’єкта. Зрештою будь-який інтерфейс повинен бути частиною об’єкта

дані (Data)

Форма подання інформації, з якою мають справу системи і їхні користувачі як споживачі інфор­мації

декомпозиція (Decomposition)

1. (об’єкта) — детальний опис об’єкта як композиції;

2. (поведінки) — детальний опис поведінки як композиції.

Композиція і декомпозиція —двоїсті терміни і протилежні дії технічних вимог

видалення <Х> (Deletion of an <Х>)

Дія руйнування, проілюстрована прикладами <Х>. <Х> може бути будь-чим, що можна проілю­струвати прикладами приватних об'єктів і інтерфейсу. Якщо <Х> — інтерфейс, то його може вида­лити тільки об’єкт, з яким <Х> зв’язаний.

Примітка. Видалення дії не має чіткої мети; дія відбувається

розподілене обробляння (Distributed processing)

Обробляння інформації, у якому окремі компоненти можуть бути розташовані в різних місцях, а зв’язок між компонентами може зазнавати затримки і може зазнати невдачі

Прозорість розподілу (Distribution transparency)

Властивість приховування від приватного користувача потенційної поведінки деяких частин розподіленої системи.

Примітка. Користувачами можуть бути, наприклад, кінцеві користувачі, прикладні розробники і проектувальники

сутність (Entity)

Будь-яка конкретна чи абстрактна річ, яка є цікавою. Загалом слово «сутність» можна викори­стовувати для співвіднесення з будь-чим. У контексті моделювання воно зарезервовано для співстав- ляння з речами у сфері дослідження

контракт середовища (Environment contract)

Контракт між об’єктом і його середовищем, зокрема обмеження: якість обслуговування (послу­ги), використовування і керування. Обмеження якості обслуговування містять:

• тимчасові обмеження (наприклад, eadlines);

• обмеження обсягу (наприклад, пропускна здатність);

• обмеження залежності, які замінюють аспекти приступності (готовності), надійності, надійності в експлуатації, захисту і безпеки (наприклад, середнє напрацювання на відмову).

Обмеження використовування і керування містять:

• обмеження розташування (тобто обране розміщення в просторі та часі);

• обмеження прозорості розподіляння (тобто вибір прозорості розподіляння).

Обмеження якості обслуговування можуть мати на увазі обмеження керування і використання. Наприклад, деяке обмеження якості обслуговування (наприклад, доступність) задоволено для забез­печення однієї і більше розподіленої прозорості (наприклад, дублювання). Обмеження середовища можуть описувати:

• вимоги, що ґрунтуються на середовищі об’єкта для надання правильної поведінки об’єкту;

• обмеження на поведінку об’єкта в «правильному» середовищі

відмова (Failure)

Порушення контракту.

Примітка 1. Поведінка, зазначена в контракті, є за визначенням «правильною» поведінкою. Таким чином, відмова — ухиляння від узгодження з правильною поведінкою.

Примітка 2. Шляхи, якими можуть здійснюватися відмови об’єкта, називаються його моделлю відмов. Розрізня­ють кілька типів відмов:

• випадкові відмови (недотримування технічних вимог як причина більшості відмов);

• відмова через помилку (коли очікувані взаємодії не відбуваються);

• відмови аварійних зупинок (постійні відмови через помилки);

• тимчасові відмови (некоректність через несвоєчасну поведінку).

Примітка 3. Відмова може бути сприйнята по-різному різними об'єктами в середовищі об’єкта, що репрезентує його. Відмова може бути: стійка, якщо будь-яке сприйняття відмови залишається таке саме; нестійка, якщо об’єкти в середовищі можуть по-різному сприймати різні дані відмови

аварія чи помилка (Fault)

Ситуація, викликана помилкою, що відбулася в об’єкті.

Примітка 1. Аварія, викликана помилкою, може відбутися з часу визначання об’єкта до моменту його руйнуван­ня. Аварія на ранньому етапі (наприклад, аварія проекту) не може призводити до відмови у пізнішого періоду (наприклад, час виконання).

Примітка 2. Аварія є активною або бездіяльною. Аварія активна, коли вона робить помилки. Наявність активної аварії визначено тільки виявлянням помилок.

Примітка 3. Аварії можуть бути:

• випадкові (виникають чи з’являються випадково) або навмисні (створені навмисно);

• фізичні (через деякі фізичні явища) чи людські (що відбулися через діяльність людини);

• внутрішні (частина стану об’єкта, що може викликати «АБО») чи зовнішні (що відбулися через вплив чи взає­модію із середовищем);

• постійні або тимчасові.

У разі визначання аварії, помилки і відмови йдеться про рекурсивні причинні залежності між аварією, помилкою і відмовою:

• аварія може призвести до помилки (якщо аварія активна);

• помилка може призвести до відмови системи (якщо система не може справитися з аварією);

• відмова відбувається у випадку, коли помилка впливає на коректність служби, наданої системою (чи елемен­том системи)

ідентифікатор (Identifier)

Однозначне ім’я в заданому контексті позначання

інформація (Information)

Будь-яке знання у сфері досліджування, придатне для обміну серед користувачів, про речі, факти, принципи тощо. Інформація обов’язково має форму подання, щоб її можна було передавати. Пер­шорядно важливим є інтерпретація цього подання (тобто зміст)