Разработка ядра информационной системы. Часть 1.

Вступление

Название статьи содержит два термина, требующих пояснений до того, как мы перейдем к изложению. Автору нравятся лаконичные формулировки ГОСТ.

Автоматизированная система — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций (ГОСТ 34.003—90 п. 1.1).
Информационная система — система, предназначенная для хранения, обработки, поиска, распространения, передачи и предоставления информации (ГОСТ 7.0—99 п. 3.1.30).

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

В первой части мы коротко, насколько позволяет формат статьи, рассмотрим требования к АИС, основные концепции и проектные решения. Во второй части остановимся на вопросах и примерах реализации ядра системы.

Обращаю ваше внимание, что речь в статье идет не о теоретических изысканиях автора, данный проект фактически «живой», поэтому по ходу изложения возможно внесение непринципиальных изменений. Предыдущая реализация подобной архитектуры на базе MS SQL Server 2000 показала свою жизнеспособность и преимущества, а в качестве развития проекта предполагается не только создание более широкой функциональности, но и перенос ядра на открытую свободную платформу  — СУБД PostgreSQL. Для проекта открыт вики (wiki — открытая система веб-публикаций) на сайте http://meta4.arbinada.com,  где заинтересованные коллеги смогут внести свои коррективы в ход реализации.

Разработка «от ядра»

Под ядром АИС будем понимать базовый функционал, набор служб, не зависящий от области применения системы.

Пользуясь определениями АИС (и опытом их разработки), перечислим основные требования к ядру системы.

  1. Промышленный стандарт реляционной СУБД, имеющий службы хранения, поиска, передачи информации.
  2. Поддержка объектно-ориентированного подхода (ООП) (фактически еще один промышленный стандарт), обеспечивающего обработку данных и реализацию прикладной логики.
  3. Подсистема метаданных — всегда актуальное описание информационной модели.
  4. Подсистема версионности информации, предоставляющая возможности от простой функции логического удаления по принципу мусорной корзины до хранения всей последовательности изменения информации.
  5. Подсистема безопасности, обеспечивающая управление доступом персонала к информации и ведение аудита.
  6. Подсистема локализации  данных. Персонал может быть интернациональным, а информация  — представлена на многих языках. Отмечу, речь идет именно о данных, а не о локализации интерфейса: это две разные задачи, имеющие пересечения.
  7. Подсистема группировки данных, позволяющая объединять информацию и ранжировать ее по разным признакам, включая иерархии.

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

Если взглянуть на структуру АИС, представленную в виде матрицы технологических слоев и уровней прикладных абстракций, то мы будем создавать функционал ячеек 1, 2 и частично 4, 5. Например, пункт 7 из вышеперечисленных относится к системным службам каталогизации.

Принцип разработки «от ядра» подразумевает создание прикладных модулей на основе этого ядра. Модули используют сервисы ядра, а оно в свою очередь может управлять модулями в соответствии с принятыми соглашениями об интерфейсах. В этом случае создается среда и каркас (framework), используя которые разработчик может сосредоточиться исключительно на прикладных задачах. Система растет уровнями, хотя равномерность роста не гарантирована и, более того, не является обязательной. Например, на базе ядра и набора системных сервисов вы можете создать приложения «Учет кадров», «Расчет зарплаты», «Поиск персонала», объединив их в решение «Управление персоналом», при этом связанные решения и приложения («Бухгалтерия», «Управление проектами» и т.п.) могут быть интегрированы из других систем.  

 Рис. 1. Матрица АИС  в слоях и уровнях

Рис. 1. Матрица АИС в слоях и уровнях

Скрещиваем ежа и ужа

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

  • самой СУБД, используя развитый механизм проекций (view) и хранимых процедур;
  • клиента СУБД (клиентом может быть и сервер приложений). Для этого случая имеется ряд готовых решений объектно-реляционной проекции — ОРП (англоязычный термин ORM — object relational mapping), таких как ECO (Bold), Hibernate (NHibernate), JDO, XPO, Vanatec и др.

Не забудем, что «скрещивание» предполагает и реализацию прикладной логики (бизнес-логики), т.е. той самой обработки данных. В первом случае обработка проходит в адресном пространстве сервера БД. Во втором объекты существуют в адресном пространстве клиента, а СУБД используется в качестве пассивного хранилища. Достоинства и недостатки обоих решений известны, я приведу наиболее очевидные из них.

  1. Высокие накладные расходы (overhead) для манипуляций с объектами вне адресного пространства СУБД во втором случае. Например, чтобы сложить два поля (свойства) целого типа двух разных объектов и сохранить их в поле третьего, требуется извлекать значения, передавать по сети клиенту, там складывать, возвращать обратно и сохранять (технологические расходы на упаковку/распаковку и межпроцессную передачу). В первом случае все операции происходят локально (in-process).
  2. Проблема интероперабельности - невозможность разделять прикладную логику между разными приложениями, работающими с одной БД. Действительно, если для доступа к БД имеется множество промышленных стандартов API (Application Programming Interface — интерфейс прикладного программирования), таких как ODBC, JDBC, OLE DB, ADO, ADO.NET и др., то в случае 2 ваш слой объектов доступа будет уникальным и на уровне API, и на уровне среды исполнения. Например, созданный с помощью NHibernate слой фактически недоступен для Win32, PHP и Java-приложений, тогда как доступ к таблицам и хранимым процедурам можно осуществить практически из любой среды разработки и даже стороннего приложения (Microsoft Excel).
  3. Проблемы оптимизации и тонкой настройки взаимодействия с БД. В общем случае использования СУБД в качестве пассивного хранилища вы не работаете с БД напрямую, за взаимодействие отвечает ваш «проектор». Даже готовые ОРП имеют много узких мест, которые придется обходить.
  4. Переносимость между СУБД. Это тот случай, когда вариант 2 имеет преимущества. В первом мы привязаны к реализации логики на конкретной СУБД и перенос фактически означает переписывание большой части кода для новой платформы.
  5. Управление процессами в многопользовательской среде, диспетчеризация, обмен сообщениями. В первом случае мы  используем фактически готовые механизмы, предоставляемые самой СУБД, но изменить их при необходимости практически невозможно.
  6. Проблемы балансировки нагрузки. Разными путями, но с успехом решаются в обоих случаях.

Проблемы 1—3 частично решаются в архитектуре с выделенным сервером (серверами) приложения: доступ к данным и логика разделяются на уровне сервера. Реализация подобной архитектуры является нетривиальной технической и неочевидной экономической задачей: возникает необходимость в системных разработчиках, усложняется система, повышается стоимость владения.

В рамках статьи мы будем рассматривать только первый вариант: реализация логики, в том числе и уровня ядра, средствами самой СУБД. Выбор в пользу первого варианта представляется разумным во многих случаях, когда приложение ориентировано на обработку постоянно хранимых данных, а не потоковой или пакетной информации.  Это первое решение, ограничивающее будущую область применения. В дальнейшем будет принято еще несколько подобных решений, составляющих основу будущего ядра АИС.

Если вернуться к приведенной выше матрице, становится понятно, почему ячейки 3 и 6 остаются вне рассмотрения: мы выбрали вариант с реализацией открытого интерфейса доступа к данным на основе имеющихся промышленных стандартов, уровень ядра слоя представлений будет  основан на этих стандартах, соответственно нам не потребуется создание собственного интерфейса (API).

Основные принципы

Нельзя объять необъятное, поэтому вначале мы сформулируем основные проектные решения, одновременно являющиеся и ограничениями.

