Проблемы онтологического программирования
Основная задача, которая стоит перед онтологическим программированием - повысить степени ре-юза софта.
Подобная задача ставилась и ставится перед объектно-ориентированным программированием.
Я лично рассматриваю онтологическое программирование как развитие идей объектно-ориентированного.
Ибо онтологии типа OWL и им подобные легко трансформируются в систему интерфейсов типа Java и им подные. Не ну там конечно есть ряд вопросов типа выражений над классами и наследование свойств, но это не суть важно. Главное, что иерархия классов прямо отображается на интерфесы Жабы, а свойства - на соответствующие методы. Учет всяких доп ограничений дело конечно полезное, но можно пережить. А в Скала можно оттранслировать, так что они в рантайме будут проверяться (а часть и на этапе компиляции).
Т.е. кроме повышения степени ре-юза других идей-то и не видно. Впрочем, одной этой идеи вполне достаточно :).
Тут надо еще только отметить, что всякие рассуждения о том, чтобы семантически вебовский софт мог взаимодействовать друг с другом и читать данные в разных онтологиях, как раз и означает повышение степени ре-юза. Т.е. код работает не только со своей неявной онтологией, но и может (теоретически) как-то работать с данными, заданными в другой онтологии.
Но это актуально вовсе не только для семантического веба, а для развития конкретного софта вообще, ибо развитие софта расширяет сферу его применения, а значит ре-юз становится актуален для сокращения издержек, а также сохранения инвестиций (в частности, инвестиций в понимание).
Итак первый шаг для повышение степени ре-юза - выделение неявной онтологии в софте, и ее формулировка в явном виде.
Тут кстати полезно почитать книжку Криса Партирджа Business Objects: Re-Engineering for Re-Use ссылку на которую давал ailev в своем посте. Там Крис популярно нам объясняет, зачем и главное как нужно извлекать эту самую онтологию, и почему это ведет к повышению степени ре-юза.
Собственно, тут мы приходим ко второму важному моменту онтологического программирования: качество ре-юза прежде всего зависит от качества онтологии, и от возможности ее ре-юза. Причем это достигается не за счет программирования, а именно за счет онтологической работы.
Вобщем-то это очень важный момент. Собственно, я поэтому в более раннем посте и вел речь именно о онтологически-ориентированном анализе, ибо онтологически-ориентированное программирование имеет собой целью поддержать какие-то расширенные (в сравнении с объектно-ориентированной парадигмой) особенности формальных онтологических описаний. Правда также надо отметить, что эта задача может быть поставлена весьма нетривиальным способом, ибо как я отмечал выше, простая трансляция в классы и интерфейсы не исчерпывает проблемы. Более того, интересно как раз глубоко переработать подход к (объектно-ориентированному) программированию с целью поддержать современные онтологические парадигмы, например 4D, идентити и проч. Вобщем-то это все можно выражать в системе типов обычных ОО языков, но паттерны использования будут несколько иными. Иными словами, хотя онтологическое программирование не меняет, по большому счету, объектно-ориентированной парадигмы, но сам подход существенно меняется, что может потребовать более удобных синтаксических семантических конструкций.
Итак, нужно извлечь неявную онтологию софта и зареинжинирить ее с целью повышения ре-юза. Хотя это два шага, на практике они тесно взаимосвязаны, и осуществлять их по отдельности не вполне практично.
Третий шаг состоит в повышении степени ре-юза именно кода. Рассмотрим сию проблему подробнее. В общем случае код более ре-юзабелен если он состоит из мелких компонентов, ибо у маленьких компонентов меньше входных данных и связей между ними, а значит и больше ситуаций, в которых сии компоненты применимы. Методика повышения онтологического ре-юза Криса Партирджа хорошо это отражает: извлеченная и ре-инжиниренная онтология становится менее гранулярной, денормализованной. Фактически речь идет о шестой нормальной форме (в применении к ОО :)), т.к. Крис агитирует за 4D онтологии т.е. выраженные в пространстве-времени. Ну для программистких целей нам больше актуально именно время, т.е. то что изменения состояния во времени явно отражены в онтологии. Сие есть один из основных требуемых парадигмальных сдвигов - естественно, если принимать 4D онтологический подход, предложенный Крисом и другими товарищами (например, ИСО 15926).
Однако разбиение онтологии на более-мелкие и гранулярные компоненты неизменно отразится на коде и потребует соответствующего рефакторинга. Однако, тут можно сделать и еще один шаг - по возможности обобщить каждый такой маленький компонентик кода. Т.е. нужно пересмотреть явно или неявно подразумеваемые ограничения на входные данные, и пересмотреть их в сторону расширения. Во многих случаях это возможно сделать без существенных затрат времени, особенно если речь идет о маленьких гранулярных компонентиках. К примеру, пусть код поддерживает единичные значения какого-то атрибута, можно ли его немного подправить чтобы он поддерживал множество значений? Нередко, ответ будет положительным. Просто в исходной системе, у сего атрибута было только одно значение, но в перспективе может появится предметная область, где возможно множество значений. Таким образом этот расширит сферу применения компонента. Естественно, такие преобразования можно делать и по мере необходимости, а не заранее.
Хочу также отметить важное следствие такого подхода - код при нем станет состоять из мелких модулей, что несвойственно типичному ОО программированию. Обычно в целях повышения производительности (либо трудностей в осуществлении рефакторинга) классы и методы в ОО коде разрастается до неимоверных размеров.
Широкое использование онтологических классов и активной нормализация вместо примитивных типов также может негативно сказать на производительности.
В силу этого, перед онтологическим программированием встает задача компенсации этой проблемы, например путем денормализации и трансформаций кода (например замена онтологических классов примитивными типами).
Подобная задача ставилась и ставится перед объектно-ориентированным программированием.
Я лично рассматриваю онтологическое программирование как развитие идей объектно-ориентированного.
Ибо онтологии типа OWL и им подобные легко трансформируются в систему интерфейсов типа Java и им подные. Не ну там конечно есть ряд вопросов типа выражений над классами и наследование свойств, но это не суть важно. Главное, что иерархия классов прямо отображается на интерфесы Жабы, а свойства - на соответствующие методы. Учет всяких доп ограничений дело конечно полезное, но можно пережить. А в Скала можно оттранслировать, так что они в рантайме будут проверяться (а часть и на этапе компиляции).
Т.е. кроме повышения степени ре-юза других идей-то и не видно. Впрочем, одной этой идеи вполне достаточно :).
Тут надо еще только отметить, что всякие рассуждения о том, чтобы семантически вебовский софт мог взаимодействовать друг с другом и читать данные в разных онтологиях, как раз и означает повышение степени ре-юза. Т.е. код работает не только со своей неявной онтологией, но и может (теоретически) как-то работать с данными, заданными в другой онтологии.
Но это актуально вовсе не только для семантического веба, а для развития конкретного софта вообще, ибо развитие софта расширяет сферу его применения, а значит ре-юз становится актуален для сокращения издержек, а также сохранения инвестиций (в частности, инвестиций в понимание).
Итак первый шаг для повышение степени ре-юза - выделение неявной онтологии в софте, и ее формулировка в явном виде.
Тут кстати полезно почитать книжку Криса Партирджа Business Objects: Re-Engineering for Re-Use ссылку на которую давал ailev в своем посте. Там Крис популярно нам объясняет, зачем и главное как нужно извлекать эту самую онтологию, и почему это ведет к повышению степени ре-юза.
Собственно, тут мы приходим ко второму важному моменту онтологического программирования: качество ре-юза прежде всего зависит от качества онтологии, и от возможности ее ре-юза. Причем это достигается не за счет программирования, а именно за счет онтологической работы.
Вобщем-то это очень важный момент. Собственно, я поэтому в более раннем посте и вел речь именно о онтологически-ориентированном анализе, ибо онтологически-ориентированное программирование имеет собой целью поддержать какие-то расширенные (в сравнении с объектно-ориентированной парадигмой) особенности формальных онтологических описаний. Правда также надо отметить, что эта задача может быть поставлена весьма нетривиальным способом, ибо как я отмечал выше, простая трансляция в классы и интерфейсы не исчерпывает проблемы. Более того, интересно как раз глубоко переработать подход к (объектно-ориентированному) программированию с целью поддержать современные онтологические парадигмы, например 4D, идентити и проч. Вобщем-то это все можно выражать в системе типов обычных ОО языков, но паттерны использования будут несколько иными. Иными словами, хотя онтологическое программирование не меняет, по большому счету, объектно-ориентированной парадигмы, но сам подход существенно меняется, что может потребовать более удобных синтаксических семантических конструкций.
Итак, нужно извлечь неявную онтологию софта и зареинжинирить ее с целью повышения ре-юза. Хотя это два шага, на практике они тесно взаимосвязаны, и осуществлять их по отдельности не вполне практично.
Третий шаг состоит в повышении степени ре-юза именно кода. Рассмотрим сию проблему подробнее. В общем случае код более ре-юзабелен если он состоит из мелких компонентов, ибо у маленьких компонентов меньше входных данных и связей между ними, а значит и больше ситуаций, в которых сии компоненты применимы. Методика повышения онтологического ре-юза Криса Партирджа хорошо это отражает: извлеченная и ре-инжиниренная онтология становится менее гранулярной, денормализованной. Фактически речь идет о шестой нормальной форме (в применении к ОО :)), т.к. Крис агитирует за 4D онтологии т.е. выраженные в пространстве-времени. Ну для программистких целей нам больше актуально именно время, т.е. то что изменения состояния во времени явно отражены в онтологии. Сие есть один из основных требуемых парадигмальных сдвигов - естественно, если принимать 4D онтологический подход, предложенный Крисом и другими товарищами (например, ИСО 15926).
Однако разбиение онтологии на более-мелкие и гранулярные компоненты неизменно отразится на коде и потребует соответствующего рефакторинга. Однако, тут можно сделать и еще один шаг - по возможности обобщить каждый такой маленький компонентик кода. Т.е. нужно пересмотреть явно или неявно подразумеваемые ограничения на входные данные, и пересмотреть их в сторону расширения. Во многих случаях это возможно сделать без существенных затрат времени, особенно если речь идет о маленьких гранулярных компонентиках. К примеру, пусть код поддерживает единичные значения какого-то атрибута, можно ли его немного подправить чтобы он поддерживал множество значений? Нередко, ответ будет положительным. Просто в исходной системе, у сего атрибута было только одно значение, но в перспективе может появится предметная область, где возможно множество значений. Таким образом этот расширит сферу применения компонента. Естественно, такие преобразования можно делать и по мере необходимости, а не заранее.
Хочу также отметить важное следствие такого подхода - код при нем станет состоять из мелких модулей, что несвойственно типичному ОО программированию. Обычно в целях повышения производительности (либо трудностей в осуществлении рефакторинга) классы и методы в ОО коде разрастается до неимоверных размеров.
Широкое использование онтологических классов и активной нормализация вместо примитивных типов также может негативно сказать на производительности.
В силу этого, перед онтологическим программированием встает задача компенсации этой проблемы, например путем денормализации и трансформаций кода (например замена онтологических классов примитивными типами).