cómo documentar un síngleton demasiado genérico
Publicado por fleong (1 intervención) el 05/03/2008 14:35:03
Hola a tod@s,
Tengo la siguiente duda:
Me enfrento a un software de gestión que implementa un singleton llamado "modelo" que implementa básicamente todas las reglas de negocio de la misma. En esta clase hay métodos de lo más variado (métodos para consultar la bd, un parser de ecuaciones matemáticas sencillas, métodos para cargar y salvar la configuración del programa, etc etc. ).
Parece ser que esta turbo-clase (si me permitis inventarme el nuevo concepto :P) soporta básicamente toda la aplicación y, aunque hay otras clases que implementan lo suyo, por lo general siempre utilizan la instanciación del modelo para lo que sea.
Bueno, pues dicho esto ahora tengo que representar el modelo de clases y me encuentro con que no tengo ni idea de cómo representar la clase "modelo" con UML. Se me ocurren dos posibles alternativas que me gustaría exponer aquí por si alguien puede opinar al respecto:
1.- Esta clase no se representa, ya que representa el TODO de la aplicación, que al fin y al cabo es lo que se pretende modelar con cada uno de los diagramas. EN otras palabras: un método de esta clase se representa en UML como una acción general del modelo, y en la implementación, todos estos "métodos sueltos" se engloban en la clase "modelo".
ó
2.- Se podría representar la clase modelo como síngleton, pero representando en el esquema de la clase únicamente el método que recupera la instancia y poco más. Por otro lado, mediante una relación de agregación, expresar que esta clase tiene "paquetes" de métodos que tienen cierta relación entre si (p.e: todos los que tengan que ver con la b.d constituyen un paquete, etc etc.)
Qué hacer??...
Saludos,
Fernando
Tengo la siguiente duda:
Me enfrento a un software de gestión que implementa un singleton llamado "modelo" que implementa básicamente todas las reglas de negocio de la misma. En esta clase hay métodos de lo más variado (métodos para consultar la bd, un parser de ecuaciones matemáticas sencillas, métodos para cargar y salvar la configuración del programa, etc etc. ).
Parece ser que esta turbo-clase (si me permitis inventarme el nuevo concepto :P) soporta básicamente toda la aplicación y, aunque hay otras clases que implementan lo suyo, por lo general siempre utilizan la instanciación del modelo para lo que sea.
Bueno, pues dicho esto ahora tengo que representar el modelo de clases y me encuentro con que no tengo ni idea de cómo representar la clase "modelo" con UML. Se me ocurren dos posibles alternativas que me gustaría exponer aquí por si alguien puede opinar al respecto:
1.- Esta clase no se representa, ya que representa el TODO de la aplicación, que al fin y al cabo es lo que se pretende modelar con cada uno de los diagramas. EN otras palabras: un método de esta clase se representa en UML como una acción general del modelo, y en la implementación, todos estos "métodos sueltos" se engloban en la clase "modelo".
ó
2.- Se podría representar la clase modelo como síngleton, pero representando en el esquema de la clase únicamente el método que recupera la instancia y poco más. Por otro lado, mediante una relación de agregación, expresar que esta clase tiene "paquetes" de métodos que tienen cierta relación entre si (p.e: todos los que tengan que ver con la b.d constituyen un paquete, etc etc.)
Qué hacer??...
Saludos,
Fernando
Valora esta pregunta
0