Hispanopedia WikiLa separación de preocupaciones (SoC, por sus siglas en inglés) es un principio de diseño en informática e ingeniería de software que sostiene que un problema complejo debe dividirse en preocupaciones distintas —aspectos o cuestiones— que pueden analizarse, abordarse o gestionarse individualmente, incluso cuando pertenecen al mismo sistema. Esto permite centrarse en una cuestión a la vez, reduciendo la carga cognitiva y la complejidad. [ 1 ]
La separación de preocupaciones se puede lograr de varias maneras: temporalmente (por ejemplo, secuenciando actividades en un ciclo de vida del software), por calidad (por ejemplo, tratando la corrección por separado de la eficiencia [ 2 ] ), por vista (por ejemplo, analizando el flujo de datos por separado del flujo de control) o por tamaño (modularidad) [ 1 ].
La modularidad es una aplicación específica de la separación de responsabilidades a los componentes del sistema (separación por tamaño). En los sistemas modulares, cada módulo encapsula una única responsabilidad, y los módulos se diseñan, implementan y comprenden de forma aislada antes de integrarse en un sistema mayor. Si bien la modularidad es la manifestación más común y reconocible de la separación de responsabilidades en la estructura del código, el principio de separación de responsabilidades es más amplio. Por ejemplo, separar el análisis de requisitos de la implementación en la cronología de un proyecto, o separar los requisitos funcionales de los no funcionales en una especificación, son formas válidas de separación de responsabilidades que no necesariamente requieren un diseño modular.
Edsger W. Dijkstra en su artículo de 1974 "Sobre el papel del pensamiento científico" [ 2 ] acuñó el término separación de preocupaciones en relación con cualidades del software tales como corrección y eficiencia .
Carlo Ghezzi en su libro "Fundamentos de ingeniería de software" [ 1 ] promueve la Separación de Responsabilidades como la principal forma de abordar la complejidad heredada en la producción de software.
Philippe Kruchten en su artículo "Planos arquitectónicos: el modelo de vista "4+1" de la arquitectura de software" [ 3 ] utilizó un modelo compuesto por cinco vistas principales para abordar arquitecturas grandes; esencialmente, se trata de una separación de preocupaciones basada en vistas, donde cada vista se centra en un aspecto diferente de la arquitectura.
Según Carlo Ghezzi , la principal ventaja de la modularidad del software es que permite aplicar el principio de separación de responsabilidades a los componentes del sistema, o "módulos". Los detalles de los módulos pueden abordarse de forma aislada; además, la integración de los módulos se trata como una cuestión independiente que se ocupa de las características generales de los módulos de software y sus relaciones.
Laplante, Phillip también mencionó que la separación de preocupaciones se puede aplicar en el diseño de software, la codificación, el tiempo y las cualidades del software. [ 4 ]
Origen
El término separación de preocupaciones probablemente fue acuñado por Edsger W. Dijkstra en su artículo de 1974 "Sobre el papel del pensamiento científico". [ 2 ]
Permítanme intentar explicarles lo que, a mi parecer, caracteriza todo pensamiento inteligente. Se trata de la disposición a estudiar en profundidad un aspecto de un tema de estudio de forma aislada, en aras de su coherencia, sabiendo en todo momento que uno se ocupa únicamente de uno de esos aspectos. Sabemos que un programa debe ser correcto y podemos estudiarlo solo desde esa perspectiva; también sabemos que debe ser eficiente y podemos estudiar su eficiencia en otro momento, por así decirlo. En otro contexto, podemos preguntarnos si el programa es deseable y, de ser así, por qué. Pero no se gana nada —¡al contrario!— abordando estos diversos aspectos simultáneamente. Es lo que a veces he llamado «la separación de preocupaciones», que, aunque no sea perfectamente posible, es la única técnica disponible para ordenar eficazmente los pensamientos, que yo conozca. A esto me refiero con «centrarse en un aspecto»: no significa ignorar los demás, sino simplemente reconocer que, desde el punto de vista de este aspecto, el otro es irrelevante. Se trata de tener una mentalidad unidireccional y multidireccional al mismo tiempo.
Quince años después, era evidente que el término separación de preocupaciones se estaba convirtiendo en una idea aceptada. En 1989, Chris Reade escribió un libro titulado Elements of Functional Programming [ 5 ] que describe SoC:
El programador tiene que hacer varias cosas al mismo tiempo, a saber:
- Describa qué es lo que se va a calcular;
- organizar la secuencia de cálculos en pequeños pasos;
- organizar la gestión de la memoria durante el cálculo.
Reade continúa diciendo:
Idealmente, el programador debería poder concentrarse en la primera de las tres tareas (describir qué se va a calcular) sin distraerse con las otras dos, de carácter más administrativo. Si bien la administración es importante, al separarla de la tarea principal es probable que obtengamos resultados más fiables y que, además, simplifiquemos el problema de programación automatizando gran parte de la administración.
El SoC presenta otras ventajas. Por ejemplo, la verificación de programas resulta mucho más factible cuando no se incluyen detalles sobre la secuenciación y la gestión de memoria. Además, las descripciones de lo que se va a calcular deben carecer de descripciones detalladas paso a paso sobre cómo hacerlo, si se van a evaluar con diferentes arquitecturas de máquina. Las secuencias de pequeños cambios en un objeto de datos almacenado pueden ser una descripción inapropiada de cómo calcular algo cuando se utiliza una máquina altamente paralela con miles de procesadores distribuidos y almacenamiento local en lugar de global.
Automatizar los aspectos administrativos implica que el desarrollador del lenguaje tenga que ocuparse de ellos, pero a cambio dispone de muchas más oportunidades para utilizar mecanismos de computación muy diferentes con distintas arquitecturas de máquina.
Ejemplos
pila de protocolos de Internet
El SoC es fundamental para el diseño de Internet. En el conjunto de protocolos de Internet , se han realizado grandes esfuerzos para separar las responsabilidades en capas bien definidas . Esto permite a los diseñadores de protocolos centrarse en las responsabilidades de una capa e ignorar las demás. El protocolo de la capa de aplicación SMTP , por ejemplo, se ocupa de todos los detalles de la comunicación de correo electrónico a través de un servicio de transporte fiable (normalmente TCP ), pero no se preocupa en absoluto de cómo el servicio de transporte garantiza su fiabilidad. Del mismo modo, TCP no se ocupa del enrutamiento de los paquetes de datos, que se gestiona en la capa de Internet .
HTML, CSS, JavaScript
HTML , CSS y JavaScript son lenguajes complementarios que se utilizan en el desarrollo de páginas web y sitios web. HTML se usa principalmente para organizar el contenido de la página web, CSS para definir el estilo de presentación del contenido y JavaScript para definir cómo interactúa el contenido con el usuario. Históricamente, esto no era así: antes de la introducción de CSS, HTML cumplía ambas funciones, definiendo tanto la semántica como el estilo.
Programación orientada a temas
La programación orientada a sujetos permite abordar las distintas preocupaciones como construcciones de software independientes, cada una en igualdad de condiciones con las demás. Cada preocupación proporciona su propia estructura de clases en la que se organizan los objetos comunes y aporta estado y métodos al resultado compuesto donde se interrelacionan. Las reglas de correspondencia describen cómo se relacionan las clases y los métodos de las distintas preocupaciones en los puntos de interacción, lo que permite derivar el comportamiento compuesto de un método a partir de varias preocupaciones. El modelo SoC multidimensional permite manipular el análisis y la composición de las preocupaciones como una "matriz" multidimensional en la que cada preocupación proporciona una dimensión en la que se enumeran diferentes puntos de elección, y las celdas de la matriz están ocupadas por los artefactos de software correspondientes.
Programación orientada a aspectos
La programación orientada a aspectos permite abordar las preocupaciones transversales como preocupaciones principales. Por ejemplo, la mayoría de los programas requieren algún tipo de seguridad y registro de eventos . La seguridad y el registro suelen ser preocupaciones secundarias, mientras que la preocupación principal suele ser lograr los objetivos de negocio. Sin embargo, al diseñar un programa, su seguridad debe integrarse en el diseño desde el principio, en lugar de tratarse como una preocupación secundaria. Aplicar la seguridad posteriormente suele resultar en un modelo de seguridad insuficiente que deja demasiadas brechas para futuros ataques. Esto puede resolverse con la programación orientada a aspectos. Por ejemplo, se puede escribir un aspecto para garantizar que las llamadas a una API determinada siempre se registren, o que los errores siempre se registren cuando se produce una excepción, independientemente de si el código procedimental del programa maneja la excepción o la propaga. [ 6 ]
Niveles de análisis en inteligencia artificial
En la ciencia cognitiva y la inteligencia artificial , es común referirse a los niveles de análisis de David Marr . En un momento dado, un investigador puede centrarse en qué necesita computar algún aspecto de la inteligencia, qué algoritmo emplea o cómo se implementa dicho algoritmo en el hardware. Esta separación de responsabilidades es similar a la distinción entre interfaz e implementación en la ingeniería de software y hardware.
Véase también
Referencias
- 1 2 3 Ghezzi, Carlo; Jazayeri, Mehdi; Mandrioli, Dino (2003). Fundamentos de la ingeniería de software (2. ed., [Nachdr.] ed.). Upper Saddle River, Nueva Jersey: Prentice Hall. ISBN 978-0-13-305699-0.
- 1 2 3 Dijkstra, Edsger W (1982). "Sobre el papel del pensamiento científico" . Escritos selectos sobre informática: una perspectiva personal . Nueva York, NY, EE. UU.: Springer-Verlag. págs. 60-66 . ISBN 0-387-90652-5.
- ↑ Kruchten, PB (1995). "El modelo de vista 4+1 de la arquitectura" . IEEE Software . 12 (6): 42– 50. arXiv : 2006.04975 . doi : 10.1109/52.469759 . ISSN 0740-7459 .
- ↑ Laplante, Phillip (2007). Lo que todo ingeniero debería saber sobre ingeniería de software . CRC Press. ISBN 978-0-8493-7228-5.
- ↑ Reade, Chris (1989). Elementos de programación funcional . Boston, MA, EE. UU.: Addison-Wesley Longman. ISBN 0-201-12915-9.
- ↑ Jess Nielsen (junio de 2006). "Creación de aplicaciones seguras" (PDF) . Consultado el 8 de febrero de 2012 .
Enlaces externos
- Separación multidimensional de preocupaciones Archivado el 9 de agosto de 2016 en Wayback Machine
- TAOSAD -- Archivado el 19 de diciembre de 2016 en Wayback Machine
- Tutorial y taller sobre programación orientada a aspectos y separación de responsabilidades. Archivado el 16 de mayo de 2008 en Wayback Machine.
- Principios de programación
- Reduccionismo