Sobre UML

kraneok #1 Abr '13 Penitente

Hola señores, vengo con una duda un poco distinta..creo..xD.

Resulta que me han mandado un trabajo donde tengo que exponer los diagramas que UML utiliza comparandolos con un guión de diseño y desarollo que el profesor nos dio, básicamente el que el hizo junto a un grupo mas de ingerieros o algo así nos comentó.

Dicho guión de diseño y desarrollo contempla el uso del Diagrama de Clases Lógico Relacional, este diagrama no se encuentra definido como técnica en UML, si embago si que está el Diagrama de Clases.
Aunque el Diagrama de Clases Lógico Relacional sirve para diseñar la estructura final de la base de datos en caso de que el sistema la vaya a necesitar, se puede decir que el Diagrama de Clases Lógico Relacional es el mismo que el Diagrama de Clases solo que añadiendo las relaciones, cardinalidades, etc?

Espero que alguien me pueda ayudar, estoy en apuros y no se salir de esto, y la verdad, en San Google no me queda claro nada, puesto que cada uno dice lo que le sale los huevos ( igual que mi profesor ).

Un saludo!

Tig #2 Abr '13

¿Alguien trabaja con UML? ¿En empresas grandes se usa? Lo vi en la carrera pero ahí se quedó...

Lo siento, no te puedo ayudar

1 respuesta

elkaoD #3 Abr '13

#2 es la Ingeniería del Software de los años 90. Es el pasado, pero es lo que tiene la carrera, va por detrás del "estado del arte".

#1 "se puede decir que el Diagrama de Clases Lógico Relacional es el mismo que el Diagrama de Clases solo que añadiendo las relaciones, cardinalidades, etc?"

No exactamente. El diagrama de clases especifica datos, relaciones y acciones; mientras que el E/R (creo que a eso te refieres con "lógico relacional" ) expresa sólo datos y relaciones (pero no acciones).

Recuerda que una clase es la encapsulación de datos y comportamiento, mientras que en una BD el comportamiento no tiene sentido.

Por cierto, el diagrama de clases también expresa relaciones (de hecho más específicas, porque distingue entre composición, agregación, etc.)

1 respuesta

kraneok #4 Abr '13 Penitente

#3 El Modelo Lógico Relacional supongo que es referido a la definición de la arquitectura de la base de datos, osea, que no tiene cabida dentro de UML, ¿ no ?

1 respuesta

bLero #5 Abr '13

#1

Yo creo que a lo que se refiere tu profesor es a un modelo del dominio de la aplicación. Que difiere sustancialmente de un diagrama de clases.

Por poner un ejemplo, imaginate una aplicación para la gestión de un almacén. Tendríamos como clases proveedores, productos, vendedores, facturas, etc, y ademas todas las clases para dibujar la UI, las clases encargadas de la persistencia (DAOs) etc.

En un diagrama de clases tendrías que reflejar todo lo arriba expuesto, mientras que en un diagrama logico-relacional tienes que centrar la atención en las clases modelo del negocio, es decir, únicamente en proveedores, productos, vendedores y facturas. Y además describir sus relacciones y cardinalidades (cosa que no haces en un diagrama de clases).

2 respuestas

elkaoD #6 Abr '13

#4 no, no es parte de UML si es eso lo que preguntas.

http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview

#5 "cosa que no haces en un diagrama de clases"

:S Yo siempre he visto los diagramas de clases con relaciones y sus cardinalidades.

1 respuesta

kraneok #7 Abr '13 Penitente

#6 Bien, gracias, entonces ya se por donde van los tiros xD.

#5 No es ese tipo de diagrama, el de dominio si lo he tocado.

PD: De todas formas lo que pasa es lo siguiente.
De un diagrama de clases vamos transformandolo en un diagrama relacional de para la base de datos, es aquí donde se determina que elementos del diagrama se van a quedar como clases del sistema y como otros van a ser tablas de la base de datos.

Muchas gracias a todos.

1 respuesta

bLero #8 Abr '13

#7

Entonces se referirá a un diagrama entidad-relación para definir la estructura de la base de datos.

#5

Las relaciones y cardinalidades sólo tienen sentido en las clases modelo del negocio. Qué relaciones o cardinalidad pondrías en clases como JDBCFacturaDao que implementa la interfaz FacturaDao, que se obtiene con el patrón Factory Method, a través de una clase Helper que carga la clase Services a partir de un fichero de texto con su ruta parcial.

En estos casos sólo te limitas a indicar el nombre de las clases, (sin atributos siquiera, y sólo con los métodos más importantes) y lo que adquiere importancia es qué clase implementa a cual, cual hereda de cual, y cual tiene una instancia de cual.

1 respuesta

