TÓPICOS DE INGENIERÍA

DE SOFTWARE
Diseño arquitectónico
Agenda
• Decisiones de diseño arquitectónico
• Puntos de vista arquitectónicos
• Patrones arquitectónicos
• Arquitecturas de aplicaciones
Diseño arquitectónico
• El diseño arquitectónico se preocupa por comprender
cómo debe organizarse un sistema de software y
diseñar la estructura general de ese sistema.
• El diseño arquitectónico es el vínculo crítico entre el
diseño y la ingeniería de requerimientos, ya que
identifica los principales componentes estructurales de
un sistema y las relaciones entre ellos.
• El resultado del proceso de diseño arquitectónico es un
modelo arquitectónico que describe cómo se organiza el
sistema como un conjunto de componentes que se
comunican entre si.
Arquitectura y el método ágil
• Se acepta generalmente que una etapa temprana de los
procesos ágiles es diseñar una arquitectura general del
sistema.
• Refactorizar la arquitectura del sistema suele ser
costoso porque afecta a muchos componentes del
sistema
La arquitectura de un sistema de control de un
robot de empaque
Sistema de
Visión

Sistema de
Controlador de Controlador de
Identificación de
brazo pinza
objetos

Sistema de
selección de
empaques

Sistema de Controlador de
empaquetamiento transportadora
Abstracción arquitectónica
• La arquitectura en lo pequeño tiene que ver con la
arquitectura de los programas individuales. En este
nivel, nos preocupa la forma en que un programa
individual se descompone en componentes.
• La arquitectura en general se refiere a la arquitectura de
sistemas empresariales complejos que incluyen otros
sistemas, programas y componentes de programas.
Estos sistemas empresariales se distribuyen en
diferentes computadoras, que pueden ser propiedad y
administradas por diferentes compañías.
Ventajas de la arquitectura explícita
• Comunicación con las partes interesadas
• La arquitectura puede ser utilizada como base de discusión
por las partes interesadas en sistemas.
• Análisis del sistema
• Significa que es posible analizar si el sistema puede cumplir
con sus requisitos no funcionales.
• Reutilización a gran escala
• La arquitectura puede ser reutilizable en una variedad de
sistemas
• Se pueden desarrollar arquitecturas de línea de productos.
Representaciones arquitectónicas

• Los diagramas de bloques simples e informales que muestran

entidades y relaciones son el método más utilizado para
documentar arquitecturas de software.
• Pero estos han sido criticados porque carecen de semántica, no
muestran los tipos de relaciones entre entidades ni las
propiedades visibles de las entidades en la arquitectura.
• Depende del uso de modelos arquitectónicos. Los requisitos para
la semántica del modelo dependen de cómo se usen los
modelos.
Diagramas de bloques y lineas

• Muy abstractos: no muestran la naturaleza de las relaciones de

componentes ni las propiedades externas visibles de los
subsistemas.
• Sin embargo, útil para la comunicación con las partes
interesadas y para la planificación del proyecto.
Uso de modelos arquitectónicos
• Como una forma de facilitar la discusión sobre el diseño del sistema
• Una vista arquitectónica de alto nivel de un sistema es útil para
la comunicación con las partes interesadas del sistema y la
planificación del proyecto porque no está abarrotada de detalles.
Las partes interesadas pueden relacionarse con él y comprender
una visión abstracta del sistema. Luego pueden discutir el
sistema como un todo sin confundirse con los detalles.
• Como una forma de documentar una arquitectura que ha sido
diseñada
• El objetivo aquí es producir un modelo de sistema completo que
muestre los diferentes componentes de un sistema, sus
interfaces y sus conexiones.
Decisiones de diseño arquitectónico
Decisiones de diseño arquitectónico
• El diseño arquitectónico es un proceso creativo, por lo que el
proceso difiere según el tipo de sistema que se esté desarrollando.
• Sin embargo, una serie de decisiones comunes abarcan todos los
procesos de diseño y estas decisiones afectan las características no
funcionales del sistema.
Decisiones de diseño arquitectónico
¿Existe una arquitectura de
¿Cómo se distribuirá el sistema
aplicación genérica que pueda ¿Qué patrones o estilos
entre núcleos de hardware o
actuar como plantilla para el arquitectónicos podrían usarse?
procesadores?
sistema que se está diseñando?

