SlideShare una empresa de Scribd logo
1 de 7
Arquitectura de software
Arquitectura de software. La arquitectura de software es un conjunto de patrones
que proporcionan un marco de referencia necesario para guiar la construcción de un
software,permitiendo a los programadores, analistas y todo el conjunto de
desarrolladores del software compartir una misma línea de trabajo y cubrir todos los
objetivos y restricciones de la aplicación.Es considerada el nivel más alto en el diseño
de la arquitectura de un sistema puesto que establecen la estructura,funcionamiento e
interacción entre las partes del software
Concepto: Conjuntode patronesque proporcionanun
marco de referencianecesarioparaguiarla
construcciónde un software.
Arquitectura"[editar]
La arquitectura de software es el diseño de más alto nivel de la estructura de un sistema.
 Una arquitectura de software, también denominada arquitectura lógica, consiste en un
conjunto de patrones y abstracciones coherentes que proporcionan un marco definido y
claro para interactuar con el código fuente del software.
 Una arquitectura de software se selecciona y diseña con base en objetivos (requisitos) y
restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero
no solamente los de tipo funcional, también otros objetivos como el mantenimiento, la
auditoria, flexibilidad e interacción con otros sistemas de información. Las restricciones
son aquellas limitaciones derivadas de las tecnologías disponibles para implementar
sistemas de información. Unas arquitecturas son más recomendables de implementar con
ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas
arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres
capas para implementar sistemas en tiempo real.
 La arquitectura de software define, de manera abstracta, los componentes que llevan a
cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda
arquitectura debe ser implementable en una arquitectura física, que consiste simplemente
en determinar qué computadora tendrá asignada cada tarea.
¿Por qué es importante la arquitectura de software?
La arquitectura de software es de especial importancia ya que la manera en que
se estructura un sistema tiene un impacto directo sobre la capacidad de este para
satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de
atributos de calidad son el desempeño, que tiene que ver con el tiempo de
respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene
que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el
sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta
introducir cambios en el sistema. Los atributos de calidad son parte de los
requerimientos (no funcionales) del sistema y son características que deben
expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el
sistema debe devolver una petición “de manera rápida”, o presentar una página
“ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos
requerimientos.
La manera en que se estructura un sistema permitirá o impedirá que se satisfagan
los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que
una petición deba transitar por muchos componentes antes de que se devuelva
una respuesta podría tener un desempeño pobre. Por otro lado, un sistema
estructurado de tal manera que los componentes estén altamente acoplados entre
ellos limitará severamente la modificabilidad. Curiosamente, la estructuración tiene
un impacto mucho menor respecto a los requerimientos funcionales del sistema.
Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los
requerimientos funcionales que se le imponen.
Además de los atributos de calidad, la arquitectura de software juega un papel
fundamental para guiar el desarrollo. Una de las múltiples estructuras que la
componen se enfoca en partir el sistema en componentes que serán desarrollados
por individuos o grupos de individuos. La identificación de esta estructura de
asignación de trabajo es esencial para apoyar las tareas de planeación del
proyecto.
Finalmente, los diseños arquitectónicos que se crean en una organización pueden
ser reutilizados para crear sistemas distintos. Esto permite reducir costos y
aumentar la calidad, sobre todo si dichos diseños han resultado previamente en
sistemas exitosos.
Componentes e interacciones
Componetentes
La arquitectura de software se compone por:
 clientes y servidores.
 bases de datos.
 filtos.
 niveles en sistemas jerárquico.
Interacciones
Entre los componentes de la arquitectura de software existe un conjunto de
interacciones entre las que sobresalen :
 llamadas a procedimientos.
 comportamiento de variables.
 protocolos cliente servidor.
 transmición asíncrona de eventos.
Características
La arquitectura de software forma la columna vertebral para construir un sistema de
software,es en gran medida responsable de permitir o no ciertos atributos de calidad
del sistema entre los que se destacan la confiabilidad y el rendimiento del
software.Además es un modelo abstracto reutilizable[1]
que puede transferirse de
un sistema a otro y que representa un medio de comunicación y discusión entre
participantes del proyecto,permitiendo así la interacción e intercambio entre los
desarrolladores con el objetivo final de establecer el intercambio de conocimientos y
puntos de vista entre ellos.
Arquitectura de software
Tipos de arquitecturas
Para utilizar la arquitectura de software se sigue un conjunto de patrones
arquitectónicos,entre los cuales podemos encontrar:
 Cliente-Servidor
 Blackboard.
 Modelo entre capas.
 Intérprete.
 Orientado a servicios.
