Эцп невозможно создание объекта сервером программирования объектов: Ошибка «Невозможно создание объекта сервером программирования объектов»

Содержание

Ошибка «Невозможно создание объекта сервером программирования объектов»

Если при попытке подписи электронного документа ЭЦП браузер выдает сообщение «Невозможно создание объекта сервером программирования объектов»,


Это означает, что библиотека CAPICOM не была автоматически зарегистрирована на Вашем компьютере,.

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

  1. Скачать архив  capicom.zip
  2. Закрыть все окна Internet Explorer’а
  3. Извлечь файлы из архива на Ваш компьютер
  4. Запустить register.bat из папки, в которую были извлечены файлы архива (для операционной системы Windows Vista запуск необходимо производить от имени администратора)

Если и с этим будут проблемы, то можно самостоятельно установить и зарегистрировать capicom.dll. Для этого:

  1. Скопировать файл capicom.
    dll в системный каталог операционной системы (обычно это, C:\WINDOWS\SYSTEM32), если там уже есть такой файл — заменить на файл из архива
  2. В меню Пуск/Выполнить ввести команду: regsvr32 capicom.dll и нажать OK.

После успешной установки проверьте наличие этой библиотеки в надстройках Internet Explorer. Для этого зайдите в меню СЕРВИС — СВОЙСТВА ОБОЗРЕВАТЕЛЯ — вкладка ПРОГРАММЫ — кнопка НАДСТРОЙКИ. В появившемся окне найдите библиотеку capicom.dll и включите её.


Если все предыдущие шаги выполнены, но ошибка при попытке подписи электронного документа ЭЦП продолжает появляться, это может означать, что работа блокируется системными службами «Брандмауэр Windows» и «Центр обеспечения безопасности». В этом случае Вам необходимо их отключить.

Для этого чтобы их отключить, необходимо перейти в «Панель управления — Администрирование — Службы». В окне появится список всех служб. Найдите эти службы. На каждой из них щёлкните дважды мышью. В появившемся окне измените типа запуска на «Вручную» или «Отключена» и нажмите кнопку «Остановить».

Невозможно создание объекта сервером программирования объектов

Обновлено 23.07.2019

При формировании запроса на портале заявителя (ФЗС Росказна) произошла ошибка: Error: Невозможно создание объекта сервером программирования объектов. Предлагаем 2 варианта решения.

1 вариант решения — установка КриптоПро ЭЦП Browser plug-in

2 вариант решения — установка библиотек Capicom

Прежде чем устанавливать библиотеку, необходимо узнать 32-х или 64-х разрядная операционная система у вас установлена. Чтобы узнать разрядность, нажмите правой кнопкой мыши на значок «Мой компьютер» и выберите пункт «Свойства». В разделе «Тип системы» указана разрядность. Узнали? Тогда начнем!

Установка библиотеки Capicom для 32-разрядных операционных систем (Windows XP, Vista, Windows 7/8/8.

1)
  1. Качаем библиотеку Capicom 32 bit и запускаем установку правой кнопкой мыши от имени администратора (установщик скачан с сайта microsoft.com
    )
  2. Нажимаем «Next»
  3. Ставим галку «I accept the terms in the License Agreement» и нажимаем «Next»
  4. Меняем путь установки по умолчанию C:\ProgramFiles\MicrosoftCAPICOM2.1.0.2\ на C:\Windows\System32\ и нажимаем «OK»
  5. Нажимаем «Next» > «Install» > «Finish»
  6. Регистрируем библиотеку. Для этого идем «Диск С > Windows > system32». В папке «system32» файл «cmd» запускаем правой кнопкой мыши «от администратора». В открывшуюся командную строку необходимо скопировать и вставить следующее

    c:\windows\system32\regsvr32.exe capicom.dll  

    и нажимаем «ENTER». В результате появится сообщение об успешной регистрации. Теперь можно формировать запрос.

Установка библиотеки Capicom для 64-разрядных операционных систем (Windows 10, Windows XP, Vista, Windows 7/8/8.

1)
  1. Качаем библиотеку Capicom 64 bit
  2. Из скачанного архива извлекаем 2 файла «capicom.dll», «capicom.inf» и копируем их в папку «Диск С > Windows > syswow64»
  3. Регистрируем библиотеку. Для этого идем «Диск С > Windows > system32». В папке «system32» файл «cmd» запускаем правой кнопкой мыши «от администратора». В открывшуюся командную строку необходимо скопировать и вставить следующее

    c:\windows\syswow64\regsvr32.exe capicom.dll

    и нажимаем «ENTER». В результате появится сообщение об успешной регистрации.

Теперь можно формировать запрос.

Невозможно создание объекта сервером программирования объектов

Нередко при необходимости подписи электронного документа в стандартном формате ЭЦП пользователь получает отказ, а мотивируется он следующим предупреждением: «Невозможно создание объекта сервером программирования объектов». Теперь нет возможности провести операцию автоматически, поэтому прибегаем к ручному преобразованию ЭЦП.

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

Невозможно создание объекта сервером программирования объектов

Причины ошибки в ЭЦП

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

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

Как исправить ошибку автоматически

Шаги предпринимаем последовательно:

  1. Capicom.zip – этот архив необходимо скачать себе на компьютер. Помните про вирусы, поэтому перепроверяйте софт на наличие вирусов глубоким сканированием всего содержимого. Сам файл мы проверили и разместили на Яндекс Диске.
  2. После скачивания в вашем браузере Internet Explorer закрываем все окна. Максимально отключаем все имеющиеся расширения.
  3. Из архива все переносим на компьютер в любое место на жестком диске, помня про извлечение с правами администратора.
  4. Register.bat – это установочный файл. Кликаем по нему и дожидаемся автоматической корректировки системы.

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

Исправляем проблему вручную

  • C:\WINDOWS\SYSTEM32 – это путь, куда распаковываем capicom.dll. Иногда при переносе выдает, что такой софт имеется в конечной директории. Тогда вручную удаляем все файлы, относящиеся к capicom.dll для размещения новых библиотек.
  • regsvr32 capicom.dll – это команда для начала процесса интеграции библиотек. Стандартно ее вносят в форму «Выполнить», которую найдете в «Пуск».

    Выполнить ввести команду regsvr32 capicom

  • В теории теперь вам доступны в Internet Explorer нужные библиотеки для выполнения операций с ЭЦП. Однако рекомендуется удостовериться в установке библиотек. В вашем браузере пройдем по настройкам: сервис – свойства обозревателя – программы.
  • Последним действием будет выбор настроек. Среди множества позиций интересуемся только форматом capicom.dll: смотрим по меню «файл» расположенного в конце. Имя при этом будет Setting Class. Перепроверяем статус библиотек, которые должны быть включены. При необходимости переключаем самостоятельно: внизу найдете нужные пункты.

    найдите библиотеку capicom.dll и включите её

«Брандмауэр» и ему подобные системы вроде «Центра обеспечения безопасности», антивирусы желательно предварительно отключать. Регистрация может блокироваться при попытках внести изменения в систему.

Заключение

Надеюсь вы разобрались как исправить ошибку в ЭЦП: невозможно создание объекта сервером программирования объектов.

Если у вас еще есть вопросы по работе с электронными цифровыми подписями – пишите нам в комментариях к этой странице и мы постараемся вам помочь.

Евгений Загорский

IT специалист. Автор информационных статей на тему Андроид смартфонов и IOS смартфонов. Эксперт в области решения проблем с компьютерами и программами: установка, настройка, обзоры, советы по безопасности ваших устройств. В свободное время занимается дизайном и разработкой сайтов.

Оценка статьи:

Загрузка… Самое читаемое: 12.01.2021

Часто при попытке добавить новую маску или красивый визуальный эффект в приложении Инстаграм появляется ошибка…

Далее 12.01.2021

Ошибка “Не удалось определить цифровой сертификат получателя 1C” может появляться при попытке отправить и. ..

Далее 12.01.2021

Данная ошибка появляется в некоторых современных играх использующих технологию Directx 12 и Vulkan. Например при запуске…

Далее 10.01.2021

С конца 2020 года пользователи смартфонов Андроид столкнулись с проблемой при обновлении программ и игр в Play Market: на…

Далее

Появляется сообщение об ошибке «Невозможно создание объекта сервером программирования объектов» либо «Произошла ошибка: undefine | Компания права Респект — КонсультантПлюс Уфа

На этапе отправки или сохранения отчета 4-ФСС появляется одно из следующих сообщений об ошибке:

1. Скриптовая ошибка с текстом:

Сообщение: Невозможно создание объекта сервером программирования объектов
Строка: 102
Символ: 9
Код: 0
URI-код: https://fss.kontur.ru/rsv/Front/TheForm/1412301/1412301.FileBuilder.js

2. Сообщение с текстом ошибки «Произошла ошибка: undefined».

3. Долгое время отображается надпись «Пожалуйста, подождите«.

Для решения ошибки необходимо выполнить следующие шаги:

1. Закрыть все окна Internet Explorer;

2. Настроить браузер с помощью утилиты Install All.  Для этого необходимо загрузить утилиту, извлечь файлы из архива и запустить файл Install All.exe. Следует дождаться окончания установки и перезагрузить компьютер. Утилита доступна для загрузки в разделе  Программное обеспечение / Обязательные программы.

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

3. Открыть страницу сервиса Отчетность в ФСС в системе «Контур-Экстерн» и повторить проверку или отправку отчета.

4. В случае, если предложенное решение не помогло исправить ошибку, необходимо проверить установленную версию Internet Explorer. Для этого выбрать меню Справка / О программе в окне Internet Explorer (см. рис. 1).

Если данное меню не отображается, необходимо нажать клавишу Alt

Рис. 1. Справка Internet Explorer

  • Если версия Internet Explorer ниже 8.0, то необходимо установить обновление. Дистрибутив доступен в разделе  Программное обеспечение / Обязательные программы.
  • Если установлена версия Internet Explorer 8.0, то необходимо проверить, что установлена финальная версия обозревателя.

                 — Для Windows XP – 8.0.6001.18702;
                 — Для Windows Vista – 8.0.6001.18943;
                 — Для windows 7 – 8.0.7600.16385;

Если установлена не финальная версия, необходимо установить обновление. Дистрибутив доступен в разделе  Программное обеспечение / Обязательные программы.

activex error невозможно создание объекта

На чтение 6 мин. Просмотров 26 Опубликовано

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

Невозможно создание объекта сервером программирования объектов

Причины ошибки в ЭЦП

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

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

Как исправить ошибку автоматически

Шаги предпринимаем последовательно:

  1. Capicom.zip – этот архив необходимо скачать себе на компьютер. Помните про вирусы, поэтому перепроверяйте софт на наличие вирусов глубоким сканированием всего содержимого. Сам файл мы проверили и разместили на Яндекс Диске.
  2. После скачивания в вашем браузере Internet Explorer закрываем все окна. Максимально отключаем все имеющиеся расширения.
  3. Из архива все переносим на компьютер в любое место на жестком диске, помня про извлечение с правами администратора.
  4. Register.bat – это установочный файл. Кликаем по нему и дожидаемся автоматической корректировки системы.

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

Исправляем проблему вручную

  • C:WINDOWSSYSTEM32 – это путь, куда распаковываем capicom.dll. Иногда при переносе выдает, что такой софт имеется в конечной директории. Тогда вручную удаляем все файлы, относящиеся к capicom.dll для размещения новых библиотек.
  • regsvr32 capicom.dll – это команда для начала процесса интеграции библиотек. Стандартно ее вносят в форму «Выполнить», которую найдете в «Пуск».

Выполнить ввести команду regsvr32 capicom

найдите библиотеку capicom.dll и включите её

«Брандмауэр» и ему подобные системы вроде «Центра обеспечения безопасности», антивирусы желательно предварительно отключать. Регистрация может блокироваться при попытках внести изменения в систему.

Заключение

Надеюсь вы разобрались как исправить ошибку в ЭЦП: невозможно создание объекта сервером программирования объектов. Если у вас еще есть вопросы по работе с электронными цифровыми подписями — пишите нам в комментариях к этой странице и мы постараемся вам помочь.

Информация обновлена: 23.07.2019

При формировании запроса на портале заявителя (ФЗС Росказна) произошла ошибка: Error: Невозможно создание объекта сервером программирования объектов. Предлагаем 2 варианта решения.

1 вариант решения — установка КриптоПро ЭЦП Browser plug-in

2 вариант решения — установка библиотек Capicom

Прежде чем устанавливать библиотеку, необходимо узнать 32-х или 64-х разрядная операционная система у вас установлена. Чтобы узнать разрядность, нажмите правой кнопкой мыши на значок «Мой компьютер» и выберите пункт «Свойства». В разделе «Тип системы» указана разрядность. Узнали? Тогда начнем!

Установка библиотеки Capicom для 32-разрядных операционных систем (Windows XP, Vista, Windows 7/8/8.1)

  1. Качаем библиотеку Capicom 32 bit и запускаем установку правой кнопкой мыши от имени администратора (установщик скачан с сайта microsoft.com)
  2. Нажимаем «Next»
  3. Ставим галку «I accept the terms in the License Agreement» и нажимаем «Next»
  4. Меняем путь установки по умолчанию C:ProgramFilesMicrosoftCAPICOM2.1.0.2 на C:WindowsSystem32 и нажимаем «OK»
  5. Нажимаем «Next» > «Install» > «Finish»
  6. Регистрируем библиотеку. Для этого идем «Диск С > Windows > system32». В папке «system32» файл «cmd» запускаем правой кнопкой мыши «от администратора». В открывшуюся командную строку необходимо скопировать и вставить следующее

c:windowssystem32
egsvr32.exe capicom.dll

и нажимаем «ENTER». В результате появится сообщение об успешной регистрации. Теперь можно формировать запрос.

Установка библиотеки Capicom для 64-разрядных операционных систем (Windows 10, Windows XP, Vista, Windows 7/8/8.1)

  1. Качаем библиотеку Capicom 64 bit
  2. Из скачанного архива извлекаем 2 файла «capicom.dll», «capicom.inf» и копируем их в папку «Диск С > Windows > syswow64»
  3. Регистрируем библиотеку. Для этого идем «Диск С > Windows > system32». В папке «system32» файл «cmd» запускаем правой кнопкой мыши «от администратора». В открывшуюся командную строку необходимо скопировать и вставить следующее

c:windowssyswow64
egsvr32. exe capicom.dll

и нажимаем «ENTER». В результате появится сообщение об успешной регистрации.

Если при попытке подписи электронного документа ЭЦП браузер выдает сообщение «Невозможно создание объекта сервером программирования объектов»,

Это означает, что библиотека CAPICOM не была автоматически зарегистрирована на Вашем компьютере,.

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

  1. Скачать архив capicom.zip
  2. Закрыть все окна Internet Explorer’а
  3. Извлечь файлы из архива на Ваш компьютер
  4. Запустить register.bat из папки, в которую были извлечены файлы архива (для операционной системы Windows Vista запуск необходимо производить от имени администратора)

Если и с этим будут проблемы, то можно самостоятельно установить и зарегистрировать capicom.dll. Для этого:

  1. Скопировать файл capicom.dll в системный каталог операционной системы (обычно это, C:WINDOWSSYSTEM32), если там уже есть такой файл — заменить на файл из архива
  2. В меню Пуск/Выполнить ввести команду: regsvr32 capicom. dll и нажать OK.

