stringtranslate.com

Marco de software

En programación informática , un marco de software es una abstracción en la que el software , que proporciona una funcionalidad genérica, puede modificarse de forma selectiva mediante código adicional escrito por el usuario, proporcionando así un software específico para 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ódigo, 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 buscan facilitar los desarrollos 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 de bajo nivel más estándar de proporcionar un sistema funcional, 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 del manejo de solicitudes y la gestión de estados .

Los frameworks suelen aumentar el tamaño de los programas, un fenómeno denominado " inflación del código ". Debido a las necesidades de las aplicaciones impulsadas por la demanda de los clientes, a veces terminan en un producto frameworks tanto competitivos como complementarios. Además, debido a la complejidad de sus API, es posible que no se logre la reducción prevista en el tiempo de desarrollo general debido a la necesidad de dedicar tiempo adicional a aprender a usar el framework; esta crítica es claramente válida cuando el personal de desarrollo se encuentra por primera vez con un framework especial o nuevo. [ cita requerida ] Si dicho framework no se usa en tareas laborales posteriores, el tiempo invertido en aprender el framework puede costar más que el código escrito específicamente para el propósito con el que está familiarizado 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 de trabajo, los proyectos futuros pueden ser más rápidos y fáciles de completar; el concepto de un marco de trabajo es crear un conjunto de soluciones que se adapten a todos los casos y, con la familiaridad, la producción de código debería aumentar lógicamente. No se hacen afirmaciones similares sobre el tamaño del código que finalmente se incluye con el producto de salida, ni sobre su eficiencia y concisión relativas. El uso de cualquier solución de biblioteca necesariamente incluye elementos adicionales y activos extraños no utilizados, a menos que el software sea un enlazador de objetos de compilador que genere un módulo ejecutable compacto (pequeño, totalmente controlado y especificado).

El problema continúa, pero más de una década de experiencia en la industria [ cita requerida ] ha demostrado que los marcos más eficaces resultan ser aquellos que evolucionan a partir de la refactorización del código común de la empresa, en lugar de utilizar un marco genérico "universal" desarrollado por terceros para fines generales. Un ejemplo de ello sería cómo la interfaz de usuario en un paquete de aplicaciones como una suite de oficina crece hasta tener un aspecto, un funcionamiento y atributos y métodos de intercambio de datos comunes, a medida que las aplicaciones agrupadas, que antes eran dispares, se unifican en una suite más compacta y más pequeña; 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 frameworks. Crear un framework 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 (funcionalidad extra o ajena, gran parte de la cual está definida por el usuario). Para aquellos frameworks que generan código, por ejemplo, la "elegancia" implicaría la creación de código que sea limpio y comprensible para un programador razonablemente informado (y que, por lo tanto, sea fácilmente modificable), en lugar de uno que simplemente genere código correcto. La cuestión de la elegancia es la razón por la que relativamente pocos frameworks de software han resistido la prueba del tiempo: los mejores frameworks han podido evolucionar con elegancia a medida que avanzaba la tecnología subyacente sobre la que se construyeron. Incluso en esos casos, una vez evolucionados, muchos de esos paquetes mantendrán capacidades heredadas que inflarán el software final, ya que se han mantenido métodos que de otro modo habrían sido reemplazados en paralelo con los métodos más nuevos.

Ejemplos

Los marcos de software generalmente contienen un código de utilidad y mantenimiento considerable para ayudar a iniciar las aplicaciones de usuario, pero generalmente se centran en dominios de problemas específicos, como:

Arquitectura

Según Pree, [8] los frameworks de software se componen 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 inalterados (congelados) en cualquier instancia del framework de aplicación. Los puntos calientes representan aquellas partes donde los programadores que utilizan el framework añaden su propio código para añadir la funcionalidad específica de su propio proyecto.

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

La funcionalidad necesaria se puede implementar mediante el uso del Patrón de método de plantilla, en el que los puntos congelados se conocen como métodos invariantes y los puntos activos se conocen como métodos de variante o de enlace. 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, te llamaremos nosotros". [10] [11] Esto significa que las clases definidas por el usuario (por ejemplo, nuevas subclases) reciben mensajes de las clases predefinidas del marco. Los desarrolladores generalmente manejan esto implementando métodos abstractos de superclase .

Véase 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 de trabajo". 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 construir editores gráficos específicos de dominio", ACM Transactions on Information Systems , 8 (3): 237–268, doi : 10.1145/98188.98197 , S2CID  11248368
  4. ^ Johnson, RE (1992), "Documentación de marcos de trabajo mediante patrones", Actas de la conferencia 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, S2CID604969 ​{{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. 21–35
  6. ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), "Arquitectura del marco de modelado del sistema terrestre (ESMF)" , Computing in Science and Engineering , 6 : 18–28, doi :10.1109/MCISE.2004.1255817, S2CID  9311752
  7. ^ Gachet, A (2003), "Software Frameworks para el desarrollo de sistemas de soporte de decisiones: un nuevo componente en la clasificación de herramientas de desarrollo de DSS", Journal of Decision Systems , 12 (3): 271–281, doi :10.3166/jds.12.271-280, S2CID  29690836
  8. ^ Pree, W (1994), "Patrones meta: un medio para capturar los elementos esenciales del diseño orientado a objetos reutilizable", Actas de la 8.ª Conferencia Europea sobre Programación Orientada a Objetos , Lecture Notes in Computer Science, 821 , Springer-Verlag : 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: 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. ^ Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John (1994). Patrones de diseño . Addison-Wesley. ISBN 0-201-63361-2.

Enlaces externos