Lo estoy haciendo bien?????

[david_uh]

Hola foro estoy tratando de modelar esto:

Esta es una empresa que se dedica a la fabricacion y venta de licores, el hecho es que tiene varios preventistas son empleados que recorres una determinada zona que se le asigna, visita tiendas de abarrotes bodegas o cualquier local enel cual expenda licores, ofrece los productos que pueden ser al contado o credito el hecho es que si el cliente requiere algo pues le hace un pedido y este le llega al dia siguiente. Un pedido consta de unencabezado donde va el nombre del cliente, la fecha del pedido, el dni del cliente si lo tuviera, el nombre del local, la direccion, etc. despues vienen los items de el pedido, como son Unidad (botellas, cajas) cantidad, producto, precio unitario. Estoy tratando de modelar esto en unas clases y no se si lo estoy haciendo bien pues si de un diagrama de entidad relacion, lo tengo claro, pero como debo modelarlo en un diagrama de clases no se si estoy mezclando las cosas con los digramas de entidad relacion, gracias por cualquier ayuda.
aqui les dejo el diagrama de clases que estoy haciendo

Agradecido de antemano

David

[[nlsgarcia]]

david_uh.

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.

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

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.

5- Puedes conseguir mucha información de UML en Internet y en la Red P2P Emule.

Espero sea útil

Nelson

[[Delphius]]

Empezado por nlsgarcia

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.

Empezado por nlsgarcia

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

Empezado por nlsgarcia

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.

Empezado por nlsgarcia

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,

[[nlsgarcia]]

Delphius,

En primer lugar gracias por tus comentarios, se ve que eres una persona muy particular y compleja en tus opiniones según he podido ver en otros post (Propios y de Terceros) y dada la naturaleza del tema comprendo tu posición, pero el punto aquí no es hacer un debate exhaustivo sobre los paradigmas sobre los que se basan las metodologías de análisis estructurado y OO, es simplemente poder colaborar con alguien que necesita un punto de partida para su proyecto, no obstante tratare de explicarme mas detalladamente.

En la década de los 90 se crearon alrededor de 50 metodologías orientadas a objeto, cada una con su orientación, pero gracias a la unificación que propuso UML se llego a un lenguaje de modelado visual que permite gran expresividad semántica gracias a la naturaleza de sus diagramas, la experiencia acumulada hasta el momento en A&D/OO y la necesidad de una herramienta que no limitara el análisis sino que lo apoyara y extendiera si era necesario según cada contexto particular.

UML no pretende ser una metodología, tampoco considera que sus diagramas modelen en su totalidad todas los escenarios, es por ello que existe un apartado de mecanismo de extensión en el cual por medio de restricciones, valores etiquetados y estereotipos se puede extender el modelo visual para que se adapte mejor a un contexto particular, es decir: UML es extensible, los DFD y DER no pueden usar a UML, pero UML si puede usar a estos si se considera apropiado y de valor semántico con las adaptaciones correspondientes a elementos de UML.

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.

¿Hace falta en UML crear un equivalente basados en clases de los DFD y DER? : A UML no le hace falta pero desde un punto de vista estrictamente comunicacional y académico que permita plasmar dichos elementos de análisis como punto de partida y complemento del estándar UML es factible hacerlo, sirve de punto de partida para el análisis y permite aclarar ideas si el área de experticia es el análisis estructurado. Tener múltiples perspectivas ayudan y facilitan el modelamiento de un sistema, esa es la idea detrás de los estereotipos de UML y de sus mecanismos de extensión.

La idea de UML es hacer el análisis y diseño orientado a objeto más fácil, sin limitaciones de metodología, adaptable a cualquier metodología y extensible para un mejor aprovechamiento de este, no lo contrario que fue lo que ocurrió en los 90 en el cual se dio un fuerte debate sobre el tema, pero gracias a estas polémicas surgió UML como un estándar de modelamiento OO vigente hasta la fecha.

Otros puntos:

1- Los Casos de Uso fueron creados por Ivar Jacobson en 1986 y usados por primera vez en 1992 en la metodología de diseño orientado a objetos OOSE (Object-Oriented Software Engineering) y posteriormente integrada a UML y RUP, aunque su uso nació dentro del ámbito OO se puede implementar en otras áreas como una forma de modelar procesos y eso es lo grandioso de UML y sus elementos: Se pueden usar como un lenguaje de modelamiento visual en otras áreas diferentes a la computación, lo cual muestra su flexibilidad y robustez semántica, pero lo cierto es que se usa principalmente el A&D/OO por ser algo propio de esta área.

2- Los Diagramas de Comunicación de UML 2.0 son una versión simplificada de los Diagramas de Colaboración de UML 1.X, pero en la mayoría de los libros se refieren a estos como Diagramas de Colaboración, la idea es usar la versión 2.X o posteriores.

