Ver Mensaje Individual
  #3  
Antiguo 23-10-2012
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 25
Delphius Va camino a la fama
Cita:
Empezado por nlsgarcia Ver Mensaje

1- Es conveniente que empieces a modelar tu proyecto usando Casos de Uso de lo general (DFD-0) a lo particular (DFD-1, DFD-2, ... , DFD-n)

2- En principio puedes modelar los objetos por medio de DER y DFD sustituyendo las tablas (DER) y los procesos (DFD) por las clases del área de negocio a modelar, tomando en cuenta durante el análisis que los verbos serán métodos de clase y los sustantivos atributos de clase. El modelo de clases es más rico semánticamente y puede expresar mucho mejor sus relaciones de clases que un DER o un DFD, aunque es factible su uso por medio de estereotipos de UML. Es de tomar en cuenta que en las clases se presentan relaciones de herencia y polimorfismo propias del modelo orientado a objetos que no son posibles de modelar en un DFD o DER por lo cual es necesario otro tipo de diagramas.
Con sólo leer esto me bastó para comprender que tienes unas confusiones mentales y que tienes una ensalada de cosas en tu cabeza.
No sabía que los CU (Casos de Uso) se hacen con DFDs (Diagrama de Flujo de Datos). Resulta ahora que el Análisis Estructurado Moderno cuenta con los Casos de Uso y se aplica para OO.

¿Tienes alguna idea de lo que es un DFD realmente? ¿Tienes alguna idea real de lo que es un Caso de Uso y para que o cuando aplica?

Me parece que no porque no se puede mezclar el pensamiento estructurado con conceptos de clases (que pertenece al paradigma Orientado a Objeto), y ni que decir... de mezclarlo inclusive con DER o Diagrama Entidad Relación.

El DFD es parte de los Diagramas que pertenecen al Análisis Estructurado Moderno. Está pensado para representar los procesos que intervienen en el contexto. Existen varios niveles, el DFD-0 tiene por objetivo representar al sistema con los procesos esenciales, delimitando los límites y alcances. Se representan en el el flujo de datos hacia el sistema como también las respuestas de éste hacia las entidades externas. Luego a este DFD-0 se lo explota y por cada uno de los procesos se diseña un DFD-1. Ahora existe una burbuja central que representa al proceso y se muestran las subburbujas o subprocesos que colaboran, dependen o en los que delega. Se puede continuar el análisis tanto como se requiera... por cada subproceso. De allí que se puede tener tantos DFDs como subprocesos dignos de marcar. Con estos DFDs es que luego se diseña el Diagrama de Estructuras.
Para hacer el DFD-0 se requiere de haber llevado a cabo la lista de eventos. Tanto la lista de eventos como el DFD-0 pertenecen al Modelo del Ambiente o Modelo del Conexto, una de las dos ramas en la que se clasifica el Análisis Estructurado Moderno.

En ningún momento se aprecia en los DFDs algo sobre clases... ni sus métodos, nada de eso. Porque cada proceso no es una clase, ES UN MODULO/SUBMODULO. Estamos en el paradigma estructurado.
Sugiero que te informes bien, agarra mejor un libro mucho más amplio... Recomiendo la lectura de Introducción al Análsisis Estructrurado Moderno de Yourdon.

Por otro lado si bien los Casos de Uso son una herramienta muy útil para reconocer las potenciales clases conceptuales, tampoco es una herramienta OO. Producto de una mala enseñanza se tiene la creencia que hacer Casos de Uso es hacer A/DOO. Los Casos de Uso son independientes del paradigma.
Son "historias" en las que se busca explicar los procesos de interés a nivel de negocio que le aportan utilidad. El error conceptual de muchos se debe a hechos de casualidad histórica. En los años en que el paradigma OO ganaba terreno (recuerden que el paradigma data de finales de la década del 60), la manera de pensar OO sacudió el tablero y la gente estaba pidiendo una nueva forma de conducir sus desarrollos... para ese entonces surgían paralelamente las primeras propuestas de desarrollar un lenguaje visual OO (Análisis Estructurado Moderno es otro lenguaje visual), y por el otro los paradigmas de desarrollo o de maduración del proceso basados en una perspectiva iterativa e incremental. Estas propuestas paralelas derivaron en lo que se conoce como UML y el principio UP por el otro.
En UML tomaron dichas historias, y ofrecieron una herramienta visual para ordenarlos: el DCU o Diagrama de Caso de Uso... más no quiere decir que extrictamente hacer un CU sea pensar en OO.
La confusión hubiera sido menor si no fuera por Rational, que tomando la filosofía del modelo UP propuso RUP. RUP clasifica su proceso en disciplinas, y tomo a UML como una herramienta más de trabajo para conducir las ideas. Clasificó de una manera formal a los diferentes diagramas UML en cada disciplina según el punto de vista que ofrece del contexto. A cada grupo de estos diagramas, les llamó Modelo.
Por ejemplo el Modelo del Dominio (RUP), que pertenece a la disciplina Modelado del Negocio (o también llamado Modelo de Negocio) consta del Diagrama de Clases; los CU, DCU, Diagrama de Secuencia a Nivel de Sistema (que algo más o menos se quisiera equiparar al DFD-0) o DSS y Contratos se agrupan en el Modelo de Casos de Uso, que pertenece a la disciplina Requisitos.
Entonces se confundió a la gente de que Casos de Uso, es algo propio del pensamiento OO, y también de que para hacer CUs se debe hacer UML y peor aún que utilizar UML necesariamente lleve a utilizarse RUP/UP/USDP.

