OJS Профил за интеграция v1

Статус: Чернова
Основен протокол: omi-integration/1
Идентификатор на профила: omi-integration/1/ojs

1. Обхват

Профилът за интеграция „OJS“ определя как дадена инсталация на Open Journal Systems (OJS) съпоставя работния си процес по издаване на списания с неутралния спрямо платформата стандарт за интеграция „OMI“ API v1.

Профилът е предназначен за архитектура, в която OJS и услугата OMI остават отделни приложения с отделни слоеве за съхранение на данни. Плъгинът за интеграция OJS действа като „тънък“ адаптер. Open Manuscript Studio НЕ ТРЯБВА да осъществява пряк достъп до базата данни OJS или до директорията с частни файлове.

OJS продължава да бъде еталон за работния процес в научните списания. OMI продължава да бъде еталон за преносимите структурирани ръкописи и научните взаимодействия, интегрирани в Studio.

2. Архитектурна граница

OJS
Own application and database
        |
        | OJS OMI Integration Plugin
        | supported OJS services / repositories / hooks
        |
        | HTTPS + OMI Integration API v1
        v
Open Manuscript Studio
Own application and PostgreSQL database

Адаптерът НЕ ТРЯБВА да изисква промени в основните файлове на OJS. Той ТРЯБВА да използва поддържаните механизми за разширения PKP/OJS и APIна ниво приложение.

3. Модел на авторитета

OJS е авторитетен източник за:

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

OMI / „Студио“ е авторитет в областта на:

структурата на документа „OMI“;
стабилни котви;
Анотации, създадени директно в студиото;
съвместно редактиране на ръкописи;
структурна история на ръкописа в OMI;
структурирани бележки за рецензиране, създадени в Studio;
състоянието на резолюцията на анотациите в Studio;
OMI създаване на пакети.

Синхронизираните метаданни ТРЯБВА да отразяват произхода и НЕ ТРЯБВА да създават тайно конкуриращи се авторитети.

4. Задължително съпоставяне на профили

OMI Интеграция API ресурс	OJS концепция
`installation`	Инсталация наOJS
`context`	списание
`submission`	OJS подаване
`component`	компонент за статии/публикации (по избор)
`contributor`	автор/съавтор, свързан с настоящата публикация
`file`	файл с подадената работа на OJS
`reviewAssignment`	Задание за рецензия на „OJS“
`reviewRound`	Преглед на „OJS“
`revision`	проследимо състояние на редакцията на ръкописа/подадената статия
`publication`	OJS списък с публикации и състояние на публикациите

OJS Числовите идентификатори ТРЯБВА да бъдат преобразувани в низове на границата на протокола.

5. Идентификационни данни за инсталацията

Всяко внедрение на „OJS“, свързано с услугата „OMI“, ТРЯБВА да има стабилен installationId, конфигуриран за интеграцията.

Идентификаторът НЕ ТРЯБВА да се променя, когато списанието бъде преименувано или когато се промени публичният му URL адрес.

Пример:

{
  "installationId": "ojs-example-university",
  "platform": "ojs",
  "profile": "omi-integration/1/ojs",
  "baseUrl": "https://journals.example.edu/"
}

Услугата „OMI“ ТРЯБВА да съхранява идентификатора на инсталацията независимо от текущия базов URL адрес.

6. Контекстът на списанието

Едно списание от OJS съответства на OMI context.

Пример:

{
  "externalId": "1",
  "type": "journal",
  "path": "example-journal",
  "name": {
    "en": "Example Journal"
  },
  "url": "https://journals.example.edu/index.php/example-journal"
}

Идентификаторът на списанието е стабилен външен идентификатор. Пътят към списанието СЛЕДВА да бъде посочен с цел навигация, но НЕ ТРЯБВА да се разглежда като единствена постоянна идентичност.

7. Съпоставяне на подадените данни

Едно подаване към OJS съответства на ресурс от типа OMI submission.

Един конектор ТРЯБВА да предоставя поне:

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

Пример:

