Lo estoy haciendo bien?????

[roman]

Empezado por Casimiro Notevi

Cuando te acostumbras a un lector de libros electrónico... ¡¡¡ya no quieres libros en papel!!!

Aunque hay que aclarar que una cosa es un e-book y otra cosa es la pantalla de la computadora. No conozco yo mucho de eso pero he visto el kindle (sí, y sé que ese no te gusta ) y supongo que otros lectores son similares: no tienen nada que ver con la pantalla de una computadora.

1. No reflejan luz, que es lo que daña la vista. De hecho, no puedes leerlo en la oscuridad.
2. El gasto de energía es ínfimo.
3. No es "prender un aparato para leer", es abrir el libro; porque el encendido es instantáneo.

Supongo que Delphius desconce estas bondades.

Por otra parte, Dephius,

¿Es realmente necesario iniciar una polémica en todo momento?

Por otra parte, hay gente que para cuando ustedes terminar de leer el primer capítulo de UML, ellos ya están facturando al cliente

// Saludos

[Casimiro Notevi]

Empezado por roman

Por otra parte, hay gente que para cuando ustedes terminar de leer el primer capítulo de UML, ellos ya están facturando al cliente

Eso es seguro

[david_uh]

Buena delphius se nota que eres un excelente teórico del UML tanto asi que es tu escudo, escudo contra que???? ni hablar el UML no es ni de lejos el santo grial de la poo de hecho es inutil, ahora te preguntaras entonces ¿por que trato de pedir ayuda sobre esto?, te respondo, siempre he programado usando mis propios diagramas y secuencias siempre he solucionado problemas informáticos sin necesidad de UML, la única razón por la que tengo que aprender este bodrio es porque en mi tesis de grado es requisito indispensable ya discutí con los coordinadores y pues son como tú UML UML UML ( no me dijeron que era su escudo, pero casi), en fin soy consciente de que en el mundo oo estoy desorientado y cada vez que me leo un libro siento que me pierdo más, y el tiempo como sabes no se detiene, así que tengo presión por todos lados, el unico articulo interesante y muy esclarecedor que encontré fue uno en inglés que si despejo muchas dudas mias y SI me orientó.

Por otro lado uno pide una opinion sobre lo que esta haciendo y se mandan con un sermonazo sobre UML, claro delphius la teoría es buena, y me puedo leer un libro de uml y discutimos sobres casos de uso, sobre clases, herencia, restricciones estereotipos y mas pero ese no era el punto de mi pregunta era un caso practico quería saber si estaba haciéndolo bien que parte de la pregunta no se entiende????


Post data
UML no sirve
casos de uso de negocio VS casos de uso de sistema

Sobre las p2p y la dudosa procedencia. la mayor parte del material en internet es de dudosa procedencia para eso esta uno para investigar y aplicar sus propios criterios y urgar en foros o paginas o redes p2p o irc o etc.

Saludos

David

[[Delphius]]

David,
No dispongo en estos momentos de responderte a todos los puntos pero espero que al menos quede en claro algunas cosas:

