[[Delphius]]

Empezado por nlsgarcia

Delphius,

Nuevamente gracias por tus comentarios, creo que toda opinión es válida y da la oportunidad de aprender, mejorar y crecer profesionalmente.

¿Toda? Ummm... estoy pensando si las opiniones de Hitler son válidas y para la mejora de muchos

Empezado por nlsgarcia

Esta comentado en el punto 2 de mi primera respuesta y explicado en mayor detalle en la segunda respuesta a tus comentarios.

A ver... veamos. Tu punto 2 fue este:

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.

Y tu ampliación fue:

El hacer un paralelismo entre procesos en un DFD y entidades en un DER con clases no esta lejos de la realidad, al final una clase es un conjunto de métodos y atributos que modelan por abstracción procesos y datos asociados en el mundo real de forma unisona por medio de un paradigma OO y UML permite por medio de los mecanismos de extensión, en este caso los estereotipos, hacer uso de nuevos elementos visuales con la salvedad de que estos nuevos elementos no forman parte del estándar UML y por consiguiente pueden prestarse a confusión y polémicas, teniendo sentido solamente dentro del contexto particular en que se los definió, por lo cual entiendo tu posición pero es algo que se puede usar si se considera que aporta mayor expresividad semántica al análisis, no solo crear tus equivalentes de DFD y DER en UML basados en clases, sino crear cualquier elemento visual que se requiera con las restricciones mencionadas anteriormente.

La forma de tu expresión no es clara. Para poder comentar que se "puede" hacer DFDs y/o DERs con UML se debe introducir previamente en los estereotipos. Y tu aclaración viene tarde. Debes saber que primero se da la oración primaria y luego la secundaria. Lee tu texto, comenzaste con:

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 (....)

Por tanto estás declarando que se puede hacer de forma muy directa.

Pero la aparición de los estereotipos no se da sino es hasta después:

(...)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

Y resulta muy confuso y contradictorio tus explicaciones. He aquí las razones:
1. Un DFD o un DERs no tiene clases. Como he dicho antes el DFD es del paradigma estructurado, en donde no existen clase y en el se muestran los procesos. Y en el DER tampoco hay clases, hay entidades o tablas de bases de datos.
Clases, procesos y entidades no necesariamente son equivalentes. Una clase puede colaborar con otras para muchos de los (mismos) procesos que podrías detectar si lo analizaras con el estructurado y los DFDs. Además, una clase puede y generalmente lo es, una materialización de más de una entidad y en varias ocasiones no tiene una representación directa o no se necesita de una materialización (las fabricaciones puras son un buen ejemplo).

Tu has dicho esto: que tanto el diagrama (que mal llamas modelo) de clases como los DFDs y los DERs manifiestan relaciones entre las clases, pero que se pueden expresar mucho mejor en el primero (Diagrama de Clases).

Un Diagrama de Clase está pensado para capturar y modelar una perspectiva diferente de un DFDs. Repito: el primero mustra el contexto desde el punto de las clases y sus relaciones. Por su parte, el segundo intenta tomar cada proceso del contexto y explotarlo para encontrar los subprocesos. Estos (sub)procesos darán forma a los módulos.

Ahora bien, en el paradigma estructurado el pensamiento esta en separar los datos de los procedimientos, estos procedimientos se agrupan en módulos... generalmente estructurándolos en top-down. Y se distinguen, sobre todo en el diagrama de estructura, tres etapas: Entrada, Transformación, Salida. En el paradigma OO en cambio no existe esta separación de los datos y los procedimientos. Una clase, por definición, tiende a ser dueña de sus datos y posee los métodos para ello y poder colaborar con el resto. Las clases no siguen ese diseño top-down. De hecho, no hay algo "secuencial"... Es una red.
Si se pudiera verlo de una forma "gráfica" la diferencia entre el paradigma estructurado y el OO es un giro de 90º.
En términos algebraicos diría que el pensamiento que busca OO es la de aplicar el Análisis de Componentes Principales y tomar los autovectores (las clases) y los autovalores (los datos) más representativos y luego tomar la matriz de covarianza (los diagramas) para regenerar el espacio inicial (el paradigma estructurado).

2. Volviendo a los estereotipos, su entrada en escena dada por ti, es accidental y no natural. La aclaración de "Cuidado para conseguir algo de DFD con OO requiere de la utilización de estereotipos".

3. Y para finalizar el párrafo cierras con una advertencia de que hay cosas que se escapan:

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

Me pregunto como es posible que se se pudiera imaginarse o concebir algo de herencia o polimorfismo en algo que ¡justamente dices que no es posible! Digo yo... ¿Da? ¿No es obvio? Ya lo he dicho: no es posible porque esos conceptos (herencia y polimorfismo) pertenecen a OO. No existe ese "otro tipo de diagrama" que le permita al DFD o al DER de ilustrar algo que no le incumbe.