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

Набор признаков категории - это шаблон набора признаков товара.


Категория (классификатор) может иметь свои собственные свойства.
При включении объекта в классификатор объект не объязан прятать свои свойство.

мод Сахават ЮсифовКатегория (классификатор) может иметь свои собственные свойства.
При включении объекта в классификатор объект не объязан прятать свои свойство.
1. может
2. обязан: видимый набор свойств объекта зависит от точки зрения на него через определенный классификатор- пример одно юр.лицо и поставщик и покупатель - набор свойств разный

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

guest_20040621Эх, такую тему чуть не прошляпил. ;)

> Мне не нравятся жесткие классификаторы. Объекты могут иметь частичную классифицируемость.

И как вы предлагаете с этим бороться?

> Главно сам классификатор (идентификатор и имя) и его свойства отбора (или пожелания классифицирующего)

А какой-нибудь распространенный пример хорошей классификации можете привести? (Предупреждая возможные вопросы: я - не могу).

Типа того. Пропали мои заказчики и все стоит уже месяц. :(

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

Давайте напишу, что сделано или хотелось бы.
1. Есть словарь.
2. Есть необъязательные шаблоны (классы) для генерации объектов. При генерации объекта ему приписывается шаблон. Но, объект может не полностью соответствовать шаблону. Класс может быть иерархическим. Объект естественно тоже (но, соответствие не объязательно). Например шаблон может задавать РЦ(Человек, машина, инструмент), а объект РЦ(Человек), но в объект можно включать только те объекты, которые приписаны к соответствующим шаблонам.
3. Есть классификаторы в виде леса. Классификатор может группировать и классификаторы и объекты и вперемежку. При прописании объекта к классификаторы (можно включить через классификатор (добавить объект) или прописать объект (проипасать в классификатор)). Естественно, объекты могут быт включены в разные классификаторы.
4. Объекты сами являются классами(с точки зрения экземплярности)(сущностями), они могут иметь определенные свойства с установленными значениями или быть не инициализированными.
А вот ресурсы(прикладные объекты что ли? :)) уже инициализированы полностью.
Пока столько. Если не туфта , то обсудим дальше.

Сделать так меня заставляет жизнь.
1. Автоконфигурирование (через спецификации и техпроцесс) изделий, услуг. Т.е. Изделие изначально не инициализировано (или неполностью инициализировано). При создании ресурса на базе Изделия не инициализированого, по всей цепочке инициализируются неинициализированные свойства (автоматически по правилам (полное наследование свойств входов или техпроцесса, формула, выбор) ) и это уже УЧЕТНАЯ единица. :)
2. Надо было иметь возможность на процесс в виде ресурсов назначить (или выбрать по совместимости свойств) и одиночный объект, и спецификацию (куда,что,сколько), и группу для множественного выбора, а то и группу групп и т.д.
При назначении можно игнорировать часть свойств объекта (просто не выбрать или удалить). Не инициализированнные свойства считаются совместимыми с любыми значениями ресурса учетного. Инициализированные должны совпасть (или быть приемлимы по условиям (пока их нет)) и т.д.

Не знаю, можно ли понять мой сумбур.

Вобщем похоже на Пролог чем то.

guest_20040621> 2. Есть необъязательные шаблоны (классы) для генерации объектов.

Сложновато получается. Предполагается, что начальные шаблоны (по крайней мере частично) заданы для всех объектов? Для шаблонов есть какие-то формальные критерии? Для обработки шаблонов, видимо, есть какие-то правила? Как они описаны? Зашиты в коде или используется какой-то OCL?


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

guest_20040621
> Класс может быть иерархическим.

Иерархия - она с наследованием? Или просто группирующая?


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

guest_20040621
> Классификатор может группировать и классификаторы и объекты

Классификаторы и объекты на уровне структуры данных различаются? Или просто имеют разный набор атрибутов и связей?


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

> Сделать так меня заставляет жизнь.

guest_20040621
Мотивы понятны. На мой взгляд, такой подход будет работать при условии относительно небольшого количества типов объектов. А если их - типов - много? В этом форуме регулярно задают вопросы про универсальные БД, - на самом деле это одна и та же задача. Иметь универсальную классификацию - значит уметь описывать данные любой природы.


Интересная вещь. Когда думаешь вообще о разнообразии, то можешь сойти с ума. А как только спускаешь на уровень предприятия, то все приходит в норму.
У одних такой набор классов, у других другой. Но их мало! Завод погрузчиков выпускает погрузчики и мелоч 10 наименований (из тех же деталей и материалов обычно + покупные), фабрика дверей - двери (отличаются материалами и т.д.).
Есть классы квазиинварианты - люди, цеха, машины, процессы... их по хорошему надо вводить полностью по части инвариантных свойств, а остальные вводить по мере необходимости как я пытаюсь.
Есть продукты, услуги - сильно вариабельны, кроем имени нет ничего общего. Эти вещи пытаюсь вывести в настройки и связываю (распознаю :)) всех их с помощью процесса.
На входах и выходах нормативного процесса может быть что угодно (не учетная не инициализированная муть).
На входе актуального процесса только учетная единица, полностью инициализированная.

Т.е. если пользоваться РБД, то только часть вариабельная выделяются в ЕАV или XML.
А если другие типы БД, то можно так и оставить все.

В принципе, эти настройки я собираюсь в конце закрыть для пользователя клиента по части шаблонов, оставив только классификатор.