Здравствуйте Уважаемые! Хотелось бы услышать ваше мнение по вопросу множественной классификации. Попробую обрисовать ситуацию на примере выдуманной системы. Есть некоторая организация (предприятие). На базе организации существует парк специализированных автомобилей. Каждый из таких автомобилей оборудован аппаратурой. В качестве аппаратуры выступают персональные компьютеры (ПК), а так же аппаратура сетевого доступа (АСД). АСД управляется ПК и передает по беспроводной сети данные с этого ПК. Внутри отдельно взятого автомобиля организуется локальная вычислительная сеть (ЛВС). Соответственно через одну АСД могут передаваться данные с нескольких ПК. На каждом из ПК авторизован один или несколько человек. Всё вышеописанное представлено диаграммой классов на рисунке ниже.

Теперь несколько изменим условия, расширив набор аппаратуры. Добавим переносные ПК и переносные АСД. То есть переносной ПК подключается к переносной АСД. Таким образом, некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети. Изменим диаграмму классов в соответствии с введёнными условиями. 

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

Теперь несколько изменим условия, расширив набор аппаратуры. Добавим переносные ПК и переносные АСД. То есть переносной ПК подключается к переносной АСД. Таким образом, некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети. Изменим диаграмму классов в соответствии с введёнными условиями. 

А где же у вас на последней Диаграме указано, что "некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети"?

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

Ну Вы сами себе притиворечите! Зачем тогда ТС объеденять в сеть когда в сеть должны быть объеденены ПК?!

Т.е. в итоге вам нужно убрать ассоциацию м/у ТС и ЛВС и м/у СтационарнойАппаратурой и ЛВС. И просто связать ЛВС и ПК

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

А языки программирования как это реализуют?

Через механизм множественного наследования, который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.

Через механизм множественного наследования, который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.

А как же иерархия классов в библиотеке J2EE?

Через механизм множественного наследования, который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.

А как же иерархия классов в библиотеке J2EE?