{
  "externalId": "1542",
  "type": "article",
  "status": "review",
  "title": {
    "en": "Example manuscript"
  },
  "abstract": {
    "en": "Example abstract"
  },
  "keywords": {
    "en": ["history", "publishing"]
  },
  "primaryLocale": "en",
  "updatedAt": "2026-08-07T17:30:00Z"
}

Коннекторът ТРЯБВА да прави разграничение между състоянието на работния процес „OJS“ и състоянието на ръкописа „OMI“. Фактът, че дадена публикация се намира в етап на рецензиране „OJS“, не означава, че документът „OMI“ е неизменен.

8. Метаданни за публикацията

OJS може да съдържа метаданни, предназначени за публикацията, отделно от данните за подаване на ниво работен процес. Коннекторът ТРЯБВА да чете библиографските метаданни, предназначени за автора, от представянето на публикацията, съответстващо на версията на „OJS“, вместо да ги възстановява от таблиците в базата данни.

При синхронизацията на „OMI“ НЕ СЕ ДОПУСКА да се приема, че дадено подаване има само едно историческо състояние на публикуване.

Коннекторът ТРЯБВА да запазва идентификаторите за подаването на данни към „OJS“ и съответния запис за публикацията, когато такъв е наличен.

9. Автори

OJS Списъкът с автори/съавтори съответства на ресурсите за съавтори на „OMI“.

Конекторът ТРЯБВА да запази:

идентификатор на външен сътрудник;
имена и фамилии;
предпочитано публично име, ако има такова;
изпращайте имейл само когато текущият обхват на интеграцията и работният процес позволяват разкриването на информация;
принадлежност;
страна, в която услугата е достъпна и разрешена;
ORCID и други идентификатори;
последователност на участниците;
роля на сътрудник, която се показва от OJS;
обозначение на кореспонденцията, когато е приложимо.

Идентичността на автора ТРЯБВА да бъде скрита, когато това се изисква от политиката за анонимно рецензиране.

Конекторът НЕ ТРЯБВА да разкрива самоличността на автора пред рецензента, когато работният процес на „OJS“ изисква анонимност на автора.

10. Компоненти

Повечето статии в научни списания могат да бъдат представени като еднократно подаване без подкомпоненти. Поради това профилът „OJS“ не изисква поддръжка на компоненти.

Един конектор МОЖЕ да предоставя достъп до компоненти, дефинирани от хоста, когато това е полезно, например класове на допълнителни материали или структурирани компоненти на статии. Такива разширения НЕ ТРЯБВА да променят семантиката на основния ресурс за подаване.

11. Файлове за подаване

OJS Файловете, подадени за участие, съответстват на ресурсите на OMI и file.

Отговорите със списък от файлове ТРЯБВА да включват:

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

Пример:

{
  "externalId": "889",
  "name": "manuscript.docx",
  "mediaType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
  "stage": "submission",
  "revision": 2
}

Studio ТРЯБВА да извлича двоичното съдържание чрез оторизирана крайна точка за интеграция на OJS. Самото познаване на идентификатора на файла от OJS НЕ ТРЯБВА да дава право на изтегляне.

Плъгинът НЕ ТРЯБВА да разкрива пътища към файловата система на сървъра OJS.

12. Импортиране на файл в Studio

Когато подаване на „OJS“ се отваря за първи път в Studio, потребителят ТРЯБВА да има възможност да избере подходящ файл с ръкопис или да използва автоматично избран основен файл с ръкопис в съответствие с политиката на коннектора.

Функцията „Import“ МОЖЕ да преобразува DOCX, JATS, HTML или друга поддържана форма на представяне в документалния модел OMI.

Оригиналният файл „OJS“ и неговата контролна сума ТРЯБВА да бъдат запазени като доказателство за произхода.

При импортирането НЕ СЕ РАЗРЕШАВА промяна на изходния файл „OJS“.

13. Изпращане на ревизия на OJS

Връщането на ръкопис от „Studio-to-OJS“ ТРЯБВА да създаде проследим нов файл или версия в „OJS“, в съответствие със семантиката на работния процес, описана на OJS.

Коннекторът НЕ ТРЯБВА да презаписва без предупреждение файл от архива.