1. En la gran mayoría de mis participaciones sobre UML he recalcado que UML no es perfecto. En ningún momento he dicho que UML sea la panacea. Es más en la mayoría de mis intervenciones que he comentado algo de UML he recalcado que tiene sus pros y contras.
2. Aún no siendo una cosa 100% perfecta, si uno la aprende a utilizar apropiadamente se sacará buen provecho.
3. Si leyeras a Pressman y otros sobre Ingeniería de Software te encontrarás que sus mensajes es muy simple: aprendan a escoger sus armas para cada batalla.
4. Ese artículo de Javier Smaldone se cae a pedazos... Por empezar lo único que hace es copiar y pegar una carta de un "estudiante" de cuando UML estaba totalmente inmaduro: UML 1. Desde UML 1 a UML 1.5 llovió mucho y las cosas mejoraron. Tanto que los mismos expertos dicen que UML 1 no es útil. Si buscas material como debe encontrarás que todos comentan desde UML 1.5 en adelante. Aunque ya desde 1.3 que las cosas van bien.
5. Continuando con el artículo de Javier, si leyeras los comentarios encontrarás la participación del "El Mendozino". Que da una estupenda cátedra y derriba todo punto que se ha intentado vender como que UML es un fracaso.
6. Para ti puede ser un bodrio pero UML llegó para quedarse... para ti puede ser una semerenda estupidez y pérdida de tiempo, escoge otras armas. De todas formas hay una gran amplia mayoría que está a favor y ha aprendido a usarlo.
7. Aprender a usar UML no es cosa de una leída. Requiere de años... yo llevo al menos 6 años y me considero que me falta más por aprender.
8. Si no estás dispuesto a darte el tiempo de dejarte cultivar por UML de nada sirve que otros te intentemos apoyar si no lo entiendes. Además he visto en tu anterior participación cuando pedías ayuda sobre unos diagramas de que es difícil apoyarte si no hay un completa puesta de tu parte de explicar de forma completa y acabada el contexto.
9. El A/DOO es subjetivo por lo que cada uno puede tener su propia propuesta, según su propio análisis. Por lo que es posible que no necesariamente todos lleguemos a la misma respuesta... El A/D tiene de arte, por lo que si preguntas a roman tendrá una visión... si le preguntas a Mamx tendrá otra... si me preguntas a mi también. ¡Y todos podemos estar en lo cierto!. Voy a decir algo que he dicho ya no se cuantas veces: mientras uno se sienta inseguro de su análisis... sus diseños y propuestas serán débiles. En cuanto te quites de tu cabeza esa sensación y ganes seguridad tu diseño te estará a tu lado.
Da lo mismo que digamos nosotros... debes convencerte a ti mismo.
Si para ti tu diseño está mal, tus ideas estarán mal.
No hay análisis totalmente erróneos, sólo análisis incompletos.

¿Que esperas que hagamos de ese breve texto que nos has puesto? ¡Con eso no se puede hacer nada!