А что иерархия классов в J2EE? Я не в курсе. По приведённой мной ссылке написано, что Java (а также VB и С#) предлагает компромиссный вариант - позволяет наследовать методы от нескольких классов-интерфейсов, но реализация методов и поля могут быть унаследованы только от одного.

А что иерархия классов в J2EE? Я не в курсе. По приведённой мной ссылке написано, что Java (а также VB и С#) предлагает компромиссный вариант - позволяет наследовать методы от нескольких классов-интерфейсов, но реализация методов и поля могут быть унаследованы только от одного.

Ок, не буду спорить, т.к. лень искать, да и к нам это имеет совсем опосредованное отношение.

Стоп, братцы. Мы говорим о множественной классификации. Которая конечно, есть часть множественного наследования. Но не полностью ей эквивалентна.
Вспомним еще динамическую классификацию.
Множественное наследование реализована кое-где. Однако нужна обработка инварианта : предпочтение слева или справа. Это все понятно.
Ни множетсвенная, ни динамическая  класификации не имеет средств выражения в UML и языках программирования.

Персона наследует множественно классы: Мужчина - Женщина, Ребенок - Взрослый, Студент и Преподаватель.
А следует получить Женщина - Ребенок - Студент
Как тут? через атрибуты?

Эдуард, давай не будем рубить с плеча, ок?

Во-первых, диаграммы классов UML имеют средства для выражения множественной классификации, что нам Slav тут и подемонстрировал. По первой ссылке по словам multiple classification in uml можно почитать о том, как в Agile методах множественная классификация используется для составления визуальных глоссариев в UML.

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

Динамическая классификация - это отдельная непростая тема и тут пока имхо о ней говорить рано.

Проблема, поставленная Slav, мне кажется несколько надуманной. Давайте вспомним, что каждая модель субъективна, можно создать разные модели одной и той же Пр.Обл.

Далее, давайте различать модели анализа, проектирования и реализации.

Представленная Slav модель по всей видимости является концептуальной моделью анализа, т.к. не содержит атрибутов. Для этих целей (моделирования ПрОбл) она, возможно, достаточно полезна и полна. Ограничение того, что в ЛВС может входить только ПК, можно задать с помощью ассоциации между Аппаратурой и ЛВС и указанием ограничений типа {Мобильность: Стационарная аппаратура; Категория: ПК}, подробнее см. напр. UML 2.0 OCL.

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

"Персона наследует множественно классы: Мужчина - Женщина, Ребенок - Взрослый, Студент и Преподаватель."
Мне казалось, наследует наследник. Разве персона - наследник?

Эдуард, давай не будем рубить с плеча, ок?

Ок, только с чего ты взял, что я рублю. Я просто задаю вопрос.

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

Вот что пишет уважаемый Мацяшек

Множественная классификация
В большинстве современных объектно-ориентированных программных сред объект может принадлежать только одному классу, это жесткое ограничение, поскольку в реальности объект может принадлежать одновременно нескольким классам.
Множественная классификация отличается от множественного наследования. При множественной классификации объект одновременно является экземпляром двух или более классов. При множественном наследовании класс может иметь множество суперклассов, но для каждого объекта должен быть определен единственный класс.
В примере множественного наследования на рис. 2.19 каждый объект Person (такой, как Мери или Питер) принадлежит одному классу (наиболее конкретизированному, который к нему применим). Если Мери — аспирантка (PostgraduateStudent), но не наставник (Tutor), то Мери принадлежит классу PostgraduateStudent.
Проблема возникает при попытке уточнить значение объекта Person для нескольких ортогональных иерархий. Например, личность (Person) может быть сотрудником (Employee) или студентом (Student), мужчиной (Male) или женщиной (Female), ребенком (Child) или взрослым (Adult) и т.д. При отсутствии возможности множественной классификации нам необходимо определить классы для каждой разрешенной комбинации иерархий, чтобы получить, к примеру, объект Person, который является ребенком (Child), женщиной (Female) и студентом (Student) (т.е. класс, который можно было бы назвать ChildFemaleStuden) [25].

Динамическая классификация
В большинстве современных объектно-ориентированных программных сред объект не может сменить класс после того, как он реализован (создан). Это еще одно жесткое ограничение, поскольку в реальности объекты могут динамически изменять класс.
Динамическая классификация является прямым следствием множественной классификации. Объект может не только принадлежать нескольким классам, но также может в процессе своего жизненного цикла приобретать или утрачивать принадлежность к классу.
В случае схемы динамической классификации объект Person в один день может быть просто сотрудником, а в другой— менеджером (и сотрудником). В отсутствие-динамической классификации деловые перемены, такие как продвижение сотрудников, трудно (или даже невозможно) декларативно моделировать в диаграмме классов. Их необходимо моделировать процедурно в диаграмме состояний или с помощью аналогичного метода моделирования.
К сожалению, язык UML не поддерживает моделирования динамической или множественной классификации. Это ставит его по отсутствию поддержки вровень с программными средами. Следовательно, наши пояснения и примеры не обогащены графическими моделями динамической и множественной классификации.

Т.е. вот мои сведения первоначальные и вероятно запутанные.

Почему она не эквивалентна, поясни?

Ну хотя бы их логики выделения отдельного термина. Какой смысл выделять такой термин? Либо я не очень понимаю что такое множественная классификация. Тогда прошу указать источники информации. Например в руководстве по UML авторов - не нашел ничего об этом...

Да, сложный вопрос.

Мацяшек похоже унёс у Фаулера, который пишет в Analysis Patterns и UML Distilled 3:

Multiple classification is different from multiple inheritance.
Multiple inheritance says that a type may have many supertypes but that a single type must be defined for each object.
Multiple classification allows multiple types for an object without defining a specific type for the purpose.

В то же время и Фаулер и Мейер подчёркивают допустимость применения множественной классификации, динамической классификации и множественного наследования на этапе концептуального анализа, но позже рекомендуют перестраивать классификацию в пользу выделенной приоритетной группы:

Мейер
Критерии для наследования видов

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

Все же я нахожу наследование видов полезным при выполнении следующих трех условий:
    * Различные критерии классификации одинаково важны, так что выбор одного в качестве основного представляется спорным.
    * Многие возможные комбинации (такие как в примере: permanent supervisor, temporary engineer, permanent engineer и так далее) являются необходимыми.
    * Рассматриваемые классы настолько важны, что стоит потратить время на разработку лучшей из возможных структур наследования. Чаще всего речь идет в таких случаях о библиотечных классах повторного использования.

Фаулер:
Should you use multiple, dynamic classification? I believe that it is useful for conceptual modeling. For software perspectives, however, the distance between it and the implementations is too much of a leap. In the vast majority of UML diagrams, you'll see only single static classification, so that should be your default.

Уважаемый bas фраза "некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети" всего лищь указывает на то, что человек имеет доступ в "общую" сеть, а не в ЛВС в нутри машины. Если я не правельно выразился прошу прощения. Я не собирался заострять внимание на несущественных моментах данного вопроса. Соответственно диаграмма не коим образом не претендует на полноту.

Slav, извини мою серость и непонимание, но я смотрю на твою диаграмму и неочень понимаю в чем проявляется множественная классификация на ней?
Не мог бы ты еще раз сформулировать положения? Хочется понять ведь..:-)

Братцы, ничего не могу понять тольком

Читаем

Однозначная и множественная классификация

Любой объект принадлежит своему единственному классу. Такое ограничение есть во многих языках моделирования. Однако оно не имеет логического обоснования — достаточно посмотреть на реальные объекты с разных точек зрения. Язык UML основывается на более общем утверждении — объект может одновременно принадлежать нескольким классам. Объект ведет себя таким образом, будто он принадлежит какому-то новому классу, унаследовавшему черты от всех прочих классов, к которым принадлежит этот объект. Таким образом, множественная классификация напоминает множественное наследование, с той лишь разницей, что в этом случае нет необходимости создавать этот новый класс.

Не могу понять эту мысль, выделенную красным.

Аппологеты! Ау!!

Вот кое-что нашел
http://www.optim.su/cs/2004/1/OOP/OOP.asp