Galogen на самом деле всё очень просто. Множественная классификация встречается сплошь и рядом. Фрукты можно классифицировать по признакам вида. Например, яблоки, апельсины и т.д. Если для системы существенно, что  апельсины выращивают в южной климатической зоне, а яблоки необязательно. Но с другой стороны, фрукты можно классифицировать по вкусовым оттенкам горькие и сладкие. Можно конечно выделить эти признаки в качестве атрибутов, но это возможно не всегда. Поэтому фрукт должен быть либо, яблоком либо апельсином и в то же время сладким либо горьким. В моём примере аппаратура классифицируется с одной стороны по типу – ПК или АСД. С другой стороны по свойствам мобильности – переносная либо стационарная. Причем обе классификации одновременно важны для системы. Поэтому никакую из них нельзя считать незначительной, как это предложил Денис "Майевтик". При множественном наследовании один класс может иметь несколько суперклассов, но для каждого экземпляра этого класса должен быть определён только один класс. Множественная классификация допускает принадлежность объекта одновременно к нескольким классам, которые необязательно связаны между собой наследованием, без определения специально класса для этого объекта.

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

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

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

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

На представленной диаграмме и в сопровождающем тексте этой информации нет, поэтому мои слова носят характер не предложения, а гипотезы, исходящей их некоторой посылки.

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

Почему, скажем для Организации, Сотрудника, ПК и ЛВС не ввести суперкласс "Физический объект", а для "Авторизации" и "Подключения" - суперкласс "Деятельность-Событие-Факт"? ) Например, Физические объекты обладают общими свойствами - координатами в пространстве, а "Деятельность-событие-факт" - скажем, признаком совершённости (Совершилось ли это событие или нет). ))

2 Galogen

Саня, и чего ты мне это нарисовал?

С точки зрения Логического представления - это множественная классификация
С точки зрения Физического размещения (кода)- это множественное наследование

Ты мне объясни что такое классификация, тогда веротяно будет понятно как она реализуется и зачем:-))

http://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F

Galogen ты привел пример классического множественного наследования. В твоём примере экземпляр класса Тигр неявным образом является экземпляром всех своих суперклассов Животное,Млекопитающее,Хищник. На рисунке я слегка подкорректировал твой пример так, что бы всё стало понятно. Я дополнительно классифицировал класс Животные по возрастному признаку и ввел два подкласса СтароеЖивотное и МолодоеЖивотной. Легко видеть, что любое животное является Млекопитающим и/или Хищником и МолодымЖивотным ЛИБО И СтарымЖивотным. То есть животное не может быть одновременно молодым и старым. Поэтому если на своей диаграмме я класс Тигр наследую от какого-то одного класса ( скажем МолодоеЖивотное), то явным образом отмечу, что все мои Тигры  молодые, а старых не существует в принципе. Но поскольку меня учили никогда не врать,  я пытаюсь решить проблему. Для этого класс Тигр делаю наследником обоих классов  (МолодоеЖивотное и СтароеЖивотное). Но в этом случае мои учителя опять смотрят на меня с упрёком. Получается, что Тигры стали и молодыми и старыми одновременно.  Ват такая вот весёлая картинка. Поэтому, при такой множественной классификации, возможные комбинации не описываются каким-либо классом (например Тигр).

Т.е. мы никак не можем изобразить факт такого наследования или там чего-то еще. И просто подразумевается само собой?

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

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

Ну в модели я те показал, как это отображается
А множественное наследование - это один из способов множественнной классификации.

... Я дополнительно классифицировал класс Животные по возрастному признаку и ввел два подкласса СтароеЖивотное и МолодоеЖивотной. Легко видеть, что любое животное является Млекопитающим и/или Хищником и МолодымЖивотным ЛИБО И СтарымЖивотным. ...

Сейчас не под рукой рисовалки, поэтому пишу так:

                     |---------------Молодое<---------------------------------МолодойТигр-|
                     |                                                                                                    |
                     |---------------Старое<---------------------------------- СтарыйТигр   |
Животное <---|                                                                                     |              |
                     |---------------Хищник <--------------|                             |              |
                     |                                                      |-------Тигр<--------|----------|
                     |---------------Млекопитающее<------|

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

Будь ласка, чуть подробнее про декларативное программирование. Почему мы туда стремимся?

[Глубинной некротредофилии псто]
Актуальная версия UML разрешает объекту иметь сколько угодно типов (классификаторов), просто перечисленных в описании через запятую. Если под термином "множественная классификация" имеется в виду эта способность, то UML нативно поддерживает "множественную классификацию".
Курьёзно, что UML в своей актуальной версии нативно поддерживает "динамическую классификацию". В частности параграфе 9.4.3.4 есть явные слова о том, что у параметра BehavioralFeature можно указать эффект = update, и это будет означать, что объект, поданный как этот параметр, может  поменять свою классификацию в ходе выполнения поведения, описанного этой  BehavioralFeature. Параграф 16.4.3.7 описывает специальные ReclassifyObjectAction-ы, которые меняют у объекта на своём входном пине список его классификаторов. В следующем параграфе расказывается про ReadIsClassifiedObjectAction-ы, которые чекают, может ли объект классифицироваться конкретным типом (классификатором).
В области ЯП, как подсказывает мой ксенолингвист, "классификация" называется "типизацией". Системы типов ЯП определяют правила, по которым в них работают аналоги ReadIsClassifiedObjectAction-ов и ReclassifyObjectAction-ов.