UML для JavaScript?

Я ищу способ графического представления объектов javascript...

Я знаю, что есть UML, но, например, как представить цепочку между двумя объектами, например:

var a, b;

a = {};
b = Object.create(a);

Интуитивно я бы нарисовал что-то вроде этого:

+-----+
|b    |
|-----|
|     |
+--+--+
   |     +-----+
   +---->|a    |
         |-----|
         |     |
         +-----+

но есть ли достойное представление в UML?

А как насчет примесей?

c = $.extend({}, a, b)

+-----+           +-----+
|a    |           |b    |
|-----|           |-----|
|     |<----------|     |
+-----+           +-----+
   +     +-----+
   |     |c    |
   |     |-----|
   +---->|     |
         +-----+

javascript uml object-diagram
person abernier    schedule 18.01.2012    source источник

Ответы (3)


arrow_upward
7
arrow_downward

Первое, что вам нужно знать, это то, что JavaScript использует наследование на основе прототипа. Это означает, что нет различий между классами и экземплярами, как в других объектно-ориентированных языках (таких как Java). Есть просто объекты. Одним из следствий этого является различие между классом и диаграммы объектов не имеет смысла.

К вашему первому примеру:

var a, b;

a = {};
b = Object.create(a);

Это наследование - объект b наследует свойства объекта a.

Правильный способ смоделировать это в UML - это диаграмма классов/объектов:

объект b наследуется от объекта a

Миксины можно рассматривать как форму множественного наследования, объект c наследует свойства от объектов a и b, диаграмма для этого может выглядеть так:

объект c наследуется от a и b

person romario333    schedule 23.02.2012
comment
Не совсем точно, что нет никакой разницы между объектом и его классом. По крайней мере, не с теоретической точки зрения типов. Любой объект имеет заданный тип. Любой объект с одним и тем же прототипом является производным от одного и того же типа, и любой объект с одним и тем же прототипом и одними и теми же свойствами объекта имеет один и тот же тип. Таким образом, у вас может быть и, вероятно, будет больше объектов, чем типов. Однако это не отменяет вашей точки зрения :) - person Rune FS; 08.03.2013
comment
Более технически правильно сказать, что в JavaScript нет представления класса. - person Sled; 06.11.2013
comment
Так как с момента публикации этого поста прошло несколько лет. Позвольте мне просто пояснить всем, кто это читает, что ECMAScript 2015 теперь включает классы и не отклоняется от наследования на основе прототипов. ссылка - person Nightforce2; 19.01.2018

arrow_upward
3
arrow_downward

Похоже, вы пытаетесь показать отношения между экземплярами объектов на диаграмме классов. Это не сработает; вы, вероятно, захотите попробовать использовать диаграмму экземпляров UML (ее также можно назвать диаграммой объектов). Диаграмма классов предназначена для фиксирования системных концепций, их структуры и взаимосвязей статическим образом. Это может помочь начать с диаграммы классов, а затем перейти к диаграмме экземпляров, где вы можете вставить некоторые значения в «слоты» или свойства экземпляров вашего объекта, чтобы увидеть, работает ли модель в вашей диаграмме классов.

person RobertMS    schedule 18.01.2012

arrow_upward
1
arrow_downward

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

Объекты связаны друг с другом в том смысле, что (в первом случае) объект a является прототипом объекта b. Я бы использовал для этого отношения зависимости. В Википедии есть хорошее описание нотации зависимостей UML здесь.

Обоснование использования зависимости состоит в том, что она отражает представление о том, что «изменение влияющего или независимого элемента моделирования может повлиять на семантику зависимого элемента моделирования». Поскольку мы часто используем объекты-прототипы для хранения свойств по умолчанию, а также методов для набора «зависимых» объектов (то есть объектов одного и того же «класса»), такое использование зависимости кажется оправданным, если не спорным.

Я бы назвал зависимость стереотипом «‹‹proto>>».

UML действительно дает вам большую гибкость, хотя и приятно следовать соглашению.

На этой странице Скотта Амблера есть хорошее описание диаграмм объектов.

Во втором примере, используя функцию jQuery extend, у вас нет настоящего отношения к прототипу, но вы объединяете свойства некоторых объектов с другим объектом. В этом случае я не уверен, что для этого существует конкретный всеобъемлющий термин моделирования. Однако здесь есть своего рода зависимость. Я бы посоветовал просмотреть список стандартных стереотипов зависимостей UML (перечисленных на вышеупомянутой странице Википедии) и посмотреть, имеет ли что-нибудь смысл в вашем конкретном приложении. Возможно, вам подходит ‹‹refine>>?

person Ray Toal    schedule 27.02.2012
comment
Почему бы не использовать наследование? Я считаю, что в данном случае это больше подходит, потому что наследование указывает на гораздо более тесную связь между двумя объектами, чем просто зависимость. Я бы проигнорировал тот факт, что вы не должны использовать диаграммы классов, UML не был разработан с учетом наследования на основе прототипов. - person romario333; 27.02.2012
comment
Я использовал бы наследование UML для JS, если бы пример OP был другим, например. ctor Shape с прототипом и ctor Circle, чей прототип был связан с Shape.prototype! Но ОП показывал только отдельные объекты и никогда не показывал ничего похожего на подклассы. Все, что я мог видеть, это объекты, производные от других объектов. Во всяком случае, в первом примере это больше похоже на то, что a — это тип, а b — это экземпляр (именно так используется Object.create). Без подклассов. Однако я согласен с вами в том, что мы должны использовать гибкость UML и игнорировать некоторые вещи там, где это необходимо. - person Ray Toal; 27.02.2012
comment
Наследование с использованием только Object.create — довольно обычная практика. Еще одна причина, по которой я считаю, что наследование здесь является лучшим подходом, заключается в том, что любые свойства внутри объекта a наследуются b, они становятся частью интерфейса b. - person romario333; 27.02.2012
comment
Ваш подход заключается в том, чтобы сделать упор на ссылку прототипа. Это может быть нормально, если вы хотите объяснить кому-то, как работает цепочка прототипов и поиск свойств. Это не обычный сценарий, хотя ИМО. В конце концов, это зависит от целевой аудитории вашей диаграммы :-) - person romario333; 27.02.2012
comment
Конечно, достаточно справедливо. Нет ничего плохого в традиционных ссылках наследования UML в JavaScript, потому что вы, безусловно, можете имитировать наследование интерфейса с помощью прототипов. Распространенный или нет, но то, как я прочитал вопрос ОП (мне он показался ясным!), заключался в том, что он спрашивал, как я представляю конкретную связь между objects? Возможно, цель вопроса была в чем-то другом, кто знает. Очевидно, что если целевая аудитория должна потреблять высокоуровневую модель, то диаграмма классов подойдет. - person Ray Toal; 28.02.2012