UML para javascript?

Busco una forma de representar gráficamente objetos de javascript ...UML para javascript?

Sé que es UML, pero por ejemplo, la forma de representar los cadena entre 2 objetos, por ejemplo:

var a, b; 

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

Intuitivamente, yo dibujo algo como esto:

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

pero ¿hay una representación decente en UML?

¿Y qué hay de mixins?

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

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

Fuente

2012-01-18 abernier

Parece que está intentando mostrar la relación entre las instancias de objeto en un diagrama de clase. Esto no funcionará realmente; es probable que desee intentar usar un diagrama de instancia UML (también se lo puede llamar diagrama de objeto). Un diagrama de clases pretende capturar los conceptos del sistema, su estructura y sus relaciones de una manera estática. Puede ser útil comenzar con un diagrama de clases y luego pasar a un diagrama de instancia donde puede conectar algunos valores en las "ranuras" o propiedades de las instancias de objeto para ver si funciona el modelo en su diagrama de clases.

Fuente

2012-01-18 23:07:38 RobertMS

Lo primero que debe saber es que JavaScript usa prototype-based inheritance. Esto significa que no hay distinción entre clases e instancias como en otros lenguajes OO (como Java). Solo hay objetos. Una implicación de eso es que diferenciar entre class y object diagrams no tiene sentido.

Para el primer ejemplo:

var a, b; 

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

Esta es la herencia - b objeto hereda las propiedades de objeto a.

manera correcta para modelar esto en UML es este diagrama de clases/objeto:

object b inherits from object a

Mixins puede ser visto como una forma de herencia múltiple, objeto c hereda propiedades de objeto a y b, diagrama para que podría tener este aspecto:

object c inherits from a and b

Fuente

2012-02-23 13:13:31 romario333

No es del todo exacto que no haya diferencia entre un objeto y su clase. Al menos no desde un punto de vista teórico tipo. Cualquier objeto tiene un tipo dado. Cualquier objeto con el mismo prototipo deriva del mismo tipo y cualquier objeto con el mismo prototipo y las mismas propiedades de objeto tienen el mismo tipo. De modo que puede tener y es probable que tenga más objetos que tipos. Sin embargo, eso no invalida tu punto :) –

Una forma más técnicamente correcta de decirlo es que no hay representación de clase en JavaScript. – ArtB

Dado que ha habido unos pocos años desde esta publicación. Permítame dejar claro a quien lea esto que ECMAScript 2015 incluye clases ahora y que no se aleja de la herencia basada en prototipos. [enlace] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes) – Nightforce2

Sus ejemplos son las relaciones que representan caderas entre objetos, no clases, por lo que el diagrama de objetos UML es el camino a seguir (como ya lo ha señalado RobertMS).

Los objetos están relacionados entre sí en el sentido de que (en el primer caso) objeto a es el prototipo de objeto b. Usaría una relación de dependencia para esto. Wikipedia tiene una buena descripción de la notación de dependencia UML here.

La razón para usar una dependencia es que refleja la noción de que "un cambio en el elemento influente o de modelado independiente puede afectar la semántica del elemento de modelado dependiente". Dado que a menudo utilizamos objetos prototipo para mantener las propiedades predeterminadas, así como los métodos, para una colección de objetos "dependientes" (es decir,, objetos de la misma "clase"), este uso de la dependencia parece justificable, si no quizás un poco controvertido.

Etiquetaría la dependencia con el estereotipo "< < proto >>".

UML le da mucha flexibilidad, aunque es bueno seguir las convenciones.

Hay un buen tratamiento de diagramas de objetos en this page by Scott Ambler.

En su segundo ejemplo, al usar la función jQuery extend, no tiene una verdadera relación de prototipo, pero está fusionando propiedades de algunos objetos en otro objeto. En este caso, no estoy seguro de que exista un término de modelado global específico para esto. Aunque hay una especie de dependencia aquí. Sugeriría consultar la lista de estereotipos de dependencia UML estándar (enumerados en la página de Wikipedia mencionada anteriormente) y ver si algo tiene sentido en su aplicación específica. Tal vez < < refinar >> ¿funciona para usted?

Fuente

2012-02-27 08:02:48

¿Por qué no utilizar la herencia? Creo que es más adecuado en este caso, porque la herencia indica una relación mucho más cercana entre dos objetos que solo la dependencia. Ignoraría que no deberías usar diagramas de clases, UML no fue diseñado teniendo en cuenta la herencia basada en prototipos. – romario333

Yo _sería_utilizar la herencia UML para JS _if_ el ejemplo del OP era diferente, p. Ej. un Ctor de forma con un prototipo y un Ctor de círculo cuyo prototipo estaba vinculado a Shape.prototype! Pero el OP mostró solo objetos individuales, y nunca mostró nada que me pareciera una subclase. Todo lo que pude ver fue que los objetos se derivan de otros objetos. En todo caso, en el primer ejemplo, es más como 'a' es el" tipo "y' b' es la "instancia" (así es como se usa 'Object.create'). Sin subclases Sin embargo, estoy de acuerdo con usted en que debemos aprovechar la flexibilidad de UML e ignorar las cosas cuando sea necesario. –

La herencia con solo 'Object.create' es bastante [práctica común] (http://javascript.crockford.com/prototypal.html). Otra razón por la que creo que la herencia es un mejor enfoque aquí es que cualquier propiedad dentro del objeto 'a' es" heredada "por' b', se vuelven parte de la interfaz de b's. – romario333

Respuesta

Cuestiones relacionadas