stringtranslate.com

Marco de software

En programación de computadoras , un marco de software es una abstracción en la que el software , que proporciona una funcionalidad genérica, puede modificarse selectivamente mediante código adicional escrito por el usuario, proporcionando así software específico de la aplicación. Proporciona una forma estándar de crear e implementar aplicaciones y es un entorno de software universal y reutilizable que proporciona una funcionalidad particular como parte de una plataforma de software más grande para facilitar el desarrollo de aplicaciones , productos y soluciones de software.

Los marcos de software pueden incluir programas de soporte, compiladores, bibliotecas de códigos, conjuntos de herramientas e interfaces de programación de aplicaciones (API) que reúnen todos los diferentes componentes para permitir el desarrollo de un proyecto o sistema .

Los marcos tienen características distintivas clave que los separan de las bibliotecas normales :

Razón fundamental

Los diseñadores de marcos de software tienen como objetivo facilitar el desarrollo de software al permitir que los diseñadores y programadores dediquen su tiempo a cumplir con los requisitos del software en lugar de lidiar con los detalles más estándar de bajo nivel de proporcionar un sistema en funcionamiento, reduciendo así el tiempo general de desarrollo. [2] Por ejemplo, un equipo que utiliza un marco web para desarrollar un sitio web bancario puede centrarse en escribir código específico para la banca en lugar de la mecánica de manejo de solicitudes y gestión estatal .

Los frameworks a menudo aumentan el tamaño de los programas, un fenómeno denominado " inflación de código ". Debido a las necesidades de las aplicaciones impulsadas por la demanda de los clientes, a veces los marcos competitivos y complementarios terminan en un producto. Además, debido a la complejidad de sus API, es posible que no se logre la reducción prevista en el tiempo general de desarrollo debido a la necesidad de dedicar tiempo adicional a aprender a utilizar el marco; Esta crítica es claramente válida cuando el personal de desarrollo encuentra por primera vez un marco especial o nuevo. [ cita necesaria ] Si dicho marco no se utiliza en tareas laborales posteriores, el tiempo invertido en aprender el marco puede costar más que el código escrito específicamente y familiar para el personal del proyecto; Muchos programadores guardan copias de código repetitivo útil para necesidades comunes.

Sin embargo, una vez que se aprende un marco, los proyectos futuros pueden ser más rápidos y fáciles de completar; el concepto de un marco es crear un conjunto de soluciones único para todos y, con la familiaridad, la producción de código lógicamente debería aumentar. No se hacen tales afirmaciones sobre el tamaño del código que finalmente se incluye con el producto final, ni sobre su relativa eficiencia y concisión. El uso de cualquier solución de biblioteca necesariamente atrae extras y activos extraños no utilizados, a menos que el software sea un compilador-enlazador de objetos que crea un módulo ejecutable ajustado (pequeño, totalmente controlado y especificado).

El problema continúa, pero más de una década de experiencia en la industria [ cita necesaria ] ha demostrado que los marcos más efectivos resultan ser aquellos que evolucionan a partir de la refactorización del código común de la empresa, en lugar de utilizar un código genérico de "talla única". "Se adapta a todos" desarrollado por terceros para fines generales. Un ejemplo de esto sería cómo la interfaz de usuario en un paquete de aplicaciones como una suite ofimática crece hasta tener una apariencia, sensación y atributos y métodos comunes para compartir datos, a medida que las aplicaciones empaquetadas, antes dispares, se unifican en una suite que es más completa. y más pequeño; la suite más nueva/evolucionada puede ser un producto que comparte bibliotecas de utilidades e interfaces de usuario integrales.

Esta tendencia en la controversia plantea una cuestión importante sobre los marcos. Crear un marco que sea elegante, en lugar de uno que simplemente resuelva un problema, sigue siendo más un oficio que una ciencia. La " elegancia del software " implica claridad, concisión y poco desperdicio (funcionalidades adicionales o superfluas, gran parte de las cuales están definidas por el usuario). Para aquellos marcos que generan código, por ejemplo, "elegancia" implicaría la creación de código que sea limpio y comprensible para un programador con conocimientos razonables (y que, por lo tanto, sea fácilmente modificable), frente a uno que simplemente genere código correcto. La cuestión de la elegancia es la razón por la que relativamente pocos marcos de software han resistido la prueba del tiempo: los mejores marcos han podido evolucionar con gracia a medida que avanzaba la tecnología subyacente sobre la que fueron construidos. Incluso allí, habiendo evolucionado, muchos de estos paquetes conservarán capacidades heredadas que inflarán el software final, ya que los métodos reemplazados se han conservado en paralelo con los métodos más nuevos.