3- ¿Por que recomendar el libro "Aprendiendo UML en 24 Horas" y no otro más complejo?: El conocimiento se construye por capas y este libro permite una orientación inicial al tema y sirve de base para posteriores libros como por ejemplo "El Lenguaje Unificado de Modelado, Manual de Referencia" escrito por los autores de UML o cualquier otro que el lector decida, al final los libros son puntos de partida hasta que nos formemos un criterio propio, cada quien encoje con que libro iniciar el camino, la simplicidad es la base de la complejidad.

4- Con respecto a las Bibliotecas, Internet y la Red P2P Emule creo que pueden convivir perfectamente, al final es muy probable que todos los libros sean digitales y las bibliotecas virtuales sean la norma en lugar de la excepción por muchas razones que pienso son conocidas por las mayoría de las personas que usan una computadora asiduamente.

5- ¿El usar términos en ingles y en español en un mundo tan globalizado, signado por la tecnología y la internet dentro del ámbito de la computación es algo reprochable?, honestamente no lo creo pero respecto las opiniones contrarias.

6- ¿Que si falto explicar esto o aquello sobre UML?, no es un tratado sobre UML es solo una orientación inicial a un problema real.

7- Creo firmemente que un rasgo notable de la computación es su flexibilidad y adaptabilidad a cualquier situación en la búsqueda de soluciones innovadoras y no la simple repetición de textos y métodos, creo que cada situación es única y por tanto una oportunidad para aprender y desarrollar lo aprendido, no veo por que esta situación sea diferente.

Pensamientos finales:

Creo que todo el problema se origino por una incorrecta redacción del punto uno el cual podemos reescribir como: "1- Es conveniente que empieces a modelar tu proyecto usando Casos de Uso de lo general a lo particular haciendo un paralelismo con los DFDs, (DFD-0) -> Caso General) y (DFD-1, DFD-2, ... , DFD-n) -> Casos particulares, pero tomando en cuenta que pertenecen a paradigmas diferentes y es válido solo como punto inicial del análisis."

Otro punto de error fue no explicar mas extensamente los estereotipos en UML pero creo que la idea es dar una guía general en la mayoría de los casos que sirva de base a la solución del problema planteado en el post y recomendar otros links y libros que complementen la respuesta.

Este tipo de controversias las he visto muchas veces en tesis de grado de pregrado y postgrado y generalmente se deben a pre concepciones muy arraigadas sobre un tema o a la falta de una mejor redacción por parte del expositor. Creo firmemente en el conocimiento, pero también en la evolución del mismo con fines prácticos y no solo teóricos, la teoría es solo el comienzo pero lo practico es y debe ser el final dentro de una concepción holística del tema.

Admito que la extensión de UML con estereotipos basados en DFD y DER es algo polémico y controversial para algunos, pero esto lo he probado en diversos ámbitos con resultados favorables a efectos de comunicación de nuevos conceptos y punto de partida de análisis mas detallados con los elementos propios del UML, esa es la idea detrás de todo este tema : Un punto inicial de transición del modelo estructurado al modelo OO por medio de UML.

Para finalizar creo que debemos respetar las opiniones de todos, manifestar nuestro desacuerdo de forma profesional, educada y con argumentos y tratar de mantener un clima de cordialidad y ayuda a todas las personas que usen este medio, no creo que una discusión peyorativa y purista ayude en nada a resolver los problemas planteados en el Club Delphi, al final las personas que viene a este foro buscan soluciones practicas a problemas reales y no simple disertación teórica que aunque necesaria en su momento, no es el objetivo final.

Espero sea útil

Nelson.

[david_uh]

Empezado por nlsgarcia

al final las personas que viene a este foro buscan soluciones practicas a problemas reales y no simple disertación teórica que aunque necesaria en su momento, no es el objetivo final.

estoy de acuerdo, inicie este post con el fin de buscar una orientacion ya que no tengo claro aun como crear mis clases para este sistema de ventas usando oo, ya que nunca he usado este paradigma, y me siento perdido, siempre he programado en forma estructurada, he usado objetos pero hasta ahi nomas, y me preguntaba si mis clases que estoy creando van bien alguna observacion, etc. estoy conciente de los diferentes puntos de vista a la hora de modelar pero el hecho es que necesito ideas, criticas, observaciones, etc

Saludos

David

[[Delphius]]

Empezado por nlsgarcia

Delphius,
En la década de los 90 se crearon alrededor de 50 metodologías orientadas a objeto,

¿Eran tantas? Recuerdo que eran muchas pero no que llegasen a las 50

Empezado por nlsgarcia

pero gracias a la unificación que propuso UML se llego a un lenguaje de modelado visual que permite gran expresividad semántica gracias a la naturaleza de sus diagramas, la experiencia acumulada hasta el momento en A&D/OO y la necesidad de una herramienta que no limitara el análisis sino que lo apoyara y extendiera si era necesario según cada contexto particular.

