Definición de uso de componentes

[JorgeBec]

Hola comunidad! Pregunta comunidad al pasar del análisis a la arquitectura de la aplicación, como definir que componentes usar??? claro que depende las caracteristicas de la plataforma, pero yo me he visto con el problema a la hora de la programación de no saber que componentes usar cual es el mas adecuado???, yo opto como lo he externado en otros mensajes, de hacer todo un trabajo de analisis y arquitectura, haciendo analogia con la construccion hacer la maqueta y planos de la aplicacio, bien, como plasmar la arquitectura de modulos de datos, en diagramas??? a caso usar diagramas de componentes uml???

agradecere sus respuestas...

[mamcx]

La pregunta es muy vaga. La idea es usar el mejor componente para la tarea... ahora, como saber si es el mejor? Bueno, empiricamente es mejor el que:

- Cubre la mayor area de requerimientos. Por ejemplo, un componente de compresion. Necesitamos uno que comprima en .ZIP, .RAR, .CAB. Un componente hace .ZIP y el otro los 3. El segundo es mejor...
- Mas nativo. Para Delphi, tiende a ser mejor un componente VCL que un ActiveX, porque VCL es nativo, ActiveX no.
- Claridad API. Ya que los componente se comunican mediante APIs, la claridad y sencillez de la api juega un gran papel.
- Es un componete confiable, o uno reparable. Un componente confiable es uno que basicamente no falla y es estable a travez del tiempo. Un TEdit es un ejemplo. A falta de uno confiable, debe ser reparable = Codigo fuente. Un componente con codigo fuente es MAS valiosos que uno sin el. De hecho, entre la comunidad Delphi entregar el codigo es una norma (muy bien fundada)
- Es Independiente. O mas bien, el componente tiene minimos enlazes con otros componentes. Un componente que exige .NET es menos independiente para una aplicacion Win32 que uno que solo exige Win32. Pero si la aplicacion es .NET, es mejor el .NET
- Nivel de panico. A mayor nivel de panico (osea= Si el componete falla, que? si no lo actualizan despues que? Mi aplicacion en que % depende de el, etc...) se requiere mejor soporte, mejor documentacion, mejor calidad de codigo fuente. Un componente que cumple 85% con los requerimientos pero tiene un alto % de incidencia en la aplicacion y tiene buen soporte, ayuda y codigo fuente es mejor que uno que cumple 100% que es un abandware.


Lo de los diagramas... mas bien arrancar por los requerimientos, luego decidir los componentes que encajan en ellos.