После успешной установки проверьте наличие этой библиотеки в надстройках Internet Explorer. Для этого зайдите в меню СЕРВИС — СВОЙСТВА ОБОЗРЕВАТЕЛЯ — вкладка ПРОГРАММЫ — кнопка НАДСТРОЙКИ. В появившемся окне найдите библиотеку capicom.dll и включите её.

Если все предыдущие шаги выполнены, но ошибка при попытке подписи электронного документа ЭЦП продолжает появляться, это может означать, что работа блокируется системными службами «Брандмауэр Windows» и «Центр обеспечения безопасности». В этом случае Вам необходимо их отключить.

Для этого чтобы их отключить, необходимо перейти в «Панель управления — Администрирование — Службы». В окне появится список всех служб. Найдите эти службы. На каждой из них щёлкните дважды мышью. В появившемся окне измените типа запуска на «Вручную» или «Отключена» и нажмите кнопку «Остановить».

© ООО «Российские логистические информационные системы»

Инструкция по установке ПО для работы ЭЦП

Инструкция для клиента.

Инструкция для клиента. Для работы плагина КриптоПро ЭЦП необходимо, чтобы помимо корневого сертификата удостоверяющего центра (УЦ), которым Вам был выдан личный сертификат, также был установл корневой

Подробнее

Инструкция по установке КриптоАРМ

Инструкция по установке КриптоАРМ Содержание 1. Установка КриптоПро… 1 1.1 Установка программы… 1 1.2 Активация лицензии Крипто Про… 2 2. Установка корневого сертификата… 4 3. Установка сертификата

Подробнее

Установка корневого сертификата

Установка корневого сертификата 1. В браузере Internet Explorer выберите раздел «Сервис Свойства обозревателя Содержание Сертификаты». 2. Найдите в списке сертификат пользователя, который используется

Подробнее

Онлайн Сервис ВБЦ vbankcenter.

ru

Онлайн Сервис ВБЦ vbankcenter.ru Инструкция по настройке рабочего места для работы с площадкой Оглавление Введение… 3 Основные системные требования… 3 Установка необходимого для работы программного

Подробнее

Установка личного сертификата.

Установка личного сертификата. Для того чтоб настроить доступ по ключу, на компьютере необходимо наличие установленного «КриптоПро CSP» версии не ниже 3.6. Проверить наличие «КриптоПро CSP» можно в «Панели

Подробнее

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

УДОСТОВЕРЯЮЩИЙ ЦЕНТР НП МосГорУслуга РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ по установке и настройке программного обеспечения для работы электронной подписи 2016 г. СОДЕРЖАНИЕ УСТАНОВКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ… 3

Подробнее

ЗАО «Национальный удостоверяющий центр»

ЗАО «Национальный удостоверяющий центр» Инструкция по ручной настройке рабочего места под управлением операционной системы семейства Microsoft Windows для работы со средством электронной подписи СКЗИ «КриптоПро

Подробнее

Шаг 1.

Установка СКЗИ

Перед началом работы на портале госуслуг, настройте рабочее место. В статье описана пошаговая инструкция для настройки рабочего места. Шаг 1. Установка СКЗИ СКЗИ (средство криптографической защиты информации)

Подробнее

Электронная площадка FINTENDER.RU

Электронная площадка FINTENDER.RU Руководство пользователя Установка и настройка программного обеспечения Москва 2017 Содержание Базовые настройки программного обеспечения… 3 Автоматическая настройка

Подробнее

Руководство пользователя

Руководство пользователя Установка сертификатов esphere.ru ОГЛАВЛЕНИЕ НЕОБХОДИМЫЕ КОМПОНЕНТЫ… 2 ПОРЯДОК УСТАНОВКИ… 3 Установка сертификата ключа подписи… 3 Установка корневого сертификата… 8 1

Подробнее

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

УДОСТОВЕРЯЮЩИЙ ЦЕНТР НП «МосГорУслуга» РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ по установке и настройке программного обеспечения для работы электронной подписи 2017 г. СОДЕРЖАНИЕ УСТАНОВКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ…

Подробнее

1. Установка КриптоПро CSP 3.6

Порядок работы с ЭЦП 1. Установка КриптоПро CSP 3.6… 1 2. RuToken для КриптоПро CSP… 3 3. Установка корневых сертификатов УЦ РОЛИС… 10 4. Установка Личного Сертификата… 11 5. Конфигурация параметров

Подробнее

Методические указания

Министерство информатизации и связи Красноярского края Краевое государственное казённое учреждение «Центр информационных технологий Красноярского края» Методические указания по установке программного обеспечения

Подробнее

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