Para comprender mejor todo esto, recomiendo leer libros de Ingeniería de Software que lo dejan bien en claro.

Cita:
Empezado por nlsgarcia Ver Mensaje
3- Te recomiendo que uses UML (Unified Modeling Language) en el podrás encontrar varios tipos de diagramas que te permitirán modelar tu proyecto:

- Diagramas de Use Cases.
- Diagramas de Clases.
- Diagramas de Estados.
- Diagramas de Secuencia.
- Diagramas de Colaboración ó Comunicación.
- Diagramas de Actividades
- Diagramas de Objetos
- Diagramas de Componentes
- Diagramas de Distribución
Bueno, al fin una buena. Bueno... quizá algunas pequeñas correcciones. Una cosa es el Diagrama de Colaboración y otra el de Comunicación. Inicialmente no existía el diagrama de Comunicación ya que apareció en 2.0; y la idea era reemplazar al de Colaboración por el de Comunicación ya que éste ofrecía una cosas que el otro no. Pero en vista a que podría confundir a algunos, se decidió mantenerlos a ambos. Técnicamente hablando, el de Comunicación es una extensión al de Colaboración y pueden utilizarse indistintamente, ya que comparten muchas similitudes. Hoy son dos hermanos y la idea es utilizar cada uno cuando se requiera.
Nombraste a todos en español, excepto el primero: el Diagrama de Caso de Uso. No entiendo el porqué esa fobia de nombrar a los CUs en inglés y a los demás en español... ¡o todos en inglés, o todos en español!
Te faltó comentar que NO ES OBLIGACIÓN QUE SE DIBUJEN TODOS LOS DIAGRAMAS. Cada diagrama está pensado para ofrecer una perspectiva diferente del sistema. Si uno elije utilizar UML como herramienta de trabajo debe tener en cuenta que en ningún momento UML te obliga a hacerlos todos, y ni que decir... en ningún orden (esto último es uno de los errores que más he detectado en muchos estudiantes).

Cita:
Empezado por nlsgarcia Ver Mensaje
4- Hay un libro titulado "Aprendiendo UML en 24 Horas" que te dará un perspectiva rápida de UML para profundizar posteriormente según requiera el proyecto.
Dejemos de fomentar estos libros. O se aprende bien o nada. En 24hs no se aprende nada, ni bien. Todo lo contrario: te surjen más dudas que respuestas, te marea porque ahora debes leerte un libro de 900 hojas para comprender el guisado mental que te ha dado ese paneo breve que no está acabado.

Hubieras recomendado UML Gota a Gota de Martin Fowler en todo caso. Que mal que bien, te presenta las cosas de una forma simple. Por mi parte lectura casi obligada: UML y Patrones y una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado de Craig Larmman. Y también leer, a estas alturas, UML 2.0 (y pensando en irse a la 2.5 en cuanto salga su publicación) escrito por sus tres gurus.

Cita:
Empezado por nlsgarcia Ver Mensaje
5- Puedes conseguir mucha información de UML en Internet y en la Red P2P Emule.

Espero sea útil

Nelson
Puedes conseguir información de primera mano, más completa, detallada, precisa, formal, profesional en los libros de las bibliotecas. Más libros menos P2P.

Y luego uno se pregunta porqué hay quienes tienen un tutti frutti en sus cabezas

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita