En ingeniería de software e informática , la abstracción es el proceso de generalizar detalles concretos , [1] como atributos , lejos del estudio de objetos y sistemas para centrar la atención en detalles de mayor importancia. [2] La abstracción es un concepto fundamental en informática e ingeniería de software , especialmente dentro del paradigma de programación orientada a objetos . [3] Ejemplos de esto incluyen:
La esencia de la abstracción es preservar la información que es relevante en un contexto determinado y olvidar la información que es irrelevante en ese contexto.
– John V. Guttag [5]
La informática opera en su mayor parte independientemente del mundo concreto. El hardware implementa un modelo de computación que es intercambiable con otros. [6] El software está estructurado en arquitecturas que permiten a los humanos crear sistemas enormes concentrándose en unos pocos problemas a la vez. Estas arquitecturas están hechas de elecciones específicas de abstracciones. La Décima Regla de Greenspun es un aforismo sobre cómo dicha arquitectura es a la vez inevitable y compleja.
La abstracción del lenguaje es una forma central de abstracción en la informática: se desarrollan nuevos lenguajes artificiales para expresar aspectos específicos de un sistema. Los lenguajes de modelado ayudan en la planificación. Los lenguajes informáticos se pueden procesar con una computadora. Un ejemplo de este proceso de abstracción es el desarrollo generacional del lenguaje de programación desde el lenguaje de máquina hasta el lenguaje ensamblador y el lenguaje de alto nivel . Cada etapa puede utilizarse como trampolín para la siguiente. La abstracción del lenguaje continúa, por ejemplo, en lenguajes de scripting y lenguajes de programación de dominio específico .
Dentro de un lenguaje de programación, algunas características permiten al programador crear nuevas abstracciones. Estos incluyen subrutinas , módulos , polimorfismos y componentes de software . Algunas otras abstracciones, como los patrones de diseño de software y los estilos arquitectónicos, permanecen invisibles para un traductor y operan sólo en el diseño de un sistema.
Algunas abstracciones intentan limitar la gama de conceptos que un programador debe tener en cuenta, ocultando por completo las abstracciones sobre las que se basan. El ingeniero de software y escritor Joel Spolsky ha criticado estos esfuerzos afirmando que todas las abstracciones tienen filtraciones : que nunca pueden ocultar por completo los detalles que aparecen a continuación; [7] sin embargo, esto no niega la utilidad de la abstracción.
Algunas abstracciones están diseñadas para interoperar con otras abstracciones; por ejemplo, un lenguaje de programación puede contener una interfaz de función externa para realizar llamadas al lenguaje de nivel inferior.
Los diferentes lenguajes de programación proporcionan diferentes tipos de abstracción, según las aplicaciones previstas para el lenguaje. Por ejemplo:
function(parameters) = 0; abstractinterfaceLos analistas han desarrollado varios métodos para especificar formalmente sistemas de software. Algunos métodos conocidos incluyen:
Los lenguajes de especificación generalmente se basan en abstracciones de un tipo u otro, ya que las especificaciones generalmente se definen antes en un proyecto (y en un nivel más abstracto) que una implementación final. El lenguaje de especificación UML , por ejemplo, permite la definición de clases abstractas , que en un proyecto en cascada permanecen abstractas durante la fase de arquitectura y especificación del proyecto.
Los lenguajes de programación ofrecen la abstracción de control como uno de los principales propósitos de su uso. Las máquinas informáticas comprenden operaciones a un nivel muy bajo, como mover algunos bits de una ubicación de la memoria a otra y producir la suma de dos secuencias de bits. Los lenguajes de programación permiten que esto se haga en un nivel superior. Por ejemplo, considere esta declaración escrita en estilo Pascal :
a := (1 + 2) * 5Para un humano, esto parece un cálculo bastante simple y obvio ( "uno más dos es tres, por cinco es quince" ). Sin embargo, los pasos de bajo nivel necesarios para llevar a cabo esta evaluación, devolver el valor "15" y luego asignar ese valor a la variable "a", son en realidad bastante sutiles y complejos. Los valores deben convertirse a representación binaria (a menudo una tarea mucho más complicada de lo que uno podría pensar) y los cálculos deben descomponerse (por el compilador o el intérprete) en instrucciones ensambladoras (nuevamente, que son mucho menos intuitivas para el programador: operaciones como desplazar un registro binario hacia la izquierda o agregar el complemento binario del contenido de un registro a otro, simplemente no es lo que los humanos piensan sobre las operaciones aritméticas abstractas de suma o multiplicación). Finalmente, asignar el valor resultante de "15" a la variable denominada "a", para que "a" pueda usarse más tarde, implica pasos adicionales "detrás de escena" para buscar la etiqueta de una variable y la ubicación resultante en el espacio físico. o memoria virtual, almacenando la representación binaria de "15" en esa ubicación de memoria, etc.
Sin la abstracción de control, un programador necesitaría especificar todos los pasos de nivel de registro/binario cada vez que simplemente quisiera sumar o multiplicar un par de números y asignar el resultado a una variable. Esta duplicación de esfuerzos tiene dos graves consecuencias negativas:
La programación estructurada implica la división de tareas complejas del programa en partes más pequeñas con un control de flujo claro e interfaces entre componentes, con una reducción de la complejidad potencial de efectos secundarios.
En un programa simple, esto puede tener como objetivo garantizar que los bucles tengan puntos de salida únicos u obvios y (cuando sea posible) tener puntos de salida únicos de funciones y procedimientos.
En un sistema más grande, puede implicar dividir tareas complejas en muchos módulos diferentes. Considere un sistema que maneja la nómina en barcos y oficinas en tierra:
Estas capas producen el efecto de aislar los detalles de implementación de un componente y sus diversos métodos internos de los demás. La programación orientada a objetos adopta y amplía este concepto.
La abstracción de datos impone una separación clara entre las propiedades abstractas de un tipo de datos y los detalles concretos de su implementación. Las propiedades abstractas son aquellas que son visibles para el código del cliente que hace uso del tipo de datos (la interfaz para el tipo de datos), mientras que la implementación concreta se mantiene completamente privada y, de hecho, puede cambiar, por ejemplo, para incorporar mejoras de eficiencia con el tiempo. La idea es que se supone que tales cambios no deben tener ningún impacto en el código del cliente, ya que no implican ninguna diferencia en el comportamiento abstracto.
Por ejemplo, se podría definir un tipo de datos abstracto llamado tabla de búsqueda que asocie claves con valores de forma única y en la que los valores se puedan recuperar especificando sus claves correspondientes. Una tabla de búsqueda de este tipo se puede implementar de varias maneras: como una tabla hash , un árbol de búsqueda binario o incluso una lista lineal simple de pares (clave:valor). En lo que respecta al código de cliente, las propiedades abstractas del tipo son las mismas en todos los casos.
Por supuesto, todo esto depende de obtener los detalles correctos de la interfaz en primer lugar, ya que cualquier cambio allí puede tener un impacto importante en el código del cliente. Como una forma de ver esto: la interfaz forma un contrato sobre el comportamiento acordado entre el tipo de datos y el código del cliente; Todo lo que no esté detallado en el contrato está sujeto a cambios sin previo aviso.
Si bien gran parte de la abstracción de datos se produce a través de la informática y la automatización, hay ocasiones en las que este proceso se realiza manualmente y sin intervención de programación. Una forma de entender esto es mediante la abstracción de datos dentro del proceso de realización de una revisión sistemática de la literatura. En esta metodología, uno o varios abstractores extraen los datos cuando se realiza un metanálisis , y los errores se reducen mediante la extracción dual de datos seguida de una verificación independiente, conocida como adjudicación . [10]
En la teoría de la programación orientada a objetos , la abstracción implica la facilidad de definir objetos que representan "actores" abstractos que pueden realizar un trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema. El término encapsulación se refiere a ocultar detalles de estado , pero extender el concepto de tipo de datos de lenguajes de programación anteriores para asociar el comportamiento más fuertemente con los datos y estandarizar la forma en que interactúan los diferentes tipos de datos es el comienzo de la abstracción . Cuando la abstracción avanza hacia las operaciones definidas, permitiendo sustituir objetos de diferentes tipos, se llama polimorfismo . Cuando se procede en sentido contrario, dentro de los tipos o clases, estructurándolos para simplificar un conjunto complejo de relaciones, se llama delegación o herencia .
Varios lenguajes de programación orientados a objetos ofrecen facilidades similares para la abstracción, todo para respaldar una estrategia general de polimorfismo en la programación orientada a objetos, que incluye la sustitución de un tipo por otro con la misma función o una similar. Aunque generalmente no es compatible, una configuración, imagen o paquete puede predeterminar muchos de estos enlaces en tiempo de compilación , tiempo de enlace o tiempo de carga . Esto dejaría sólo un mínimo de dichos enlaces para cambiar en tiempo de ejecución .
Common Lisp Object System o Self , por ejemplo, presentan menos distinción de instancia de clase y más uso de delegación para polimorfismo . Los objetos y funciones individuales se abstraen de manera más flexible para encajar mejor con una herencia funcional compartida de Lisp .
C++ ejemplifica otro extremo: depende en gran medida de plantillas , sobrecargas y otros enlaces estáticos en tiempo de compilación, lo que a su vez tiene ciertos problemas de flexibilidad.
Aunque estos ejemplos ofrecen estrategias alternativas para lograr la misma abstracción, no alteran fundamentalmente la necesidad de admitir sustantivos abstractos en el código: toda programación se basa en la capacidad de abstraer verbos como funciones, sustantivos como estructuras de datos y ambos como procesos.
Consideremos, por ejemplo, un fragmento de muestra de Java para representar algunos "animales" de granja comunes a un nivel de abstracción adecuado para modelar aspectos simples de su hambre y alimentación. Define una Animalclase para representar tanto el estado del animal como sus funciones:
clase pública Animal extiende Cosa Viviente { ubicación privada loc ; Reservas de energía dobles privadas ; public boolean isHungry () { return reservas de energía < 2,5 ; } public void eat ( Comida comida ) { // Consumir comida reservas de energía += comida . obtenerCalorías (); } public void moveTo ( ubicación ubicación ) { // Mover a una nueva ubicación this . loc = ubicación ; } } Con la definición anterior, se podrían crear objetos de tipoAnimaly llama a sus métodos así:
elCerdo = nuevo Animal (); la Vaca = nuevo Animal (); if ( el Cerdo . tiene hambre ()) { el Cerdo . comer ( mesaScraps ); } if ( la Vaca . tiene hambre ()) { la Vaca . come pasto ) ; } la vaca . moverA ( elGranero ); En el ejemplo anterior, la clase Animales una abstracción utilizada en lugar de un animal real, LivingThinges una abstracción adicional (en este caso una generalización) de Animal.
Si se requiere una jerarquía de animales más diferenciada –para diferenciar, por ejemplo, aquellos que proporcionan leche de aquellos que no proporcionan nada más que carne al final de sus vidas–, ese es un nivel intermedio de abstracción, probablemente DairyAnimal (vacas, cabras) que comen alimentos aptos para dar buena leche, y animales de carne (cerdos, novillos) que comen alimentos para dar la mejor calidad de carne.
Esta abstracción podría eliminar la necesidad de que el codificador de la aplicación especifique el tipo de alimento, de modo que pudiera concentrarse en el horario de alimentación. Las dos clases podrían estar relacionadas mediante herencia o de forma independiente, y el programador podría definir distintos grados de polimorfismo entre los dos tipos. Estas facilidades tienden a variar drásticamente entre idiomas, pero en general cada uno puede lograr todo lo que es posible con cualquiera de los demás. Una gran cantidad de sobrecargas de operaciones, tipo de datos por tipo de datos, pueden tener el mismo efecto en tiempo de compilación que cualquier grado de herencia u otros medios para lograr polimorfismo. La notación de clases es simplemente una conveniencia para el codificador.
Las decisiones sobre qué abstraer y qué mantener bajo el control del codificador se convierten en la principal preocupación del diseño orientado a objetos y del análisis de dominio ; en realidad, determinar las relaciones relevantes en el mundo real es la preocupación del análisis orientado a objetos o análisis de legado.
En general, para determinar la abstracción adecuada, se deben tomar muchas decisiones pequeñas sobre el alcance (análisis de dominio), determinar con qué otros sistemas se debe cooperar (análisis heredado) y luego realizar un análisis detallado orientado a objetos que se expresa dentro del tiempo y el presupuesto del proyecto. restricciones como un diseño orientado a objetos. En nuestro ejemplo simple, el dominio es el corral, los cerdos y las vacas vivos y sus hábitos alimentarios son las limitaciones heredadas, el análisis detallado es que los codificadores deben tener la flexibilidad de alimentar a los animales con lo que esté disponible y, por lo tanto, no hay razón para codificar. el tipo de alimento en la clase misma, y el diseño es una única clase Animal simple de la cual los cerdos y las vacas son instancias con las mismas funciones. Una decisión de diferenciar a DairyAnimal cambiaría el análisis detallado, pero el análisis de dominio y legado no cambiaría; por lo tanto, está completamente bajo el control del programador y se denomina abstracción en la programación orientada a objetos, a diferencia de la abstracción en el dominio o legado. análisis.
Cuando se habla de semántica formal de lenguajes de programación , métodos formales o interpretación abstracta , la abstracción se refiere al acto de considerar una definición menos detallada, pero segura, de los comportamientos observados del programa. Por ejemplo, se puede observar sólo el resultado final de la ejecución del programa en lugar de considerar todos los pasos intermedios de la ejecución. La abstracción se define como un modelo de ejecución concreto (más preciso).
La abstracción puede ser exacta o fiel con respecto a una propiedad si uno puede responder igualmente bien a una pregunta sobre la propiedad en el modelo concreto o abstracto. Por ejemplo, si uno desea saber cuál es el valor del resultado de la evaluación de una expresión matemática que involucra solo números enteros +, -, ×, módulo n , entonces solo necesita realizar todas las operaciones módulo n (una forma familiar de esta abstracción es convertir de nueves ).
Las abstracciones, sin embargo, aunque no necesariamente exactas , deben ser sólidas . Es decir, debería ser posible obtener respuestas sólidas de ellos, aunque la abstracción pueda simplemente producir un resultado de indecidibilidad . Por ejemplo, los estudiantes de una clase pueden ser abstraídos por sus edades mínima y máxima; si se pregunta si una determinada persona pertenece a esa clase, se puede simplemente comparar la edad de esa persona con las edades mínima y máxima; si su edad está fuera del rango, se puede responder con seguridad que la persona no pertenece a la clase; si no es así, sólo se puede responder "No lo sé".
El nivel de abstracción incluido en un lenguaje de programación puede influir en su usabilidad general . El marco de las dimensiones cognitivas incluye el concepto de gradiente de abstracción en un formalismo. Este marco permite al diseñador de un lenguaje de programación estudiar las compensaciones entre la abstracción y otras características del diseño, y cómo los cambios en la abstracción influyen en la usabilidad del lenguaje.
Las abstracciones pueden resultar útiles cuando se trata de programas de computadora, porque las propiedades no triviales de los programas de computadora son esencialmente indecidibles (ver el teorema de Rice ). Como consecuencia, los métodos automáticos para obtener información sobre el comportamiento de los programas informáticos tienen que prescindir de la terminación (en algunas ocasiones, pueden fallar, bloquearse o nunca dar un resultado), la solidez (pueden proporcionar información falsa) o la precisión ( pueden responder "No sé" a algunas preguntas).
La abstracción es el concepto central de la interpretación abstracta . La verificación del modelo generalmente se realiza en versiones abstractas de los sistemas estudiados.
La informática suele presentar niveles (o, menos comúnmente, capas ) de abstracción, en los que cada nivel representa un modelo diferente de la misma información y procesos, pero con diferentes cantidades de detalle. Cada nivel utiliza un sistema de expresión que involucra un conjunto único de objetos y composiciones que se aplican únicamente a un dominio particular.[11] Cada nivel "superior" relativamente abstracto se basa en un nivel "inferior" relativamente concreto, que tiende a proporcionar una representación cada vez más "granular". Por ejemplo, las puertas se basan en circuitos electrónicos, el binario en puertas, el lenguaje de máquina en binario, el lenguaje de programación en lenguaje de máquina, las aplicaciones y los sistemas operativos en lenguajes de programación. Cada nivel está encarnado, pero no determinado, por el nivel subyacente, lo que lo convierte en un lenguaje de descripción que en cierto modo es autónomo.
Dado que muchos usuarios de sistemas de bases de datos carecen de una familiaridad profunda con las estructuras de datos informáticas, los desarrolladores de bases de datos a menudo ocultan la complejidad en los siguientes niveles:
Nivel físico: el nivel más bajo de abstracción describe cómo un sistema realmente almacena datos. El nivel físico describe en detalle estructuras de datos complejas de bajo nivel.
Nivel lógico: el siguiente nivel superior de abstracción describe qué datos almacena la base de datos y qué relaciones existen entre esos datos. Por tanto, el nivel lógico describe una base de datos completa en términos de un pequeño número de estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede implicar estructuras complejas en el nivel físico, el usuario del nivel lógico no necesita ser consciente de esta complejidad. Esto se conoce como independencia física de los datos . Los administradores de bases de datos , que deben decidir qué información conservar en una base de datos, utilizan el nivel lógico de abstracción.
Nivel de vista: el nivel más alto de abstracción describe solo una parte de toda la base de datos. Aunque el nivel lógico utiliza estructuras más simples, la complejidad persiste debido a la variedad de información almacenada en una gran base de datos. Muchos usuarios de un sistema de base de datos no necesitan toda esta información; en cambio, necesitan acceder sólo a una parte de la base de datos. El nivel de abstracción de vista existe para simplificar su interacción con el sistema. El sistema puede proporcionar muchas vistas para la misma base de datos.
La capacidad de proporcionar un diseño de diferentes niveles de abstracción puede
Tanto el diseño de sistemas como el diseño de procesos de negocio pueden utilizar esto. Algunos procesos de diseño generan específicamente diseños que contienen varios niveles de abstracción.
La arquitectura en capas divide las preocupaciones de la aplicación en grupos apilados (capas). Es una técnica utilizada en el diseño de software, hardware y comunicaciones en la que los componentes del sistema o de la red se aíslan en capas para que se puedan realizar cambios en una capa sin afectar a las demás.