УДОСТОВЕРЯЮЩИЙ ЦЕНТР ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ НП МОСЖИЛРЕГИСТРАЦИЯ РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ по установке и настройке программного обеспечения для работы электронной цифровой подписи (ключевой носитель

Подробнее

Удаленный доступ к приложениям

Удаленный доступ к приложениям Общая информация В Томском политехническом университете работает сервис (Remote Desktop Web Access) web-доступа к удаленным приложениям (RemoteApp), рабочим столам на основе

Подробнее

ЭЦП не работает — Решение основных ошибок в работе электронной подписи

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

Выбранная подпись не авторизована

Обычно ошибка ‎«‎Выбранная ЭЦП не авторизована‎»‎ возникает во время попытки входа в личный кабинет на электронных торговых площадках.

Возникает она при использовании нового ключа ЭЦП на торговой площадке без регистрации пользователя или без регистрации нового сертификата. Для авторизации подписи в личном кабинете необходимо:

  1. Перейти на главную страницу торговой площадки.
  2. Выбрать раздел ‎«Вход по ЭЦП».
  3. Выбрать ‎«Авторизация ЭЦП‎».
  4. Нажать «Пользователь организации‎».
  5. Подтвердить выбор нового ключа ЭЦП».
  6. В открывшемся окне ‎«Идентификационные данные‎ заполнить все обязательные поля».
  7. Нажать ‎«Отправить на рассмотрение‎».

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

ЭЦП поставлено сертификатом без заключенного соглашения

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

Если соглашения нет, то его необходимо заключить в письменной форме. Если соглашение было заключено ранее, то нужно проверить соответствие ФИО, указанное в соглашении, с ФИО в сертификате ключа ЭЦП.  Если данные не менялись, то нужно дождаться ‎квитанции о приеме,‎ которая приходит в течение 4 рабочих дней после отправки отчета об ошибке. Протокол проверки ошибки приходит вместо квитанции в случае, когда проверка наличия пользовательского соглашения прошла ранее запроса.

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

Не поддерживается алгоритм сертификата ЭЦП

При подписании документов и во время отправления отчетности иногда возникает ошибка «‎Алгоритм ключа сертификата не поддерживается»‎‎. Исправить ее можно переустановкой КриптоПро CSP и проверкой совместимости ПО с компонентами Microsoft.

Также нужно проверить хранилище сертификатов на предмет наличия там закрытого ключа ЭЦП. Если проблема повторяется, то можно установить КриптоПро.nет и sdk версии 1.0.48668.1 или выше. Если переустановка криптопровайдера не помогает и одновременно возникает ошибка ОС «‎Неустранимая ошибка при инициализации исправлений»‎‎, то необходима полная переустановка операционной системы.

Электронная подпись невалидна

Ошибка «‎Электронная подпись документа невалидна»‎ ‎‎ чаще возникает при работе в системах 1С. Обычно связана проблема с тем, что на ПК не установлен корневой сертификат (КС) Удостоверяющего центра. Это может быть по следующим причинам:

  • не установлен в соответствующую папку сертификат головного удостоверяющего центра минкомсвязи;
  • не установлен в соответствующую папку корневой сертификат удостоверяющего центра, изготовившего ЭЦП.

Для устранения ошибки нужно открыть документ и проверить ЭЦП, которая обозначена красным.

Далее двойным кликом мышки нужно открыть сертификат и сохранить его на рабочем столе или в любом удобном месте на ПК.

Затем сохраненный сертификат открывают и выбирают вкладку «‎Путь сертификации»‎.

Для установки сертификата нужно лишь открыть его и установить.

Если не открывается цепочка сертификатов, то нужно перейти во вкладку «‎Состав»‎ и «‎Доступ к информации о центре сертификации»‎.

Затем пользователь выделяет и копирует одну из ссылок, имеющих в окончании .cer/.crt, после чего вставляет ссылку в адресную строку используемого браузера и начинает скачивание КС.

После скачивания КС открывают и нажимают «‎Установить сертификат»‎.

Местом хранилища назначают ‎«‎Доверенные корневые центры сертификации»‎.

Следующий шаг — подтверждение установки КС.

Затем пользователь возвращается в рабочее окно 1С и нажимает на подпись-статус «‎ЭЦП не верна»‎. В открывшемся меню нужно выбрать ‎«‎Проверить ЭЦП»‎‎.

Если установка прошла без ошибок, то статус изменится на ‎«‎ЭЦП верна»‎.

Ошибка создания объекта сервером программирования объектов подписи

При подписании документов или при формировании запросов в разных информационных системах может возникнуть ошибка «‎‎Невозможно создание объекта сервером программирования объектов ЭЦП».

Решить проблему можно переустановкой КриптоПро или обновлением плагина для Криптопро. Если после переустановки ПО ошибка повторяется, то нужно зарегистрировать библиотеку capicom.

Для этого нужно:

  1. Скачать capicom.zip.
  2. Закрыть все рабочие окна в IE.
  3. Извлечь из архива файлы.
  4. Запустить из папки с файлами register.bat.

Если установка через архивы вызывает сложности, то можно установить capicom.dll вручную. Для этого пользователь должен:

  1. Скопировать файл capicom.dll в каталог операционной системы. При необходимости файл заменяют на новый.
  2. Через меню ‎«‎Пуск»‎‎ вызывают командную строку и вводят ‎«‎regsvr32 capicom.dll‎»‎.
  3. Нажимают ‎«‎ОК»‎‎.

После установки библиотеки нужно проверить ее наличие в надстройках IE. Для этого пользователь переходит в «‎Сервис»‎‎/‎«‎Свойства обозревателя»‎/‎«‎Программы»‎/«‎Надстройки»‎. В открывшемся окне нужно найти и включить capicom.dll.

Если после всех действий ошибка повторяется, то проблема кроется в блокировке работы ЭЦП системными службами. В этом случае необходимо отключить ‎брандмауэр windows‎ и ‎центр обеспечения безопасности‎. Делается это просто:

  1. Пользователь переходит в ‎«‎Панель управления»‎панель управления‎/‎«‎Администрирование»‎‎/«‎Службы»‎.
  2. В открывшемся списке нужно найти системные службы и щелкнуть по каждой двойным кликом мышки.
  3. В новом окне изменяют тип запуска на «‎Отключена»‎ ‎ и затем нажимают кнопку ‎«‎Остановить»‎‎.

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

ЭЦП попала в список отозванных

Ошибка «‎Ваш сертификат ключа подписи включен в список отозванных‎»‎ может возникать из-за закончившегося срока действия сертификата или из-за необходимости обновить список сертификатов на ПК.

Если срок действия ЭЦП еще не истек. то нужно:

  1. Скачать программу certsuniv.exe для автоматической установки списка отозванных сертификатов (wiki.7405405.ru/images/certsuniv.exe).
  2. Загрузить список отозванных сертификатов (ca.center-inform.ru/media/crl/center-inform.crl) головного удостоверяющего центра.

Также можно загрузить вручную список отозванных квалифицированных сертификатов ЭЦП (https://r77.center-inform.ru/crl/v5/center_inform_mskf.crl).

Для установки нужно:

  • В окне ‎сохранить‎ выбрать месторасположение «‎Рабочий стол»‎‎ или любое удобное место.

  • Правой кнопкой мышки кликнуть по файлу и выбрать «‎Установить список отзыва»‎.
  • Нажать последовательно ‎«‎Далее»‎/‎«‎Готово»‎/‎«‎Готово»‎.

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

Сертификат подписи не зарегистрирован

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

Для Сбербанк-АСТ

Чтобы зарегистрировать новый сертификат на ЭТП нужно:

  1. Нажать на главной странице «‎Участникам»‎ и ‎«‎Регистрация»‎.
  2. Нажать «‎Выбрать»‎ около пункта ‎«‎Регистрация нового сертификата»‎ и далее выбрать «‎Привязать сертификат»‎.
  3. В открывшемся окне выбрать «‎Новый сертификат ЭЦП»‎ и нажать «‎Заполнить форму»‎.
  4. Заполнить все поля формы.
  5. Нажать «‎Подписать и отправить»‎.

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

Для Национальной электронной площадки

Добавление нового сертификата может происходить двумя способами. Можно войти в личный кабинет используя логин и пароль или через личный кабинет Еиной Системы Идентификации и Аутентификации (ЕСИА). Далее перейти в «‎Мой кабинет»‎ и выбрать в ‎окне «‎Загрузка сертификатов»‎ новый сертификат ЭЦП.

Если по каким-то причинам вход в личный кабинет невозможен, то нужно:

  1. на главной странице ЭТП выбрать ‎ «‎Участникам»‎ и «‎Регистрация доверенности»‎.
  2. Заполнить предложенную форму с указанием нового логина и пароля.
  3. Выбрать новый сертификат ЭЦП и нажать «‎Отправить»‎.
  4. Дождаться письма на указанный электронный адрес со ссылкой для входа в личный кабинет.

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

Для РТС-Тендер

Привязка нового сертификата для личного кабинета в системе РТС-Тендер зависит от того имеет ли пользователь учетную запись в Единой Информационной Системе или нет.

Если у участника есть личный кабинет. то нужно выбрать в нем «‎Добавление нового сертификата»‎. Если личного кабинета нет, то пользователь должен:

  1. Перейти на главную страницу ЭТП и выбрать раздел  «‎44-ФЗ»‎ /«‎Участникам»‎.
  2. Нажать «‎Добавить пользователя»‎ или «‎Аккредитация»‎.
  3. Нажать «‎Подать запрос на добавление нового пользователя»‎.  ‎
  4. Заполнить форму заявки на добавление. где из списка закрытых ключей ЭЦП выбирают новый.
  5. Проверить указанный данные.
  6. Нажать «‎Отправить»‎ и подписать заявку новой ЭЦП.

При правильном заполнении данный заявка будет утверждена через 20-40 минут. Если после всех действий ЭЦП не работает, то лучше обратиться в службу технической поддержки.

Работа с электронной подписью обычно не вызывает затруднений, а все возникающие ошибки можно устранить самостоятельно. Часть проблем решается переустановкой программного обеспечения КриптоПро и обновлением списка сертификатов. А часть — повторной регистрацией сертификата ЭЦП в информационной или торговой системе, а также отправкой запроса на добавление нового пользователя. Если после всех произведенных действий ошибка повторяется, то нужно обратиться в поддержку пользователей используемой системы или удостоверяющего центра, т.к. проблема может крыться в неисправности подписи или ее носителя.

Является ли объектно-ориентированное программирование катастрофой на триллион долларов?

Старший инженер full-stack Илья Суздальницкий недавно опубликовал живое эссе из 6000 слов, в котором объектно-ориентированное программирование названо «катастрофой на триллион долларов». Драгоценное время и умственные способности тратятся на размышления об «абстракциях» и «шаблонах проектирования» вместо решения реальных проблем … Объектно-ориентированное программирование (ООП) было создано с единственной целью — управлять сложностью процедурных кодовых баз. Другими словами, предполагалось улучшить организацию кода . Нет объективных и открытых доказательств того, что ООП лучше простого процедурного программирования … Вместо того, чтобы уменьшить сложность, оно поощряет беспорядочное совместное использование изменяемого состояния и вносит дополнительную сложность с его многочисленными шаблонами проектирования . ООП делает обычные методы разработки, такие как рефакторинг и тестирование, излишне сложными …

Использование ООП кажется невинным в краткосрочной перспективе, особенно в проектах с нуля.Но каковы долгосрочных последствий использования ООП? ООП — это бомба замедленного действия, которая взорвется когда-нибудь в будущем, когда кодовая база станет достаточно большой. Проекты откладываются, сроки не соблюдаются, разработчики выгорают, добавление новых функций становится почти невозможным . Организация маркирует кодовую базу как « legacy codebase », а группа разработчиков планирует переписать . … ООП предоставляет разработчикам слишком много инструментов и вариантов выбора, не налагая нужных ограничений.Несмотря на то, что ООП обещает решить проблему модульности и улучшить возможность повторного использования, оно не выполняет своих обещаний …

Я не критикую ООП Алана Кея — он гений. Я бы хотел, чтобы ООП было реализовано так, как он это задумал. Я критикую современный подход Java / C # к ООП … Я думаю, что совершенно неверно, что ООП считается де-факто стандартом организации кода многими людьми, в том числе на очень высоких технических должностях. Также неверно, что многие основные языки не предлагают других альтернатив организации кода, кроме ООП.
Эссе в конечном итоге обвиняет Java в популярности ООП, цитируя комментарий Алана Кея о том, что Java «является самым неприятным явлением, которое случится с компьютерами со времен MS-DOS». Здесь также цитируется наблюдение Линуса Торвальдса о том, что «ограничение вашего проекта C означает, что люди не испортят ничего с какой-либо идиотской« объектной моделью »».

И в конечном итоге предлагает функциональное программирование как превосходную альтернативу, делая следующие утверждения о ООП:

  • «Код ООП поощряет использование разделяемого изменяемого состояния, которое снова и снова оказывается небезопасным… [E] nкапсуляция, по сути, является прославленным глобальным состоянием. «
  • » ООП обычно требует большого количества шаблонного кода (низкое отношение сигнал / шум). «
  • » Некоторые могут не согласиться, но, как известно, ООП трудно модульное тестирование … [R] Факторинг ООП-кода действительно сложно без специальных инструментов, таких как Resharper. «
  • » Невозможно написать хороший и поддерживаемый объектно-ориентированный код. «

Персональное программирование и объектный компьютер

Мы входим в подключенное общество.Все, каждый человек и каждый лок будут связаны с коммуникационной сетью. Некоторые из этих сетей будут изолированы; некоторые будут подключены через Интернет. Интернет вещей — это сеть физических устройств, транспортных средств, бытовой техники и других элементов, встроенных в электронику, программное обеспечение, датчики, исполнительные механизмы и средства связи, которые позволяют этим вещам обмениваться сообщениями. Footnote 19 Интернет с подключенными к нему IoT можно рассматривать как единый глобальный компьютер , состоящий из совокупности взаимодействующих объектов.Это артефакт, созданный аппаратным и программным обеспечением и не имеющий физического или логического центра. Эта единая глобальная машина все еще находится в зачаточном состоянии. Никто точно не знает, как он в конечном итоге будет выглядеть и для чего именно он будет использоваться. И никто не знает, поддастся ли он рано или поздно возрастающей тяжести собственной сложности.

Персональные распределенные вычисления

Понятие персональных распределенных вычислений не ново. В начале 1970-х годов проект Prokon был частью инициативы по созданию совместных рабочих структур с децентрализованным управлением и контролем в бизнес-организациях [6, 14]. Идея заключалась в том, чтобы отразить распределение ответственности и компетенций в организации в распределенной архитектуре ее информационной системы. Ближайшей целью было создание системы, которая поддерживала бы децентрализованное планирование при сохранении общего контроля . Проект представил видение каждого менеджера, владеющего персональным компьютером, который они использовали для своих личных задач и для общения с другими менеджерами (рис. 11). Менеджеры также делегировали часть своего однорангового общения на свой компьютер: Антон задает вопросы, запрашивает изменения или отправляет отчеты другим менеджерам.Когда компьютер Кари получает запрос или отчет, она может принять или отклонить его автоматически или дождаться личного вмешательства.

Рис. 11

Распределенные персональные компьютеры Prokon (на рисунке толстые прямые линии обозначают компьютерную связь, а тонкие линии обозначают человеческое общение. Рисунок скопирован из [14])

Одна из задач Антона — создать план для своего отдела и согласовать его с планами коллеги. У разных отделов разные обязанности: один может нести ответственность за проектирование детали, а другой — за ее производство.Они могут строить свои планы по-разному, но оба понимают логику своей программы личного планирования и в идеале сами пишут ее.

Время от времени менеджеры встречаются, чтобы согласовать свои индивидуальные планы. Их персональные компьютеры работают под столом на рис. 12 и обмениваются данными, чтобы поддержать своих владельцев, которые ведут переговоры лично над столом.

Рис. 12

Люди координируют свои планы, поддержанные их общающимися Локами

Главный спонсор проекта Prokon обанкротился, и проект был внезапно прекращен.

Одновременно с проектом Prokon разработки в Xerox PARC в 1970-е годы отличались творчеством, воздействием и финансированием. Footnote 20 Одним из первых инициаторов этого развития был Алан Кей с его идеями Dynabook [11, 12] и его концепцией объектной ориентации:

С компьютерной точки зрения Smalltalk — это рекурсия самого компьютера. Вместо того, чтобы разделять «компьютерный материал» на вещи, каждая из которых менее сильна, чем целое — например, структуры данных, процедуры и функции, которые являются обычными атрибутами языков программирования — каждый объект Smalltalk представляет собой рекурсию всех возможностей компьютера.Таким образом, его семантика немного похожа на тысячи и тысячи компьютеров, соединенных очень быстрой сетью. Таким образом, вопросы о конкретном представлении можно отложить почти на неопределенное время, потому что мы в основном озабочены тем, чтобы компьютеры вели себя надлежащим образом, и интересуемся конкретными стратегиями только в том случае, если результаты оказываются неверными или возвращаются слишком медленно.

Несмотря на то, что у него действительно благородные предки, вклад Smalltalk — это новая парадигма дизайна, которую я назвал объектно-ориентированной, для решения больших проблем профессионального программиста и решения мелких проблем для начинающего пользователя.Объектно-ориентированное проектирование — это успешная попытка качественного повышения эффективности моделирования все более сложных динамических систем и взаимоотношений с пользователями, ставшая возможной благодаря взрыву кремния [13].

Loke опирается на открытую структуру людей и сотрудничества Prokon, а также на объектную ориентацию Кея. Объекты Лока включают как вселенную объектов Squeak, так и объекты, найденные в Сети. Он заменяет компьютер фон Неймана объектным компьютером и делает его персональным, как смартфон.Результат — Локи: персональный объектный компьютер.

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

Концептуально Smalltalk (и Squeak) начал свое выполнение где-то в далеком прошлом, и мой экземпляр является ответвлением этого исполнения. Выполнение приостанавливается, когда я сохраняю свои объекты (мое изображение ) в файле, и возобновляется, когда я загружаю этот файл. Файл изображения может быть скопирован, и при загрузке этой копии начинается новая ветвь выполнения. Как следствие, Антон имеет не только свою личную копию программ, но и исключительное право собственности на свои личные объекты, программы и поток выполнения.

Концептуальная модель Локи и машина.

Лок был представлен во Введении как персональный компьютер, который является результатом слияния общих объектов единой глобальной машины с личными объектами вилки Smalltalk / Squeak. Рисунок 2 иллюстрирует объединенные объекты Локи; На рис. 13 представлена ​​более подробная картина.

Рис. 13

Я создал Loke, чтобы он был настолько интуитивно понятным, насколько это возможно, без потери выразительной силы, чтобы миллионы пользователей могли использовать его без предварительного формального обучения программированию.

Локи — это вселенная объектов и ничего, кроме объектов.

Каждый объект имеет неизменяемый глобально уникальный идентификатор.

Каждый объект характеризуется своим интерфейсом сообщений RESTful Footnote 21 .

Объект либо общий, либо личный.

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

Традиционный способ программирования с его записью кода, компиляцией, загрузкой и запуском заменен на выбор и изменение объектов Loke .В обычном, закрытом виде исходного кода нет.

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

DCI: парадигма программирования Локи

Когда Эллен программировала свой умный будильник в разд.2.1 она запустила часы с помощью команды меню, которая отправила сообщение роли таймера во взаимодействии. Это сообщение ознаменовало переход от одной системы координат к другой; От Squeak с его объектами, методами и классами до DCI с его контекстами, ролями и сценариями ролей. На рисунке 14 показано, как они образуют новые уровни абстракции над Squeak. Роль может отправлять сообщения только себе, ролям, с которыми она связана, и объекту, который она представляет. У объектов нет ссылок на роли, которые их играют.Эта ограниченная видимость является важной особенностью строгого разделения задач DCI, которое защищает Эллен от идиосинкразии Squeak и нижестоящих уровней программирования.

Рис. 14

Обменивающиеся роли в Loke находятся на новом уровне абстракции

Надежность, безопасность, конфиденциальность

Растет озабоченность по поводу надежности, безопасности и конфиденциальности информационных систем в целом и Интернета вещей в частности [ 9]. Мое понимание множества проблем и решений практически отсутствует, но я могу наблюдать за своим компьютером.Мое оборудование — это машина фон Неймана со своим процессором и памятью (рис. 1). Программа находится в памяти, а ЦП выполняет все, что там находит; мой компьютер изначально небезопасен. Я использую популярную операционную систему (ОС), которая имеет всего два уровня безопасности: User и System . Различные меры безопасности оборачивают мой компьютер фон Неймана и операционную систему уровнями защиты. Защита не может быть идеальной, поскольку новые исправления безопасности появляются почти каждую неделю. Слабость заключается в том, что злоумышленники находят бреши в защите и загрязняют память вредоносным кодом, который точно выполняется ЦП.

В качестве примера я однажды обнаружил, что компания X предлагает интересную программу для бесплатной пробной версии. В процессе загрузки моя ОС спросила: « Вы разрешаете X доступ к вашей системе? ». Мне пришлось ответить ДА, задавшись вопросом, почему X должно быть разрешено тайно внедрять какие-либо вредоносные программы в мою систему и почему менее полного разрешения может быть недостаточно. То, что у меня есть, — это внутренне незащищенный процессор с наивной с точки зрения безопасности ОС поверх него. Неудивительно, что так много компьютеров (включая мой) заражены троянами и другими вредоносными программами.(Альтернативой является, конечно, игнорирование увлекательных предложений программного обеспечения в сети.)

Локе идет к корню проблемы, заменяя компьютер ван Неймана более безопасной альтернативой объектному компьютеру. Loke разработан для работы на уровне абстракции непосредственно над оборудованием, а ансамбли взаимодействующих объектов заменяют ОС. Я определил природу объекта Loke во введении: « Как и компьютер, объект — это сущность, которая инкапсулирует состояние и поведение и имеет глобальную уникальную идентичность .«Инкапсуляция является ключевым моментом: она теоретически отделяет объект снаружи от его внутренней части. Снаружи — возможно невежественный или злой мир, который может получить доступ к объекту только через предоставленный ему интерфейс сообщений. Внутренняя часть может обрабатывать каждое входящее сообщение как внутреннюю последовательность сообщений, проходящих через ансамбль участвующих объектов. Инкапсуляция обеспечивает барьер безопасности в каждом объекте до тех пор, пока инкапсуляция является единственным путем извне внутрь. Рекурсия и защита заканчиваются, когда входящее сообщение обрабатывается другим способом.

Бран Селич прокомментировал предложение, выделенное курсивом выше:

Мы обсуждали это ранее: я не думаю, что вы представляете хороший аргумент в пользу безопасности в Локи, вот почему:

Большинство нарушений безопасности происходит не через API, а через черный ход к базовым машинам. Например, Антон мог (злонамеренно или непреднамеренно) настроить словарь ресурсов на вредоносное устройство, которое повреждает виртуальную машину Loke.

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

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

Я наивен и невежественен в этих вопросах, и аргументы Брана убедительны.Тем не менее, я не могу не задаться вопросом, есть ли пределы их действительности. В настоящее время я использую компьютер со многими установленными приложениями, которые разделяют большую часть своих поддерживающих аппаратных / программных уровней. Интересно, были бы угрозы такими же, если бы эти приложения были удаленными приложениями, которые использовали свои отдельные поддерживающие аппаратные / программные уровни? Другими словами: может ли добавление коммуникации к нашей модели вычислений уменьшить проблемы? (Я называю это переходом от парадигмы, ориентированной на ЦП, к парадигме, ориентированной на коммуникацию в Sect. 3.7.) Я надеюсь, что ответ положительный, когда я в Разд. 3.8 построить компьютер Loke как киоск, предоставляющий доступ к удаленным приложениям.

Я где-то читал, что все разработчики программ, связанных с Интернетом вещей, должны понимать вопросы конфиденциальности, безопасности и другие вопросы. Я верю, что у Эллен и Антонов в этом мире будет более чем достаточно собственных проблем, без принятия на себя проблем, которые должны были быть решены в инфраструктуре. Тем не менее, Loke должен уметь обрабатывать исключения, не запутывая своего владельца.Простое решение — сообщить пользователю в более или менее юмористической форме, что что-то пошло не так, прервать выполнение и отправить отчет об ошибке разработчику Loke. Так что Эллен может проснуться в 10 часов утра при ярком солнечном свете с сообщением об ошибке: Я не разбудил тебя, потому что что-то пошло не так .

Программирование мышлением

Предпосылкой для надежности программы является то, что программа делает то, что она должна делать, и ничего больше. Свою первую программу я написал в 1957 году на компьютере первого поколения.Мои программы состояли всего из нескольких строк двоичного кода. Однако программы были настолько сложными, что я не мог осмыслить их: они были нечитаемыми. Я приступил к своему первому крупному проекту программирования в 1960 году. Мой старый способ «программирование по вдохновению» явно должен был быть заменен чем-то лучшим. Поскольку у меня не было лучшего ума, мне пришлось взглянуть на свои программные привычки. Сначала я рассмотрел «программирование тестированием» и написал короткий цикл внутри цикла на обратной стороне конверта.Исчерпывающее тестирование всех возможных исполнений заняло бы несколько сотен лет, поэтому я быстро отказался от этого подхода. Footnote 22 и пришел к «программирование мышлением» :

«Любой метод, который мешает программисту писать код, является хорошим методом». Сноска 23

Эти соображения привели к простой архитектуре с четким разделением задач: центральная база данных, окруженная прикладными программами. Каждое приложение было далее разбито на небольшие подпрограммы в дереве вызовов.Теперь я мог обдумать все и каждую часть по отдельности. На этом фундаменте моя команда построила Autokon, программу сборки 50 000 линий для автоматизированного проектирования и производства судов. Впервые оно было развернуто в 1963 году и продано как программный продукт в 1965 году. Программное обеспечение было развернуто на множестве различных компьютеров на большинстве крупных верфей мира и имело относительно небольшое количество ошибок. С годами программа была расширена множеством новых прикладных программ с той же архитектурой.

Намного позже Эллен программирует свой умный будильник в соответствии с парадигмой DCI, парадигмой «программирования посредством мышления». Ее данные — это отдельные объекты, которые были разработаны независимо. Контексты с их ролями, сценариями ролей и взаимодействиями ортогональны данным. В своей магистерской диссертации Гектор А. Вальдекантос обнаружил, что парадигма программирования DCI с ее разделением задач помогает сделать код более понятным и, следовательно, более простым, чем сопоставимый код Java [19]. Другими примерами использования DCI для повышения простоты являются Bluemke [1] и программа со структурой DCI для управления выдачей книг в библиотеке. Footnote 24

В своей лекции о премии Тьюринга 1991 года Тони Хоар лаконично заявил о ценности простоты:

«Существует два способа создания проекта программного обеспечения: один способ — сделать его настолько простым, чтобы явно не было недостатков, а другой — сделать его настолько сложным, чтобы не было очевидных недостатков. Первый способ гораздо сложнее.”(Хоар [10])

Программирование в сотрудничестве

Партнерская проверка — это хорошо известный метод раннего обнаружения ошибок. Впервые я прочитал об этом в журнале Byte Magazine примерно за 1969 год. В статье приводился довод в пользу экспертной оценки кода как очень мощного метода устранения недостатков в программе, в то время как и авторы, и рецензенты кода учатся на собственном опыте. Footnote 25 На момент написания статьи о Byte моя команда создавала небольшую программу с архитектурой, ориентированной на базы данных, и приложениями, написанными на Fortran. В ходе реализации проекта проводились еженедельные совещания о ходе выполнения, что обеспечивало усвоение всей командой текущей версии схемы базы данных и дерева вызовов программы.

Единицей проверки была подпрограмма: команда назначила подпрограмму члену группы, который разработал ее, написал код и пропустил через компилятор для удаления синтаксических ошибок. Затем процедура вернулась к совещанию о ходе работы, которое поручило ее другому члену команды для проверки. Команда терпела и даже ожидала, что люди будут делать ошибки при кодировании.Они также ожидали, что рецензент найдет их все. Следовательно, рецензент несет полную ответственность за правильность кода, а автор не участвует в работе. При модульном тестировании в 3 из 4 подпрограмм не было обнаружено никаких недостатков. В остальных подпрограммах были только мелкие ошибки. Во время тестирования системы или за время существования программы дефектов обнаружено не было. Footnote 26 Процесс с его коллегиальной проверкой был довольно трудоемким с еженедельными совещаниями о ходе выполнения, обзорами и модульными тестами. У многих проектов нет времени и человеческих ресурсов для таких сложных процессов разработки, но они находят время для длительного тестирования и доработки.

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

Программная инженерия — исключительная отрасль инженерии. Техническая документация обычно сопровождается как минимум двумя подписями: Создано (дата и инициалы) и Проверено (дата и инициалы) .Объектно-ориентированные программы могут иметь первую сигнатуру, но они нечитаемы и не могут быть проверены. Чтобы процитировать книгу Design Patterns [7] с. 22:

Структура времени выполнения объектно-ориентированной программы часто мало похожа на структуру ее кода. Структура кода замораживается во время компиляции; он состоит из классов с фиксированными отношениями наследования. «Структура времени выполнения состоит из быстро меняющихся сетей взаимодействующих объектов… Ясно, что код не раскрывает всего, как система будет работать».

Следствием этого пугающего наблюдения является то, что массовым программистам остается «Программирование путем тестирования» в качестве стандартного способа программирования. Более того, их код не раскрывает всего, как их система будет работать.

Сегодня, примерно через 50 лет после моего первого опыта, проверка кода снова стала возможной, и было бы интересно использовать ее для решения реальной проблемы. Теперь у нас есть две абстракции объектов, позволяющие идентифицировать фрагменты кода для проверки. Абстракция класса дает фрагменты кода для данных, т.е.е., автономные объекты. Ортогональная абстракция ролей дает независимые блоки кода для абстракции ролей, то есть поведения системы. Рецензирование снова возможно. Дейкстра выразился так (Дейкстра [4]):

Если вам нужны более эффективные программисты, вы обнаружите, что им не следует тратить свое время на отладку, они не должны с самого начала вводить ошибки.

Если мы перейдем от кодирования к программированию, сфера наших интересов станет намного шире.Среди прочего в него вошли стейкхолдеры:

Заинтересованное лицо — это лицо, заинтересованное или озабоченное чем-то, особенно бизнесом. Заинтересованное лицо — это кто-то, кто может быть:

  • Использование системы

  • Поддержка системы

  • Получение преимуществ от системы.

  • Организация или лицо, оплачивающее систему Сноска 27

Этот широкий взгляд на процесс программирования выходит за рамки данной статьи, и я отсылаю заинтересованных читателей к Коплиену [2].

Нам нужна смена парадигмы

История западной астрономии показывает серию смены парадигмы от геоцентрической парадигмы с ее неподвижной Землей как центром Вселенной с ее существенными сложностями. Footnote 28 Астрономия эволюционировала через гелиоцентрическую парадигму до нынешней распределенной парадигмы, в которой куски массы связаны гравитацией. То, что казалось существенной сложностью в одной парадигме, легко разрешалось в следующей.

Заманчиво поискать аналогичные сдвиги парадигмы в вычислениях.Мейнстримное программирование основывает большую часть своей теории и практики на парадигме, ориентированной на ЦП, примером которой является машина фон Неймана. Для меня парадигма, ориентированная на память, появилась в 1960 году с центральной базой данных Autokon [14]. Решение было очевидным, и, должно быть, было много подобных инициатив, о которых я не знал.

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

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

Рис. 15

Три парадигмы вычислений

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

Парадигма, ориентированная на общение, появилась на горизонте уже много лет. Я впервые встретил это в идее Прокона о распределенных компьютерах [15], но, должно быть, было много других инициатив. Более новым примером является Service Ориентированная архитектура (SOA) , которая, по сути, ориентирована на коммуникации. Он не увенчался немедленным успехом, возможно, потому, что люди пытались применить его в рамках парадигмы, ориентированной на ЦП, где ему не место. Есть много других примеров, таких как распределенные вычисления. Footnote 29 И, конечно же, DCI и сам IoT по определению ориентированы на коммуникации.

Мечта о компьютере Loke

Первоначальная идея заключалась в том, что компьютер Loke должен быть частью оборудования, которое, как Dynabook Алана Кея [11, 12], должно удовлетворять все вычислительные потребности его владельца. Компьютер должен был быть автономным и включать аппаратное и программное обеспечение, необходимое для работы персонального компьютера Локи. Я отказался от этой идеи. Потенциальные пользователи, такие как Эллен, зависят от ее смартфона в повседневной жизни.Она использует его для многих целей, начиная от оплаты продуктов и заканчивая поиском значения слова astrobleme . Невозможно перепрограммировать все эти службы на специальном устройстве Loke. Следовательно, первое устройство Loke должно быть похоже на существующее интеллектуальное устройство, дополненное Loke.

Эллен владеет множеством устройств, и она хочет запустить свою локу на всех из них. Поэтому Loke следует развернуть как удаленное приложение на подходящем сервере:

Удаленное приложение — это решение для доставки приложений, в котором фактическое приложение устанавливается на центральном сервере и используется с удаленного устройства.Конечный пользователь получает снимки экрана приложения, в то же время имея возможность вводить данные с клавиатуры, большого пальца и мыши. У удаленных приложений много названий: удаленное приложение, серверно-клиентские приложения, удаленное взаимодействие приложений, виртуализация приложений и виртуальные приложения. Протокол RDP — один из наиболее популярных протоколов, используемых для передачи данных из приложения, размещенного в центре обработки данных, на удаленные устройства. Сноска 30

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

«Программное обеспечение киоска — это программное обеспечение системы и пользовательского интерфейса, разработанное для интерактивного киоска или Интернет-киоска, которое включает систему таким образом, чтобы предотвратить взаимодействие пользователя и действия на устройстве, выходящие за рамки выполнения программного обеспечения». Footnote 31

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

Для устройства Loke требуется только минимальная операционная система, такая как микроядро. Footnote 32 или сам Squeak. Это значительно снизит его уязвимость для злонамеренных атак, равно как и барьеры безопасности между киоском и удаленными приложениями. Устройство Локэ представляет собой оболочку; все происходит где-то еще.

Обучение детей программированию

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

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

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

Программирование умного будильника Эллен — это простой пример, иллюстрирующий фундаментальные концепции Локи в простой презентации.Другая крайность — презентация TED Ханса Рослинга: Лучшая статистика, которую вы когда-либо видели, . Footnote 34 Рослинг создал эту презентацию путем объединения доступной мировой статистики со сложными графическими инструментами представления. Такой эксперт, как Антон, должен быть в состоянии составить аналогичную презентацию из тех же ресурсов в его Локе, таким образом узнавая о мире через изучение официальной статистики.

Разработчикам школьных программ будет предложено новое измерение в обучении: обучение путем моделирования и исследования [11, 12].

Объектно-ориентированное программирование в разработке программного обеспечения систем управления

Введение

Хотя объектно-ориентированное программирование (ООП) находилось в зачаточном состоянии, оно проникло в основные приложения информационных технологий (ИТ) к середине 1980-х годов. Десять лет спустя ООП проникло в приложения для разработки программного обеспечения систем управления множеством коммерчески доступных библиотек и приложений. Очень популярное воплощение этих объектно-ориентированных приложений для управления процессами представляет собой технологию клиент / сервер OPC.Эти приложения используют OPC как основанный на стандартах механизм связи. Методологии ООП сыграли ключевую роль в быстром внедрении технологии OPC. Благодаря широкому распространению OPC упрощает абстракцию компонентов систем управления, таких как DCS (Honeywell, Emerson, Yokogawa и т. Д.), PLC (Rockwell, Siemens, Triconex и т. Д.), Историков процессов (AspenTech, Microsoft, OSI и т. Д.) И многих других. другие.

Методология процедурного программирования

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

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

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

Методология объектно-ориентированного программирования

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

Используя методы проектирования ООП, архитектор программного обеспечения может абстрагировать проблемную область с помощью набора объектов. Каждый объект полностью инкапсулирует часть проблемы программного обеспечения. Например, если поставщик хотел разработать программное приложение, такое как сервер Matrikon OPC для Bailey Infi90, которое абстрагирует распределенную систему управления, каждый объект функционального блока может иметь несколько объектов атрибутов.Затем эти объекты можно было бы повторно использовать для создания программного приложения, которое абстрагирует отдельную DCS, или даже ПЛК, такого как OPC-сервер Matrikon для Triconex Tricon. Как только проблема будет решена, объекты можно будет повторно использовать для решения других программных проблем.

Методы

ООП представляют сущности в проблемной области с объектами в коде. Эта абстракция может помочь в концептуализации программы и взаимодействии разработчиков между собой. Одним из преимуществ выбора ООП является возможность использовать инструменты автоматизированной разработки программного обеспечения (CASE) в процессе проектирования и расширения. Обычно инструменты CASE позволяют разработчику быстро спроектировать и зафиксировать архитектуру продукта, используя стандартный язык моделирования «Унифицированный язык моделирования (UML)». Наличие стандартизированной системы описания проектов программного обеспечения позволяет инженерам-программистам из любой точки мира обмениваться проектами без необходимости сначала объяснять, каковы соглашения о моделировании.

Преимущества ООП

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

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

Программное обеспечение ООП и системы управления

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

Продукты, использующие методологию ООП, позволяют клиентам легко расширять базовые объекты в соответствии с конкретными потребностями клиента. Например, Matrikon OPC Genie (Generic Information Exchange) позволяет пользователю создавать объект протокола, который инкапсулирует настраиваемый протокол для создания настраиваемого сервера OPC. Компании, использующие объектно-ориентированные структуры, могут быстро создавать программное обеспечение, используя существующий код ООП. Использование базы кода объектно-ориентированного программного обеспечения позволяет таким компаниям, как Matrikon, создавать собственные программные приложения быстро и экономично.

Межпроизводственные решения — это побочный эффект объектно-ориентированных методологий проектирования. Технология, которая произвела революцию в разработке и внедрении программного обеспечения систем управления, — это OPC. OPC позволяет преобразовать любой источник данных в системе управления в простое приложение. OPC определяет набор интерфейсов, которые описывают, как приложения системы управления могут взаимодействовать. Основа OPC состоит из сотен поставщиков (часто конкурентов). Члены фонда OPC работают вместе над развитием спецификаций OPC.Можно утверждать, что обучение ООП, распространенное в членских организациях, позволило фонду быстро адаптировать спецификации к потребностям потребителей технологии. Типичное собрание спецификаций OPC включает в себя инженеров из многих разных частей мира, работающих вместе с использованием UML и объектно-ориентированных технологий для сбора и развития спецификаций. OPC Foundation предоставляет примеры объектных архитектур, которые можно использовать в качестве основы для разработки OPC, тем самым облегчая распространение технологии OPC.

ООП в будущем

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

Методики ООП

имеют много преимуществ (как упоминалось в этой статье). Некоторые из недостатков методологий ООП заключаются в том, что объектные модели могут очень быстро усложняться. Программное обеспечение становится все более сложным. Процедурное программирование подходило для небольших систем; ООП, возможно, хорош для больших систем. А как насчет очень больших систем? Когда-то 640k памяти казались чрезвычайно большим объемом памяти. Размер системы является относительной мерой. ООП, возможно, переживает свой век, когда системы измеряются количеством компьютеров (как в случае со многими решениями на основе OPC), а не объемом памяти. Следующей может быть методология сервисно-ориентированного программного обеспечения (тема для другой статьи). Дело в том, что методологии будут приходить и уходить. ООП решило многие проблемы, которые преследовали предыдущие методологии.

Заключение

ООП обеспечила быстрый рост внедрения и развертывания программного обеспечения систем управления. Быстрое внедрение OPC — хороший пример некоторых преимуществ подхода ООП. Технологии ООП позволили разработчикам программного обеспечения вставить слово «продвинутый» во фразу «управляющие приложения».Это также способствовало быстрой эволюции программного обеспечения для управления процессами. Без экономической выгоды от создания повторно используемого кода у поставщиков не было бы мотивации расширять технологический диапазон, как они это сделали. Программисты Process Control сделали все возможное, чтобы сделать возможным сборку лучших в своем классе систем с использованием OPC. Теперь фокус смещается на интеграцию решения.

###

Matrikon Inc.

10405 Джаспер Авеню

Эдмонтон, Альберта, Канада

T5J 3N4

Дополнительные ресурсы:

Matrikon OPC: www.matrikon.com/opc

Мультимедийное руководство: www.matrikon.com/tutorial

Ваш код: OOP или POO?

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

Возможно, Пол Грэм лучше всего резюмировал это:

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

Эрик Липперт наблюдал аналогичный профессиональный риск среди разработчиков. Он называет это объектным счастьем.

То, что я иногда вижу, когда беру интервью у людей и просматриваю код, — это симптомы болезни, которую я называю объектным счастьем. Объект Счастливые люди чувствуют необходимость применять принципы объектно-ориентированного дизайна к небольшим, тривиальным, одноразовым проектам.Они тратят много ненужного времени на создание чистых виртуальных абстрактных базовых классов — на написание программ, в которых IFoo взаимодействуют с IBars, но существует только одна реализация каждого интерфейса! Я подозреваю, что раннее знакомство с принципами объектно-ориентированного дизайна в отрыве от любого практического контекста, который мотивирует эти принципы, приводит к объектному счастью. Люди уходят как ОО Истинно Верующие, а не ОО-прагматики.

Я видел так много проблем, вызванных чрезмерным рабским соблюдением ООП в производственных приложениях.Не то чтобы объектно-ориентированное программирование — это плохо по своей природе, заметьте, но небольшое ООП имеет очень большое значение . Добавление объектов в код похоже на добавление соли в блюдо: добавьте немного, и это будет пикантная приправа; добавить слишком много, и это полностью испортит еду. Иногда лучше ошибиться в сторону простоты, и я предпочитаю подход, который приводит к меньше кода , а не больше .

Учитывая мою двойственность во всем, что касается объектно-ориентированного программирования, меня позабавило, когда Джон Гэллоуэй переслал мне ссылку на веб-страницу Патрика Смаккиа.Патрик — французский разработчик программного обеспечения. Очевидно, аббревиатура объектно-ориентированного программирования на французском пишется немного иначе, чем на английском: POO.

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

Но код POO может иметь другое, более конструктивное значение. Автор этого блога утверждает, что ООП бледнеет по важности для POO. То есть программирование для других.

Проблема в том, что программистов учат тому, как писать объектно-ориентированный код и как это улучшить ремонтопригодность их кода.И под словом «учил» я не имел в виду просто «взял пару классов». Я имею в виду: забили себе голову в школе, провели годы в качестве профессионала под наставничеством старшего ОО. «архитекторы» и только потом, наконец, понимают, как правильно пользоваться, иногда. Большинство инженеров не стали бы рассматривать использование языка, отличного от объектно-ориентированного, даже если бы он имел потрясающие функции. Шумиха такова.

Итак, что же тогда обо всем, что программисты пишут до того, как закончится 10-летнее обучение в объектно-ориентированной среде? Он просто обречен на отстой? Конечно, нет, если они применяют другие техники, кроме ОО. Эти методы существуют, но не так широко обсуждаются.

Улучшение [я предлагаю] не имеет ничего общего с какой-либо конкретной техникой программирования. Это больше вопрос сочувствия; в данном случае — сочувствие к программисту, которому, возможно, придется использовать ваш код. Автор этого кода на самом деле продумывал, какие ошибки мог бы сделать другой программист, и стремился заставить компьютер сказать программисту, что он сделал не так.

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

Принципы объектно-ориентированного программирования гораздо важнее, чем бездумное создание объектов с помощью роботов повсюду:

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

Объектно-ориентированная база данных: объяснение + преимущества и недостатки

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

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

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

Давайте посмотрим на пример.Предположим, мы сохраняем конкретный объект велосипеда как объектно-ориентированную единицу со всеми его свойствами и методами. Он красный, на нем можно ездить, у него есть седло и так далее. Этот объект одновременно является частью класса «Велосипеды». Например, внутри одного класса мы можем найти синий и зеленый велосипед. Класс «Велосипеды», в свою очередь, является подкатегорией «Транспортные средства», которая также содержит «Автомобили». Но в то же время объект также имеет отношение к классу «Активный отдых».Если мы получаем наш объект по его уникальному идентификатору, все связанные с ним атрибуты и методы становятся доступны напрямую.

Глубокая история ваших приложений: Стив Джобс, NeXTSTEP и раннее объектно-ориентированное программирование

С 2008 года более ста миллиардов приложений было загружено из Apple App Store на iPhone или iPad пользователей. Тысячи разработчиков программного обеспечения написали эти приложения для мобильной платформы Apple iOS. Однако технологии и инструменты, которые привели к революции мобильных приложений, сами по себе не новы, а имеют долгую историю, охватывающую более тридцати лет, которая связана не только с NeXT, компанией, которую Стив Джобс основал в 1985 году, но и с ее истоками. программной инженерии и объектно-ориентированного программирования в конце 1960-х.

NeXT Cube (1990) был шедевром инженерной мысли… но слишком дорогим. NeXT превратилась в софтверную компанию после того, как Cube и несколько других аппаратных продуктов NeXT потерпели неудачу на рынке. Самым большим нововведением NeXT стала операционная среда NeXTSTEP. CHM № 102626734

Apple iOS основана на операционной системе Mac OS X для настольных ПК. Что еще более важно, комплект разработчика программного обеспечения (SDK) iOS, известный как «Cocoa Touch», основан на тех же принципах и основах, что и SDK Mac OS X для настольных ПК, Cocoa.(SDK — это набор инструментов и программных библиотек, которые разработчики приложений используют для создания своих приложений. Обычно они представлены в форме прикладных программных интерфейсов или «API-интерфейсов», которые представляют собой интерфейсы или «вызовы» функций, предоставляемых встроенными в платформу -в библиотеках.) OS X и Cocoa, которые были впервые выпущены в марте 2001 г., в свою очередь, были основаны на среде разработки и эксплуатации NeXTSTEP (изначально заглавной буквы «NeXTStep»). NeXT был основан Стивом Джобсом после ухода из Apple после того, как его лишили власти после попытки переворота в совете директоров.Компьютеры NeXTSTEP и NeXT были современными, но они были слишком дорогими для образовательного рынка, на который нацелился NeXT.

В связи с падением бизнеса в области аппаратного обеспечения к 1993 году NeXT была вынуждена закрыть свой завод, став компанией-разработчиком программного обеспечения, специализирующейся на разработке индивидуальных приложений для предприятий. Платформа разработки NeXTSTEP, переименованная в OpenStep, была перенесена на другое оборудование и другие операционные системы, включая процессоры Intel и рабочие станции Sun.

В 1996 году Apple сама оказалась в тяжелом положении, и ей нужно было заменить устаревшую Mac OS на более современную и надежную операционную систему.Не сумев создать свою собственную, Apple приобрела NeXT, чтобы сделать NeXTSTEP основой для того, что в конечном итоге стало Mac OS X. В январе 1997 года на ежегодной торговой выставке Macworld Expo Стив Джобс триумфально вернулся на сцену в качестве первого сотрудника Apple. время с 1985 года, на этот раз, чтобы объяснить, что, по его мнению, нужно Apple, чтобы выжить и снова стать великим, и как технология NeXTSTEP может помочь Apple в этом.

Видео: Джобс демонстрирует OpenStep, MacWorld Expo, январь 1997 г.

В этой короткой 20-минутной презентации на MacWorld Expo в январе 1997 года Джобс продемонстрировал технологию, которая станет Cocoa, системой разработки программного обеспечения, которая в конечном итоге будет использоваться тысячами разработчиков приложений для iOS по всему миру.Стив Джобс показывал разработчикам Apple, как будет выглядеть их будущее, которое, действительно, сегодняшние разработчики iOS сочли бы удивительно похожим на их повседневный опыт. На самом деле, то, что Джобс показывал разработчикам Apple в 1997 году, не было новым, но было выпущено NeXT почти десятилетием раньше, в 1988 году.

Персонал

PARC, возглавляемый научным сотрудником CHM Робертом Тейлором, был одним из ведущих компьютерных ученых того времени (среди них были сотрудники CHM Чак Такер, Батлер Лэмпсон, Боб Меткалф, Линн Конвей, Чарльз Гешке и Джон Варнок. Сотрудник CHM Алан Кей. Кей предвидел «Dynabook», компьютер, похожий на планшет, который станет динамичным средством обучения. Текер и Лэмпсон разработали с использованием технологий, доступных в то время, «промежуточный» Dynabook, который мог бы частично сделать настоящий компьютер Кея. идеи.Результатом стала Alto, персональная рабочая станция, разработанная для одного пользователя, работающая с первым в мире графическим пользовательским интерфейсом (GUI) с окнами, значками и меню, управляемыми с помощью мыши. Xerox Alto, который посетители могут увидеть на выставке CHM’s Revolution, и большая часть исходного кода которого CHM опубликовал для публики, был прародителем того, как почти все пользователи настольных компьютеров сегодня взаимодействуют со своими компьютерами.

Xerox Alto CHM # 102626737, 102656238, X1741.99C, X1741.99D, X124.82C

Во время демонстрации MacWorld 1997 года Джобс показал, что в 1979 году он фактически пропустил мельком две другие технологии PARC, которые имели решающее значение для будущего. Одним из них было повсеместное сетевое взаимодействие между персональными компьютерами, которое Xerox установила с Ethernet, который она изобрела, на каждой из своих рабочих станций Alto. Другой была новая парадигма программирования, которую Алан Кей назвал «объектно-ориентированным программированием». Кей, работая с Дэном Ингаллсом и Адель Голдберг, разработал новый язык программирования и среду разработки, которые воплотили эту парадигму, работая на Alto.Кей назвал систему «Smalltalk», потому что он хотел, чтобы она была достаточно простой для использования детьми. Программа будет состоять из «объектов», моделирующих вещи в реальном мире, таких как «Животное» или «Транспортное средство». Это отличалось от традиционного «процедурно-ориентированного» (или «процедурного») программирования, где подпрограммы («процедуры») оперируют входными данными, каждая из которых хранится отдельно. В Smalltalk объекты состоят из данных, сгруппированных вместе с подпрограммами («методами»), которые работают с этими данными. Кей представил программу как динамическую систему объектов, отправляющих сообщения друг другу.Объект, получающий сообщение, будет использовать его для выбора, какую из множества подпрограмм или методов запустить. Одно и то же сообщение, отправленное разным объектам, приведет к тому, что каждый принимающий объект будет выполнять свою собственную процедуру, каждый из которых отличается от других. Например, объект Dog и объект Cat будут по-разному реагировать на сообщение «Speak»; Собака запускала метод «Лая», а Кот — метод «Мяу».

Среда разработки

Smalltalk была графической, с окнами и меню.Фактически, Smalltalk был точным графическим интерфейсом пользователя, который Стив Джобс увидел в 1979 году. Графический интерфейс Smalltalk состоял именно из такого набора взаимодействующих объектов, который мы обсуждали. Например, объекту Window может быть отправлено сообщение «Draw», которое он будет пересылать всем объектам внутри него, включая кнопки и слайдеры. У каждого из этих объектов будет свой собственный метод рисования. Во время визита Джобса в PARC он был настолько увлечен поверхностными деталями графического интерфейса пользователя, что полностью пропустил радикальный способ его создания с помощью объектов.В результате программирование графических приложений на Macintosh стало намного сложнее, чем при помощи Smalltalk. Как сказал Джобс в своем представлении NeXT Computer в 1988 году: «Macintosh произвел революцию, упростив жизнь конечному пользователю. Но разработчик программного обеспечения заплатил цену … Разрабатывать программное обеспечение … для Macintosh … если вы посмотрите на время, необходимое для создания [графического интерфейса] приложения … пользовательский интерфейс занимает 90% времени ».

Графический интерфейс пользователя (GUI) Smalltalk-80 и среда разработки, около 1980 г., любезно предоставлено библиотекой PARC

В компьютере NeXT Джобс планировал исправить именно этот недостаток Macintosh. Технологии PARC, отсутствующие в Mac, станут центральными функциями NeXT. Компьютеры NeXT, как и другие рабочие станции, были разработаны для работы в постоянно подключенной к сети среде. Джобс назвал это «межличностными вычислениями», хотя это было просто переименование того, что из Xerox Такер и Лэмпсон назвали «персональными распределенными вычислениями». Точно так же динамическое объектно-ориентированное программирование на модели Smalltalk послужило основой для всей разработки программного обеспечения на NeXTSTEP. По словам Джобса в 1988 году, NeXTSTEP сократит время разработчика на создание пользовательского интерфейса приложения с 90% до 10%.Однако вместо использования Smalltalk NeXT выбрала Objective-C в качестве языка программирования, который обеспечил бы техническую основу для успеха NeXT и программных платформ Apple в следующие два десятилетия и далее. Objective-C по-прежнему используется Apple сегодня для разработки iOS и OS X, хотя в 2014 году Apple представила свой новый язык Swift, который однажды может заменить его.

Objective-C был создан в 1980-х Брэдом Коксом для добавления объектной ориентации в стиле Smalltalk к традиционным, ориентированным на процедуры программам на языке C. 1 У него было несколько существенных преимуществ перед Smalltalk. Программы, написанные на Smalltalk, не могут быть автономными. Для запуска программы Smalltalk должны были быть установлены вместе со всей средой выполнения Smalltalk — виртуальной машиной, очень похожей на современные программы Java. Это означало, что Smalltalk был очень ресурсоемким, использовал значительно больше памяти и работал часто медленнее, чем сопоставимые программы на C, которые могли работать сами по себе. Также как и Java, программы Smalltalk имели свои собственные соглашения о пользовательском интерфейсе, которые выглядели и ощущались иначе, чем другие приложения в собственной среде, в которой они выполнялись.(Udell, 1990). Реализовав заново идеи Smalltalk на C, Кокс позволил программистам Objective-C организовать архитектуру своих программ с использованием абстракций Smalltalk более высокого уровня, одновременно отрегулировав критически важный для производительности код в процедурном C, что означало, что Objective-C Программы на C могли работать так же быстро, как и традиционные программы на C. Более того, поскольку их не нужно было устанавливать вместе с виртуальной машиной Smalltalk, их объем памяти был сопоставим с объемом памяти программ на языке C, и, будучи полностью встроенным в платформу, выглядел бы так же, как и все другие приложения в системе.(Cox, 1991) Еще одним преимуществом было то, что программы Objective-C, будучи полностью совместимыми с C, могли использовать сотни библиотек C, которые уже были написаны для Unix и других платформ. Это было особенно выгодно для NeXT, потому что NeXTSTEP, основанный на Unix, мог получить преимущество над программами, которые могли работать на нем. Разработчики могут просто «обернуть» существующую базу кода C новым объектно-ориентированным графическим интерфейсом пользователя и получить полнофункциональное приложение. Гибридный характер Objective-C позволил программистам NeXT получить лучшее из мира Smalltalk и C.

Какую ценность будет иметь эта комбинация для разработчиков программного обеспечения? Еще в 1960-х компьютерные профессионалы жаловались на «программный кризис». Широко распределенный график предсказывал, что стоимость программирования превзойдет стоимость оборудования, поскольку программное обеспечение становится все более сложным. (Slayton, 2013, стр. 155–157). Как известно, проект IBM OS / 360 был доставлен с опозданием, превышал бюджет и содержал ужасные ошибки. (Ensmenger, 2010, стр. 45–47, 205–206; Slayton, 2013, стр. 112–116) IBM подготовила отчет, в котором утверждалось, что лучшие программисты были в 25 раз производительнее среднего программиста.(Ensmenger, 2010, стр. 19). Программисты, часто оптимизирующие машинный код с помощью хитрых приемов для экономии памяти или времени, считались практиками «черного искусства» (Ensmenger, 2010, стр. 40), и поэтому ими невозможно было управлять. Беспокойство было настолько велико, что в 1968 году НАТО созвала конференцию компьютерных ученых в Гармише, Швейцария, чтобы посмотреть, можно ли превратить программирование в дисциплину, больше похожую на инженерию. После провала OS / 360 сотрудник CHM Фред Брукс, менеджер IBM, отвечающий за OS / 360, написал основополагающий текст в области разработки программного обеспечения — «Мифический человеко-месяц». В нем Брукс классно изложил то, что стало известно как закон Брукса: после того, как команда разработчиков программного обеспечения достигает определенного размера (и, следовательно, по мере увеличения сложности программного обеспечения), добавление дополнительных программистов фактически увеличивает стоимость и задерживает его выпуск. Программное обеспечение, как утверждает Брукс, лучше всего разрабатывать в небольших «хирургических» группах, возглавляемых главным программистом, который отвечает за все архитектурные решения, а подчиненные выполняют реализацию. (Брукс, 1995)

К 1980-м годам проблемы стоимости и сложности программного обеспечения оставались нерешенными.Оказалось, что индустрия программного обеспечения может находиться в постоянном кризисе. В 1986 году Брукс пересмотрел свою диссертацию и заявил, что, несмотря на скромные выгоды от улучшенных языков программирования, не существует единой технологии, никакой «серебряной пули», которая сама по себе могла бы повысить производительность программиста на порядок — 10-кратное улучшение, которое могло бы поднять рядовых программистов до уровня исключительных. (Брукс, 1987) Брэд Кокс умолял не согласиться. Кокс утверждал, что объектно-ориентированное программирование можно использовать для создания библиотек программных объектов, которые разработчики затем могут покупать в готовом виде, а затем легко комбинировать, как набор Lego, для создания программ в кратчайшие сроки.Так же, как взаимозаменяемые части привели к первоначальной промышленной революции, рынок готовых программных объектов многократного использования приведет к промышленной революции программного обеспечения. (Cox, 1990a, 1990b) Язык Objective-C Кокса был испытательной площадкой для именно такого видения, и Кокс основал компанию Stepstone, чтобы продавать библиотеки объектов другим разработчикам.

Стив Джобс и его инженеры из NeXT увидели, что видение Кокса в значительной степени совместимо с их собственным, и лицензировали Objective-C от Stepstone.Stepstone, а позже и инженер NeXT Стив Нарофф проделали тяжелую работу по модификации языка и компилятора для нужд NeXT. 2 Но вместо того, чтобы покупать библиотеки у Stepstone, NeXT разработала свой собственный набор объектных библиотек с использованием Objective-C и объединила эти «Наборы» с операционной системой NeXTSTEP как часть своей среды разработки программного обеспечения. Центральной библиотекой графического пользовательского интерфейса, которую все разработчики NeXT использовали для создания своих приложений, была ApplicationKit или AppKit.Вместе с AppKit компания NeXT создала визуальный инструмент под названием «Interface Builder», который дал разработчикам возможность графически соединять объекты в своих программах.

В рамках своей презентации MacWorld 1997 года Джобс продемонстрировал, насколько легко можно создать приложение с помощью Interface Builder — процесса, знакомого сегодня любому разработчику iOS. Джобс просто перетаскивал текстовое поле и ползунок из палитры в окно, а затем перетаскивал из ползунка в текстовое поле, чтобы установить «соединение», выбрав команду для одного объекта для отправки другому.В результате текстовое поле теперь было подключено к ползунку, отображая в реальном времени числовое значение от 1 до 100, которое представляло положение ползунка. Джобс продемонстрировал все это, не написав ни единой строчки кода, доведя до конца свою точку зрения: «Строка кода, которую разработчик может написать быстрее всего… поддерживать самую дешевую… которая никогда не ломается для пользователя, — это строка кода, которую разработчик никогда не использовал. написать.» Сегодня AppKit по-прежнему является основной платформой приложений в OS X, а UIKit iOS в значительной степени смоделирован на нем.Интерфейсный редактор тоже все еще существует как часть интегрированной среды разработки Apple Xcode (IDE).

Комбинация Objective-C, AppKit и Interface Builder позволила Стиву Джобсу похвастаться тем, что NeXTSTEP может сделать разработчиков в пять-десять раз более продуктивными — именно такой порядок улучшения, который, как утверждал Брукс, не может быть достигнут. Джобс предположил, что его аудитория на Macworld в 1997 году была знакома с Бруксом. «Вы все читали мифический человеко-месяц », — сказал он аудитории.«По мере того, как ваша команда разработчиков программного обеспечения становится больше, она как бы рушится под собственным весом. Подобно деревянному зданию, вы не можете построить деревянное здание такой высоты ».

Используя эту метафору здания, Джобс блестяще объяснил сравнительные преимущества AppKit от NeXTSTEP. Он утверждал, что программирование для DOS равносильно началу работы с первого этажа, и разработчик приложения может добавить три этажа функциональности, чтобы достичь четырех этажей возможностей. Классическая Mac OS с API Toolbox фактически подняла фундамент на пятый этаж, позволяя разработчику достичь восьми этажей функциональности.Это, по словам Джобса, позволило создать такие потрясающие приложения, как Pagemaker на Mac (1985), которые в сочетании с лазерными принтерами во многом сделали для создания совершенно нового рынка настольных издательских систем. Джобс настаивал на том, что Apple должна развивать именно эту способность к инновациям — чтобы создавать на платформе Apple новые виды приложений, которые просто не могут существовать где-либо еще, — если она хочет выжить и развиваться.

Проблема, продолжал Джобс, в том, что Microsoft Windows догнала Mac.Windows NT фактически обеспечила седьмой этаж, опередив Mac. Вот где Джобс увидел, что NeXT приходит на помощь Apple. По словам Джобса, NeXTSTEP с его инструментом Interface Builder вместе с AppKit и другими объектно-ориентированными библиотеками обеспечивает настолько богатую функциональность из коробки, что они подняли разработчика на двадцатый этаж. Это означало, что разработчики могли исключить 80% кода, который является общим для всех графических приложений, что позволило им сосредоточиться на 20% кода, который сделал их приложение уникальным и предоставил дополнительную ценность для пользователей.В результате, как настаивал Джобс, небольшая команда из двух-десяти разработчиков могла бы написать приложение, столь же полнофункциональное, как и команда из ста человек, работающая на крупную корпоративную компанию, производящую программное обеспечение, такую ​​как Microsoft.

Я утверждаю, что это видение, изложенное Джобсом, на самом деле удивительно похоже на представление Фреда Брукса о программировании с небольшими хирургическими бригадами, возглавляемыми «главным» программистом. Разница в том, что вместо того, чтобы поручить главному программисту делегировать черновую работу подчиненным кодировщикам, как описал Брукс в видении Джобса, эта работа выполнялась библиотеками объектов.На самом деле, это тоже было видением Кокса, за исключением того, что в то время как Кокс предназначался для объектов, которые должны быть приобретены на открытом рынке, NeXT объединил свои объектные библиотеки как часть операционной системы и среды разработки NeXTSTEP, что могло фактически препятствовать формированию последующего рынок для объектов. В видении и Кокса, и Джобса, основная работа по созданию приложения была переложена на разработчиков объектов; никому в небольшой команде не нужно быть простым «исполнителем», вынужденным работать над «основой программы».В отличие от процедурных блоков кода, именно заключенная в черный ящик, инкапсулированная природа объектов — которая не позволяла другим программистам вмешиваться в их код — обеспечивала модульность, которая позволяла их повторно использовать взаимозаменяемо. Застройщикам, стоящим на каком-либо этаже, просто не разрешалось возиться с фундаментом, на котором они стояли. Освободившись от забот о внутренних деталях объектов, разработчики могли сосредоточиться на более творчески вознаграждаемой работе в области дизайна и архитектуры, которая была прерогативой «главного» программиста в схеме Брука.Все члены команды будут начинать с двадцатого этажа и сотрудничать друг с другом на равных, и их усилия будут продолжать расти, а не отвлекаться на переделку полов, на которых они стояли.

Было ли это обещание 5-10-кратного улучшения несбыточной мечтой? Мы уже видели, что NeXTSTEP использовался в качестве инструмента быстрого прототипирования для создания первой версии WorldWideWeb. Хотя NeXTSTEP не нашел большой базы пользователей, он был очень хорошо принят программистами, особенно в академических кругах.Также существовало твердое сообщество сторонних разработчиков NeXT, поддерживающих Джобса своими продуктами. Небольшие магазины, такие как OmniGroup, Lighthouse Design и Stone Design, команды не более восемнадцати человек в случае Lighthouse и один человек в случае Stone, написали полнофункциональные приложения, такие как электронные таблицы, программное обеспечение для презентаций, веб-браузеры и графические объекты. инструменты дизайна. Более того, NeXTSTEP оказался настолько продуктивным для быстрой разработки «критически важных» специализированных приложений, что банки Уолл-Стрит и организации национальной безопасности, такие как ЦРУ, платили за него тысячи долларов за лицензию.

Шесть месяцев спустя, в беседе у камина на Всемирной конференции разработчиков Apple в мае 1997 года, Джобс сказал, что Lighthouse (который с тех пор был приобретен Sun) доказал, что технология NeXTSTEP обеспечивает пяти-десятикратное увеличение скорости внедрения существующих приложений. Более того, более убедительным преимуществом было то, что NeXTSTEP позволил бы какому-то инновационному разработчику создать что-то совершенно новое, что изначально не могло быть разработано на какой-либо другой платформе, и что нельзя было воспроизвести на других платформах без огромных усилий.NeXTSTEP — это то, что Тим Бернерс-Ли использовал для создания WorldWideWeb, а также то, что Dell использовала для создания своего первого веб-сайта электронной коммерции в 1996 году. Именно так объектно-ориентированная среда разработки NeXTSTEP будет способствовать инновациям на платформах Apple в двадцать первом веке.

Оглядываясь назад с точки зрения 2016 года, Стив Джобс был удивительно прозорливым. После того, как Mac OS X появилась на персональных компьютерах Macintosh, небольшие бывшие разработчики NeXT и разработчики условно-бесплатного ПО для Mac начали писать приложения с использованием AppKit и Interface Builder, которые теперь называются «Cocoa.Эти разработчики, воспользовавшись преимуществами электронной коммерции в Интернете, стали называть себя независимыми или «инди-разработчиками» программного обеспечения, в отличие от крупных корпоративных компаний, таких как Microsoft и Adobe, с их сотнями команд. В 2008 году Apple открыла iPhone для сторонних разработчиков программного обеспечения и создала App Store, что позволило разработчикам продавать и распространять свои приложения непосредственно среди потребителей на своих мобильных устройствах, без необходимости настраивать собственные серверы или платежные системы. App Store стал эпицентром новой золотой лихорадки в разработке программного обеспечения, пригласив легендарную венчурную компанию Kleiner Perkins Caulfield & Byers создать «iFund» для финансирования стартапов мобильных приложений. (Wortham, 2009) В то же время инди-разработчики Mac, такие как Эндрю Стоун и Уил Шипли, предсказывали, что Cocoa Touch и App Store произведут революцию в индустрии программного обеспечения вокруг миллионов мелких разработчиков.

К сожалению, за годы, прошедшие с 2008 года, эта утопическая мечта медленно угасла: по мере того, как на рынок приходили единороги, поглощения и крупные корпорации, рынок мобильной связи созрел, вытесняя маленьких ребят, которые отказываются от финансирования инвесторов. С сотнями конкурентов в App Store может быть чрезвычайно сложно привлечь внимание к своему приложению без дорогостоящего внешнего маркетинга.Реальность такова, что большинство мобильных разработчиков не могут зарабатывать себе на жизнь созданием приложений, а наиболее прибыльные разработчики — это подрядчики, пишущие приложения для крупных корпораций. Тем не менее, объектно-ориентированная технология, продемонстрированная Джобсом в 1997 году, сегодня является основой для всех приложений iPhone, iPad, Apple Watch и Apple TV. Прогнозировал ли Стив Джобс будущее? Алан Кей сказал: «Лучший способ предсказать будущее — это изобрести его». Автор киберпанка Уильям Гибсон заметил: «Будущее уже наступило — просто оно распределено неравномерно.«NeXT уже изобрела будущее еще в 1988 году, но, поскольку NeXT никогда не поставляла более 50 000 компьютеров, лишь немногим посчастливилось увидеть это в 1990-х. Стиву Джобсу нужно было вернуться в Apple, чтобы рассказать об этом будущем всему остальному миру.

Coda

В сегодняшней Кремниевой долине, сосредоточенной на инновациях и будущем, часто забывают глубокую историю таких технологий, как среды разработки Apple Cocoa. Однако понимание прошлого жизненно важно для изобретения будущего, поскольку, скорее всего, будущее уже изобретено, нужно лишь немного покопаться.В Музее истории компьютеров наша миссия — сохранить это прошлое, не только физическое оборудование (у нас есть несколько компьютеров и периферийных устройств NeXT), но и программное обеспечение, которое является душой этих машин. В CHM есть небольшая коллекция программного обеспечения NeXT, включая NeXTSTEP 3.3, OpenStep 4.2, Enterprise Object Frameworks 1.1 и WebObjects 3.0 на компакт-диске, но нам не хватает более ранних версий NeXTSTEP, у нас мало возможностей для приложений NeXT. Заполнение коллекции важно, потому что программное обеспечение — это контекстная связь между компьютерами, пользователями, а также учреждениями и обществом, в которые они встроены.«Программное обеспечение — это история, организация и общественные отношения, которые стали осязаемыми», — написал историк компьютерных технологий Натан Энсменгер. (Ensmenger, 2010, стр. 227) Таким образом, помимо сохранения, важно также придать содержательность историям о наследии компьютерных программ и контекстуализировать их в культуре своего времени. Это мой первый пост в блоге в качестве куратора нового Центра истории программного обеспечения в CHM, и он знаменует начало моего проекта по сбору и интерпретации материалов, программного обеспечения и устных историй, связанных с графическим пользовательским интерфейсом, объектно-ориентированным программированием и разработкой программного обеспечения. начиная с NeXT, Apple и Xerox PARC.Ждите больше подобных историй в этом разделе, и если вы бывший инженер NeXT, Apple или Xerox PARC и хотели бы внести свой вклад в этот проект, свяжитесь со мной по адресу [email protected]!

Банкноты

  1. Objective-C — это работа не только Брэда Кокса, и она могла бы стать малоизвестной сноской в ​​истории языков программирования, если бы компьютер NeXT Стива Джобса не выбрал ее в качестве основы для программирования на NeXTSTEP. Кокс вместе с Томом Лавом стал соучредителем Stepstone (первоначально называвшегося «Productivity Products International» или PPI) для продвижения объектно-ориентированных решений, которые могут сосуществовать с существующими языками.Objective-C возник как объектно-ориентированный прекомпилятор. Первая версия языка, называвшаяся Objective-C, по-прежнему использовала отдельный препроцессор C для перевода кода Obj-C в прямой C перед передачей его компилятору. Однако этой версии языка и компилятора было недостаточно для целей NeXT, и потребовался вклад Стива Нароффа и других, чтобы превратить Objective-C в язык, который мы знаем сегодня. (См. Примечание 2 ниже.)
  2. Чтобы адаптировать Objective-C к потребностям NeXT, инженер Stepstone Стив Нарофф взял на себя разработку у Cox и внес значительные дополнения в язык для поддержки инструмента визуального программирования NeXT, InterfaceBuilder.Работа Нароффа была настолько важна, что в конце концов Стив Джобс нанял его в NeXT, а позже оставил в Apple. Нарофф интегрировал Objective-C непосредственно в компилятор C, который использовал NeXT, компилятор GNU C с открытым исходным кодом, GCC, в тесном сотрудничестве с Ричардом Столлманом. Это устранило отдельный этап перевода. Для поддержки InterfaceBuilder Нарофф добавил в язык ключевую функцию: «категории» (известные сегодня как «расширения классов»), способ динамически добавлять методы к существующему классу без создания подклассов.

    Еще одна ключевая функция, называемая «протоколы», была позже добавлена ​​инженерами NeXT Бертраном Серлетом (который позже стал вице-президентом Apple по программному обеспечению) и Блейном Гарстом (который позже возглавил команду Java в Apple). Протоколы позволяют классам наследовать несколько спецификаций интерфейса без наследования их реализаций, избегая конфликтов, которые могут возникнуть при наследовании нескольких классов в таких языках, как C ++. Позже эта функция была принята Java как «интерфейсы». Эти две функции, «категории» и «протоколы», сделали возможными несколько ключевых шаблонов проектирования, активно используемых библиотеками классов NeXT AppKit, и в последующие годы стало невозможно думать об Objective-C без них.

    В дополнение к этому, многие другие вклады в Objective-C со стороны инженеров NeXT были необходимы, исходя из практических потребностей разработчиков NeXT в реальном использовании, а не потребностей исследователей вычислительной техники. Кевин Эндерби работал над компоновщиком и ассемблером. Нарофф решил проблему нестабильности метода, которая повлияла на совместимость динамических библиотек, добавил явные конструкции объявления, директиву #import и интеграцию с C ++. В сервлет добавлена ​​переадресация методов для включения прокси удаленных объектов.Гарст работал над средой выполнения Objective-C и был ключевым сторонником управления памятью с подсчетом ссылок. Эти и другие модификации заложили основу для долгой работы Objective-C в NeXT, а затем и в Apple, обеспечив прочную основу, которая в конечном итоге будет поддерживать разработку Mac OS X и iPhone вплоть до наших дней.

Список литературы

  • Брукс, Фредерик П. 1987. «Серебряной пули нет: сущность и случайности разработки программного обеспечения». Компьютер 20 (4): 10–19.
  • ———. 1995. Мифический человеко-месяц: очерки программной инженерии . Юбилейное изд. Ридинг, Массачусетс: Аддисон-Уэсли Паб. Co.
  • Кокс, Брэд Дж. 1983. «Объектно-ориентированный прекомпилятор: программирование методов Smalltalk 80 на языке C». SIGPLAN Нет. 18 (1): 15–22. DOI: 10,1145 / 948093,948095.
  • ———. 1990a. «Есть серебряная пуля: промышленная революция в области программного обеспечения, основанная на использовании многоразовых и взаимозаменяемых частей, изменит мир программного обеспечения.” BYTE , 1 октября.
  • ———. 1990b. «Планирование промышленной революции программного обеспечения». Программное обеспечение IEEE 7 (6): 25.
  • ———. 1991. Объектно-ориентированное программирование: эволюционный подход . 2-е изд. Читающий Массачусетс: Эддисон-Уэсли Паб. Co.
  • Энсменгер, Натан Л. 2010. «Компьютерные мальчики»: компьютеры, программисты и политика технической экспертизы . Кембридж, Массачусетс: MIT Press.
  • Слейтон, Ребекка.2013. Важные аргументы: физика, вычисления и противоракетная оборона , 1949-2012. Кембридж, Массачусетс: MIT Press.
  • Уделл, Джон. 1990. «Smalltalk-80 вступает в девяностые годы». BYTE , 1 октября.
  • Вортам, Дженна. 2009. «Золотая лихорадка iPhone». The New York Times , 5 апреля. Http://www.nytimes.com/2009/04/05/fashion/05iphone.html.

DCE и объекты

DCE и объекты
Дэвид Чаппелл
Chappell & Associates

DCE Сегодня


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

Обеспечение этой общей мультивендорной инфраструктуры является целью Open Software Распределенная вычислительная среда Foundation (DCE). DCE предоставляет ключевые услуги требуется для поддержки распределенных приложений, в том числе:

  • поддержка удаленного вызова процедур (RPC) между клиентами и серверами;
  • — служба каталогов, позволяющая клиентам находить серверы;
  • и службы безопасности для обеспечения безопасного доступа между клиентами и серверами.

Услуги, предоставляемые DCE, сегодня доступны у широкого круга поставщиков на практически все основные системы. Многие организации развертывают DCE в качестве основы для клиент / серверное предприятие.

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

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

Первый — это набор технологий, входящих в состав Common Object Request Broker. Архитектура (CORBA). CORBA, производимая Object Management Group (OMG), представляет собой набор стандарты интерфейсов для различных распределенных сервисов.Как и DCE, CORBA спецификации направлены на определение решения от разных поставщиков для построения общей распределенной инфраструктура. Однако, в отличие от DCE, CORBA явно объектно-ориентирована, и различные Стандарты CORBA определяют только интерфейсы, но не фактические реализации этих интерфейсов. Это означает, что поставщик, предоставляющий продукт на основе CORBA, может (но не обязан) поддерживать эти интерфейсы с помощью DCE. Таким образом, запуск CORBA через DCE — это один из возможных способов добавить поддержку объектов в среду DCE.Сегодня, например, продукты на основе CORBA от IBM, Digital и Hewlett Packard могут эффективно работать через DCE, используя преимущества Существующие услуги DCE.

Вторая из двух основных предпринятых усилий по поддержке распределенных объектов — это Сеть OLE от Microsoft. Хотя это еще не доступно, Network OLE будет использовать RPC DCE и обеспечить некоторую поддержку и для других технологий DCE. В отличие от CORBA (и в отличие от DCE сам), Network OLE — это исключительно усилие одного поставщика, и насколько хорошо он на самом деле взаимодействие с DCE еще предстоит выяснить.Тем не менее, потенциал для Сетевого OLE — эффективный путь к поддержке распределенных объектов в среде DCE.

Добавление поддержки объектов — важная часть постоянного развития DCE. И как только описано, есть несколько возможных путей к этой цели. Цель данной статьи — описать основные варианты в этой области и выявить сильные и слабые стороны каждый.

О объектно-ориентированности


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

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

Размышляя об объектах, полезно различать объект класс и объект экземпляр .Класс описывает некоторую группу объектов, все из которых поддерживают одни и те же методы и один и тот же тип данных. Каждый объект принадлежит к определенному классу, и знание класса объекта обычно позволяет определить возможности объекта. An экземпляр объекта — это именно то, что следует из названия: конкретный экземпляр некоторого класса. За Например, можно представить себе класс объектов, представляющих банковские счета, и конкретный экземпляр этого класса, представляющий, скажем, ваш банковский счет.

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

Инкапсуляция означает, что данные объекта недоступны для пользователей, кроме как через его методы. Например, объектно-ориентированный язык программирования может выдает ошибку компилятора, если пользователь объекта пытается напрямую получить доступ к этому объекту внутренние переменные.Состояние этих переменных и, следовательно, данных объекта может только быть доступным или измененным с помощью методов объекта (интересно, C ++, наиболее широко использовал объектно-ориентированный язык программирования, имеет способы обойти это ограничение — прагматический опасения иногда могут перевешивать догмы). Инкапсуляция может значительно улучшить программное обеспечение модульность, приводящая к тому, что код легче поддерживать и с большей вероятностью будет правильным.

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

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

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

Третья характеристика объектной ориентации также в некоторых отношениях является наиболее сложной для описать: полиморфизм . Проще говоря, полиморфизм означает, что пользователь двух различные виды объектов могут, по крайней мере в некоторой степени, обращаться с ними, как если бы они были одно и тоже. Подумайте, например, о двух разных объектах, один из которых представляет ваш текущий счет. и еще один сберегательный счет.Эти два объекта могут быть очень похожими или даже идентичные интерфейсы. Каждый, например, может предлагать способы зачисления депозита и внесения вывод. Однако способ реализации этих методов может значительно отличаться. Например, метод вывода объекта сберегательного счета, вероятно, просто проверит сумма, которая будет снята с баланса счета. Если запрашиваемая вами сумма не превышают баланс, вывод средств проходит успешно; в противном случае это не удается.Проверка счетов, на с другой стороны, часто выдают автоматическую ссуду для защиты от овердрафта. В метод вывода в объекте текущего счета, тогда может проверить запрошенный вами сумма вывода против остатка на счете плюс текущая сумма, доступная для автоматический заем. Если запрошенная сумма превышает остаток на счете, но не превышает остаток плюс доступная сумма кредита, запрос будет успешным. Пользователю этих двух объектов способ вывода выглядит так же.Различия, какими бы важными они ни были, скрыто от глаз.

Этот простой пример иллюстрирует ключевое преимущество полиморфизма. Позволяя пользователю относиться к разным вещам так, как если бы они были одинаковыми, это снижает сложность. Объекты, которые разделяют тот же интерфейс или даже некоторые из тех же методов могут использовать полиморфизм, чтобы сохранить свои жизнь пользователей максимально проста. А поскольку полиморфизм зависит от разных типов объекты, разделяющие часть или весь интерфейс, очевидно, связаны с наследованием.An простой способ реализовать полиморфизм — унаследовать интерфейс и / или реализацию другой объект, затем настройте его каким-либо образом. Хотя наследование не требуется заставить полиморфизм работать, он может быть эффективным инструментом в его создании.

Понятие объекта как набора данных и методов вместе с тремя ключевые концепции инкапсуляции, наследования и полиморфизма составляют основу объектная ориентация. Однако это ни в коем случае не единственные актуальные идеи.Объект теологи могут вечно спорить о том, должен ли объект иметь только один интерфейс, как в CORBA, или несколько отдельных интерфейсов, как в Microsoft OLE. Есть также много спорных вопросов, касающихся жизненного цикла объекта (например, как отдельные объекты должны быть созданы и уничтожены), как следует идентифицировать конкретные экземпляры объекта и более. Тем не менее, преимущества объектных технологий не подлежат обсуждению. Остается спорным вопрос о том, как получить эти преимущества в среде DCE.

Добавление объектов в DCE


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

Во-вторых, DCE уже поддерживает инкапсуляцию и полиморфизм, два из трех требуемых характеристики объектной ориентации перечислены выше.Чтобы понять инкапсуляцию в DCE, подумайте о том, как определить отношения между клиентом и сервером. В DCE разработчик должен указать эту взаимосвязь, используя язык определения интерфейса (IDL) DCE. Интерфейс IDL явно описывает удаленные процедуры, которые клиент может вызывать в сервер. Поскольку единственный способ доступа клиента к данным сервера — это процедуры, данные сервера эффективно инкапсулируются.

DCE также поддерживает полиморфизм.Сервер DCE может поддерживать два или более разных набора реализации удаленных процедур, к которым можно получить доступ через тот же интерфейс. Клиент определяет, какую из этих реализаций он хочет вызвать (т. е. какой объект методы, которые он хочет выполнить), указав универсальный уникальный идентификатор (UUID) для конкретный объект. Для клиента каждый из этих объектов представляет один и тот же интерфейс, но на самом деле «методы» в этих объектах вполне могут быть реализованы по-разному. Это полиморфизм, и он был встроен в DCE ее первоначальными разработчиками.

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

Однако для многих sine qua non объектной ориентации является способность писать код на объектно-ориентированный язык, такой как C ++.Если стандартный интерфейс к DCE определен Некоторые говорят, что только в C DCE нельзя рассматривать как действительно объектно-ориентированную. Конечно есть некоторая заслуга в этой точке зрения; ведь пока можно развить объектно-ориентированные приложения на C или даже на ассемблере, это намного проще и далеко естественнее сделать это на объектно-ориентированном языке. С этой целью несколько разных были предприняты попытки определить объектно-ориентированные надстройки к DCE, обычно в форме Библиотеки классов C ++.Наиболее широко используемым из них является продукт Hewlett Packard под названием OODCE.

OODCE представляет внутреннюю объектную модель DCE через ряд классов C ++. Эти классы обеспечивают более естественный доступ к объектно-ориентированным функциям DCE, а также делают Иногда сложные интерфейсы DCE намного проще в использовании. Для людей, которые хотят писать на C ++ приложений в среде DCE, OODCE предлагает привлекательное решение.

Однако сама по себе

DCE не зависит от производителя, а OODCE — патентованный продукт.Хотя он потенциально может работать не только на системах HP, OODCE, тем не менее, контролируется одним поставщиком. Для добавления объектов в DCE без учета поставщика требуется мультивендорное соглашение под эгидой OSF. Сделать это, по крайней мере частично, — одна из целей. следующего основного выпуска DCE, DCE 1.2.

DCE 1.2 будет включать расширенную версию IDL, которая поддерживает ряд объектно-ориентированные функции (на самом деле, многие из этих новых функций были вдохновлены CORBA и OLE).Среди них возможность передавать ссылки на объекты в качестве параметров, наследование интерфейса и поддержка генерации файлов заголовков C ++. Это также возможно, что интерфейс прикладного программирования C ++, подобный определенному в OODCE, будет добавлен в стандартную базу источников DCE примерно в те же сроки.

Таким образом, одним из путей к распределенным объектам в среде DCE является прямое использование DCE встроенная поддержка объектов, что сегодня довольно минимально, но будет улучшено в DCE 1.2. Более полная альтернатива, по крайней мере, в ближайшем будущем, — это использование дополнительного продукта. как OODCE от HP. Однако есть другой маршрут, который не требует изменения DCE в все. При таком подходе DCE становится фундаментом, на котором строится другой, а именно: объектно-ориентированная, распределенная технология. Ярким примером такой технологии является OMG. CORBA.

DCE и CORBA


В некотором смысле CORBA очень похожа на DCE. Оба, например, определяют технологию для поддержка распределенных приложений, и оба стандарта не зависят от производителя.Это также существенные различия между ними. Наиболее очевидное различие в том, что CORBA была спроектирован так, чтобы быть полностью объектно-ориентированным с самого начала, чего нельзя сказать о DCE. Еще одно важное (хотя, возможно, менее очевидное) отличие заключается в следующем: в то время как DCE указать стандартные интерфейсы для своих сервисов, он также предоставляет эталонную реализацию, код, на котором базируются практически все продукты DCE. CORBA, с другой стороны, определяет почти ничего, кроме интерфейсов — единой эталонной реализации нет.Вместо этого каждый Поставщик CORBA может свободно реализовывать стандартные интерфейсы CORBA по своему усмотрению. Который реализация может быть построена на DCE, а может и нет — это выбор поставщика. Это очень важное различие между двумя технологиями в немалой степени связано с разные цели их контролирующих организаций и, особенно, от разных способы, которыми они были созданы.

Создание CORBA

Термин «CORBA» обычно используется для обозначения большого и растущего набора спецификации для распределенных объектных вычислений, созданные OMG.Чтобы создать эти документы, OMG выдает запросы предложений (RFP), в которых излагается конкретная проблема, которую необходимо решить. мой Бог Затем организации-члены отправляют ответы на запрос предложений с подробным описанием своих решений. Эти решения обычно, хотя и не всегда, принимают форму стандартных интерфейсов к объектам. Официально члены OMG голосуют по различным полученным материалам, выбирая один, чтобы стать стандартом OMG. На практике подающие организации (в основном поставщики) собираются вместе на разных этапах процесса и объединяют свои предложения.Когда проводится официальное голосование, обычно бывает только одно совместное представление, одно это одобрено с небольшим осуждением или без него. Хотя были ожесточенные бои за содержание различных стандартов OMG, большинство этих битв происходит за сцены — официальное одобрение самой OMG редко вызывает споры.

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

Этот последний пункт был особенно важен при разработке CORBA.Когда началась OMG работали над CORBA несколько лет назад, ее основные поставщики-спонсоры уже имели продукты или в этой области предпринимаются значительные усилия по развитию. Эти производители, естественно, хотели защитить свои вложения. Это означало, что все, что стандартизировано OMG, должно быть может быть реализована каждым из них, в идеале с ограниченным изменением существующей работы. Даже сегодня, когда большинство ведущих поставщиков предлагают продукты на основе CORBA, их разнообразное наследие очевидно. В отличие от DCE, где все поставщики предлагают очень похожие продукты, практически все производные от одной и той же базы исходного кода, продукты CORBA весьма разнообразны.Хотя все они поддерживают ключевые интерфейсы CORBA (и большинство из них добавляют поддержку новых так быстро, как возможно), уровень разнообразия среди продуктов на основе CORBA намного больше, чем среди Продукция DCE.

Брокер объектных запросов (ORB)

Стандарты CORBA определяют среду для распределенных объектных вычислений, мир в какие объекты могут взаимодействовать как клиенты и серверы. Ключевой частью этой среды является брокер объектных запросов (ORB).Согласно базовому стандарту CORBA, ORB «предоставляет средства, с помощью которых клиенты отправляют и получают запросы и ответы». А клиент вызывает метод в некотором объекте через ORB, который передает запрос в соответствующий объект. Метод выполняется, и результат, если он есть, возвращается еще раз. через ORB. Все коммуникации между настоящими объектами в среде CORBA опираются на ORB. Его функцию часто сравнивают с шиной в компьютерной системе; так же, как автобус поддерживает связь между различными частями оборудования в машине, ORB предоставляет программное обеспечение шина, соединяющая группу объектов.

Хотя абстрактная идея ORB проста, думать о ORB больше конкретно немного сложнее. Стандарты CORBA определяют только интерфейс к ORB, а не как на самом деле реализован ORB. Как видно из приведенного определения выше, поставщики могут реализовывать межобъектную связь любым способом, который они пожелают. при условии, что они поддерживают стандартный интерфейс ORB. Например, продавец может выбрать реализовать ORB с использованием RPC или какой-либо схемы передачи сообщений, или, возможно, в каким-то другим способом.ORB, поддерживающий связь между объектами в одной системе, может полагаться на какой-то механизм межпроцессного взаимодействия. Функциональность ORB может быть частью операционной системы, или это может быть реализовано в отдельном процессе или в библиотеки, связанные с клиентскими и серверными объектами, или некоторая комбинация этих вещей. Как бы то ни было, по определению все коммуникации между объектами проходят через ШАР.

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

К сожалению, производители не смогли достичь полного согласия относительно того, что этот интерфейс ORB должен быть. Пока клиентская часть интерфейса была стандартизирована довольно полно, серверная сторона была определена гораздо более свободно.Усилия в настоящее время в настоящее время, чтобы исправить это, более полно определив серверную часть интерфейса ORB. Это Стоит отметить, однако, что большинство поставщиков предоставляют среду разработки помимо этого определено CORBA. В результате даже стандартный интерфейс, который в настоящее время определен, может быть в значительной степени скрыто проприетарными расширениями, что уже не помогает CORBA ограниченная поддержка переносимости приложений.

Вызов операций

CORBA определяет два разных способа для клиентов вызывать операции с объектами сервера.Первый, называемый статическим интерфейсом, работает очень похоже на RPC. Объект определяет свое интерфейс с использованием CORBA Interface Definition Language (IDL), инструмента, в котором много общий с IDL DCE (хотя он и является объектно-ориентированным по дизайну, он поддерживает интерфейс наследование). Это определение IDL затем компилируется для создания клиентской заглушки и сервера. скелет, код, который обычно связывается с объектами клиента и сервера соответственно (официально и заглушка, и скелет входят в состав ORB).Чтобы вызвать метод на сервере объект, клиент вызывает функцию, запрос, который через ORB передается и выполняется в целевом объекте. Клиент блокируется до тех пор, пока функция не вернется, поэтому использование этот статический интерфейс очень похож на удаленный вызов процедуры в DCE.

Альтернатива для клиентов называется интерфейсом динамического вызова (DII). С DII, клиент создает запрос динамически, создавая его по одному параметру за раз.Тогда это отправляет запрос через ORB объекту назначения. Запрошенный метод в этом объект выполняется, и возвращается результат, если таковой имеется. Клиент, вызвавший операцию однако есть выбор; он может выбрать блокировку, ожидая этого результата, или он может выбрать продолжить выполнение без ожидания. Если клиент выберет второй вариант, он обычно проверяют позже, был ли возвращен результат операции. DII позволяет то, что спецификация CORBA называет отложенной синхронной операцией , возможность вызывать запрос без блокировки.

С DII клиент создает запрос динамически, а не полагается на предварительно скомпилированная клиентская заглушка, используемая в статическом интерфейсе. Это означает, что возможно клиент, чтобы узнать о совершенно новом виде объекта во время выполнения клиентом, затем создавать запросы и вызывать операции с этим объектом. Чтобы поддержать такую ​​динамику world, CORBA определяет репозиторий интерфейса . Этот репозиторий содержит определения интерфейсов для объектов в среде ORB.Когда клиент встречает нового, неизвестный класс объекта, он может запрашивать интерфейс объекта в репозитории. Как только он узнает этот интерфейс, клиент может затем использовать DII для динамического построения и вызвать запрос к новому объекту. Такая гибкость может быть очень полезна в некоторых виды приложений, а этого нет в DCE.

Хотя CORBA определяет два варианта клиентских интерфейсов, объект сервера может оставаться совершенно не зная, какой из них использует клиент — он просто получает вызовы через ORB как всегда.И хотя наличие двух разных интерфейсов может быть весьма полезным, оно также обеспечивает еще один пример эффектов дизайна, ориентированного на консенсус. В работе над оригиналом В соответствии со стандартом CORBA, поставщики разделились на две группы. Один отстаивал статику интерфейс, в то время как другой настаивал на превосходстве динамического интерфейса (неудивительно, что в каком лагере находился продавец, сильно коррелировал с тем, в каком существующая реализация уже предоставлена). Дилемма была решена в традиционном мода на комитеты по стандартам: все поставщики должны были поддерживать оба варианта.

Услуги CORBA

Определение стандартного интерфейса для ORB — стоящая задача. Это еще не конец истории, однако. Чтобы создать полную среду для распределенных объектных вычислений, полезно также определить другие стандартные интерфейсы, интерфейсы к службам, которые нужны самые разные объекты. Например, CORBA требует, чтобы клиент держал объект ссылка на объект, прежде чем он сможет вызывать операции с этим объектом (объект CORBA ссылка аналогична дескриптору привязки в DCE).Как клиент получает это ссылка на объект? Один очевидный ответ заключается в том, что он запрашивает какое-то имя или каталог служба. Чтобы сделать это стандартным способом, необходимо определить хотя бы стандартный интерфейс для эта услуга. OMG дает следующие определения интерфейсов для таких обычно полезных сервисов: под общим названием CORBAservices.

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

Например, интерфейс службы именования был специально разработан для использования в меньше всего по сравнению со службой каталогов сотовой связи (CDS) DCE, службой каталогов X.500 OSI и службой Sun NIS +.Это разнообразие, как всегда, отражает различные способы, которыми различные CORBA поставщики реализуют свои продукты. Однако гибкость редко бывает бесплатной. В этом случае Определенный OMG интерфейс службы именования мог включать только функции, которые были во всех целевые службы каталогов — стандартный интерфейс не может быть больше пересечения их возможностей. Службы, которые были только в одной из этих служб каталогов, вещи как и способность CDS создавать группы и профили, не могла быть включена в стандарт.Если поставщики хотят добавить поддержку этих дополнительных функций, они должны сделать это нестандартным способом.

Достижение соглашения с несколькими поставщиками иногда может привести к еще большему разнообразию. Крайний Примером является определение услуг жизненного цикла объекта OMG. С этим сервис, объект, который хочет разрешить своим клиентам копировать или перемещать его, должен поддерживать определенный стандартный интерфейс, который определяет методы для запроса обоих этих вещей. Каждый из этих двух методов, соответственно называемых «копировать» и «переместить», имеет два параметра.В обоих случаях, однако, первый параметр иногда может быть эффективно опущено, а второй параметр оставлен полностью неопределенным. Поскольку заявленная цель определение стандартных интерфейсов должно обеспечить переносимость приложений, остается только задаться вопросом: как можно написать переносимый код стандартными методами, где первый параметр необязательно, а второй не определен?

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

Еще один важный момент, на который стоит обратить внимание: если интерфейсы CORBA иногда определены так широко, как можно будет создать работоспособный набор тестов на соответствие? Покупая стандартные продукты, пользователи обычно хотят получить гарантии, прежде чем подписывать убедитесь, что то, что они покупают, действительно соответствует стандарту.Многие стандартные технологии идут до некоторой степени, чтобы обеспечить это. DCE, например, имеет большой набор тестов на соответствие, который поставщики должны пройти, чтобы получить сертификацию DCE. Поскольку практически все продукты DCE производятся из того же исходного кода, и поскольку интерфейсы этого исходного кода точно указано, создание этого набора тестов было несложным. Однако для CORBA с ее разнообразие реализаций и иногда слабо определенные интерфейсы, создавая Набор тестов на соответствие, который гарантирует переносимость приложений, гораздо более проблематичен.В результате покупатели продуктов на основе CORBA могут не чувствовать себя так уверенно переносимость приложений, как и покупатели продуктов DCE.

Взаимодействие с ORB

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

Самый последний стандарт CORBA, CORBA 2.0, по-прежнему ничего не говорит о том, как создавать ORB для использования в среде с одним поставщиком. Однако в нем прописаны требования для связи между ORB, созданными разными производителями.Для соблюдения требования совместимости этой новейшей версии спецификации, все ORB должны каким-то образом поддерживать протокол Internet Inter-ORB Protocol (IIOP). ORB могут опционально поддерживать альтернативные протоколы взаимодействия, известные как протоколы взаимодействия между ORB для конкретной среды (ESIOP) в дополнение к IIOP. Примером ESIOP является DCE Common Inter-ORB. Протокол (DCE CIOP), основанный на DCE RPC. Поддержка как IIOP, так и DCE CIOP была показано многими поставщиками ORB, и эти протоколы, безусловно, обеспечивают взаимодействие между ORB от разных производителей.

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

Эту ситуацию стоит сравнить с ситуацией в DCE. В среде DCE виртуально все продукты построены на единой кодовой базе. Существует один протокол, DCE RPC, используемый для все коммуникации, и каждый продукт поддерживает одно и то же прикладное программирование интерфейсы.Хотя DCE имеет ограниченную поддержку объектов, ее уровень стандартизации очень высоко. Напротив, продукты на основе CORBA, безусловно, больше похожи, чем могли бы были, если бы OMG никогда не существовали, но они намного больше отличаются друг от друга чем продукты DCE.

Реализация CORBA с использованием DCE

С самого начала процесса некоторые (но далеко не все) ведущие производители в OMG планировала поддерживать стандартные интерфейсы CORBA с помощью DCE.Хотя ни один из оригинальные реализации CORBA использовали этот подход, решения, использующие по крайней мере некоторые части DCE начали выпускать IBM, Digital и Hewlett Packard в конце 1995 года.

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

Построение CORBA поверх DCE также имеет некоторые недостатки. Главный из них — CORBA ограниченная стандартизация практически сводит на нет одно из величайших преимуществ DCE: нейтралитет поставщика. Если организация, взявшая на себя обязательства по DCE, решит использовать CORBA для переходить к распределенным объектам, у них будет сильный стимул выбрать одного поставщика ORB. Ограниченная переносимость и проблемная совместимость продуктов CORBA сегодня очень вероятно сделать решение от одного производителя.

DCE и Microsoft OLE / COM


Любой, кто думает о решениях от одного производителя для распределенных объектных вычислений, будет трудно игнорировать Microsoft, хотя бы из-за огромной установленной базы Windows. Хотя Microsoft в настоящее время не предлагает продуктов в этой области, они объявили планы вращаются вокруг того, что стало ключевой технологией в их среде: OLE.

Хотя изначально OLE означало «Связывание и внедрение объектов», сегодня OLE рассматривается как просто имя.Семейство технологий OLE включает в себя множество вещей, начиная от составных документов и заканчивая стандартными интерфейсами для доступа к базе данных. Все OLE Однако у технологий есть одна общая черта: все они полагаются на Component Object. Модель (COM).

COM определяет соглашения и предоставляет услуги для определения и использования объектов. Много как и CORBA, у него есть язык определения интерфейса (IDL) для указания интерфейсов для объекты, и он включает службы, которые позволяют объектам создавать экземпляры и взаимодействовать с друг друга.Эти службы, по сути, делают то же, что ORB в мире CORBA.

Однако, как уже упоминалось выше, OLE и COM сегодня являются единой системной технологией — нет Поддержка распространения, предоставляемая Microsoft. Это должно измениться с прибытием Сеть OLE. Хотя Network OLE еще недоступен, некоторые из его объявленных атрибутов особенно интересно пользователям DCE. Прежде всего, Network OLE выбрала DCE RPC в качестве его протокол связи. В идеале это обеспечит взаимодействие между OLE и DCE, хотя это обязательно потребует некоторой работы на стороне DCE.Кроме того, Network OLE будет поддерживать несколько вариантов безопасности, один из которых предназначен для совместимости с DCE безопасность. Даже IDL OLE заимствован из работы, проделанной OSF, поскольку по сути расширение DCE IDL.

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

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

Выводы


DCE — отличный выбор в качестве инфраструктуры для поддержки распределенных приложений. на предприятии клиент / сервер.Хотя DCE обеспечивает некоторую поддержку объектов, это поддержка сегодня ограничена. Чтобы улучшить эту ситуацию, по сути, есть три разрабатываемые сегодня подходы к созданию DCE надежной основы для распределенного объекта вычисление.

Первый — напрямую изменить DCE, чтобы добавить лучшую поддержку объектов. Это можно сделать отдельными поставщиками, такими продуктами, как HP OODCE, или поставщиками, работающими вместе через OSF. Этот последний путь используется в следующем основном выпуске DCE, DCE 1.2, который добавляет дополнительная поддержка объектно-ориентированных технологий.

Второй подход — установить продукт на основе CORBA через DCE. Среди достопримечательностей вот хорошая поддержка CORBA для технологий распределенных объектов и широкий спектр стандартные сервисные интерфейсы, которые он предлагает. Существенным недостатком этого подхода является то, что из-за весьма ограниченной стандартизации CORBA, нейтральность DCE к поставщикам скрыта под несколько фирменный шпон. Хотя существует множество отличных продуктов на основе CORBA доступны, выбор этого маршрута, вероятно, означает выбор реализации от одного поставщика CORBA во всей среде DCE организации.

Третий подход — это тот, который сегодня имеет больше всего неизвестных: Microsoft Сеть OLE. Хотя Network OLE, похоже, хорошо подходит для DCE с технической точки зрения, это слишком рано. чтобы знать, насколько хорошо это будет работать на практике. Сеть OLE, как и продукты на базе CORBA, эффективно предоставляет решение только от одного поставщика, хотя оно от поставщика, с которым практически каждая организация должна бороться. Все три подхода используются сегодня и у всех есть сильные и слабые стороны.Для организации, приверженной DCE, но размышляя о том, как совместить это обязательство с растущим использованием объектных технологий, сообщение простое. Дело в том, что не-объекты страха прибывают в DCE, возможно, более чем через в одну сторону. Выбор DCE не отправляет организацию в технологические захолустья, потому что DCE может расти по мере необходимости. В качестве фундаментальной основы для Многопрофильная компания клиент / сервер, DCE остается непревзойденной.

Для получения дополнительной информации


Дополнительную информацию о DCE и программе DCE см. На главной странице DCE. Страница.

.