Искането за преразглеждане ТРЯБВА да съдържа:

{
  "baseExternalRevision": "3",
  "source": "omi",
  "omiRevision": "01J...",
  "message": "Author revision from Open Manuscript Studio"
}

Коннекторът „OJS“ ТРЯБВА да отхвърли операцията поради конфликт в синхронизацията, ако очакваното базово състояние се е променило и автоматичното съгласуване би довело до риск от загуба на данни.

14. Подписана процедура за пускане

Добавката „OJS“ ТРЯБВА да предоставя достъп до действието „Отвори в Studio“ само на потребители, които имат право на достъп до съответното подаване и операция.

Утверждението при стартиране ТРЯБВА да посочва:

installationId;
идентификатор на контекста на списанието;
идентификационен номер на заявката;
OJS идентификатор на потребителя;
исканите обхвати;
време на издаване;
срок на валидност;
nonce.

Примерна област на действие за автор, редактиращ версия:

[
  "metadata.read",
  "contributors.read",
  "files.read",
  "manuscript.read",
  "manuscript.write",
  "revision.write"
]

На рецензента ТРЯБВА да бъде определен по-тесен обхват, специфичен за конкретната рецензия.

15. Идентичност на потребителя и свързване на акаунти

Идентификаторът на потребител в „OJS“ представлява външно потвърждение на самоличността и НЕ ТРЯБВА автоматично да се превръща в идентификатор на акаунт в Studio.

Studio MAY може да свърже автентифициран акаунт в Studio с една или повече външни идентичности от OJS след успешно стартиране с подпис и локална авторизация.

Един препоръчителен ключ е:

installationId + externalUserId

Имейл адресът НЕ ТРЯБВА да се използва като единствен неизменен идентификационен ключ, валиден за всички системи.

16. Орган за партньорска оценка

OJS продължава да бъде авторитетен източник за:

дали има задача за преглед;
кой рецензент го притежава;
активният етап на преглед;
крайни срокове;
преразглеждане на метода/политиката;
дали самоличността на автора може да бъде разкрита;
дали може да бъде разкрита самоличността на рецензента;
допустими препоръчителни стойности;
състояние на завършеност;
редакционно решение след преглед.

Студиото НЕ ТРЯБВА самостоятелно да определя рецензент на списанието „OJS“ или да изразява предварително редакционно решение относно списанието „OJS“.

17. Стартиране на прегледа

При стартирането на преглед ТРЯБВА да се посочи конкретна одобрена задача за преглед, а не само подадена заявка и потребител.

Пример:

{
  "installationId": "ojs-example-university",
  "context": {"externalId": "1", "type": "journal"},
  "submission": {"externalId": "1542"},
  "reviewAssignment": {"externalId": "991"},
  "reviewRound": {"externalId": "2"},
  "actor": {"externalId": "77"},
  "scope": ["manuscript.read", "review.read", "review.write"]
}

Добавката „OJS“ ТРЯБВА да провери дали текущият потребител OJS има право да извърши това задание, преди да издаде потвърждение за стартиране.

18. Преглед на анонимността

Коннекторът „OJS“ ТРЯБВА да определи действителната политика за анонимност при прегледа въз основа на авторитетната конфигурация на работния поток „OJS“ и контекста на възлагането.

Преди да предаде полезен товар, достъпен за рецензента, конекторът ТРЯБВА да премахне данните, за които рецензентът няма право да вижда.

Филтрирането МОЖЕ да включва:

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

Studio ТРЯБВА също така да прилага получената политика от страна на сървъра. Скриването на самоличността само в кода на потребителския интерфейс на Reactне отговаря на изискванията.

19. Структуриран преглед в Studio

Студио MAY представя преглед на „OJS“ като структуриран преглед на „OMI“, който съдържа:

общ текст на рецензията;
коментари, достъпни само за редактора;
коментари, видими за автора;
препоръка;
закрепени анотации;
препратки към приложения;
състояние на завършеност;
отговори и състояние на разрешаването на анотациите.

Когато е възможно, анкерираната анотация ТРЯБВА да се позовава на стабилна координата от типа „OMI“, а не на координата от типа „PDF“, изчислена въз основа на визуализираната страница.

