Pienso que no, no es lo mismo decir que un caso de uso incluye otro a decir que un caso de uso requiere que otro se haya ejecutado antes de él.

Es decir, creo que hay diferencia entre “include” y “prerequisito”.

Para dejar clara la diferencia, imagina la posibilidad de dos ejecuciones del caso de uso “Viajar en el sistema”. Dos ejecuciones cuyo prerequisito se puede satisfacer con una sola ejecución de “Comprar Ticket” incluso, con mucho tiempo entre estas.

Si hubiera una relación “include”, sería obligar a comprar el Ticket cada vez que se va a viajar en el metro, cosa falsa la verdad, ya que uno puede entrar en la estación y comprar tickets para toda la semana sin tener que viajar necesariamente ese día.

Eso sí, hay que recordar que lo de “prerequisito” visto como relación es poco frecuente. Lo más común es documentar los reprequisitos en una sección del caso de uso en forma textual y no en el diagrama.

¿Cual es la diferencia entre la extensión y la herencia/generalización?

Es decir, la extensión es una dependencia con un estereotipado. En el origen digamos que esta el caso de uso base y en el destino esta el caso de uso que:
a) añade comportamiento sin modificar el comportamiento del origen
b) añade comportamiento y puede modificar el comportamiento de origen.

La extensión es el a ¿verdad?, si fuera el b, no veo ninguna diferencia con la generalización de casos de uso.

La inclusión la tengo claro.

Otra duda parecida, si no es molestia:
En el diagrama de clases, podemos unir las clases mediante:
1- herencia / generalización, flecha
2- dependencia, linea discontinua
3- asociación, linea continua

¿No es cierto que toda herencia supone dependencia? ¿Cuando se usa la dependencia sin estereotipo alguno? Es decir, por lo que veo, en los diagramas de clase, normalmente se usa el 1 y 3, es ¿asi?

Y ya para rayarme finalmente, la asociación indica navegabilidad entre 2 clases, ¿eso no es tambien dependencia?

Me dio por pensar que la dependencia se puede usar para cuando depende del interfaz de la clase, y tener verificado y controlado el efecto onda al modificar una clase.

En fin, aprobaré el parcial sobre esto, pero no estoy seguro si he aprendido aún xD

un saludo.

Ramon

La respuesta es simple: un desarrollo no consiste en hacer diagramas, así que no tienes por que usarlos todos y aún más, no tendrías que usar ninguno del todo.

Si te puedes pasar sin diagramas, quizás valga la pena hacerlo así.

Los diagramas se hacen en aquellos casos en que aporten algo útil. Por ejemplo, si tienes un software que es construido como una maquina de estado, el tener un diagrama con dichos estados puede ser útil para hablar sobre el sistema y entenderlo dentro del grupo de programadores.

Otro ejemplo sería tener un programa que deba ser instalado en múltiples computadores de diversos tipos con diversas configuraciones, de ser este el caso, un diagrama de despliegue te va a permitir visualizar todo a la vez y entenderlo.

Es decir, los diagramas son útiles cuando tienes una historia que contar sobre el sistema. Así que los hacemos cada vez que son útiles y no los hacemos si no tenemos nada que decir o lo hemos dicho de otro modo.

Si vez de cerca las recomendaciones, notaras que los métodos de desarrollo hablan de tareas, de trabajo invertido en la construcción del sistema, enfocándose poco o nada en los instrumentos que en un momento dado te puedan ayudar. Es decir, un desarrollo apegado a un método definido “debe” cumplir con ciertas tareas, y “puede” recurrir a los diagramas UML en aquellos casos en que sean útiles y aporten algo de valor.

En general, en la medida en que el proyecto se haga más complejo de entender y en que participen más personas, será más probable que un diagrama te ayude. Eventualmente en proyectos muy complejos o muy grandes puede que se tengan muchos modelos con múltiples diagramas… pero tenerlos todos es aún así, un poco artificial y en mi experiencia no se dan mucho estos casos.

El modelo de dominio representa al negocio o área en que se va a usar el sistema, por lo que posiblemente sea igual tanto si lo hacemos pensando en la situación actual como si lo hacemos pensando en el sistema futuro.

Si lo que queremos es expresar como es un sistema software hoy en día, el cual vamos a sustituir, lo que usamos es el modelo de diseño de dicho software.

Y claro esta, cuando queramos mostrar el diseño del nuevo sistema de software, recurriremos al modelo de diseño de este nuevo software.

Entonces, en palabras simples:

1. El modelo de dominio describe conceptos del negocio, por lo que posiblemente sea igual en los dos casos que mencionas.

2. El modelo de diseño describe conceptos del software, por lo que es apropiado tanto para mostrar el sistema nuevo como para documentar el anterior.

Espero te sirva.

Saludos!

Esa es una pregunta difícil de responder. Los modelos de dominio son artefactos creativos, que se construyen como parte del proceso de identificación de requisitos ya sea en reuniones con el cliente o como parte de un proceso de aprendizaje en el área de negocio por parte de los analistas.

Si revisas el post “Modelo de Dominio”, cuyo link te copio a continuación, verás que ya ha surgido algo de debate sobre este modelo entre quienes leen el blog.

http://synergix.wordpress.com/2008/07/10/modelo-de-dominio/

En líneas generales, dado que el modelo de dominio es un artefacto que sirve para capturar el conocimiento de un área de negocios, ha de ser desarrollado con fuerte participación del cliente y de expertos en el área. Ya queda a la dinámica propia de dichas reuniones seguir una determinada secuencia de pasos u otra.

Espero haber podido ayudarte. Cualquier cosa no dudes en preguntar de nuevo.