uy y entonces a que etapa de la metodologia de sistemas pertenece un DFD ?? Respondan que hoy doy el final !!
Para mi corresponde al Analisis de requisitos del sistema y al Diseño. Porque lo dice en el cuadernillo .
Cuadernillo pagina 17 dice.
Analisis de requisitos del sistema:
bla bla bla
Se puede trabajar con diferentes paradigmas: estructurado , objetos.
Estos enfoques, dependiendo del paradigma utilizado, utilizan una variedad de tecnicas tales como diagramas de flujo de datos, de entidad relacion, de clases, diccionario de datos, casos de uso , etc.

Y abajo ..

Diseño:

Transforma el modelo creado durante el analisis en las estructuras de datos que se van a requerir para implementar el sistema y ademas se definen las relaciones entre los principales elementos. --->Se utilizan las tecnicas mencionadas para la fase anterior.<-----

(05-12-2011 15:14)AGUSTIN27 escribió:  uy y entonces a que etapa de la metodologia de sistemas pertenece un DFD ?? Respondan que hoy doy el final !!
Para mi corresponde al Analisis de requisitos del sistema y al Diseño. Porque lo dice en el cuadernillo .

Si, yo también leí eso en el cuadernillo en lo que respecta a Análisis de Requisitos. Dice el mismo: "...utilizan una variedad de técnicas tales como diagramas de flujo de datos, de entidad relación, de clases..."
A mi entender, claramente se usan en Análisis de Requisitos, pero se los documentan en el Relevamiento.
Y me parece lógico que sea así. Uno cuando hace el DFD no tiene todavía armado el sistema, sino que es un diagrama que te da una idea de como se mueven (o se debería mover) los flujos de datos en el futuro sistema a implementar, y también los procesos del mismo.

Yo también doy el final hoy,

Y que se responde entonces?

Fijate estos V o F para ver que pondrias che asi nos damos una mano y nos va bien hoy !


http://www.utnianos.com.ar/foro/tema-fin...23-09-2011

Responde ahi de paso cañaso!

(05-12-2011 15:35)AGUSTIN27 escribió:  http://www.utnianos.com.ar/foro/tema-fin...23-09-2011

Responde ahi de paso cañaso!

Che no veo que hayan preguntas concretas allí, solo comentaron mas o menos lo que habían tomado...

si esta medio mal redactado pero bueno.
si hoy nos toca el punto ese del dfd a que etapa corresponde no se que voy a responder, porque unos dicen una cosa y otros otra

La especificación de casos de uso se puede usar para cualquier paradigma, porque sirve para documentar la funcionalidad del sistema desde el punto de vista de usuario, fijar los límites del sistema, etc.

Ahora, el diagrama de casos de uso está dentro del paradigma de objetos. Al menos como está definido en UML.

No, ojo. Los casos de uso se pueden usar tanto en el paradigma estructurado como en OO. Y no está definido en UML, sino que UML lo toma como una de sus herramientas de modelaje, pero casos de uso no forma parte en sí mismo de UML, sino que es una técnica que tranquilamente puede estar aislada, si bien esté fuertemente relacionada al concepto de UML y OO.

el diagrama de casos de usos ES de UML


el tema es que UML esta muy relacionada con Objetos, porque "pega" por asi decir mucho

pero UML es un conjunto de herramientas de modelado, que pueden aplicarse a cualquier paradigma (o deberian. Con el que mejor pegan es como ya dije, con Objetos)


y el diagrama de Casos de Uso ES una de esas herramientas de modelado de ese conjunto

http://www.utnianos.com.ar/foro/tema-apo...mas-teoria
En el doc de casos de uso dice

Cita: Los casos de uso son una técnica independiente del paradigma que se adopte, es decir se podrán utilizar tanto en el paradigma estructurado como en el paradigma orientado a objeto. En base a lo antedicho, se puede concluir en que los casos de uso no son un herramienta propia del UML.
Dada la utilidad e importancia de los casos de uso, UML los incluye dentro del conjunto de herramienta de modelado, definiendo un estándar de representación gráfica, la cual será adoptada en el presente documento.

No sé si está bien ese razonamiento de !POO => !UML

para mi esto esta mal

Cita:En base a lo antedicho, se puede concluir en que los casos de uso no son un herramienta propia del UML.

Es que el problema de lo que dice ahi es que infiere que UML es propio de objetos.. y en realidad UML es una herramienta que existe per se, y que se adapta muy bien a objetos.. pero podria (deberia poderse) usar en otros paradigmas

Son una herramienta de UML, pero puede usarse para otras cosas

Si dijera "herramienta exclusiva", ahí sí es recontrafalso!

---

La gente tiende a pensar mal y hacer exclusivo a los CU y diagramas de CU, en Objetos, y eso está MUY mal.

(22-11-2011 14:38)Anirus escribió:  1) Según Yourdon:
Es una persona o grupo, por ejemplo una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización pero fuera del control del sistema que se está modelando. En algunos casos puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.

También dice que es conveniente poner el papel (rol) de la persona en lugar de la identidad, por lo cuál no sé si b sea correcta, me parece que va c. a y d van seguro, en la carpeta tengo copiado que puede ser un sistema, sector de la organización o un 3ro.

2) Si proceso temporal es aquel que se activa por un flujo temporal es la d, sino ni idea...

Hola chicos, tengo tambien una pequeña pero importante duda aqui. Yo responderia que la respuesta correcta es la "d", y lo justifico diciendo que no hay estimulo o flujo que lo active sino que un evento del tipo temporal se activa por medio del tiempo.
Pero tambien queria hacer una observacion tambien pienso que podria ser un flujo de datos demorado, o sea, un conjunto de datos almacenados que a futuro seran usados como estimulo por otro proceso. Que opinan ustedes?
Espero su aporte chicos
Gracias