¿Cuál será el enfoque ¿Qué estrategia se utilizará para

fundamental utilizado para
estructurar el sistema? ? controlar el funcionamiento de
los componentes en el sistema?

¿Qué organización
¿Cómo se descompondrán los
arquitectónica es mejor para ¿Cómo debe documentarse la
componentes estructurales del
cumplir con los requisitos no arquitectura del sistema?
sistema en subcomponentes?
funcionales del sistema?
Reutilización de la arquitectura
• Los sistemas en el mismo dominio a menudo tienen arquitecturas
similares que reflejan conceptos de dominio.
• Las líneas de productos de aplicación se basan en una arquitectura
central con variantes que satisfacen los requisitos particulares del
cliente.
• "La arquitectura de un sistema puede diseñarse en torno a uno o
más patrones arquitectónicos o "estilos ".
• Capturan la esencia de una arquitectura y se pueden instanciar
de diferentes maneras.
Arquitectura y las características del sistema
• Rendimiento
• Localizar operaciones críticas y minimizar las comunicaciones. Utilizar componentes
grandes en lugar de componentes muy pequeños.
• Protección
• Utilice una arquitectura por capas con componentes críticos en las capas internas.
• Seguridad
• Localice las características críticas para la seguridad en un número pequeño de
subsistemas.
• Disponibilidad
• Incluir componentes redundantes y mecanismos para tolerancia de fallas.
• Mantenibilidad
• Utilice componentes pequeños reemplazables.
Perspectivas arquitectónicas
Perspectivas arquitectónicas

• ¿Qué puntos de vista o perspectivas son útiles al diseñar y documentar

la arquitectura de un sistema?
• ¿Qué anotaciones deberían usarse para describir modelos
arquitectónicos?
• Cada modelo arquitectónico solo muestra una vista o perspectiva del
sistema.
• Puede mostrar cómo se descompone un sistema en módulos, cómo interactúan
los procesos en durante la ejecución o las diferentes formas en que los
componentes del sistema se distribuyen a través de una red. Tanto para el
diseño como para la documentación, generalmente se necesita presentar
múltiples vistas de la arquitectura del software.
Perspectivas arquitectónicas

Perspectiva de la Lógica Perspectiva Física

Arquitectura del
sistema

Perspectiva del Desarrollo Perspectiva Procedural

