Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Slav от 16 Января 2007, 19:10:42
-
Здравствуйте Уважаемые! Хотелось бы услышать ваше мнение по вопросу множественной классификации. Попробую обрисовать ситуацию на примере выдуманной системы. Есть некоторая организация (предприятие). На базе организации существует парк специализированных автомобилей. Каждый из таких автомобилей оборудован аппаратурой. В качестве аппаратуры выступают персональные компьютеры (ПК), а так же аппаратура сетевого доступа (АСД). АСД управляется ПК и передает по беспроводной сети данные с этого ПК. Внутри отдельно взятого автомобиля организуется локальная вычислительная сеть (ЛВС). Соответственно через одну АСД могут передаваться данные с нескольких ПК. На каждом из ПК авторизован один или несколько человек. Всё вышеописанное представлено диаграммой классов на рисунке ниже.
(http://)
Теперь несколько изменим условия, расширив набор аппаратуры. Добавим переносные ПК и переносные АСД. То есть переносной ПК подключается к переносной АСД. Таким образом, некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети. Изменим диаграмму классов в соответствии с введёнными условиями.
(http://)
При разработке диаграммы классов я использовал множественную классификацию. Аппаратура классифицируется, как с точки зрения типа (ПК или АСД), так и с точки зрения расположения (стационарная в автомобиле или переносная). На данной диаграмме присутствуют дискриминаторы классификация, которые явно указываю, что объект класса Аппаратура должен быть либо ПК либо АПД и в то же время являться либо переносным либо стационарным. Но при таком подходе появляется ряд проблем. Во-первых, ассоциация ВходитВ между СтационарнаяАппаратура и ЛВС не задаёт явного ограничения на то, что ЛВС организуется только ПК и не может включать АСД. Ну а во-вторых, это проблемы реализации на языках программирования. Если у вас есть более элегантные решения данной проблемы, то было бы очень интересно их выслушать!
-
Теперь несколько изменим условия, расширив набор аппаратуры. Добавим переносные ПК и переносные АСД. То есть переносной ПК подключается к переносной АСД. Таким образом, некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети. Изменим диаграмму классов в соответствии с введёнными условиями.
А где же у вас на последней Диаграме указано, что "некоторый человек вне автомобиля, может свободно перемещаясь иметь доступ к сети"?
На данной диаграмме присутствуют дискриминаторы классификация, которые явно указываю, что объект класса Аппаратура должен быть либо ПК либо АПД и в то же время являться либо переносным либо стационарным. Но при таком подходе появляется ряд проблем. Во-первых, ассоциация ВходитВ между СтационарнаяАппаратура и ЛВС не задаёт явного ограничения на то, что ЛВС организуется только ПК и не может включать АСД.
Ну Вы сами себе притиворечите! Зачем тогда ТС объеденять в сеть когда в сеть должны быть объеденены ПК?!
Т.е. в итоге вам нужно убрать ассоциацию м/у ТС и ЛВС и м/у СтационарнойАппаратурой и ЛВС. И просто связать ЛВС и ПК
-
А вообще про множественную классификацию можно услышать чуть подробнее. Насколько я знаю UML не имеет средств для выражения этой сути. А языки программирования как это реализуют?
Просто я немного профан(а может быть много:-) ) в этом...
-
А языки программирования как это реализуют?
Через механизм множественного наследования (http://en.wikipedia.org/wiki/Multiple_inheritance), который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.
-
Через механизм множественного наследования (http://en.wikipedia.org/wiki/Multiple_inheritance), который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.
А как же иерархия классов в библиотеке J2EE?
-
Через механизм множественного наследования (http://en.wikipedia.org/wiki/Multiple_inheritance), который кстати не поддерживается мажорами (С#, Java), т.к. в теории это красиво и правильно, а на практике приводит к ряду серьёзных проблем.
А как же иерархия классов в библиотеке J2EE?
А что иерархия классов в J2EE? Я не в курсе. По приведённой мной ссылке написано, что Java (а также VB и С#) предлагает компромиссный вариант - позволяет наследовать методы от нескольких классов-интерфейсов, но реализация методов и поля могут быть унаследованы только от одного.
-
А что иерархия классов в J2EE? Я не в курсе. По приведённой мной ссылке написано, что Java (а также VB и С#) предлагает компромиссный вариант - позволяет наследовать методы от нескольких классов-интерфейсов, но реализация методов и поля могут быть унаследованы только от одного.
Ок, не буду спорить, т.к. лень искать, да и к нам это имеет совсем опосредованное отношение.
-
Стоп, братцы. Мы говорим о множественной классификации. Которая конечно, есть часть множественного наследования. Но не полностью ей эквивалентна.
Вспомним еще динамическую классификацию.
Множественное наследование реализована кое-где. Однако нужна обработка инварианта : предпочтение слева или справа. Это все понятно.
Ни множетсвенная, ни динамическая класификации не имеет средств выражения в UML и языках программирования.
Персона наследует множественно классы: Мужчина - Женщина, Ребенок - Взрослый, Студент и Преподаватель.
А следует получить Женщина - Ребенок - Студент
Как тут? через атрибуты?
-
Эдуард, давай не будем рубить с плеча, ок?
Во-первых, диаграммы классов UML имеют средства для выражения множественной классификации, что нам Slav тут и подемонстрировал. По первой ссылке по словам multiple classification in uml (http://www.google.ru/search?q=multiple+classification+in+uml&ie=utf-8&oe=utf-8&rls=org.mozilla:ru:official&client=firefox-a) можно почитать о том, как в Agile методах множественная классификация используется для составления визуальных глоссариев в UML.
Во-вторых, множественная классификация/обобщение объектного моделирования в языках программирования обычно реализуется с помощью концепции множественного наследования (http://www.eiffel.com/general/monthly_column/2006/October.html). Почему она не эквивалентна, поясни?
Динамическая классификация - это отдельная непростая тема и тут пока имхо о ней говорить рано.
Проблема, поставленная Slav, мне кажется несколько надуманной. Давайте вспомним, что каждая модель субъективна, можно создать разные модели одной и той же Пр.Обл.
Далее, давайте различать модели анализа, проектирования и реализации.
Представленная Slav модель по всей видимости является концептуальной моделью анализа, т.к. не содержит атрибутов. Для этих целей (моделирования ПрОбл) она, возможно, достаточно полезна и полна. Ограничение того, что в ЛВС может входить только ПК, можно задать с помощью ассоциации между Аппаратурой и ЛВС и указанием ограничений типа {Мобильность: Стационарная аппаратура; Категория: ПК}, подробнее см. напр. UML 2.0 OCL (http://www.google.ru/search?hl=ru&client=firefox-a&rls=org.mozilla%3Aru%3Aofficial&q=UML+2.0+OCL&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&lr=).
Проблемы и задачи реализации данной модели на конкретном языке программирования (построение модели реализации) возникают только тогда, когда объектная модель анализа будет дополнена атрибутами и методами и преобразована в модель проектирования. Так вот, при преобразовании проектировщиком модели анализа в модель проектирования он может например принять решение на основании свойств объектов иначе организовать наследование, чем в аналитической модели. Например, возможно, класс "Аппаратура" не несёт никаких полезных для проектирования свойств (на данной модели анализа это не видно) и может быть исключён. Возможно, стоит сделать центральным класс ПК, от него унаследовать СтацПК и МобПК, а для АСД посчитать, что её мобильность не имеет значения, т.к. не имеет специфических свойств, зависящих от мобильности.
"Персона наследует множественно классы: Мужчина - Женщина, Ребенок - Взрослый, Студент и Преподаватель."
Мне казалось, наследует наследник. Разве персона - наследник?
-
Эдуард, давай не будем рубить с плеча, ок?
Ок, только с чего ты взял, что я рублю. Я просто задаю вопрос.
Впервые с термином множественная классификация, я познакомился у "Мацяшек. Анализ требований и проектирования систем". Не скрою, я еще довольно безграмотен в теории ООП.
Потому я зондирую общественное мнение, провоцируя его своими(возможно глупыми) высказываниями:-) Ну судите строго.
Вот что пишет уважаемый Мацяшек
Множественная классификация
В большинстве современных объектно-ориентированных программных сред объект может принадлежать только одному классу, это жесткое ограничение, поскольку в реальности объект может принадлежать одновременно нескольким классам.
Множественная классификация отличается от множественного наследования. При множественной классификации объект одновременно является экземпляром двух или более классов. При множественном наследовании класс может иметь множество суперклассов, но для каждого объекта должен быть определен единственный класс.
В примере множественного наследования на рис. 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. (http://www.win.tue.nl/~wstomv/quotes/analysis-patterns.html)
В то же время и Фаулер и Мейер подчёркивают допустимость применения множественной классификации, динамической классификации и множественного наследования на этапе концептуального анализа, но позже рекомендуют перестраивать классификацию в пользу выделенной приоритетной группы:
Мейер
Критерии для наследования видов
Нет ничего необычного в рассмотрении наследования видов на ранних этапах анализа проблемной области, когда обсуждаются фундаментальные концепции и рассматриваются несколько равно привлекательных критериев классификации. В дальнейших исследованиях часто оказывается, что один из критериев начинает доминировать, выступая в качестве основы построения иерархической структуры. Тогда, как показывает наше обсуждение, следует отказаться от наследования типов в пользу построенной нами схемы.
Все же я нахожу наследование видов полезным при выполнении следующих трех условий:
* Различные критерии классификации одинаково важны, так что выбор одного в качестве основного представляется спорным.
* Многие возможные комбинации (такие как в примере: permanent supervisor, temporary engineer, permanent engineer и так далее) являются необходимыми.
* Рассматриваемые классы настолько важны, что стоит потратить время на разработку лучшей из возможных структур наследования. Чаще всего речь идет в таких случаях о библиотечных классах повторного использования. (http://www.intuit.ru/department/se/ooad/6/10.html)
Фаулер:
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, извини мою серость и непонимание, но я смотрю на твою диаграмму и неочень понимаю в чем проявляется множественная классификация на ней?
Не мог бы ты еще раз сформулировать положения? Хочется понять ведь..:-)
-
Братцы, ничего не могу понять тольком
Читаем
Однозначная и множественная классификация (http://old.sgu.ru/users/matmodel/tutorial/tutor4/Chapter3.htm)
Любой объект принадлежит своему единственному классу. Такое ограничение есть во многих языках моделирования. Однако оно не имеет логического обоснования — достаточно посмотреть на реальные объекты с разных точек зрения. Язык UML основывается на более общем утверждении — объект может одновременно принадлежать нескольким классам. Объект ведет себя таким образом, будто он принадлежит какому-то новому классу, унаследовавшему черты от всех прочих классов, к которым принадлежит этот объект. Таким образом, множественная классификация напоминает множественное наследование, с той лишь разницей, что в этом случае нет необходимости создавать этот новый класс.
Не могу понять эту мысль, выделенную красным.
Аппологеты! Ау!!
-
Вот кое-что нашел
http://www.optim.su/cs/2004/1/OOP/OOP.asp
-
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 ты привел пример классического множественного наследования. В твоём примере экземпляр класса Тигр неявным образом является экземпляром всех своих суперклассов Животное,Млекопитающее,Хищник. На рисунке я слегка подкорректировал твой пример так, что бы всё стало понятно. Я дополнительно классифицировал класс Животные по возрастному признаку и ввел два подкласса СтароеЖивотное и МолодоеЖивотной. Легко видеть, что любое животное является Млекопитающим и/или Хищником и МолодымЖивотным ЛИБО И СтарымЖивотным. То есть животное не может быть одновременно молодым и старым. Поэтому если на своей диаграмме я класс Тигр наследую от какого-то одного класса ( скажем МолодоеЖивотное), то явным образом отмечу, что все мои Тигры молодые, а старых не существует в принципе. Но поскольку меня учили никогда не врать, ;) я пытаюсь решить проблему. Для этого класс Тигр делаю наследником обоих классов (МолодоеЖивотное и СтароеЖивотное). Но в этом случае мои учителя опять смотрят на меня с упрёком. Получается, что Тигры стали и молодыми и старыми одновременно. :D Ват такая вот весёлая картинка. Поэтому, при такой множественной классификации, возможные комбинации не описываются каким-либо классом (например Тигр).
(http://)
-
Т.е. мы никак не можем изобразить факт такого наследования или там чего-то еще. И просто подразумевается само собой?
-
Саша, спасибо. Только мнене эта классификация нужна, а классификация в ООП. Если это одно и тоже, тогда вообщем-то ясно, что такое эта множественная классификация. Да вообщем-то все понятно, вопрос только в том, каким образом в моделировании отражать факт этой самой множестенной классификации. И можно ли говорить, что множестевнное наследование частный случай классификации ?
-
... вопрос только в том, каким образом в моделировании отражать факт этой самой множестенной классификации. И можно ли говорить, что множестевнное наследование частный случай классификации ?
Ну в модели я те показал, как это отображается
А множественное наследование - это один из способов множественнной классификации.
... Я дополнительно классифицировал класс Животные по возрастному признаку и ввел два подкласса СтароеЖивотное и МолодоеЖивотной. Легко видеть, что любое животное является Млекопитающим и/или Хищником и МолодымЖивотным ЛИБО И СтарымЖивотным. ...
Сейчас не под рукой рисовалки, поэтому пишу так:
|---------------Молодое<---------------------------------МолодойТигр-|
| |
|---------------Старое<---------------------------------- СтарыйТигр |
Животное <---| | |
|---------------Хищник <--------------| | |
| |-------Тигр<--------|----------|
|---------------Млекопитающее<------|
-
В частности, чем ближе эти механизмы к явно заданным бизнес-правилам предметной области (то бизнес-правила не размазываются тонким слоем по всей системе), тем ближе мы подходим к декларативному програмированию (куда стремимся при создании многих приложений).
Будь ласка, чуть подробнее про декларативное программирование. Почему мы туда стремимся?
-
[Глубинной некротредофилии псто]
Актуальная версия UML разрешает объекту иметь сколько угодно типов (классификаторов), просто перечисленных в описании через запятую. Если под термином "множественная классификация" имеется в виду эта способность, то UML нативно поддерживает "множественную классификацию".
Курьёзно, что UML в своей актуальной версии нативно поддерживает "динамическую классификацию". В частности параграфе 9.4.3.4 есть явные слова о том, что у параметра BehavioralFeature можно указать эффект = update, и это будет означать, что объект, поданный как этот параметр, может поменять свою классификацию в ходе выполнения поведения, описанного этой BehavioralFeature. Параграф 16.4.3.7 описывает специальные ReclassifyObjectAction-ы, которые меняют у объекта на своём входном пине список его классификаторов. В следующем параграфе расказывается про ReadIsClassifiedObjectAction-ы, которые чекают, может ли объект классифицироваться конкретным типом (классификатором).
В области ЯП, как подсказывает мой ксенолингвист, "классификация" называется "типизацией". Системы типов ЯП определяют правила, по которым в них работают аналоги ReadIsClassifiedObjectAction-ов и ReclassifyObjectAction-ов.