10. P2P podrá ser de utilidad, pero de todas formas lo que más valor aporta y lo que más resulta completo y seguro es el material físico: los libros. Hoy en día es muy fácil escribir un pdf de un supuesto "resumen" o manual para x cosa y no decir nada bueno, y ni que decir... decente.
En internet hay tanto material bueno como malo. Pero la ley del menor esfuerzo inclina la balanza hacia el segundo.
11. Si esto que estás consultando es para tu tesis de grado entonces seguramente tienes a tu alcance la biblioteca... ¡no muerden!. Además, ¿que haces aquí? ¿Que acaso no tienes un profesor guía o tutor que te asiste? Se supone que cuando uno está haciendo un proyecto/tesis de grado, se asesora con el guía que es quien le aconseja y le da el visto bueno a los avances.
Primero consulta a tu tutor y el círculo de tus profesores (no hay nada de malo en consultarles, de hecho es lo que se debe hacer) y luego de acabar los recursos académicos recién considera la posibilidad de ir a los foros (no sin antes de comentarle a tu tutor de ello, ¿O es que pretendes arriesgarte a que no valide algo que no haya pasado por sus ojos?.
Por último y también relacionado con el material que puedas encontrar en la red de redes... Seguramente sabrás que en TODOS los tribunales se prima material de consulta físico que el que hay en internet. Hasta incluso en algunos rechazan a wikipedia en su versión inglesa y sus fuentes.

Las respuestas a nlsgarcia, Casimiro Notevi y roman se las daré más adelante. Ahorita me voy a disfrutar justamente de más UML.

Saludos,

[[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.

[[Delphius]]

Conclusión has intentado mezclar cosas que no van. ¿Para que mencionar en una misma oración términos como herencia, polimorfismo, DFD y DER? ¡Son agua y aceite! ¿Donde quedó la explicación del estereotipo en esto? ¡Dime!

Mi parecer: intentaste dar una forma de presentar y combinar ambos temas y no encontraste la forma y mandaste lo que te salió del momento. Resultado: ¡tutti frutti! Aquí hace calor y admito que me encanta la ensalada de frutas, pero prefiero no comer demasiada porque me provoca diarrea... como la diarrea mental que largarse en ese párrafo.

En tu ampliación a las explicaciones arreglaste mejor tus palabras. Pero te olvidas de algo fundamental: no existe paralelismo entre un DFD/DER con Diagrama de Clases. Como he expresado antes, son perpendiculares, hay un ángulo conceptual de 90º... Se dice que allá en el infinito las paralelas se cruzan. La conversión no es directa.
Y como tu indicas que la introducción de estereotipos para conseguir semejante cosa es ya fuera de estándar, entonces con más razón es un motivo muy riesgoso de presentarlo ya que requiere de una mayor preparación y se reduce el potencial de comunicar ideas y que otros las entiendan. No todos están al tanto de los estereotipos... y peor se pone si justamente el estereotipo para conseguir DFD en UML es uno definido por el usuario.

Si David lo utilizase ¿cuál será la probabilidad de que se lo acepten y le den el visto bueno? Para cátedra, ¡deja las cosas en el estándar! Los "experimentos fuera "del libro" déjalos para después, para cuando tenga tiempo, ganas y pueda profundizarse.
Ese es el motivo por el cual yo trato de mantener a los diagramas limpio y de usar las cosas para los que fueron concebidas y el porqué de toda esta lección: Mantenerme lo más simple y apegado al estándar, y aprovechar cada cosa con lo suyo:
UML -> apoyo a mis A/D OO
Diagramas de flujo (que no el diagrama de flujo de datos, o DFD) -> algoritmos
DER -> para mis DBs
Análisis Estructurado -> para mis A/D estructurados

Estas ármas ya son estándares, y uno puede tomarlas sin problemas. Si alguien más las lee podrá entenderme. Si yo condimentara como tu a los diagramas con el estereotipo estructurado (y que te invito a que nos muestres como se ve; en parte por curisoso) me expongo a reducir ese poder que posee el UML que es la de comunicación, y en el peor caso que oscurezca demasiado las cosas al punto en que termine siendo peor la cura que la enfermedad.

Ya lo he dicho: los estereotipos son un arma de doble filo. UML ofrece flexibilidad y muchas cosas se las puede dar de forma simple, sin estar rellenando todo. Ese poder es fantástico, porque uno puede regular la cantidad de cosas a mostrar sin perder el hilo; pero también se vuelve en contra cuando para ilustrar una idea debe meterle más cosas que las por defecto y las opcionales que ofrece a disposición el estándar.
Existe un equilibrio, ni mucho ni poco. Dime ahora ¿Tu que lado de la balanza prefieres?

Empezado por nlsgarcia

La idea era dar una referencia teórica que permita establecer el paralelismo entre UML y el Análisis Estructurado basado en DFDs y DER, pero por supuesto depende del que lo lee investigar un poco sobre el tema, en este caso es un punto de partida práctico no la solución final y mucho menos ideal.

Si tu idea era dar ese supuesto paralelismo, ¿donde está? Porque en ningún momento te deteniste a explicar en como llevarlo. Dices que con estereotipos, ¡pero al menos debes dar una pista de como proceder!
Cuando un profesor corrige una prueba no sólo debe decir la respuesta es la C, sino agarrar una tiza y explicarles al menos medianamente en cómo se podría llegar a ese resultado. Seguramente, alguna vez, tu has pedido a tus profes que se detenga a explicar algo o que te evacue una duda. ¿Porqué no hacer ese mismo ejemplo con David?

Si tan seguro estás de que la respuesta está en UML estereotipado con estructurado. ¡Demuéstralo! ¡Algo breve!

Empezado por nlsgarcia

Creo que es una gran virtud del lenguaje que expresa su gran capacidad de adaptabilidad y flexibilidad a diversos escenarios.

En eso coincidimos. Pero el punto es que no por mucha flexibilidad quiere decir que se pueda jugar con ella. No abuses.

Empezado por nlsgarcia

Solo explique el origen de los Casos de Uso y su relación con el A&D/OO, los Casos de Uso son fundamentales en UML y RUP y una herramienta muy poderosa para el modelado OO.

Error. Los casos de uso no son fundamentales para UML, de hecho todo diagrama de UML es independiente de otro, no existe una dependencia... nada te obliga a hacer todos o algunos; uno elige que y cuando hacerlo. UML es muy libre e independiente de paradigmas de desarrollo y/o metodologías. No hay un orden establecido (allí es donde SI se meten los modelos o procesos de desarrollo y metodologías).
Lo que dices es justamente el error que veo en muchos: creen que todo comienza en los casos de uso y que sin ellos no se puede avanzar. Para hacer diagramas UML se puede partir de cero, con cualquiera; lo lógico es empezar con el diagrama que más te ofrezca claridad para conducir las ideas, aclarar las dudas y bajarlas a tierra. Si es el diagrama de clases, perfecto; si son los DS (Diagrama de Secuencia) también, si es el de Paquetes... ¡también!
Este error tiene un trasfondo en una mala enseñanza de Ingeniería de Software y una concidencia histórica mal difundida. Para RUP si es fundamental, porque así lo dispuso. Esto es más de "metodología" que una necesidad o que en verdad existiera algún orden de como hacer las cosas.
Si sigues otro modelo o proceso de desarrollo que no sea RUP o algún otro de la línea UP (aclaro por las dudas, y para quien no sepa: RUP no es el único modelo UP) te darás cuenta de lo que digo: que RUP proponga y parta desde los casos de uso no quiere decir que necesariamente deba ser así siempre y para otros modelos (incluso uno propio).
Comparto contigo que los CUs son una herramienta poderosa, ¡pero no necesariamente son indispensables! ¡Saca eso de la cabeza!

[[Delphius]]

Empezado por nlsgarcia

¿Podemos asumir que versión simplificada y se lo ha hecho más light son equivalentes?, si es así estamos de acuerdo.

Parcialmente de acuerdo. Simplificada y Light no necesariamente es que son equivalentes. No me estás entendiendo: El diagrama de Comunicación aparenta ser más simple (o simplificado), pero es una extensión al concepto que propone el de Colaboración. Lo que se le hizo al DC (Diagrama de Comunicación) es eliminarles cosas que tenía por defecto y llevarlas al plano de opcionales, más los agregados. Si le sumas todo tienes algo que no es simple.

Empezado por nlsgarcia

Es tu opinión, la respecto pero no la comparto.

Yo no comparto que se sigan haciendo aparatitos y que se deba gastar más energía en toda su cadena de producción y comercialización de una forma desenfrenada. Peor, si incluso algunos de esos aparatitos se diseñan exclusivamente para algo tan elemental, básico, simple y tan libre como leer. Si ya de por sí con la era de la PC se empezó a leer menos, ¡para los próximos años peor se pone! Lo único que se consigue con más aparato es poner más intermediarios para algo, que repito: puede ser más simple. Voy a ser redundante pero... ¡es que es aparatoso!
Y muchos dicen "¡Pero ve el lado bueno, ya no se talarán más árboles!" Perfecto, que se tale menos... no me opongo a eso. El punto es que no te dicen el resto de la historia: ese árbol que no se taló para hacer libros, se taló para poner una fábrica que tira más CO2 de lo que ese árbol podría absorver.
De que hay que ser más responsables de la tala seguro, segurísimo. De que hay que talar menos, estoy convencido.
Ahora de que me digan que lo que mata a los árboles son los libros, tal como ha dicho cierto productor de TV, sinceramente ¡No pueden ser más estúpidos! La solución no pasa únicamente por talar menos.
¿De que sirve no talar si seguimos saturando el ambiente de CO2?
Si talas, replanta y continúa plantando más. Es muy simple: si se hiciera de forma responsable (todos) podríamos seguir teniendo libros que leer, hojas que escribir y conocimiento que transmitir y sin necesidad de gastar recursos para hacer un aparato... recursos que no se pueden devolver a la tierra de forma simple.

Empezado por nlsgarcia

Respeto tu opinión, pero no creo que sea la única.

No digo que sea la única pero es que es la más coherente. Si estoy hablando un idioma y lo estuve haciendo el 99% del tiempo... y en el medio te aviento algo en otro sólo por "de modé" habiendo palabras en nuestro bello idioma ¿Como crees que suena?
Un bochorno.
No es cosa de que se pueda o no... ¡es que queda mal! No te haces más profesional si dices una lista en español y te dejas uno para decirlo en inglés... todo lo contrario: quedas en ridículo.
No estoy en contra del inglés, en varios momentos deberemos recurrir a éste porque no hay términos en nuestro idioma (sobre todo en el aspecto técnico) pero mientras exista algo en español debemos seguir defiendo nuestro idioma que ya de por si está desgastado y deformado. Por aquí incluso tenemos un término para eso: ¡en Argentina hablamos cagastellano!

Empezado por nlsgarcia

No, pero agradezco tus comentarios.

Lo siento pero no puede ser más ciego. Considero que ya he demostrado varios puntos sobre tus fallas. Ahora dime sinceramente, quiero ver algún argumento bien presentado de porqué debemos hacer uso de UML estereotipado con estructurado. Da una muestra a ver si en verdad es la gran cosa como tu aseguras.

Fíjate en como han sido mis palabras: desde el comienzo aclaré que UML tiene de bueno como malo, que los estererotipos son buenos como malos, que debe encontrarse su justa medida. Es una perspectiva más racional, mediana y más centrada a lo que puede enfrentar David. Si ya de por si David de UML poco y nada... ¿Tu quieres meterles estereotipos? ¿Te das cuenta?

Empezado por nlsgarcia

No es posible, los estereotipos son fundamentales en la idea que quería plasmar.

Bien, para hacer lo que dices son indispensables. Vuelve a leer mi anterior párrafo.
Estás planeando traer algo que es más complejo de que lo que académicamente está en condiciones David. Yo a eso ya lo había previsto, cuando uno va a responder a un hilo debe ir viendo la evolución histórica de quien pone la duda para tener una mejor percepción de a como encararlo.
Lo hago siempre que voy a postear... me fijo en las anteriores dudas de dicha persona.
Para evitar más frustación me es necesario dar un alto sermón de porqué no ir a por tu confusa propuesta. E intuyendo en como se podría ir desarrollando el hilo si no hubiera dicho nada, hoy David estaría peor porque debería ir hacia un paradigma abajo.

Empezado por nlsgarcia

La vida esta basada en experiencias, la vida profesional no es la excepción, quizás con el tiempo hagas un postgrado y veras lo importante que son las experiencias personales propias y de terceros en el crecimiento académico y profesional, el tiempo lo dira.

El tiempo que llevo en CD me viene demostrando la riqueza de muchos usuarios. Y también me ha estado preparando para "oler" a los que tienen más dificultades.
Yo en lo posible trato de separar y utilizar las palabras más neutrales para exponer lo que es de carácter teórico de lo que puede ser mi formación. Por ejemplo cuando menciono la literatura, lo hago diciendo algo como "lectura casi obligada". Precisamente para indicar que es un material que puede ser de utilidad porque a mi por un lado me ha ayudado y me gusta recomendarlo y por el otro porque se que se trata de una referencia ampliamente citada en el área académica y de fácil acceso. Allí termina mi exposición... No les digo que o como ha de tomar (aprender) de dicha literatura. Les doy la pelota y dejo que ellos la evalúen.
Tu por el contrario presentaste un problema, que no supiste presentar bien, y que además lo condiciona enormemente y está basado UNICAMENTE en tu experiencia. ¿Tienes alguna referencia o material que exponga justamente el estereotipo estructurado que no sea tus palabras? ¿De donde lo aprendiste? ¿O es que se trata de un estereotipo definido por el usuario?