Modelo de arquitectura de software 4 + 1
perspectivas
• Una perspectiva lógica, que muestra las abstracciones claves en el
sistema como objetos o clases de objetos.
• Una perspectiva de procesos, que muestra cómo el sistema se
compone de procesos interactivos durante el tiempo de ejecución, .
• Una perspectiva de desarrollo, que muestra cómo se divide el software
para el desarrollo.
• Una vista física, que muestra el hardware del sistema y cómo se
distribuyen los componentes de software entre los procesadores del
sistema.
• Relacionados con casos de uso o escenarios (+1)
Representando vistas arquitectónicas
• Algunas personas argumentan que el lenguaje de modelado unificado
(UML) es una notación apropiada para describir y documentar
arquitecturas de sistemas
• No estoy de acuerdo con esto, ya que no creo que el UML incluya
abstracciones apropiadas para una descripción del sistema de alto
nivel.
• Los lenguajes de descripción arquitectónica (ADL) se han desarrollado
pero no se utilizan ampliamente
Patrones arquitectónicos
Patrones arquitectónicos
• Los patrones son un medio para representar, compartir y reutilizar el
conocimiento.
• Un patrón arquitectónico es una descripción estilizada de buenas
prácticas de diseño, que se ha probado y validado en diferentes
entornos.
• Los patrones deben incluir información sobre cuándo son y cuándo no
son útiles.
• Los patrones pueden representarse mediante descripciones tabulares
y gráficas.
El patrón Control de Vista de Modelo (CVM)
Nombre CVM (Control de Vista de Modelo)
Descripción Separa la presentación y la interacción de los datos del sistema. El sistema está estructurado en tres
componentes lógicos que interactúan entre sí. El componente Modelo gestiona los datos del sistema
y las operaciones asociadas en esos datos. El componente Ver define y gestiona cómo se presentan
los datos al usuario. El componente Controlador gestiona la interacción del usuario (por ejemplo,
pulsaciones de teclas, clics del mouse, etc.) y pasa estas interacciones a la Vista y al Modelo. Vea
Figura 6.3.
Ejemplo La Figura 6.4 muestra la arquitectura de un sistema de aplicación basado en web organizado
utilizando el patrón MVC.
Cuándo se Se usa cuando hay varias formas de ver e interactuar con los datos. También se utiliza cuando se
utiliza? desconocen los requisitos futuros para la interacción y la presentación de datos.
Ventajas Permite que los datos cambien independientemente de su representación y viceversa. Promueve la
presentación de los mismos datos de diferentes maneras con los cambios realizados en una
representación que se muestra en todos ellos.
Desventajas Puede involucrar código adicional y complejidad de código cuando el modelo de datos y las
interacciones son simples.
La organización del Control de Vista de Modelo (CVM)

Controlador Vista
Selección de Vista Dibuja el modelo.
Asigna acciones del usuario a
Solicita actualizaciones del
las actualizaciones del
modelo.
modelo.
Eventos de Envía eventos del usuario al
Selecciona la vista
Usuario controlador.

Notificación de
Cambio

Cambio de Estado Inquisición de

Modelo Estado

Encapsula el estado de la
aplicación.
Notifica la vista de los
cambios de estado

Figura 6.3
Arquitectura de la aplicación web usando el patrón CVM
Navegador de
Internet

Controlador Vista
Formato para
mostrar
Procesamiento de pedidos de http. Creación de páginas
Lógica específica de la aplicación. dinámicas.
Validación de datos. Gestión de formatos.
Eventos de
Usuario

Notificación de
Cambio

Pedido de Pedido de
actualización Modelo actualizar

Lógica del negocio.

Base de Datos.

Figura 6.4
Arquitectura en capas
• Utilizado para modelar la interfaz de subsistemas.
• Organiza el sistema en un conjunto de capas (o máquinas abstractas),
cada una de las cuales proporciona un conjunto de servicios.
• Admite el desarrollo incremental de subsistemas en diferentes capas.
Cuando cambia la interfaz de una capa, solo se ve afectada la capa
adyacente.
• Sin embargo, a menudo es artificial estructurar sistemas de esta
manera.
Patrón de arquitectura en capas
Nombre Arquitectura en capas
Descripción Organiza el sistema en capas con funcionalidad relacionada asociada con cada capa. Una capa
proporciona servicios a la capa superior, por lo que las capas de nivel más bajo representan
servicios centrales que probablemente se utilizarán en todo el sistema. Ver Figura 6.6.
Ejemplo Un modelo en capas de un sistema para compartir documentos con derechos de autor en diferentes
bibliotecas, como se muestra en la Figura 6.7.
Cuándo se Se usa al construir nuevas instalaciones sobre los sistemas existentes; cuando el desarrollo se
utiliza? extiende a varios equipos y cada equipo es responsable de una capa de funcionalidad; cuando existe
un requisito para la seguridad multinivel.
Ventajas Permite el reemplazo de capas enteras siempre que se mantenga la interfaz. Se pueden proporcionar
recursos redundantes (por ejemplo, autenticación) en cada capa para aumentar la confiabilidad del
sistema.
Desventajas En la práctica, proporcionar una separación limpia entre capas a menudo es difícil y una capa de
alto nivel puede tener que interactuar directamente con las capas de nivel inferior en lugar de a
través de la capa inmediatamente debajo de ella. El rendimiento puede ser un problema debido a los
múltiples niveles de interpretación de una solicitud de servicio a medida que se procesa en cada
capa.
Una arquitectura genérica en capas