elkaoD #9 Abr '13

#8 pues sólo con la primera frase indicaría que implementa la inferfaz FacturaDao.

Factory method también es expresable como relación (y deberías expresarlo para dejar claro el patrón):

Si no he entendido mal tu ejemplo:

"a través de una clase Helper"

Relación (es el ConcreteCreator de arriba).

"que carga la clase Services"

Relación (es el Product de arriba).

EDIT: Entiendo que si no lo haces es porque UML es una castaña y no merece la pena llegar a tanto nivel de detalle (¿merece la pena UML siquiera?) máxime cuando los requisitos y la arquitectura te van a cambiar, pero poderse se puede... pero vamos para eso pues no haces UML y te haces un diagrama abstracto y santas pascuas.

EDIT2: Acabo de leerte "lo que adquiere importancia es qué clase implementa a cual, cual hereda de cual, y cual tiene una instancia de cual." ¡Eso son relaciones! Obviamente no les vas a poner cardinalidad porque son relaciones con cardinalidad implícita, pero si la clase tiene relaciones de agregación/composición pues se ponen (junto a su cardinalidad).

1 respuesta

bLero #10 Abr '13

#9

Respecto al EDIT2: Sí, son relaciones, aunque yo me refería a especificar con texto la relación, me he expresado mal.

Esas descripciones en las relaciones y cardinalidades se suelen utilizar en los modelos de dominio, pero no en los modelos globales de clases. A eso me refería.

1 respuesta

elkaoD #11 Abr '13

#10 aaah ok! Entendido

EnZo #12 Abr '13

En sustitucion a un diagrama UML que se hace? Que es lo que suelen hacer las empresas para representar una app tocha?

1 respuesta

Tig #13 Abr '13

#12 no he hecho proyectos MUY grandes, pero la idea es identificar los bloques de una aplicación y modularizarlos, de manera que son cajas negras con las que hablas a través de un interfaz de entrada salida, algo así como un API.

Diría que no es muy distinto a UML, donde si no recuerdo mal se hacía algo de alto nivel parecido, pero luego la locura era identificar las clases y métodos, diagramas de flujo, etc. Y todo antes de ponerte a picar código.

Ya desde el punto de vista de gestión de proyectos, creo que el problema de desarrollos en cascada (UML/Diagramas de Gantt, etc.) es su rigidez para adaptarse a cambios (nuevos requisitos, problemas inesperados), mientras que ahora se apuesta por iteraciones de trabajo más cortas y donde se es capaz de reaccionar a opiniones de clientes o adaptarse a fallos.

Por lo que veo, elkaoD sabrá más que yo de todo esto. Si he dicho algo erróneo que me corrija ^^

3 respuestas

MTX_Anubis #14 Abr '13 :psyduck:

#13 Ya desde el punto de vista de gestión de proyectos, creo que el problema de desarrollos en cascada (UML/Diagramas de Gantt, etc.) es su rigidez para adaptarse a cambios

Por eso es la ingeniería del software de los 90 xD.

Ahora se lleva el agilismo!

EnZo #15 Abr '13

#13 Pero esa metodologia de disenio tiene nombre? Para buscar documentacion o algo digo.

1 respuesta

elkaoD #16 Abr '13

#15 tienes que tirar a varios conceptos. UML no es una metodología, es un lenguaje de modelado.

Busca sobre Agile, SCRUM, etc. en cuanto a metodología de desarrollo de software.

En cuanto a modelado... es "menos diagramas, más código". Los diagramas son de más alto nivel y no necesitas que estén regulados como UML, sino que son simples diagramas conceptuales para guiar el entendimiento del software. Si no puedo entender tu diagrama sin acudir a un estándar, "you're doing something wrong".

Ya ni siquiera se usan diagramas para diseñar porque no se diseña. Diseñar es para n00bs Se favorecen iteraciones rápidas en muchos casos dirigidas por comportamiento (BDD, TDD). La teoría es que documentar el diseño es contraproducente porque el diseño cambia radicalmente en las primeras fases del desarrollo y no vale de nada diseñar pasadas estas primeras fases porque el diseño ya está implícito en los resultados de estas primeras iteraciones. La idea es que hay que favorecer el prototipado y el desarrollo incremental frente a un desarrollo monolítico/en cascada.

Además ahora el código ahora se auto-documenta (véase Javadocs, Docco y tal).

En resumen: lo que ha dicho #13 solo que ahora hay mil "escuelas" y cada una tiene su forma de trabajar... Es lógico si lo piensas partiendo de la base de que no hay una metodología universal que funcione para todos los proyectos ni para todos los equipos. Las propias metodologías ágiles favorecen la "personalización" de estas.

Usuarios habituales