Yo no estoy en contra del UML, todo lo contrario ¡apoyo y defiendo mi uso! Hasta me atreví a poner a modo de portada en mi cuenta de facebook la frase "UML es mi escudo y mi espada"
Creí que con mi resumen de historia dejaba en claro que UML se formalizó justamente con la intención de proponer algo estándar y que todos pudieran entender.
Que UML sea extensible es ya una cuestión secundaria, y por las circunstancias y su naturaleza.

Empezado por nlsgarcia

UML no pretende ser una metodología,

En ningún momento he dicho que lo fuera. Si lo hubiera dicho me reprobaría y me mandaría derecho a recursar Ingeniería de Software.

Empezado por nlsgarcia

tampoco considera que sus diagramas modelen en su totalidad todas los escenarios,

Tampoco dije que modele en su totalidad. Simplemente comenté que UML ofrece un amplio abanico de diagramas para representar a un sistema desde diversos puntos de vistas. Más esto no quiere decir que en su totalidad.

Empezado por nlsgarcia

es por ello que existe un apartado de mecanismo de extensión en el cual por medio de restricciones, valores etiquetados y estereotipos se puede extender el modelo visual para que se adapte mejor a un contexto particular, es decir: UML es extensible,

Seguramente sabes que si bien los esterotipos son un buen recurso, también pueden ser un arma de doble filo.

Empezado por nlsgarcia

los DFD y DER no pueden usar a UML,

Por supuesto que no. Si pudieran se estaría mezclando ambos lenguajes visuales, de dos paradigmas diferentes, y un tercero que es aplicable ya fuera del contexto de programación... me refiero al DER. Que está pensado para justamente no apegarse a ningún paradigma de desarrollo ni de programación.

Empezado por nlsgarcia

pero UML si puede usar a estos si se considera apropiado y de valor semántico con las adaptaciones correspondientes a elementos de UML.

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,

Precisamente debido al mezclar UML con capacidad de DER gracias a estereotipos es que las cosas se confunden. Por algo existe UML por un lado y por el otro el DER. Y justamente el estereotipo DER en UML es el más criticado y el que menos se recomienda utilizarlo que al final termina nublando y complicando más las cosas. El DER es más limpio y está pensado para representar base de datos.
Cada cosa en su lugar.
Los estereotipos como dije son armas de doble filo, e intentar adaptar UML hacia el paradigma estructurado para asimilar los DFDs es ir contra su corriente. Si en verdad se quiere pensar en estructurado ¡utiliza algo que está pensado para eso!

Empezado por nlsgarcia

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.

No puedo estar a favor de eso. Entiendo tu punto, pero discrepo totalmente. Y una muy buena parte de la comunidad ya lo ha advertido... no por mucho poner estereotipos se consiguen mejores cosas.
Fabuloso que UML se vaya ampliando y mejorando, pero cada paradigma está para lo suyo.

Empezado por nlsgarcia

¿Hace falta en UML crear un equivalente basados en clases de los DFD y DER? : A UML no le hace falta

Precisamente no le hace falta porque no fue pensado ni diseñado para eso. De que se pueda, gracias a "extensiones" (y fuera del estándar) no quiere decir que se deba. Es un error conceptual, una cosa es el pensamiento estructurado y otra el OO. Al igual que cuando uno mezclas bebidas... alguien que vea OO + Estructurado le provocará nauseas y perderá la perspectiva. Es querer forzar a algo para lo que no es.

Empezado por nlsgarcia

pero desde un punto de vista estrictamente comunicacional y académico que permita plasmar dichos elementos de análisis como punto de partida y complemento del estándar UML es factible hacerlo,

Con más razón si dices que es académico: ¡NO MEZCLAR! Lo peor que puedes hacerles a los estudiantes es justamente presentarles UML con elementos del estructurado. Los estancas más. La idea es que se piense más en OO y no en OO estruturado. ¡No hay que acostumbrarlos! Porque luego es que se comenten justamente cosas como las que he señalado: se confuden y se mezclan cosas.

Empezado por nlsgarcia

sirve de punto de partida para el análisis y permite aclarar ideas si el área de experticia es el análisis estructurado.

Si la idea es enseñarles estructurado, entonces ¡dales las herramientas para eso!
Te lo podría aceptar si se tratase de una manera de hacer transición entre ambos paradigmas. Pero de allí en más, hay que evitar mezclar cosas. Y cuanto más limpio y estándar te mantengas, más fácil será comunicarte.

Empezado por nlsgarcia

Tener múltiples perspectivas ayudan y facilitan el modelamiento de un sistema, esa es la idea detrás de los estereotipos de UML y de sus mecanismos de extensión.

En eso estamos de acuerdo. UML fue pensado para ofrecer múltiples vistas. Pero hay que hacer las derivas advertencias sobre un abuso de estereotipos... ¡que se ha hablado mucho de eso! Por favor no los expongas como si fueran la gran solución cuando no lo es. UML tiene sus pros y contras... seamos sinceros. Pero los estereotipos se han puesto más como una medida forzada que una verdadera necesidad... no son la panacea.

Yo uso estereotipos, pero si puedo evitarme usarlos mejor.