Interfaz de Usuario

Gestión de interfaz de Usuario

Autenticación y autorización

Funcionalidad central de la aplicación de la empresa

Herramientas del sistema

Soporte del sistema (Sistema Operativo, base de datos, etc.)

Figura 6.6
Una arquitectura genérica en capas

Interfaz de Usuario basada en navegador iLearn app

Servicios de Configuración
Gestión de grupo Gestión de aplicación Gestión de identidad

Servicios de la aplicación
Email Mensajes Conferencias de Video Archivo de Periódicos
Procesamiento de textos Simulación Almacenamiento de Video
Hoja de cálculo Plataforma de aprendizaje virtual Archivo histórico

Servicios de herramientas
Autenticación Registro y monitoreo Interfaz
Almacenamiento de Almacenamiento de la Búsqueda
usuarios aplicación

Figura 6.7
Arquitectura de repositorio
• Los subsistemas deben intercambiar datos. Esto se puede hacer de
dos maneras:
• Los datos compartidos se mantienen en una base de datos
central o repositorio y todos los subsistemas pueden acceder a
ellos;
• Cada subsistema mantiene su propia base de datos y pasa datos
explícitamente a otros subsistemas.
• Cuando se van a compartir grandes cantidades de datos, el modelo
de repositorio de uso compartido se usa más comúnmente, este es
un mecanismo eficiente para compartir datos.
Patrón de repositorio
Nombre Repositorio
Descripción Todos los datos de un sistema se administran en un repositorio central al que pueden acceder todos
los componentes del sistema. Los componentes no interactúan directamente, solo a través del
repositorio.
Ejemplo La Figura 6.9 es un ejemplo de un IDE donde los componentes usan un repositorio de información
de diseño del sistema. Cada herramienta de software genera información que luego está disponible
para su uso por otras herramientas.
Cuándo se Debe usar este patrón cuando tenga un sistema en el que se generan grandes volúmenes de
utiliza? información que deben almacenarse durante mucho tiempo. También puede usarlo en sistemas
basados ​en datos donde la inclusión de datos en el repositorio desencadena una acción o
herramienta.
Ventajas Los componentes pueden ser independientes; no necesitan conocer la existencia de otros
componentes. Los cambios realizados por un componente se pueden propagar a todos los
componentes. Todos los datos se pueden administrar de manera coherente (por ejemplo, copias de
seguridad realizadas al mismo tiempo), ya que se encuentran en un solo lugar.
Desventajas El repositorio es un punto único de falla, por lo que los problemas en el repositorio afectan a todo el
sistema. Pueden haber ineficiencias en la organización de toda la comunicación a través del
repositorio. Distribuir el repositorio en varias computadoras puede ser difícil.
A repository architecture for an IDE

Editores Generadores
de UML de código
Editor de
Java

Traductor
Repositorio del Proyecto
de Diseños

Editor de
Python
Analizador Generador
de diseño de Reportes

IDE = Integrated Development Environment

Figura 6.9
Arquitectura cliente-servidor

• Modelo de sistema distribuido que muestra cómo se distribuyen

