1.

- Arquitectura de software
https://www.youtube.com/watch?v=7ukajubprdE (1)
https://www.youtube.com/watch?v=rWh7RtVJzhA (2)
En los inicios de la informática, la programación se consideraba un arte y se
desarrollaba como tal debido a la dificultad que entrañaba para la mayoría de
las personas, pero con el tiempo se han ido descubriendo y desarrollando
formas y guías generales, con base a las cuales se puedan resolver los
problemas. A estas, se les ha denominado arquitectura de software, porque,
a semejanza de los planos de un edificio o construcción, estas indican la
estructura, funcionamiento e interacción entre las partes del software.
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 auditoría, 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.
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.

Modelos o vistas
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

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 (interfaz de usuario), otra para el
cálculo (donde se encuentra modelado el negocio) y otra para el
almacenamiento (persistencia).

Proceso para el desarrollo de software

El Proceso para el desarrollo de software, también denominado ciclo de

vida del desarrollo de software es una estructura aplicada al desarrollo de un
producto de software. Hay varios modelos a seguir para el establecimiento de
un proceso para el desarrollo de software, cada uno de los cuales describe un
enfoque diferente para diferentes actividades que tienen lugar durante el
proceso. Algunos autores consideran un modelo de ciclo de vida un término
más general que un determinado proceso para el desarrollo de software. Por
ejemplo, hay varios procesos de desarrollo de software específicos que se
ajustan a un modelo de ciclo de vida de espiral.

