avlasov (avlasov) wrote,
avlasov
avlasov

Category:

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

Основная задача, которая стоит перед онтологическим программированием - повысить степени ре-юза софта.
Подобная задача ставилась и ставится перед объектно-ориентированным программированием.
Я лично рассматриваю онтологическое программирование как развитие идей объектно-ориентированного.
Ибо онтологии типа OWL и им подобные легко трансформируются в систему интерфейсов типа Java и им подные. Не ну там конечно есть ряд вопросов типа выражений над классами и наследование свойств, но это не суть важно. Главное, что иерархия классов прямо отображается на интерфесы Жабы, а свойства - на соответствующие методы. Учет всяких доп ограничений дело конечно полезное, но можно пережить. А в Скала можно оттранслировать, так что они в рантайме будут проверяться (а часть и на этапе компиляции).

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

Итак первый шаг для повышение степени ре-юза - выделение неявной онтологии в софте, и ее формулировка в явном виде.
Тут кстати полезно почитать книжку Криса Партирджа Business Objects: Re-Engineering for Re-Use ссылку на которую давал ailev  в своем посте. Там Крис популярно нам объясняет, зачем и главное как нужно извлекать эту самую онтологию, и почему это ведет к повышению степени ре-юза.

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

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

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

Третий шаг состоит в повышении степени ре-юза именно кода. Рассмотрим сию проблему подробнее. В общем случае код более ре-юзабелен если он состоит из мелких компонентов, ибо у маленьких компонентов меньше входных данных и связей между ними, а значит и больше ситуаций, в которых сии компоненты применимы. Методика повышения онтологического ре-юза Криса Партирджа хорошо это отражает: извлеченная и ре-инжиниренная онтология становится менее гранулярной, денормализованной. Фактически речь идет о шестой нормальной форме (в применении к ОО :)), т.к. Крис агитирует за 4D онтологии т.е. выраженные в пространстве-времени. Ну для программистких целей нам больше актуально именно время, т.е. то что изменения состояния во времени явно отражены в онтологии. Сие есть один из основных требуемых парадигмальных сдвигов - естественно, если принимать 4D онтологический подход, предложенный Крисом и другими товарищами (например, ИСО 15926).

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

Хочу также отметить важное следствие такого подхода - код при нем станет состоять из мелких модулей, что несвойственно типичному ОО программированию. Обычно в целях повышения производительности (либо трудностей в осуществлении рефакторинга) классы и методы в ОО коде разрастается до неимоверных размеров.
Широкое использование онтологических классов и активной нормализация вместо примитивных типов также может негативно сказать на производительности.
В силу этого, перед онтологическим программированием встает задача компенсации этой проблемы, например путем денормализации и трансформаций кода (например замена онтологических классов примитивными типами).
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 6 comments