los datos y el procesamiento en una gama de componentes.
• Se puede implementar en una sola computadora.
• Conjunto de servidores independientes que proporcionan servicios
como impresión, gestión de datos, etc.
• Conjunto de clientes que solicitan estos servicios.
• Red que permite a los clientes acceder a los servidores.
Patrón de cliente-servidor
Nombre Cliente-servidor
Descripción En una arquitectura cliente-servidor, la funcionalidad del sistema se organiza en servicios, y cada
servicio se entrega desde un servidor separado. Los clientes son usuarios de estos servicios y
acceden a los servidores para utilizarlos.
Ejemplo La Figura 6.11 es un ejemplo de una biblioteca de películas y videos / DVD organizada como un
sistema cliente-servidor.
Cuándo se Se utiliza cuando se debe acceder a los datos de una base de datos compartida desde una variedad
utiliza? de ubicaciones. Debido a que los servidores se pueden replicar, también se pueden usar cuando la
carga en un sistema es variable.
Ventajas La principal ventaja de este modelo es que los servidores se pueden distribuir a través de una red.
La funcionalidad general (por ejemplo, un servicio de impresión) puede estar disponible para todos
los clientes y no es necesario que todos los servicios la implementen.
Desventajas Cada servicio es un punto único de falla tan susceptible a ataques de denegación de servicio o falla
del servidor. El rendimiento puede ser impredecible porque depende de la red y del sistema. Pueden
haber problemas de administración si los servidores son propiedad de diferentes organizaciones.
Una arquitectura cliente-servidor para una biblioteca de
películas

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Internet

Servidor de
Servidor de Servidor de Servidor de
Web
Catálogo Video Fotos
Informació
Catálogo de Tienda de Tienda de
n de Fotos y
Biblioteca Videos Fotos
Videos

Figura 6.11
Arquitectura de tubería y filtros

• Las transformaciones funcionales procesan sus entradas para producir

salidas.
• Puede ser referido como un modelo de tubería y filtro (como en el
“shell” de UNIX).
• Las variables de este enfoque son muy comunes. Cuando las
transformaciones son secuenciales, este es un modelo secuencial por
lotes que se usa ampliamente en los sistemas de procesamiento de
datos.
• No es realmente adecuado para sistemas interactivos.
Patrón de tubería y filtro
Nombre Tubería y filtro
Descripción El procesamiento de los datos en un sistema está organizado de modo que cada componente de
procesamiento (filtro) sea discreto y lleve a cabo un tipo de transformación de datos. Los datos
fluyen (como en una tubería) de un componente a otro para su procesamiento.
Ejemplo La Figura 6.13 es un ejemplo de un sistema de tubería y filtro utilizado para procesar facturas.
Cuándo se Comúnmente utilizado en aplicaciones de procesamiento de datos (basadas tanto en lotes como en
utiliza? transacciones) donde las entradas se procesan en etapas separadas para generar salidas relacionadas.
Ventajas Fácil de entender y admite reutilización de transformación. El estilo de flujo de trabajo coincide con
la estructura de muchos procesos empresariales. La evolución al agregar transformaciones es
sencilla. Se puede implementar como un sistema secuencial o concurrente.
Desventajas El formato para la transferencia de datos debe acordarse entre las transformaciones comunicantes.
Cada transformación debe analizar su entrada y su salida a la forma acordada. Esto aumenta la
sobrecarga del sistema y puede significar que es imposible reutilizar las transformaciones
funcionales que usan estructuras de datos incompatibles.
Un ejemplo de la arquitectura de tuberías y
filtros utilizada en un sistema de pagos

Emitir recibos Recibos

Identificar
pagos

Emitir
Encontrar pagos
recordatorio de
vencidos
pago.
Pagos
Arquitecturas de aplicación
Arquitecturas de aplicación

• Los sistemas de aplicación están diseñados para satisfacer una

necesidad organizacional.
• Como las empresas tienen mucho en común, sus sistemas de
aplicación también tienden a tener una arquitectura común que refleja
los requerimientos de la aplicación.
• Una arquitectura de aplicación genérica es una arquitectura para un
tipo de sistema de software que puede configurarse y adaptarse para
crear un sistema que cumpla requisitos específicos.
Uso de arquitecturas de aplicaciones

• Como punto de partida para el diseño arquitectónico.