20. Отговор на рецензия

При операция по връщане на преглед ЗАДЪЛЖИТЕЛНО трябва да се посочат заданието за преглед „OJS“ и кръгът на прегледа.

Пример:

{
  "assignmentExternalId": "991",
  "roundExternalId": "2",
  "recommendation": "revisions-required",
  "summary": "The manuscript requires clarification in several places.",
  "editorOnly": "The central argument is publishable after revision.",
  "annotations": [
    {
      "anchor": "omi:anchor:01J...",
      "visibility": "author-and-editor",
      "body": "Please provide a source for this statement.",
      "status": "open"
    }
  ]
}

Коннекторът ТРЯБВА да провери съответствието на препоръката спрямо допустимите стойности за контекста на проверката „OJS“.

Подаването на рецензия в „Studio“ НЕ ТРЯБВА автоматично да води до редакционно решение, освен ако „OJS“ изрично не предвиди и одобри такава операция.

21. Няколко кръга на преглед

Студиото ТРЯБВА да третира кръговете на преглед на „OJS“ като отделни външни обекти в работния процес.

Анотациите от по-ранен кръг ТРЯБВА да останат исторически свързани с този кръг, дори когато се прехвърлят с цел проследяване на разрешаването.

По-късен цикъл МОЖЕ да се позовава на по-ранни анотации, но НЕ ТРЯБВА да презаписва историческия архив на прегледа.

22. Редакция от автора и отговор

Когато работният процес на „OJS“ позволява редактиране от автора, Studio МОЖЕ да предостави на автора работна среда, съдържаща коментари от рецензията, до които авторът има достъп.

Авторът МОЖЕ:

да се преразгледа съдържанието на финализирания ръкопис;
да отговаря на коментарите към рецензиите;
да се отбележи отговорът като даден от гледна точка на автора;
създаване на нова ревизия на OMI;
Върнете пакета/файла с ревизии на OJS.

Местното решение на автора НЕ ТРЯБВА да се представя като одобрение от рецензента, освен ако рецензентът или редакторът изрично не го потвърди.

23. Използване за редакционни цели

Редакторите МОГАТ да получат по-широки правомощия в сравнение с авторите или рецензентите, при условие че това бъде одобрено от OJS.

Работното пространство на Studio, предназначено за редактори, МОЖЕ да показва:

всички одобрени доклади от преглед;
коментари, достъпни само за редактора;
редактиране на ръкописи;
състояние на разрешаване на анотациите;
състояние на синхронизацията.

Авторитетното редакционно решение ТРЯБВА все пак да бъде отразено в „OJS“.

24. Интегриране на публикациите

След одобрение „Studio MAY“ изнася производни на публикацията за производство в „OJS“, включително формати, поддържани от спецификациите на OMI и инсталираните конвертори.

Възможните резултати включват:

OMI пакет;
JATS XML;
HTML;
DOCX-производство, произтичащо от;
свързани активи.

OJS остава авторитетен източник за планирането на публикациите, разпределянето на броевете, DOI/работния процес по метаданните на публикациите, статуса на коректурите/публикациите и публичното предоставяне, освен ако това не бъде изрично делегирано от бъдещо разширение на профила.

25. Изисквания към възможностите

Коннекторът „OJS“, който претендира, че отговаря на базовия профил „omi-integration/1/ojs“, ТРЯБВА да поддържа:

launch
metadata.read
contributors.read
files.read

Коннектор, който твърди, че осигурява OJS синхронизация на ръкописи, ТРЯБВА допълнително да поддържа:

manuscript.read
manuscript.write
revision.read
revision.write

Коннектор, за който се твърди, че поддържа OJS интеграция чрез рецензиране от колеги, ТРЯБВА допълнително да поддържа:

review.read
review.write

Един конектор, който твърди, че поддържа интеграция с публикациите наOJS, ТРЯБВА да обяви:

publication.read
publication.export

26. Препоръчителна повърхност на крайната точка

