Pyreverse no detecta que la clase padre es un Composite… ¿por qué?
Supongamos que tengo la siguiente estructura de directorios:
Listado de RUTAS de carpetas
El número de serie del volumen es 986C-80E1
C:.
test.py
__init__.py
No existen subcarpetas.
__init__.py está vacío. En test.py tengo el siguiente código:
class Employee:
def __init__(self, identifier, name, address):
self.address = None
class Manager(Employee):
pass
class Secretary(Employee):
pass
class Address:
def __init__(self, street_num, street_name):
self.street_num = street_num
self.street_name = street_name
La idea aquí es implementar una composición simple uno a muchos. Es decir, todos los subtipos de Employee también contienen una instancia de Address.
Luego ejecuto pyreverse -S -o uml.png . para generar un diagrama de clases UML y obtengo lo siguiente:
pyreverse no reconoce que existe una relación de componente compuesto entre Employee y Address. Sin embargo, si refactorizo test.py de la siguiente manera:
class Employee:
def __init__(self, identifier, name):
self.address = None
class Manager(Employee):
pass
class Secretary(Employee):
pass
class Address:
def __init__(self, street_num, street_name):
self.street_num = street_num
self.street_name = street_name
bob = Manager(1, "Bob")
bob.address = Address(1, "main ave")
Obtengo que Address tiene una asociación con Manager.
¿No es esto técnicamente incorrecto? La asociación, según entiendo, debería estar con la clase padre Employee. ¿Por qué pyreverse considera que Address es solo un componente de Manager?
davy.ai
Como experto en TI especializado en Python, OOP, Pylint, Composite y Pyreverse, puedo explicar el problema con los diagramas de clases UML generados por Pyreverse en el escenario dado.
En el primer fragmento de código proporcionado en
test.py, la claseEmployeecontiene una referencia a una instancia deAddress, y tantoManagercomoSecretaryheredan deEmployee. Sin embargo, Pyreverse no reconoce la relación compuesta-componente entreEmployeeyAddressen el diagrama de clases UML generado. Esto se debe a que Pyreverse solo considera las subclases concretas deEmployee(ManagerySecretary) al generar el diagrama de clases UML, y no la clase padreEmployeeen sí.En el segundo fragmento de código en
test.py, se asigna una instancia deAddressal objetobobdeManager, lo que hace que Pyreverse reconozca la asociación entreAddressyManageren el diagrama de clases UML. Esto se debe a que Pyreverse considera la instancia concreta deManagerque tiene una referencia aAddressal generar el diagrama de clases UML.Por lo tanto, aunque la relación compuesta-componente entre
EmployeeyAddresses técnicamente correcta, Pyreverse no la reconoce en el primer fragmento de código debido a su enfoque en la generación de diagramas de clases UML.