Объектная модель. Используется схема обобщения (наследования) с общим для всех абстрактным предком (суперклассом) Object. Любой класс в системе является прямым или дальним потомком (подклассом) класса Object. Множественное наследование не поддерживается. По умолчанию используется схема отображения 2 (см. Приложение. Методы отображения: основные понятия и термины) «класс — таблица», т.е. каждый класс отображается на новую таблицу, а связь 1:1 с таблицей суперкласса (предка) осуществляется по ключу-идентификатору ObjectID; атрибуты суперкласса не переносятся в подкласс, за исключением ключа. На самом деле метод отображения на таблицы на данном этапе не так важен, поскольку снаружи классы будут видны только как проекции.

Проекции (view) автоматически генерируются ядром системы на основании метаданных (для специальных случаев также предусмотрен ручной режим). Каждая проекция соответствует классу и содержит все его поля, включая поля суперклассов. Формат именований будет определен позже. У класса может быть несколько проекций, например проекция для работы только с актуальными версиями объектов (при включенной версионности), для логически удаленных объектов или для объектов в контексте языка локализации данных.

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

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

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

Все манипуляции с объектами осуществляются посредством операций с проекциями или прямой посылкой сообщений. Проекции допускают весь стандартный набор операций для обычных таблиц: выборку, вставку, модификацию и удаление. Подобные операции рассматриваются как посылка сообщений (создать, изменить, удалить) всем объектам, попавшим во множество, определяемое SQL-запросом. Таким образом, обработка объектов через проекции будет ориентирована на множества, а не на последовательность операций, присущих популярным императивным объектно-ориентированным языкам типа Java, Delphi, C# и др. Ведь SQL  — декларативный язык: вы только задаете «что сделать», а «как сделать» — решает интерпретатор на уровне СУБД. Впрочем, работа через посылку сообщений отдельным объектам позволяет использовать и традиционный императивный стиль программирования.

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

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

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

Безопасность. Кроме системы безопасности самой СУБД ядро имеет собственную подсистему расширения. Используются механизмы идентификации и проверки подлинности (аутентификации) уровня СУБД, но пользователь СУБД при этом ассоциируется с профилем пользователя АИС.

Мы будем использовать систему безопасности на основе матриц доступа или, по терминологии Windows, списков доступа (ACL  — Access Control List). В простом варианте это значит, что в системе хранятся соответствия между субъектом (пользователем, группой), имеющим доступ, объектами, к которым осуществляется доступ, и методом доступа к объектам.

В минимальном варианте предоставляются возможности по управлению доступом как на уровне класса (ко всем объектам данного класса), так и на уровне экземпляров (объектов).

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

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

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

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

Предварительные итоги

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

Схема будет разделена на две части:

  • базовые структуры самого ядра и метаданных,
  • базовые объекты и сервисы ядра.

Физическую схему для СУБД PostgreSQL 8 и особенности реализации мы рассмотрим в рамках второй части публикации.

Продолжение следует.

Рис. 2. Концептуальная модель БД. Структуры ядра и метаданные

Рис. 3. Концептуальная модель БД. Базовые объекты и сервисы

Приложение. Методы отображения: основные понятия и термины

Можно выделить три основных метода отображения классов объектов на реляционную схему БД.

  1. Хранение всех атрибутов (полей) в одной таблице.
  2. Группировка общих атрибутов в одной таблице и разнесение уникальных атрибутов подклассов по связанным таблицам.
  3. Представление каждого класса в виде отдельной таблицы.

Первый метод не относится собственно к реляционной модели и может рассматриваться только как средство оптимизации. Остальные методы используются CASE-средствами проектирования базы данных, например ErWin или PowerDesigner, и обозначаются как «полный/неполный подтип» (complete/incomplete subtyping) со схемой «атрибуты подкласса в новой таблице» (inherit only primary attributes, метод 2) и «наследуемые атрибуты добавляются к таблице подкласса» (inherit all attributes, метод 3).

