July 15th, 2011

medved

Придумал новый OOA

Новый OOA - Ontology-Oriented Analysis :)
Отсюда же вытекает новые OOD и OOP - Ontology-Oriented Design и Ontology-Oriented Programming.
Хотя лучше говорить об Ontology-Based Analysis (Design, Programming) OBA (OBD, OBP).
Ну или по крайней мере OntOA (OntOD, OntOP).

NB Не то чтобы это я придумал, более точно сформулировал как OntOA, потому такой подход во многом присутствует в F-Logic, хотя у меня конечно есть свои задумки и требования, которым F-Logic не полностью удовлетворяет. Впрочем мой подход можно основывать на разных логиках, например FOL, HOL, Coq.
Тем не менее из существующих систем F-Logic наиболее близко отражает тот подход который я узрел (типа vision и все такое).

Изначальный смысл примерно как в обычном ООА, там ведь тоже есть классы, атрибуты, отношения.
Все это прямолинейно преобразуется в онтологии (собсно оно и есть онтологии).

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

А в Онтологически-Базированом Анализе мы используем онтологии (в компьютерном их понимании) для создания моделей софта.
А из них уже генерим софт, причем не прямолинейно.
Т.е. в классическом ООА мы оперируем компьютерными понятиями, типа классов, инстансов, атрибутов, схем баз данных, сущностей и связей, стейт-машин и сообщений, вызовов методов и передачей данных и проч. Для моделирования онтологических сущностей.
А в ОнтОА мы используем онтологии для моделирования сущностей компьютерных. Причем моделирование не обязательно прямолинейное, типа онтологический класс вовсе не обязательно соответствует классу в ООП. Онтологический класс есть просто множество, моделироваться в языке программирования оно может по разному, не обязательно объектно-ориентированно.

Основные различия такие
1 Работа на онтологическом уровне, т.е. никаких неявных предположений об объектно-ориентированной реализации нет, она может быть любая, в том числе мультипарадигмальная.
2 Заведомо есть множественное наследование. Хотя ООА тоже предполагает множественное наследование, но где-то на пути к
ООП оно может теряться.
3 Сложная трансляция в ЯП, по пути обрастающая имплементационными онтологиями. Т.е. вообще говоря есть несколько view на систему, отражающее разные ее аспекты.

Некоторые специфические принципы, которые в принципе можно избежать, но я думаю что они хорошо задают основу ОнтОА (точнее его логику, можно использовать и другие логики):
4 Основные понятия: экземпляры и отношения (предикаты)
5 Классы есть специфичные экземпляры, и связаны со своими членами отношением принадлежности классов: instanceOf(a, A)
Примечание: если логика высокопорядковая, то класс одновременно может быть и отношением: A(a) <-> instanceOf(a, A)
6 Специализация (классов) есть тоже специфичная форма отношений: specialization(A, B)
Примечание: если логика высокопорядковая, то specialization(A, B) <-> forall a, A(a) -> B(a)
7 Атрибуты заданы онтологически, т.е. принадлежностью к классам или задаются отношениям
8 Множество классов и их членов (могут) пересекаются, т.е. класс может быть членом другого класса. Т.е. есть классы классов, они же мета классы.
9 Отношениям тоже (могут) соответствуют экземпляры, и у них тоже есть классы.

Еще хитрость:
10 Для моделирования стейт-машин и вообще динамики используем что-то типа 4D онтологии. Ну точнее так как 3D не есть само по себе необходимость в программировании, то просто задаем что сущности заданы в пространстве, которое дополнено временем. По крайней мере, для описания динамики (стейт-машин, функций, передача сообщений, события).