Niveles de un diseños de software
El diseño de software tiene varios niveles los cuales están relacionados entre sí,cada
nivel tiene sus propios problemas,técnicas de análisis y componentes los que pueden
ser simples o complejos,reglas de composición las cuales permiten construir
componentes complejos.
Modelos de la arquitectura de software
La arquitectura de software cuenta con varios modelos,ellos son:
Modelos estructurales
Son similares a la vista estructural, pero su énfasis primario radica en la (usualmente
una sola) estructura coherente del sistema completo, en vez de concentrarse en su
composición. Los modelos de framework a menudo se refieren a dominios o clases de
problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de
software específicas de dominios, como CORBA, o modelos basados en CORBA,
o repositorios de componentes específicos, como PRISM.
Modelos dinámicos
Enfatizan la cualidad conductual de los sistemas ,“Dinámico” puede referirse a los
cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de
la computación, tales como valores cambiantes de datos.
Modelos de proceso
Se concentran en la construcción de la arquitectura, y en los pasos o procesos
involucrados en esa construcción. En esta perspectiva, la arquitectura es el resultado
de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual
trabajo sobre programación de procesos para derivar arquitecturas.
Breve reseña histórica[editar]
En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de
investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los años
1990 tras reconocerse la denominada crisis del software y como tema de interés de la
incipiente disciplina de la ingeniería del software.
Modelos o vistas[editar]
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente,
cada uno de estos aspectos se describe de una manera más comprensible si se utilizan
distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una
descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento
entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado
que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir
una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en
cualquier arquitectura:
 La visión estática: describe qué componentes tiene la arquitectura.
 La visión funcional: describe qué hace cada componente.
 La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y
como interactúan entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o
varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como
los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados
únicamente para un modelo o vista. Afortunadamente existe cierto consenso en
adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje
único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de
no ser capaz de describir determinadas restricciones de un sistema de información (o
expresarlas de manera incomprensible).
Arquitecturas más comunes[editar]
Generalmente, no es necesario inventar una nueva arquitectura de software para cada
sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus
ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales
son:
 Descomposición Modular. Donde el software se estructura en grupos funcionales muy
acoplados.
 Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes
independientes pero sin reparto claro de funciones.
 Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la
carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para
la presentación (interfazde usuario), otra para el cálculo (donde se encuentra modelado el
negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación
con la siguiente.
Otras arquitecturas menos conocidas son:
 Modelo Vista Controlador.
 En pipeline.
 Entre pares.
 En pizarra.
 Orientada a servicios (SOA del inglés Service-Oriented Architecture).
 Arquitectura de microservicios (MSA del inglés MicroServices Architecture). Algunos
consideran que es una especialización de una forma de implementar SOA.
 Dirigida por eventos.
 Máquinas virtuales
El ciclo de desarrollo de la arquitectura
Dentro de un proyecto de desarrollo, e independientemente de la metodología que
se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este
desarrollo, que precede a la construcción del sistema, esta dividido en las
siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe
señalar que las actividades relacionadas con el desarrollo de la arquitectura de
software generalmente forman parte de las actividades definidas dentro de las
metodologías de desarrollo.
A continuación se describen dichas etapas.
Requerimientos. La etapa de requerimientos se enfoca en la captura,
documentación y priorización de requerimientos que influencian la arquitectura.
Como se mencionó anteriormente, los atributos de calidad juegan un papel
preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en
ellos. Otros requerimientos, sin embargo, son también relevantes para la
arquitectura, estos son los requerimientos funcionales primarios y las restricciones.
Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y
probablemente la más compleja. Durante esta etapa se definen las estructuras
que componen la arquitectura. La creación de estas estructuras se hace en base a
patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se
realiza debe buscar ante todo satisfacer los requerimientos que influencian a la
arquitectura, y no simplemente incorporar diversas tecnologías por que están “de
moda”.
Documentación. Una vez creado el diseño de la arquitectura, es necesario poder
comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa
del diseño muchas veces depende de que dicho diseño sea documentado de
forma apropiada. La documentación de una arquitectura involucra la
representación de varias de sus estructuras que son representadas a través de
distintas vistas. Una vista generalmente contiene un diagrama, además de
información adicional, que apoya en la comprensión de dicho diagrama.
Evaluación. Dado que la arquitectura de software juega un papel crítico en el
desarrollo, es conveniente evaluar el diseño una vez que este ha sido
documentado con el fin de identificar posibles problemas y riesgos. La ventaja de
evaluar el diseño es que es una actividad que se puede realizar de manera
temprana (aún antes de codificar), y que el costo de corrección de los defectos
identificados a través de la evaluación es mucho menor al costo que tendría el
corregir estos defectos una vez que el sistema ha sido construido.
El rol de arquitecto
Las actividades descritas anteriormente requieren de habilidades particulares que
son la responsabilidad del arquitecto de software. El arquitecto es un líder técnico
que debe conocer los principios relacionados con la arquitectura de software, tener
un amplio conocimiento respecto a la tecnología, y tener excelentes habilidades de
comunicación escrita y oral.
Desafortunadamente, en la actualidad pocos arquitectos de software que laboran
en la industria han recibido una formación teórica respecto al tema. Esto se debe a
que no es sino hasta épocas recientes que se han establecido de manera más
formal los conceptos relacionados con la arquitectura de software, y que
actualmente pocas instituciones ofrecen cursos enfocados en el tema. El
desconocimiento de los principios relativos a la arquitectura de software
frecuentemente impacta de manera negativa a los proyectos de desarrollo.
Apenas empezamos
A lo largo de las distintas entregas de esta columna que inicia se buscará dar una
panorámica del tema de arquitectura de software y se discutirá de manera más
detallada aspectos como:
 requerimientos que influyen en la arquitectura,
 el diseño, documentación y evaluación de la arquitectura,
 los retos relacionados con la introducción de prácticas de arquitectura de
software en un contexto organizacional,
 la arquitectura de software dentro de las metodologías de desarrollo,
 el perfil del arquitecto de software.

Más contenido relacionado

Similar a Arquitectura de software.docx

Similar a Arquitectura de software.docx (20)

Fundamentos
FundamentosFundamentos
Fundamentos
 
Patricio quiros tarea final
Patricio quiros tarea finalPatricio quiros tarea final
Patricio quiros tarea final
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Guillermo cárdenas
Guillermo cárdenasGuillermo cárdenas
Guillermo cárdenas
 
Guillermo cárdenas
Guillermo cárdenasGuillermo cárdenas
Guillermo cárdenas
 
Clase 16 arq-capa-negocios
Clase 16  arq-capa-negociosClase 16  arq-capa-negocios
Clase 16 arq-capa-negocios
 
Diseño de-la-arquitectura-de-software
Diseño de-la-arquitectura-de-softwareDiseño de-la-arquitectura-de-software
Diseño de-la-arquitectura-de-software
 
9.diseño de la arquitectura
9.diseño de la arquitectura9.diseño de la arquitectura
9.diseño de la arquitectura
 
Tema 2.UML parte 1.ppt
Tema 2.UML parte 1.pptTema 2.UML parte 1.ppt
Tema 2.UML parte 1.ppt
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Desarrollo de software basado en componentes
Desarrollo de software basado en componentesDesarrollo de software basado en componentes
Desarrollo de software basado en componentes
 
MVC.ppt
MVC.pptMVC.ppt
MVC.ppt
 
La arquitectura de 41 vistas
La arquitectura de 41 vistasLa arquitectura de 41 vistas
La arquitectura de 41 vistas
 
Arquitectura de hardware
Arquitectura de hardwareArquitectura de hardware
Arquitectura de hardware
 
Clase De Fds22
Clase De Fds22Clase De Fds22
Clase De Fds22
 
1127082.ppt
1127082.ppt1127082.ppt
1127082.ppt
 
Presentacion Arquitectura
Presentacion ArquitecturaPresentacion Arquitectura
Presentacion Arquitectura
 
Arquitecturas de software
Arquitecturas de softwareArquitecturas de software
Arquitecturas de software
 
arquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdfarquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdf
 
Glosario de terminos
Glosario de terminosGlosario de terminos
Glosario de terminos
 

Último

LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptx
LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptxLINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptx
LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptxdanalikcruz2000
 
Unidad II Doctrina de la Iglesia 1 parte
Unidad II Doctrina de la Iglesia 1 parteUnidad II Doctrina de la Iglesia 1 parte
Unidad II Doctrina de la Iglesia 1 parteJuan Hernandez
 
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptx
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptxSINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptx
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptxlclcarmen
 
Plan Año Escolar Año Escolar 2023-2024. MPPE
Plan Año Escolar Año Escolar 2023-2024. MPPEPlan Año Escolar Año Escolar 2023-2024. MPPE
Plan Año Escolar Año Escolar 2023-2024. MPPELaura Chacón
 
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptx
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptxPPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptx
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptxOscarEduardoSanchezC
 
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfMapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfvictorbeltuce
 
c3.hu3.p1.p3.El ser humano como ser histórico.pptx
c3.hu3.p1.p3.El ser humano como ser histórico.pptxc3.hu3.p1.p3.El ser humano como ser histórico.pptx
c3.hu3.p1.p3.El ser humano como ser histórico.pptxMartín Ramírez
 
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIA
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIATRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIA
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIAAbelardoVelaAlbrecht1
 
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdf
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdfBIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdf
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdfCESARMALAGA4
 
Fundamentos y Principios de Psicopedagogía..pdf
Fundamentos y Principios de Psicopedagogía..pdfFundamentos y Principios de Psicopedagogía..pdf
Fundamentos y Principios de Psicopedagogía..pdfsamyarrocha1
 
Clasificaciones, modalidades y tendencias de investigación educativa.
Clasificaciones, modalidades y tendencias de investigación educativa.Clasificaciones, modalidades y tendencias de investigación educativa.
Clasificaciones, modalidades y tendencias de investigación educativa.José Luis Palma
 
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIA
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIARAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIA
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIACarlos Campaña Montenegro
 
Procesos Didácticos en Educación Inicial .pptx
Procesos Didácticos en Educación Inicial .pptxProcesos Didácticos en Educación Inicial .pptx
Procesos Didácticos en Educación Inicial .pptxMapyMerma1
 
La Función tecnológica del tutor.pptx
La  Función  tecnológica  del tutor.pptxLa  Función  tecnológica  del tutor.pptx
La Función tecnológica del tutor.pptxJunkotantik
 
TEST DE RAVEN es un test conocido para la personalidad.pdf
TEST DE RAVEN es un test conocido para la personalidad.pdfTEST DE RAVEN es un test conocido para la personalidad.pdf
TEST DE RAVEN es un test conocido para la personalidad.pdfDannyTola1
 
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...JAVIER SOLIS NOYOLA
 

Último (20)

LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptx
LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptxLINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptx
LINEAMIENTOS INICIO DEL AÑO LECTIVO 2024-2025.pptx
 
Unidad II Doctrina de la Iglesia 1 parte
Unidad II Doctrina de la Iglesia 1 parteUnidad II Doctrina de la Iglesia 1 parte
Unidad II Doctrina de la Iglesia 1 parte
 
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptx
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptxSINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptx
SINTAXIS DE LA ORACIÓN SIMPLE 2023-2024.pptx
 
Plan Año Escolar Año Escolar 2023-2024. MPPE
Plan Año Escolar Año Escolar 2023-2024. MPPEPlan Año Escolar Año Escolar 2023-2024. MPPE
Plan Año Escolar Año Escolar 2023-2024. MPPE
 
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptx
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptxPPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptx
PPT GESTIÓN ESCOLAR 2024 Comités y Compromisos.pptx
 
TL/CNL – 2.ª FASE .
TL/CNL – 2.ª FASE                       .TL/CNL – 2.ª FASE                       .
TL/CNL – 2.ª FASE .
 
Earth Day Everyday 2024 54th anniversary
Earth Day Everyday 2024 54th anniversaryEarth Day Everyday 2024 54th anniversary
Earth Day Everyday 2024 54th anniversary
 
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdfMapa Mental de estrategias de articulación de las areas curriculares.pdf
Mapa Mental de estrategias de articulación de las areas curriculares.pdf
 
c3.hu3.p1.p3.El ser humano como ser histórico.pptx
c3.hu3.p1.p3.El ser humano como ser histórico.pptxc3.hu3.p1.p3.El ser humano como ser histórico.pptx
c3.hu3.p1.p3.El ser humano como ser histórico.pptx
 
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIA
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIATRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIA
TRIPTICO-SISTEMA-MUSCULAR. PARA NIÑOS DE PRIMARIA
 
Tema 7.- E-COMMERCE SISTEMAS DE INFORMACION.pdf
Tema 7.- E-COMMERCE SISTEMAS DE INFORMACION.pdfTema 7.- E-COMMERCE SISTEMAS DE INFORMACION.pdf
Tema 7.- E-COMMERCE SISTEMAS DE INFORMACION.pdf
 
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdf
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdfBIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdf
BIOLOGIA_banco de preguntas_editorial icfes examen de estado .pdf
 
Fundamentos y Principios de Psicopedagogía..pdf
Fundamentos y Principios de Psicopedagogía..pdfFundamentos y Principios de Psicopedagogía..pdf
Fundamentos y Principios de Psicopedagogía..pdf
 
Clasificaciones, modalidades y tendencias de investigación educativa.
Clasificaciones, modalidades y tendencias de investigación educativa.Clasificaciones, modalidades y tendencias de investigación educativa.
Clasificaciones, modalidades y tendencias de investigación educativa.
 
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIA
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIARAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIA
RAIZ CUADRADA Y CUBICA PARA NIÑOS DE PRIMARIA
 
Procesos Didácticos en Educación Inicial .pptx
Procesos Didácticos en Educación Inicial .pptxProcesos Didácticos en Educación Inicial .pptx
Procesos Didácticos en Educación Inicial .pptx
 
La Función tecnológica del tutor.pptx
La  Función  tecnológica  del tutor.pptxLa  Función  tecnológica  del tutor.pptx
La Función tecnológica del tutor.pptx
 
TEST DE RAVEN es un test conocido para la personalidad.pdf
TEST DE RAVEN es un test conocido para la personalidad.pdfTEST DE RAVEN es un test conocido para la personalidad.pdf
TEST DE RAVEN es un test conocido para la personalidad.pdf
 
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...
LA ECUACIÓN DEL NÚMERO PI EN LOS JUEGOS OLÍMPICOS DE PARÍS. Por JAVIER SOLIS ...
 
Power Point: "Defendamos la verdad".pptx
Power Point: "Defendamos la verdad".pptxPower Point: "Defendamos la verdad".pptx
Power Point: "Defendamos la verdad".pptx
 

Arquitectura de software.docx

  • 1. Arquitectura de software Arquitectura de software. La arquitectura de software es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construcción de un software,permitiendo a los programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea de trabajo y cubrir todos los objetivos y restricciones de la aplicación.Es considerada el nivel más alto en el diseño de la arquitectura de un sistema puesto que establecen la estructura,funcionamiento e interacción entre las partes del software Concepto: Conjuntode patronesque proporcionanun marco de referencianecesarioparaguiarla construcciónde un software. Arquitectura"[editar] La arquitectura de software es el diseño de más alto nivel de la estructura de un sistema.  Una arquitectura de software, también denominada arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan un marco definido y claro para interactuar con el código fuente del software.  Una arquitectura de software se selecciona y diseña con base en objetivos (requisitos) y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como el mantenimiento, la auditoria, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.  La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea. ¿Por qué es importante la arquitectura de software? La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el
  • 2. sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos. La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición deba transitar por muchos componentes antes de que se devuelva una respuesta podría tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los componentes estén altamente acoplados entre ellos limitará severamente la modificabilidad. Curiosamente, la estructuración tiene un impacto mucho menor respecto a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los requerimientos funcionales que se le imponen. Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto. Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos. Componentes e interacciones Componetentes La arquitectura de software se compone por:  clientes y servidores.  bases de datos.  filtos.  niveles en sistemas jerárquico. Interacciones Entre los componentes de la arquitectura de software existe un conjunto de interacciones entre las que sobresalen :  llamadas a procedimientos.  comportamiento de variables.
  • 3.  protocolos cliente servidor.  transmición asíncrona de eventos. Características La arquitectura de software forma la columna vertebral para construir un sistema de software,es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del software.Además es un modelo abstracto reutilizable[1] que puede transferirse de un sistema a otro y que representa un medio de comunicación y discusión entre participantes del proyecto,permitiendo así la interacción e intercambio entre los desarrolladores con el objetivo final de establecer el intercambio de conocimientos y puntos de vista entre ellos. Arquitectura de software Tipos de arquitecturas Para utilizar la arquitectura de software se sigue un conjunto de patrones arquitectónicos,entre los cuales podemos encontrar:  Cliente-Servidor  Blackboard.  Modelo entre capas.  Intérprete.  Orientado a servicios. Niveles de un diseños de software El diseño de software tiene varios niveles los cuales están relacionados entre sí,cada nivel tiene sus propios problemas,técnicas de análisis y componentes los que pueden ser simples o complejos,reglas de composición las cuales permiten construir componentes complejos. Modelos de la arquitectura de software
  • 4. La arquitectura de software cuenta con varios modelos,ellos son: Modelos estructurales Son similares a la vista estructural, pero su énfasis primario radica en la (usualmente una sola) estructura coherente del sistema completo, en vez de concentrarse en su composición. Los modelos de framework a menudo se refieren a dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de dominios, como CORBA, o modelos basados en CORBA, o repositorios de componentes específicos, como PRISM. Modelos dinámicos Enfatizan la cualidad conductual de los sistemas ,“Dinámico” puede referirse a los cambios en la configuración del sistema, o a la dinámica involucrada en el progreso de la computación, tales como valores cambiantes de datos. Modelos de proceso Se concentran en la construcción de la arquitectura, y en los pasos o procesos involucrados en esa construcción. En esta perspectiva, la arquitectura es el resultado de seguir un argumento (script) de proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar arquitecturas. Breve reseña histórica[editar] En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los años 1990 tras reconocerse la denominada crisis del software y como tema de interés de la incipiente disciplina de la ingeniería del software. Modelos o vistas[editar] Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa. Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:  La visión estática: describe qué componentes tiene la arquitectura.  La visión funcional: describe qué hace cada componente.  La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.
  • 5. Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible). Arquitecturas más comunes[editar] Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:  Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados.  Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.  Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfazde usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente. Otras arquitecturas menos conocidas son:  Modelo Vista Controlador.  En pipeline.  Entre pares.  En pizarra.  Orientada a servicios (SOA del inglés Service-Oriented Architecture).  Arquitectura de microservicios (MSA del inglés MicroServices Architecture). Algunos consideran que es una especialización de una forma de implementar SOA.  Dirigida por eventos.  Máquinas virtuales El ciclo de desarrollo de la arquitectura Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, esta dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo. A continuación se describen dichas etapas.
  • 6. Requerimientos. La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la arquitectura, estos son los requerimientos funcionales primarios y las restricciones. Diseño. La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías por que están “de moda”. Documentación. Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama. Evaluación. Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido. El rol de arquitecto Las actividades descritas anteriormente requieren de habilidades particulares que son la responsabilidad del arquitecto de software. El arquitecto es un líder técnico que debe conocer los principios relacionados con la arquitectura de software, tener un amplio conocimiento respecto a la tecnología, y tener excelentes habilidades de comunicación escrita y oral. Desafortunadamente, en la actualidad pocos arquitectos de software que laboran en la industria han recibido una formación teórica respecto al tema. Esto se debe a que no es sino hasta épocas recientes que se han establecido de manera más formal los conceptos relacionados con la arquitectura de software, y que actualmente pocas instituciones ofrecen cursos enfocados en el tema. El desconocimiento de los principios relativos a la arquitectura de software frecuentemente impacta de manera negativa a los proyectos de desarrollo. Apenas empezamos
  • 7. A lo largo de las distintas entregas de esta columna que inicia se buscará dar una panorámica del tema de arquitectura de software y se discutirá de manera más detallada aspectos como:  requerimientos que influyen en la arquitectura,  el diseño, documentación y evaluación de la arquitectura,  los retos relacionados con la introducción de prácticas de arquitectura de software en un contexto organizacional,  la arquitectura de software dentro de las metodologías de desarrollo,  el perfil del arquitecto de software.