В ОРП, поддерживающих выбор метода генерации схемы БД, например JDO, обозначения несколько иные. Первый метод называется «плоским отображением» (flat mapping), остальные методы реализуются с помощью либо «вертикального отображения» (метод 2, vertical mapping), либо «смешанного отображения» (методы 2 и 3, mixed mapping).

Сергей Тарасов, май 2007.

Статья также опубликована в журнале "Мир ПК" №7-2007.

Комментарии

Я уже реализовал данную схему

Привет всем.

За лето 2007 года мне удалось реализовать данный движок. И даже на этом движке реализовал прикладную задачу "Система электронного документооборота" заменив использовавшийся на предприятии DocsVision.

Только я никакими дизайнерами не пользуюсь, описываю прикладную часть в виде скрипт SQL, но по определенным правилам, и скрипт выглядит очень похоже на ООЯ. Пример описания сущности "Бизнес-Процесс". С помощью этой сущности настраиваю маршрут прохождения документа при согласовании.

exec Class 'Process', 'Object', 'Бизнес-процесс'
exec Field 'ObjectClass', 'Class', 'Класс объекта процесса'
exec SubTable 'Entries', 'Точки входа в процесс'
exec Field 'Operation', 'Operation', 'Операция', 'Key'
exec Field 'ID', 'String', 'ID', 'null default(newid()) Invisible'
exec SubTable 'Routes', 'Маршрут'
exec Field 'State', 'State', 'Состояние', 'Key'
exec Field 'Operation', 'Operation', 'Операция', 'Key'
exec Field 'ID', 'String', 'ID', 'null default(newid()) Invisible'
exec Method 'GetEntries', 'Process_GetEntries'
exec Method 'GetRoutes', 'Process_GetRoutes'
exec Action 'Edit', 'TfrmProcessEdit'
exec Page ''
exec Control 'Name', null, 'Required'
exec Control 'ObjectClass'
exec Page 'Entries', 'Entries', 'Grid'
exec Page 'Routes', 'Routes', 'Grid'
exec Action 'Start', '', 'Запустить процесс'
exec DefaultAction 'Start'
exec Folder 'Processes', 'System', 'Бизнес-процессы'
exec Compile

Изображение пользователя Serguei_Tarassov.

Коля,

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

Есть

В одной из реализаций есть. В данной нет, но на добавление потребуется не более одного рабочего дня.

Лень регистрироваться. Думаю немного попозже.

Изображение пользователя Serguei_Tarassov.

Насчет одного

Насчет одного дня я бы не торопился.
Множественный доступ к обьектам через вьюшки тоже есть?

Изображение пользователя NickLobastov.

не понял вопроса

Что значит множественный доступ?

Есть вьюхи для каждого класса VPerson, VDocument со всеми атрибутами и редактированием через instead of триггеры

Изображение пользователя NickLobastov.

Ну да, так и есть

как же еще может быть :-)

Только есть ограничение, класс объекта во вьюшке должен полностью соответсвовать классу вьюшки, с абстрактными вьюшками не выйдет. Например вьюшку VDocument апдейтить не удастся
Хотя думаю, что данную проблему можно будет решить. Пока надобности нет.

Решаю проблемы по мере их поступления :-)

Изображение пользователя ipanshin.

интересно

Коля, это Игорь
А этот движок пойдет на моем ядре (точнее на ядре, который в СР)? Или надо что либо дорабатывать? Сейчас я вижу перед собой некую последовательность процедур из твоего API, при помощи которого можно описать поведение неких сущностей в некотором процессе. Но описание это еще не движок. Что выполняет функцию движка мне не очень понятно? Опирается ли это на ранее разработанные классы "маршрут","функция" и т.д.?

И еще вопрос твой клиент на делфи это полностью другой клиент? Сколько времени ты на него потратил?

Изображение пользователя NickLobastov.

Опишу немного подробнее

Мой Дельфи клиент не имеет ничего общего с клиентом NEXUS.
У него больше общего с ОНТАРИО.

