Tutoriales
Enlaces
Licencia
Esta obra está bajo una licencia de Creative Commons.
Para reconocer la autoría debes poner el enlace https://old.chuidiang.org
En un diagrama de clases del negocio, presentamos como rectángulos todas aquellas cosas que un experto en el tema entiende. No ponemos cosas de programación como listas, arrays, botones, paneles, ventanas, sockets, etc. Sólo ponemos cosas que alguien que no tiene ni idea de informática pero que sabe mucho del tema de que trata nuestro programa conozca.
En nuestro ejemplo del ajedrez, el diagrama de clases del negocio sólo debe presentar cosas como partida, tablero, pieza, cronómetro, etc, etc. Un ejemplo puede ser el de la figura
Este diagrama no pretende ser un diagrama de verdad de un diseño de ajedrez, sino símplemente un ejemplo. Lo que hay en este diagrama, salvo alguna pequeña excepción, lo puede entender cualquier persona que sepa jugar al ajedrez y que no sepa de programación. La excepción es el tipo de "flechas" que une, por ejemplo, "pieza blanca" con "pieza". Este tipo de flechas indican que "pieza blanca ES una pieza" (en el mundo de orientación a objetos se conoce como herencia, "pieza blanca" hereda de "pieza"). Al "Kasparov" de turno hay que explicarle únicamente esto, el resto posiblemente lo entienda.
El objeto de este diagrama, aparte de servir de base para el diseño, es presentarlo a alguien que sepa de ajedrez y nos diga si lo que hemos puesto ahí es correcto, antes de empezar a programarlo, y que nos diga si faltan cosas que el considere importantes. En un juego de ajedrez es más o menos trivial, casi todos tenemos unas nociones de ajedrez, pero si un informático tiene que hacer un programa para jugar en bolsa, posiblemente tenga que aprender conceptos desconocidos y necesite que alguien se los aclare. Una buena forma es que se ponga junto con un jugador profesional de bolsa a hacer uno de estos diagramas.
A partir de este diagrama de clases del negocio, se pueden empezar los diagramas de clases del diseño. Una vez que se da por bueno, ya es cuestión de ir agrupando clases en paquetes y añadir más clases, esta vez sí, propias del mundo de la programación, como ventanas, sockets, arrays y listas.
Nuevamente, como todos los diagramas de UML, lo importante es que comuniquen algo y lo hagan de forma clara. Si el diagrama va dirigido a una persona que no sabe de informática, a un "Kasparov", hay que darle un diagrama de clases de negocio. Si yo soy el diseñador del programa y tengo "curritos" que van a codificar que saben mucho de informática, tendré que darles diagramas más detallados con clases propias de programación que reflejen exactamente lo que quiero. Al "Kasparov" le valen unas simples flechas con un texto que indique el tipo de relación, como se ve en la figura). Al programador quizás deba especificarle muy bien las flechas, indicando si son herencias, composiciones, agregaciones, dependencias, etc.