Приложението МОЖЕ да адаптира маршрутизацията към своята хост-среда, но ТРЯБВА да осигурява еквивалентни операции за:

GET  /capabilities
POST /launch
GET  /contexts/{contextId}
GET  /contexts/{contextId}/submissions/{submissionId}
GET  /contexts/{contextId}/submissions/{submissionId}/contributors
GET  /contexts/{contextId}/submissions/{submissionId}/files
GET  /contexts/{contextId}/submissions/{submissionId}/files/{fileId}/content
GET  /contexts/{contextId}/submissions/{submissionId}/revisions
POST /contexts/{contextId}/submissions/{submissionId}/revisions
GET  /contexts/{contextId}/submissions/{submissionId}/reviews/{assignmentId}
POST /contexts/{contextId}/submissions/{submissionId}/reviews/{assignmentId}/result
GET  /contexts/{contextId}/submissions/{submissionId}/publication

Тези пътища описват протоколни ресурси; те не изискват от „OJS“ да замени собствената си REST структура „API“. Плъгинът за интеграция МОЖЕ да предостави специално пространство от имена за адаптери.

27. Разрешение

Всяка операция ТРЯБВА да бъде одобрена на нивото на приложението „OJS“.

Коннекторът НЕ ТРЯБВА да разчита единствено на наличието на идентификационен номер на подадената заявка, идентификационен номер на файла, идентификационен номер на заданието за преглед или активна сесия в Studio.

Удостоверенията „от услуга към услуга“ определят връзката между конекторите; оторизацията на потребителя/работния поток определя дали може да се осъществи достъп до даден ресурс.

28. Състояние на синхронизацията

Студиото ТРЯБВА да запази метаданните за синхронизация, включително:

installationId
contextExternalId
submissionExternalId
externalPublicationId (when applicable)
lastExternalRevision
lastSynchronizedAt
source checksum(s)

Състоянието на синхронизацията представлява метаданни за интеграцията и ТРЯБВА да остане отделено от каноничното съдържание на ръкописа на OMI.

29. Управление на конфликти

Коннекторът ТРЯБВА да върне съобщение „409 Conflict“, когато Studio се опита да запише от неактуална външна базова ревизия или когато състоянието „OJS“ се е променило по начин, който не позволява безопасно изпълнение на операцията.

Конъкторът НЕ ТРЯБВА да разрешава конфликтите в ръкописа, като незабележимо презаписва съдържанието от „OJS“.

30. Идемпотентност

Качването на ревизии, подаването на рецензии и други операции за запис, които могат да се повторят, ТРЯБВА да приемат ключ за идемпотентност.

Повторният опит за изпращане през мрежата НЕ ТРЯБВА случайно да създава дублиращи се доклади за рецензиране или дублиращи се версии на ръкописа.

31. Одит и произход

Събитията, свързани с интеграцията, ТРЯБВА да подлежат на одит. Съответните записи включват:

издаване и приемане на емисии;
импортиране на ръкопис;
извличане на файлове;
връщане на ревизия;
старт на ревюто;
подаване на рецензия;
експорт на публикации.

В аудиторските регистри НЕ СЕ РАЗРЕШАВА да се записват без необходимост съдържанието на ръкописите, паролите, споделените тайни или поверителният текст на рецензиите.

32. Изолиране на неизправности

Недостъпността на Studio НЕ ТРЯБВА да възпрепятства обичайното администриране на OJS или работния процес по публикуване извън функциите, които изрично зависят от Studio.

Недостъпна инсталация на „OJS“ НЕ ТРЯБВА да повреди или да направи невалиден вече импортиран ръкопис от „OMI“.

Добавката „OJS“ ТРЯБВА да отхвърля заявките за защитени интеграционни операции и ТРЯБВА да предоставя полезна информация за грешката на оторизираните потребители.

33. Съвместимост при актуализации

Плъгинът за интеграция ТРЯБВА да изолира кода за съответствие, специфичен за версията на OJS, от протоколния слой на OMI.

От концептуална гледна точка:

OMI Integration API
        |
OJS profile mapper
        |
OJS-version adapter
        |
Supported OJS services / repositories / hooks