Перво-наперво я разработал несколько базовых классов вручную и с их помощью теперь по описательным скриптам (пример которого я привел) формирую новые сущности - прикладные классы.

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

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

Набор процедур Class, Field, SubTable и т.д. я сделал чтобы легче и быстрее можно было разрабатывать прикладные сущности. По этим метаданным работаю датасеты на клиенте (тоже мои компоненты, очень функциональные) и автоформа не требующая какой-либо логики на клиенте.

Изображение пользователя ipanshin.

вполне можно создать такой же набор процедур,

вполне можно создать такой же набор процедур,

Т.е. взять твои процедуры за прототип и написать для нексуса? Примерное время какое я затрачу на это, по твоей оценке? В конечном итоге я смогу создавать твои прикладные классы?

бизнес-процессов, то это прикладная часть

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

не имеет ничего общего с клиентом NEXUS.

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

Изображение пользователя NickLobastov.

Скрестить ужа и ежа

Я думаю что реализовать такой набор процедур можно максимум за месяц. И да, думаю что в таком случае скрипт в моем формате станет универсальным и для NEXUS и для ONickS (моя система) и для любой другой системы. Есть правда одно но: я кроме данного скрипта еще использую обычные скрипты, например, обычные процедуры дополнительные. Но именно по описанию структуры это вполне будет работоспособно.

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

При желании конечно можно сделать так чтобы из ONickS открывался NEXUS, т.к. ONickS поставляется с исходным кодом и разработка части кода класса вполне возможно на клиенте. Я специально не закрываю никакие возможности Дельфи и Сервера. Но проще было бы не вызывать чужого клиента, а сделать в ONickS доп. интерфейс для буферной таблицы NEXUS.
Только не знаю зачем это нужно?

Изображение пользователя ipanshin.

автомат бизнесс процессов

Со скриптом, описывающим прикладные классы, в общих чертах ясно.

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

Вопрос о скрещивании чисто теоретический. Я тоже не вижу смысла. Нексус клиент не имеет графического редактора бизнесс процессов. А без такого редактора приложение выглядит грустно.

Изображение пользователя Serguei_Tarassov.

Интерфейсы не

Интерфейсы не нужны - здесь слабая типизация.
В SmallTalk есть нечто подобное: послать событие (дернуть за метод) можно любому обьекту. Если событие им не обрабатывается (читай, метода в интерфейсе нет), то генерируется исключение.

"здесь слабая

"здесь слабая типизация" - хм...мне кажется, это зависит от предметной области, или я не прав?

Пример. Имеем два "сильных" типа - "Организации" и "Персоны". Экземпляр и того и другого класса может быть "Контрагентом"-"Покупателем"-"Постоянным/VIP покупателем"(по сути - иерархия интерфейсов с множеством методов), и вот интересно, что будет происходить при выполнении запросов типа "Выбрать покупателей (с таким-то, покупательским, свойством"?

Изображение пользователя Serguei_Tarassov.

Не зависит от

Не зависит от предметной области (ПО), зависит от применяемой техники.
При моделировании ПО наследование в 3 уровня практически всегда означает ошибку в проектировании. Для небольших задач в пару-тройку десятков классов это может не мешать или вовсе не проявляться. Проблемы начнутся, когда рядом встанет смежная задача с пересечением по нескольким классам.
В вашем примере "Контрагент", "Покупатель" - это контейнеры, содержащие ссылку на организацию или персону, тогда проблема решается без наследования.
Запрос будет выглядеть на SQL в виде соедиениния (INNER JOIN) вьюшек контрагентов и организаций/персон с возможным UNION если у организаций и персон есть общие атрибуты.

контейнер -> классификатор -> класс

> Не зависит от предметной области (ПО), зависит от применяемой техники.
> "Контрагент", "Покупатель" - это контейнеры, содержащие ссылку на организацию или персону

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