Generalidades
La gran cantidad de organizaciones de desarrollo de software implementan
metodologías para el proceso de desarrollo. Muchas de estas organizaciones
pertenecen a la industria armamentística, que en los Estados Unidos necesita
un certificado basado en su modelo de procesos para poder obtener un
contrato.
El estándar internacional que regula el método de selección, implementación y
monitoreo del ciclo de vida del software es ISO 12207.
Durante décadas se ha perseguido la meta de encontrar procesos
reproducibles y predecibles que mejoren la productividad y la calidad. Algunas
de estas soluciones intentan sistematizar o formalizar la aparentemente
desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión
de proyectos para la creación del software. Sin una gestión del proyecto, los
proyectos de software corren el riesgo de demorarse o consumir un
presupuesto mayor que el planeado. Dada la cantidad de proyectos de
software que no cumplen sus metas en términos de funcionalidad, costes o
tiempo de entrega, una gestión de proyectos efectiva es algo imprescindible.
Algunas organizaciones crean un grupo propio (Software Engineering Process
Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo
de software en la organización.

2.- Actividades del desarrollo de software

Planificación
La importante tarea a la hora de crear un producto de software es obtener
los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea
más bien abstracta del resultado final, pero no sobre las funciones que debería
cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un
análisis del ámbito del desarrollo. Este documento se conoce como
especificación funcional.
Planificación: es el paso previo al inicio de cualquier proyecto de desarrollo y
sin dudas el más importante. En este se definen los requerimientos y
funcionalidades que debe tener el software, mediante el trabajo en conjunto
entre los desarrolladores, el departamento de ventas, los estudios de mercado
y, fundamentalmente, el contacto con el cliente. En este punto se realizan
asimismo los análisis de riesgo para el emprendimiento y se fijan los requisitos
de aseguramiento de la calidad.
Implementación, pruebas y documentación
La implementación es parte del proceso en el que los ingenieros de
software programan el código para el proyecto de trabajo que está en relación
de las demandas del software, en esta etapa se realizan las pruebas de caja
blanca y caja negra.
Las pruebas de software son parte esencial del proceso de desarrollo del
software. Esta parte del proceso tiene la función de detectar los errores de
software lo antes posible.
La documentación del diseño interno del software con el objetivo de facilitar su
mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir
la documentación de un API, tanto interior como exterior. Prácticamente es
como una receta de cocina

Despliegue y mantenimiento
El despliegue comienza cuando el código ha sido suficientemente probado, ha
sido aprobado para su liberación y ha sido distribuido en el entorno de
producción.
Entrenamiento y soporte para el software es de suma importancia y algo que
muchos desarrolladores de software descuidan. Los usuarios, por naturaleza,
se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es
fundamental instruir de forma adecuada a los futuros usuarios del software.
El mantenimiento o mejora de un software con problemas recientemente
desplegado, puede requerir más tiempo que el desarrollo inicial del software.
Es posible que haya que incorporar código que no se ajusta al diseño original
con el objetivo de solucionar un problema o ampliar la funcionalidad para un
cliente. Si los costes de mantenimiento son muy elevados puede que sea
oportuno rediseñar el sistema para poder contener los costes de
mantenimiento.

Modelos de Desarrollo de Software

Los modelos de desarrollo de software son una representación abstracta de
una manera en particular. Realmente no representa cómo se debe desarrollar
el software, sino de un enfoque común. Puede ser modificado y adaptado de
acuerdo a las necesidades del software en proceso de desarrollo. Hay varios
modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta
con pros y contras. El proyecto debería escoger el más apropiado para sus
necesidades. En ocasiones puede que una combinación de varios modelos sea
apropiado. Existen tres paradigmas de los modelos de desarrollo de software:
1. Paradigma Tradicional:
Es uno de los paradigmas más antiguo, se inventó durante la creación del
método estructurado. Si se elige un proyecto, el método varia en etapas. Como
todo modelo, existen sus pros y contras al usar este paradigma:
Si se aplica este paradigma, unos de los principales problemas, es que las
etapas realizadas no son autónomas de las siguientes, creando una
dependencia estructural y en el caso de un error atrasaría todo el proyecto. Se
tiene que tener pautas bien definidas, y que no se incurra a modificación
porque implicaría en que el software no cumpla con su ciclo de vida. Tener en
cuenta que el cliente no se vea afectado por la impaciencia.
2. Paradigma Orientado a Objetos: Estos modelos se basan en
la Programación orientada a objetos; por lo tanto, se refiere al concepto de
clase, el análisis de requisitos y el diseño. El modelo o paradigma orientado a
objetos posee dos características principales, las cuales son:
Permite la re-utilización de software.
Facilita el desarrollo de herramientas informáticas de apoyo al desarrollo, el
cual es simple al implementarla en una notación orientada a objetos
llamado UML.
3. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De
Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos
caminos de las metodologías tradicionales enfocándose en las personas y los
resultados. Usa un enfoque basado en el Valor para construir software,
colaborando con el cliente e incorporando los cambios continuamente.

Principales Roles en el proceso de Desarrollo de Software

Un Rol se define como una “Función que alguien o algo cumple” (Abstracta
Academy, 2016).
Cada uno de los roles aportará al grupo parte del total necesario para tener
éxito en el desarrollo. Los roles son necesarios para cubrir todas las
especificaciones necesarias para cumplir un proceso ya que no todos tenemos
las mismas cualidades y experiencias. Además al asignar roles, se definen
objetivos y actividades para cada uno; evitando que alguna actividad no sea
asignada o que dos personas realicen el mismo trabajo.
Descripción de roles en el Proceso de Desarrollo de Software
El software se construye en equipo y hay muchas metodologías diferentes. Los
roles se asignan de acuerdo a las capacidades de cada persona, así como
también su especialización, experiencia e interés. Los roles más comunes son:
Gerente de proyecto
Tiene por función presentar informes sobre las litigaciones de riesgos, hacer
cumplir los plazos y lleva el control de los costos. También organiza el equipo,
realiza planificación y estima el tiempo de las actividades. En conclusión,
resuelve problemas.
Analista de requerimientos
Se encarga del revelamiento de los requerimientos esenciales para
el desarrollo del Software, la documentación de los requerimientos para así el
resto del equipo lo pueda consultar en cualquier momento. Debe ser una
persona con capacidad de abstracción y análisis.

Arquitecto de software
Determina las estructuras de la aplicación y las tecnologías con las que se
construirá la aplicación. Está encargado del aseguramiento de la calidad,
mejorar continuamente la arquitectura. Gestiona los requerimientos no
funcionales, asume la dirección técnica para asegurar que todos los aspectos
de la arquitectura se estén desarrollando de manera correcta.
Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a
los integrantes del equipo, dispuesto a recibir y aplicar abiertamente
recomendaciones.

Desarrollador de software o programador

Encargado de la concepción y el diseño, escribe el código, prueba lo que
construye y se encarga de hacer el mantenimiento del código.
Testeador
Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar
claro está, estudiar funcionalidad del producto y desarrollar las pruebas que
revelen incidentes críticos. Reporta los incidentes y provee información sobre la
calidad del sistema.

3.- PERSPECTIVA DE CALIDAD

La palabra calidad tiene múltiples significados.

Es un conjunto de propiedades inherentes a un objeto que le confieren

capacidad para satisfacer necesidades implícitas o explícitas. La calidad de un
producto o servicio es la percepción que el cliente tiene del mismo, es una
fijación mental del consumidor que asume conformidad con dicho producto o
servicio y la capacidad del mismo para satisfacer sus necesidades. Por tanto,
debe definirse en el contexto que se esté considerando, por ejemplo, la calidad
del servicio postal, del servicio dental, del producto, de vida, etc.
Definición de la norma ISO 9000:

“Calidad: grado en el que un conjunto de características inherentes cumple con

los requisitos”
Según Luis Andres Arnauda Sequera Define la norma ISO 9000 "Conjunto de
normas y directrices de calidad que se deben llevar a cabo en un proceso".
Real Academia de la Lengua Española: “Propiedad o conjunto de propiedades
inherentes a una cosa que permiten apreciarla como igual, mejor o peor que las
restantes de su especie”
Características de calidad de software

¿Qué es la calidad del software? En 1990 se establecen principios de calidad

del Software
 Calidad del producto, en todos sus estados
 Calidad del proceso
¿Qué diferencia hay con otros productos?
 Naturaleza
 Ciclo de vida
 Flexibilidad
 Reutilización

El software es una de las herramientas de mayor utilidad en la optimización de

procesos en las organizaciones, con el propósito de contar y ofrecer
optimización, eficiencia y satisfacción de necesidades, razón por la cual el
software debe contar con criterios que garanticen su calidad. De acuerdo con
esta necesidad, diferentes entidades o investigadores han propuesto
estrategias modelos, metodologías, guías, incluso normas y estándares de
calidad que brindan apoyo al desarrollo y/o uso de un producto software y
permiten evaluar si efectivamente tiene un nivel de calidad durante su ciclo de
vida, y de esta manera fomentar un ambiente de calidad, con base en la
adecuada administración de la información.
En este documento se contextualiza inicialmente en cuanto a términos propios
de calidad de software, posterior a esto se realiza una clasificación de los
modelos de acuerdo con el enfoque presentado (proceso, producto y uso) y al
tiempo de aparición; esto con el fin de dar a conocer aquellos modelos que se
consideran pioneros o base del desarrollo de otros recientes, de igual manera
se realiza una descripción de las características más relevantes de algunos
modelos, su estructura y objetivo, finalmente se presentan casos de aplicación
de algunos modelos en el sector empresarial.
Contextualización de calidad de software
Es importante conocer los conceptos y características acerca de lo que es la
calidad de software, y en cuanto a los modelos de calidad de software, su
estructura y enfoque.
El término calidad de software se refiere al grado de desempeño de las
principales características con las que debe cumplir un sistema computacional
durante su ciclo de vida, dichas características de cierta manera garantizan que
el cliente cuente con un sistema confiable, lo cual aumenta su satisfacción
frente a la funcionalidad y eficiencia del sistema construido.
El concepto de calidad de software, según Pressman (2010) se asocia a la
"concordancia con los requisitos funcionales y de rendimiento explícitamente
establecidos con los estándares de desarrollo plenamente documentados y con
las características implícitas que se espera de todo software desarrollado
profesionalmente", con base en los requisitos funcionales y no funcionales
identificados en la etapa de análisis del sistema, insumo principal para
implementar dichos requisitos con los atributos mínimos de calidad,
fomentando la aplicación de procesos estandarizados y criterios necesarios en
cada una de sus etapas, así se fomenta que el avance en el ciclo de vida del
software minimice el riesgo de fracaso del proyecto. Por su parte, el Instituto de
Ingenieros Eléctricos y Electrónicos (IEEE, 1990) define calidad de software
como "el grado con el que un sistema, componente o proceso cumple los
requerimientos especificados y las necesidades o expectativas del cliente o
usuario", denotando que el énfasis radica en los requisitos específicos del
sistema y en la búsqueda de la satisfacción del cliente.
Para garantizar la calidad de software es importante implementar algún modelo
o estándar de calidad que permita la gestión de atributos en el proceso de
construcción de software, teniendo en cuenta que la concordancia de los
requisitos y su construcción son la base de las medidas de calidad
establecidas.
Modelos de calidad de software
Aunque modelo y metodología distan en su definición, se rescata la cita dada
por Moszkowitz (2010) en la que presenta una metodología que permite a
cualquier organización realizar una autoevaluación o autodiagnóstico, por
medio de una revisión sistemática de sus estrategias y prácticas de gestión.
En el caso de la calidad de software el modelo debe ir enfocado a hacer
seguimiento y evaluación a cada etapa de construcción del producto software.
Por otro lado se menciona (Scalone, 2006) que
Los modelos de calidad son aquellos documentos que integran la mayor parte
de las mejores prácticas, proponen temas de administración en los que cada
organización debe hacer énfasis, integran diferentes prácticas dirigidas a los
procesos clave y permiten medir los avances en calidad.
Esta definición, enfocada a la calidad del software, identifica que la
organización debe contar con un proceso que como soporte al mismo lleve una
documentación, y se valga de distintas prácticas definidas en el modelo, dando
apoyo a la organización para tener una mejora continua y ser más
competentes, para así poder medir la calidad y brindar producto o servicios de
alto nivel.
En el ámbito de la construcción de software, el modelo de calidad debe permitir
evaluar el sistema, bien sea cualitativa o cuantitativamente, y de acuerdo con
esta evaluación la organización podrá proponer e implementar estrategias que
permitan la mejora del proceso dentro de las etapas de análisis, diseño,
desarrollo y pruebas del software.
Estructura y enfoque de los modelos de calidad de software
Los modelos de calidad de software generalmente están estructurados como
se muestra en la Figura 1 (Scalone, 2006) y (Bautista, 2012), donde se pueden
tener diversos factores de calidad que a su vez se componen de criterios que
son evaluados por métricas, con el propósito de abordar la evaluación desde lo
general a lo particular, y permitir la reducción de la subjetividad en la
asignación de un valor, ya sea cuantitativo o cualitativo.

Así mismo, los modelos de calidad de software se clasifican de acuerdo con el

enfoque de evaluación, ya sea a nivel de proceso, producto o calidad en uso.
C ALIDAD A NIVEL DE PR OCESO
La calidad de un sistema software debe ser programada desde el inicio del
proyecto, y posteriormente en cada etapa del proceso de desarrollo se debe
llevar a cabo el control y seguimiento de los aspectos de calidad, para
minimizar los riesgos y ofrecer soporte continuo, se garantiza así un óptimo
nivel de cumplimiento de los factores de calidad, teniendo en cuenta que si en
alguna de las etapas se deja de lado la verificación de los factores y criterios es
posible que se presente deficiencia en alguno de éstos y disminuirá el nivel de
calidad no solo del proceso, sino también del producto en desarrollo.
C ALIDAD A NIVEL DE PR ODUCTO

La principal finalidad del modelo de calidad de producto es especificar y evaluar

el cumplimiento de criterios del producto, para lo cual se aplican medidas
internas y/o medidas externas (Bevan, 2010). Por esta razón, algunas normas y
estándares han definido la calidad a nivel de producto en tres tipos: interna,
externa y en uso (Rodríguez, 2016). Este enfoque está orientado a verificar el
cumplimiento de las características que permitan alcanzar la satisfacción del
cliente en cuanto a los requisitos definidos en las etapas iniciales del proceso
de desarrollo.
C ALIDAD EN USO

Es importante resaltar que aunque en diferentes escenarios se utilizan los

términos usabilidad y calidad en uso, con el mismo propósito y de forma
intercambiable tienen significados distintos, principalmente porque el concepto
de calidad en uso es más amplio y abarca más elementos que la usabilidad
(Covella, 2005), y esta última es una de las características de calidad de un
producto software. La calidad en uso se define como el "conjunto de atributos
relacionados con la aceptación por parte del usuario final y seguridad", y está
basada en la eficacia, productividad, seguridad y satisfacción, según ISO/IEC
9126.
Estilos de Arquitectura
¿Qué es un patrón arquitectónico?
Un patrón arquitectónico es una solución general y reutilizable a un problema
común en la arquitectura de software dentro de un contexto dado. Los patrones
arquitectónicos son similares al patrón de diseño de software pero tienen un
alcance más amplio.
Se explicará brevemente los siguientes 10 patrones arquitectónicos comunes
con su uso, pros y contras.
1. Patrón de capas
2. Patrón cliente-servidor
3. Patrón maestro-esclavo
4. Patrón de filtro de tubería
5. Patrón de intermediario
6. Patrón de igual a igual
7. Patrón de bus de evento
 8. Modelo-vista-controlador
9. Patrón de pizarra
10. Patrón de intérprete

1. Patrón de capas

Este patrón se puede utilizar para estructurar programas que se pueden

descomponer en grupos de subtareas, cada una de las cuales se encuentra en
un nivel particular de abstracción. Cada capa proporciona servicios a la
siguiente capa superior.
Las 4 capas más comúnmente encontradas de un sistema de información
general son las siguientes.
Capa de presentación (también conocida como capa UI )
Capa de aplicación (también conocida como capa de servicio )
Capa de lógica de negocios (también conocida como capa de dominio )
Capa de acceso a datos (también conocida como capa de persistencia)
Uso
 Aplicaciones de escritorio generales.
 Aplicaciones web de comercio electrónico.

2. Patrón cliente-servidor
Este patrón consiste en dos partes; un servidor y múltiples clientes. El
componente del servidor proporcionará servicios a múltiples componentes del
cliente. Los clientes solicitan servicios del servidor y el servidor proporciona
servicios relevantes a esos clientes. Además, el servidor sigue escuchando las
solicitudes de los clientes.
Uso
Aplicaciones en línea como correo electrónico, uso compartido de documentos y
banca.
3. Patrón maestro-esclavo
Este patrón consiste en dos partes; maestro y esclavos. El componente
maestro distribuye el trabajo entre componentes esclavos idénticos y calcula el
resultado final de los resultados que devuelven los esclavos.
Uso
En la replicación de la base de datos, la base de datos maestra se considera
como la fuente autorizada y las bases de datos esclavas se sincronizan con
ella.
Periféricos conectados a un bus en un sistema informático (unidades maestra y
esclava).
4. Patrón de filtro de tubería

Este patrón se puede usar para estructurar sistemas que producen y procesan una secuencia de
datos. Cada paso de procesamiento se incluye dentro de un componente de filtro. Los datos
que se procesarán se pasan a través de las tuberías. Estas tuberías se pueden utilizar para el
almacenamiento en búfer o con fines de sincronización.

Uso

Compiladores Los filtros consecutivos realizan análisis léxico, análisis sintáctico y generación de
código.

Flujos de trabajo en bioinformática.

5. Patrón del agente

Este patrón se usa para estructurar sistemas distribuidos con componentes
desacoplados. Estos componentes pueden interactuar entre sí mediante
invocaciones de servicios remotos. Un componente de intermediario es
responsable de la coordinación de la comunicación entre los componentes.
Los servidores publican sus capacidades (servicios y características) a un
intermediario. Los clientes solicitan un servicio del intermediario y el
intermediario redirecciona al cliente a un servicio adecuado desde su registro.
Uso
Software de Message Broker como: Apache ActiveMQ , Apache
Kafka , RabbitMQ y JBoss Messaging .

6. Patrón de igual a igual

En este patrón, los componentes individuales se conocen como pares. Los
pares pueden funcionar tanto como un cliente, solicitando servicios de otros
pares, y como un servidor, proporcionando servicios a otros pares. Un par
puede actuar como un cliente o como un servidor o como ambos, y puede
cambiar su rol dinámicamente con el tiempo.
Uso
Redes de intercambio de archivos como Gnutella y G2
Protocolos multimedia como P2PTV y PDTP
7. Patrón de bus de evento
Este patrón trata principalmente con eventos y tiene 4 componentes
principales; fuente de evento, escucha de evento, canal y bus de evento.
Las fuentes publican mensajes en canales particulares en un bus de eventos.
Los oyentes se suscriben a canales particulares. Los oyentes son notificados de
los mensajes que se publican en un canal al que se han suscrito anteriormente.
Uso
 Desarrollo de Android
 Servicios de notificación
8. Patrón de modelo-vista-controlador
Este patrón, también conocido como patrón MVC, divide una aplicación
interactiva en 3 partes, como
modelo — contiene la funcionalidad y los datos básicos
vista : muestra la información al usuario (se puede definir más de una vista)
controlador : maneja la entrada del usuario
Esto se hace para separar las representaciones internas de información de las
formas en que se presenta y acepta la información del usuario. Desacopla los
componentes y permite la reutilización eficiente del código.
Uso
Arquitectura para aplicaciones World Wide Web en los principales lenguajes de
programación.
Marcos web como Django y Rails
9. Patrón de pizarra
Este patrón es útil para problemas para los que no se conocen estrategias de
solución deterministas. El patrón de pizarra consta de 3 componentes
principales.
pizarra : una memoria global estructurada que contiene objetos del espacio de
solución
fuente de conocimiento : módulos especializados con su propia
representación
componente de control : selecciona, configura y ejecuta módulos.
Todos los componentes tienen acceso a la pizarra. Los componentes pueden
producir nuevos objetos de datos que se agregan a la pizarra. Los componentes
buscan tipos particulares de datos en la pizarra, y pueden encontrarlos por
coincidencia de patrones con la fuente de conocimiento existente.
Uso
 Reconocimiento de voz
 Identificación y seguimiento del vehículo
 Identificación de la estructura proteica
 Sonar señala la interpretación.
10. Patrón de intérprete
Este patrón se usa para diseñar un componente que interpreta programas
escritos en un lenguaje dedicado. Especifica principalmente cómo evaluar las
líneas de programas, conocidas como oraciones o expresiones escritas en un
idioma particular. La idea básica es tener una clase para cada símbolo del
idioma.
Uso
 Lenguajes de consulta de base de datos como SQL.
 Idiomas utilizados para describir los protocolos de comunicación.
** Pondremos énfasis en 3 Estilos o patrones de Arquitectura **
1. Patrón de capas
2. Patrón cliente-servidor
3. Modelo-vista-controlador

Patrón Arquitectónico de Capas / Layers

https://www.youtube.com/watch?v=G5Qq5fYPpiY (3)

¿Qué es la Arquitectura por capas?

La arquitectura en capas es un patrón de arquitectura software usada en la
gran mayoría de sistemas.
Se centra en una distribución jerárquica de las roles y responsabilidades
proporcionando una separación efectiva de las preocupaciones (cada cual se
encarga de lo que le corresponde).
Al pensar en un sistema en términos de capas, se imaginan los principales
subsistemas de software ubicados de la misma forma que las capas de un
pastel, donde cada capa descansa sobre la inferior.
Por ejemplo, el diseño de una típica aplicación Web comprende:
Capa de presentación (funcionalidad relacionada con la User Interfase)
Capa de negocio (procesamiento de reglas de negocio).También denominada
Lógica de Dominio, esta capa contiene la funcionalidad que implementa la
aplicación. Involucra cálculos basados en la información dada por el usuario y
datos almacenados y validaciones. Controla la ejecución de la capa de acceso
a datos y servicios externos. Se puede diseñar la lógica de la capa de negocios
para uso directo por parte de componentes de presentación o su
encapsulamiento como servicio y llamada a través de una interfaz de servicios
que coordina la conversación con los clientes del servicio o invoca cualquier
flujo o componente de negocio.
Capa de datos (funcionalidad relacionada con el accesos a datos). Es donde
residen los datos y es la encargada de acceder a los mismos. Está formada por
uno o más gestores de bases de datos que realizan todo el almacenamiento de
datos, reciben solicitudes de almacenamiento o recuperación de información
desde la capa de negocio.
Beneficios:
Abstracción, encapsulamiento, capas de funcionalidad muy bien definidas, alta
cohesión, reusabilidad (las capas inferiores de la pirámide no tienen
dependencias de las superiores por lo que es fácil reutilizarlas) y débil
acoplamiento (comunicación basada en abstracciones)
La separación, reduce el riesgo y el impacto de los cambios tecnológicos. Por
ejemplo al cambiar el mecanismo de persistencia de la aplicación las capas
que lo consumen no tienen por qué realizar cambios. Además aumenta el
rendimiento (a partir de cierta carga de trabajo) al distribuir las capas sobre
múltiples capas físicas. También aumenta la escalabilidad y la tolerancia a
fallos.
Este escenario es propicio para implementar una buena política de pruebas,
permitiendo conmutar entre diferentes implementaciones de los interfaces.

https://www.youtube.com/watch?v=A8AJ_bb7Oec (4)
https://www.youtube.com/watch?v=plr1H4rFg_g (5)