Това разделяне позволява адаптерът OJS 3.5 да бъде усъвършенстван или заменен, без да се променя неутралният спрямо платформата договор omi-integration/1.

34. Разширения

OJS-конкретните стойности МОГАТ да бъдат предоставени чрез обект за разширение с пространство от имена:

{
  "extensions": {
    "org.pkp.ojs": {
      "stageId": 3
    }
  }
}

Studio ТРЯБВА да може безопасно да игнорира неизвестни разширения от типа „OJS“. Разширението НЕ ТРЯБВА да предефинира поле от основния набор от данни „OMI“ или от интеграцията „API“.

35. Съответствие

Една реализация, която претендира за съответствие с „omi-integration/1/ojs“, ТРЯБВА:

да съответства на интеграцията на „OMI“ API v1;
да предостави стабилна идентичност на инсталацията на OJS;
да съпостави списанията с контекстите и подадените материали в „OJS“ с подадените материали;
да се използва оторизация на ниво приложение;
да се избегне пряк достъп от Studio до таблиците в базата данни на OJS и до пътеките към частните файлове;
рекламирани функции;
да се запазят външните идентификатори и произходът;
да се наложи анонимност на отзивите от страна на сървъра, когато е активирана интеграцията с отзивите;
да се запази проследима история на промените при операциите по запис;
да могат да се отключват безопасно от Studio.

36. Инвариант на дизайна

Коннекторът „OJS“ интегрира работния поток на списанието с „OMI“; той не превръща „OMI“ в подсистема на „OJS“.

OJS управлява процеса на публикуване на научни статии. Studio осигурява структурирана среда за създаване, анотиране, рецензиране, редактиране и преобразуване. Ръкописът остава преносим между двете системи.

1. Обхват​

2. Архитектурна граница​

3. Модел на авторитета​

4. Задължително съпоставяне на профили​

5. Идентификационни данни за инсталацията​

6. Контекстът на списанието​

7. Съпоставяне на подадените данни​

8. Метаданни за публикацията​

9. Автори​

10. Компоненти​

11. Файлове за подаване​

12. Импортиране на файл в Studio​

13. Изпращане на ревизия на OJS​

14. Подписана процедура за пускане​

15. Идентичност на потребителя и свързване на акаунти​

16. Орган за партньорска оценка​

17. Стартиране на прегледа​

18. Преглед на анонимността​

19. Структуриран преглед в Studio​

20. Отговор на рецензия​

21. Няколко кръга на преглед​

22. Редакция от автора и отговор​

23. Използване за редакционни цели​

24. Интегриране на публикациите​

25. Изисквания към възможностите​

26. Препоръчителна повърхност на крайната точка​

27. Разрешение​

28. Състояние на синхронизацията​

29. Управление на конфликти​

30. Идемпотентност​

31. Одит и произход​

32. Изолиране на неизправности​

33. Съвместимост при актуализации​

34. Разширения​

35. Съответствие​

36. Инвариант на дизайна​

1. Обхват

2. Архитектурна граница

3. Модел на авторитета

4. Задължително съпоставяне на профили

5. Идентификационни данни за инсталацията

6. Контекстът на списанието

7. Съпоставяне на подадените данни

8. Метаданни за публикацията

9. Автори

10. Компоненти

11. Файлове за подаване

12. Импортиране на файл в Studio

13. Изпращане на ревизия на OJS

14. Подписана процедура за пускане

15. Идентичност на потребителя и свързване на акаунти

16. Орган за партньорска оценка

17. Стартиране на прегледа

18. Преглед на анонимността

19. Структуриран преглед в Studio

20. Отговор на рецензия

21. Няколко кръга на преглед

22. Редакция от автора и отговор

23. Използване за редакционни цели

24. Интегриране на публикациите

25. Изисквания към възможностите

26. Препоръчителна повърхност на крайната точка

27. Разрешение

28. Състояние на синхронизацията

29. Управление на конфликти

30. Идемпотентност

31. Одит и произход

32. Изолиране на неизправности

33. Съвместимост при актуализации

34. Разширения

35. Съответствие

36. Инвариант на дизайна