> При моделировании ПО наследование в 3 уровня практически всегда означает ошибку в проектировании.
Т.е., например дотнет - сплошная ошибка проектирования? ;)

Изображение пользователя Serguei_Tarassov.

Насколько я

Насколько я понял из предыдущего примера, "Контрагент", "Покупатель" - это небольшой "куст", растущий из какого-нибудь "абстрактного контрагента", что не мешает им быть контейнерами для частных лиц или организаций.
Соответственно, заказы (данного класса заказов) содержат либо абстрактных контрагентов либо конкретных покупателей.
Т.е. иерархия растет "вширь", не поднимаясь выше 2-3 уровней.

>> При моделировании ПО наследование в 3 уровня практически всегда означает ошибку в проектировании.
>Т.е., например дотнет - сплошная ошибка проектирования? ;)
При моделировании ПО (предметной области, т.е. реального мира), дотнет здесь не при чем.

> Т.е. иерархия

> Т.е. иерархия растет "вширь", не поднимаясь выше 2-3 уровней.
Глубина иерархии меня не очень беспокоит. А беспокоит вопрос насколько онтология выстраиваемая в системе будет соответствовать(будет адекватной) имеющейся в предметной области (и, не в последнюю очередь, для разработчика системы).
В предметной области:
"типы"(идея) - "Организация", "Персона", ...
"роли"(качество, свойство, действие) - "Покупатель", "Поставщик", "Производитель", "Отец 2-х детей"...
"экземпляры"(воплощение) - "ООО Рога и копыта", "Горбунков С.С."
что неплохо соотв-т схеме(разрешающей множеств.насл.) ООЯП:
класс(тип)-(поддерживаемые)интерфейсы-экземпляры

> При моделировании ПО (предметной области, т.е. реального мира), дотнет здесь не при чем.
Считаете, в дотнет нет модели ПО, или ПО, или она(оно) не часть реального мира?

Изображение пользователя Serguei_Tarassov.

Глубина

Глубина иерархий вложения (is a part of) меня тоже мало волнует. А вот глубина иерархий обобщения (is a) - та самая таксономия в упомянутой вами онтологии - волнует в плане непригодности использования на стыках разных ПО. Да и сама задача построения классификации даже в отдельно взятой ПО тянет на диссертацию.

По поводу ролей (интерфейсов) есть у нас такая статья
http://www.arbinada.com/node/8
По-моему, там говорится о вашем подходе.

Что касается предлагаемой архитектуры, то она не завязана на конкрентный подход. Совсем нетрудно изменить схему метаданных, добавить интерфейсы, а методы (события) связывать с ними. На логике ядра это скажется незначительно.
Принципиальный момент в другом: это не ОРП (ORM), а превращение РСУБД в ООСУБД путем надстраивания слоя на уровне и средствами самой СУБД.

ELIT.Продолжение?

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

> есть у нас такая статья http://www.arbinada.com/node/8 По-моему, там говорится о вашем подходе.
Прямо в яблочко! Спасибо! А где же продолжение? Ничего не смог нагуглить... Неужели все так и заглохло в далеком 99-м? :(

> превращение РСУБД в ООСУБД путем надстраивания слоя на уровне и средствами самой СУБД
Если видели это - http://sqlserverbible.com/ (Nordic O/R dbms for SQL Server) - что можете сказать?

Изображение пользователя Serguei_Tarassov.

Я послал автору

Я послал автору вопрос, возможно он и ответит.
Владимир, кстати, в ФИДО-группах проявляется иногда.
По ссылке посмотрю на досуге, спасибо.

Изображение пользователя ipanshin.

развитый механизм проекций (view)

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

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

update vw set ... from tbl join vw x ...

С таблицами все катит отменно. Я уже не говорю про квери планы в теле триггера и обновление индексов и пр. В итоге налицо проседание производительности настолько, что систему можно выкидывать на помойку.