• Como una lista de verificación de diseño.
• Como una forma de organizar el trabajo del equipo de
desarrollo.
• Como un medio para evaluar los componentes para su
reutilización.
• Como vocabulario para hablar sobre tipos de aplicaciones.
Ejemplos de tipos de aplicaciones
• Aplicaciones de procesamiento de datos
• Aplicaciones basadas en datos que procesan datos en lotes sin
intervención explícita del usuario durante el procesamiento.
• Aplicaciones de procesamiento de transacciones
• Aplicaciones centradas en datos que procesan las solicitudes de los
usuarios y actualizan la información en una base de datos del sistema.
• Sistemas de procesamiento de eventos
• Aplicaciones donde las acciones del sistema dependen de la
interpretación eventos del entorno del sistema.
• Sistemas de procesamiento de lenguaje
• Aplicaciones donde las intenciones de los usuarios se especifican en
un lenguaje formal que es procesado e interpretado por el sistema.
Ejemplos de tipos de aplicaciones
• Dos arquitecturas de aplicaciones genéricas muy utilizadas
son los sistemas de procesamiento de transacciones y los
sistemas de procesamiento de lenguaje.
• Sistemas de procesamiento de transacciones
• Sistemas de comercio electrónico;
• Sistemas de reservaciones.
• Sistemas de procesamiento de lenguaje
• Compiladores;
• Intérpretes de comandos.
Sistemas de procesamiento de transacciones
• Procesar solicitudes de usuario de información de una
base de datos o solicitudes para actualizar la base de
datos.
• Desde la perspectiva del usuario, una transacción es:
• Cualquier secuencia coherente de operaciones que satisfaga un
objetivo;
• Por ejemplo: encuentre los horarios de los vuelos de Londres a
París.
• Los usuarios realizan solicitudes asíncronas de servicio
que luego son procesados ​por un administrador de
transacciones.
La estructura de las aplicaciones de
procesamiento de transacciones

Procesamiento Lógica de la Gestor de

Base de Datos
de I/O aplicación transacciones
La arquitectura de software de un sistema
ATM
Entrada Proceso Salida

Obtener ID
Imprimir
de cuenta de
detalles
cliente Consulta de
cuenta

Validar Devolver
tarjeta tarjeta

Actualizar
cuenta
Seleccionar Dispensar
servicio efectivo

AT Base de Datos AT
M M

ATM: Automatic Teller Machine (Cajero Automático)

Arquitectura de sistemas de información
• Los sistemas de información tienen una arquitectura genérica
que se puede organizar como una arquitectura en capas.
• Estos son sistemas basados ​en transacciones, ya que la
interacción con estos sistemas generalmente involucra
transacciones de bases de datos.
• Las capas incluyen:
• La interfaz de usuario
• Comunicaciones del usuario
• Recuperación de información
• Base de datos del sistema
Arquitectura del sistema de información en capas

Interfaz de Usuario

Comunicaciones del Autenticación y

usuario autorización

Recuperación y modificación de información

Gestión de transacciones
Base de Datos
La arquitectura del sistema Mentcare

Navegador
Navegador web
web

Comprobación de Administrador de
Iniciar sesión Validación de Datos
Roles formularios y menús

Administrador de
Importación y
Gestión de seguridad Información de Creación de Informe
exportación de Datos
Pacientes