Ejemplos

Los marcos de software suelen contener una cantidad considerable de código de mantenimiento y utilidad para ayudar a iniciar las aplicaciones de los usuarios, pero generalmente se centran en dominios de problemas específicos, como por ejemplo:

Arquitectura

Según Pree, [8] los marcos de software constan de puntos congelados y puntos calientes . Los puntos congelados definen la arquitectura general de un sistema de software, es decir, sus componentes básicos y las relaciones entre ellos. Estos permanecen sin cambios (congelados) en cualquier instancia del marco de la aplicación. Los puntos calientes representan aquellas partes donde los programadores que utilizan el marco agregan su propio código para agregar la funcionalidad específica de su propio proyecto.

En un entorno orientado a objetos , un marco consta de clases abstractas y concretas . La creación de instancias de dicho marco consiste en componer y subclasificar las clases existentes. [9]

La funcionalidad necesaria se puede implementar utilizando el patrón de método de plantilla en el que los puntos congelados se conocen como métodos invariantes y los puntos calientes se conocen como métodos variantes o de gancho. Los métodos invariantes de la superclase proporcionan un comportamiento predeterminado, mientras que los métodos de enlace de cada subclase proporcionan un comportamiento personalizado.

Al desarrollar un sistema de software concreto con un marco de software, los desarrolladores utilizan los puntos calientes de acuerdo con las necesidades y requisitos específicos del sistema. Los marcos de software se basan en el principio de Hollywood : "No nos llames, nosotros te llamaremos". [10] [11] Esto significa que las clases definidas por el usuario (por ejemplo, nuevas subclases) reciben mensajes de las clases marco predefinidas. Los desarrolladores normalmente manejan esto implementando métodos abstractos de superclase .

Ver también

Referencias

  1. ^ Riehle, Dirk (2000), Diseño de marcos: un enfoque de modelado de roles (PDF) , Instituto Federal Suizo de Tecnología
  2. ^ "Marco". DocForge . Archivado desde el original el 7 de octubre de 2018 . Consultado el 15 de diciembre de 2008 .
  3. ^ Vlissides, JM; Linton, MA (1990), "Unidraw: un marco para crear editores gráficos de dominio específico", ACM Transactions on Information Systems , 8 (3): 237–268, doi : 10.1145/98188.98197 , S2CID  11248368
  4. ^ Johnson, RE (1992), "Documentación de marcos utilizando patrones", Actas de conferencias sobre sistemas, lenguajes y aplicaciones de programación orientada a objetos - OOPSLA '92 , ACM Press, págs. 63–76, doi : 10.1145/141936.141943 , ISBN 0201533723, S2CID  604969{{citation}}: Mantenimiento CS1: fecha y año ( enlace )
  5. ^ Birrer, A; Eggenschwiler, T (1993), "Actas de la conferencia europea sobre programación orientada a objetos", Marcos en el dominio de la ingeniería financiera: un informe de experiencia , Springer-Verlag , págs.
  6. ^ Colina, C; DeLuca, C; Balaji, V; Suárez, M; da Silva, A (2004), "Arquitectura del marco de modelado del sistema terrestre (ESMF)" , Computación en ciencia e ingeniería , 6 : 18–28, doi :10.1109/MCISE.2004.1255817, S2CID  9311752
  7. ^ Gachet, A (2003), "Marcos de software para el desarrollo de sistemas de apoyo a la toma de decisiones: un nuevo componente en la clasificación de herramientas de desarrollo DSS", Journal of Decision Systems , 12 (3): 271–281, doi :10.3166/jds.12.271 -280, S2CID  29690836
  8. ^ Pree, W (1994), "Metapatrones: un medio para capturar los elementos esenciales del diseño orientado a objetos reutilizable", Actas de la octava conferencia europea sobre programación orientada a objetos , Apuntes de conferencias sobre informática, Springer-Verlag , 821 : 150–162, CiteSeerX 10.1.1.74.7935 , doi :10.1007/BFb0052181, ISBN  978-3-540-58202-1
  9. ^ Buschmann, F (1996), Arquitectura de software orientada a patrones Volumen 1: un sistema de patrones. Chichester , Wiley , ISBN 978-0-471-95869-7
  10. ^ Larman, C (2001), Aplicación de UML y patrones: una introducción al análisis y diseño orientado a objetos y al proceso unificado (2ª ed.), Prentice Hall , ISBN 978-0-13-092569-5
  11. ^ Gama, Erich ; Timón, Richard ; Johnson, Ralph ; Vlissides, John (1994). Patrones de diseño . Addison-Wesley. ISBN 0-201-63361-2.

enlaces externos