Gestión de transacciones
Base de Datos
Sistemas de información basados ​en la web
• Los sistemas de información y gestión de recursos ahora son
generalmente sistemas basados ​en la web donde las interfaces
de usuario se implementan utilizando un navegador web.
• Por ejemplo, los sistemas de comercio electrónico son
sistemas de gestión de recursos basados ​en Internet que
aceptan pedidos electrónicos de bienes o servicios y luego
organizan la entrega de estos bienes o servicios al cliente.
• En un sistema de comercio electrónico, la capa específica de la
aplicación incluye una funcionalidad adicional que admite un
"carrito de compras" en el que los usuarios pueden colocar una
cantidad de artículos en transacciones separadas y luego
pagarlos todos juntos en una transacción.
Implementación del servidor
• Estos sistemas a menudo se implementan como arquitecturas
de servidor-cliente de varios niveles
• El servidor web es responsable de todas las comunicaciones
del usuario, con la interfaz de usuario implementada
mediante un navegador web;
• El servidor de aplicaciones es responsable de implementar la
lógica específica de la aplicación, así como el
almacenamiento de información y las solicitudes de
recuperación;
• El servidor de la base de datos mueve la información hacia y
desde la base de datos y maneja la gestión de transacciones.
Sistemas de procesamiento de lenguaje
• Aceptan un lenguaje natural o artificial como entrada y
generan alguna otra representación de ese idioma.
• Pueden incluir un intérprete para actuar según las
instrucciones en el idioma que se está procesando.
• Utilizado en situaciones donde la forma más fácil de
resolver un problema es describir un algoritmo o describir
los datos del sistema
• Las herramientas de meta-casos procesan
descripciones de herramientas, reglas de métodos, etc.
y generan herramientas.
La arquitectura de un sistema de
procesamiento de lenguaje

Traductor
Instrucciones en
lenguaje de origen Verificar sintaxis
Verificar semántica
Generar

Instrucciones para
máquina abstracta

Intérprete

Data Traer Resultados

Ejecutar
Componentes del compilador

• Un analizador léxico, que toma tokens de lenguaje de

entrada y los convierte a una forma interna.
• Una tabla de símbolos, que contiene información sobre los
nombres de entidades (variables, nombres de clase,
nombres de objetos, etc.) utilizados en el texto que se está
traduciendo.
• Un analizador de sintaxis, que verifica la sintaxis del
idioma que se está traduciendo.
• Un árbol de sintaxis, que es una estructura interna que
representa el programa que se está compilando.
Componentes del compilador
• Un analizador semántico que utiliza información del
árbol de sintaxis y la tabla de símbolos para verificar la
corrección semántica del texto del idioma de entrada.
• Un generador de código que "recorre" el árbol de
sintaxis y genera un código de máquina abstracto.
Una arquitectura de repositorio para un
sistema de procesamiento de lenguaje

Análisis Análisis Análisis

Léxico sintáctico Semántico

Análisis Árbol de
Definición de
Análisis
Léxico sintaxis Semántico
gramática
abstracta

Análisis Tabla de Definición de Generar

símbolos salida
Sintáctico Código
Repositorio
Una arquitectura de compilación de
tuberías y filtros

Tabla de símbolos

Árbol de Sintaxis

Análisis Análisis Análisis Generar

Léxico Sintáctico Semántico Código
Puntos Clave
• Una arquitectura de software es una descripción de cómo se
organiza un sistema de software.
• Las decisiones de diseño arquitectónico incluyen decisiones sobre
el tipo de aplicación, la distribución del sistema, los estilos
arquitectónicos que se utilizarán.
• Las arquitecturas pueden documentarse desde varias perspectivas
o puntos de vista diferentes, como una vista conceptual, una vista
lógica, una vista de proceso y una vista de desarrollo.
• Los patrones arquitectónicos son un medio para reutilizar el
conocimiento sobre arquitecturas genéricas de sistemas.
Describen la arquitectura, explican cuándo se puede usar y
describen sus ventajas y desventajas.
Puntos Clave
• Los modelos de arquitecturas de sistemas de aplicaciones nos
ayudan a comprender y comparar aplicaciones, validar diseños de
sistemas de aplicaciones y evaluar componentes a gran escala
para su reutilización.
• Los sistemas de procesamiento de transacciones son sistemas
interactivos que permiten que una cantidad de usuarios acceda y
modifique de forma remota la información de una base de datos.
• Los sistemas de procesamiento de lenguaje se utilizan para traducir
textos de un idioma a otro y para llevar a cabo las instrucciones
especificadas en el lenguaje de entrada. Incluyen un traductor y
una máquina abstracta que ejecuta el lenguaje generado.