Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Investigación Modelaje de Sistemas
Investigación Modelaje de Sistemas
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles
y, en caso de que sobrevenga algún cambio, solo afectará al nivel requerido sin tener que revisar
entre el código fuente de otros módulos, dado que se habrá reducido el Acoplamiento
informático hasta una interfaz de paso de mensajes.
Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo,
cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con
conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o
programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo
que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso
de que las necesidades aumenten).
Capas y niveles
1. Capa de presentación: la que ve el usuario (también se la denomina «capa de usuario»),
presenta el sistema al usuario, le comunica la información y captura la información del
usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay
errores de formato). También es conocida como interfaz gráfica y debe tener la
característica de ser «amigable» (entendible y fácil de usar) para el usuario. Esta capa
se comunica únicamente con la capa de negocio.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las
peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las
reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para
recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al
gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí
los programas de aplicación.
3. Capa de 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.
Arquitectura de microservicios
La arquitectura de microservicios (en inglés, Micro Services Architecture, MSA) es una
aproximación para el desarrollo de software que consiste en construir una aplicación como un
conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican
con mecanismos ligeros (normalmente una API de recursos HTTP). Cada servicio se encarga
de implementar una funcionalidad completa del negocio. Cada servicio es desplegado de forma
independiente y puede estar programado en distintos lenguajes y usar diferentes tecnologías
de almacenamiento de datos.1
Se suele considerar la arquitectura de microservicios como una forma específica de realizar
una arquitectura orientada a servicios.
Arquitectura de microkernel
Las funciones centrales de un SO son controladas por el núcleo (kernel) mientras que la interfaz
del usuario es controlada por el entorno (shell). Por ejemplo, la parte más importante del DOS
es un programa con el nombre “COMMAND.COM” Este programa tiene dos partes. El kernel,
que se mantiene en memoria en todo momento, contiene el código máquina de bajo nivel para
manejar la administración de hardware para otros programas que necesitan estos servicios, y
para la segunda parte del COMMAND.COM el shell, el cual es el interprete de comandos.
Las funciones de bajo nivel del SO y las funciones de interpretación de comandos están
separadas, de tal forma que puedes mantener el kernel DOS corriendo, pero utilizar una interfaz
de usuario diferente. Esto es exactamente lo que sucede cuando cargas Microsoft Windows, el
cual toma el lugar del shell, reemplazando la interfaz de línea de comandos con una interfaz
gráfica del usuario. Existen muchos “shells” diferentes en el mercado, ejemplo: NDOS (Norton
DOS), XTG, PCTOOLS, o inclusive el mismo SO MS-DOS a partir de la versión 5.0 incluyó un
Shell llamado DOS SHELL.
Arquitectura en pizarra
Los agentes suelen estar especializados en una tarea concreta o elemental. Todos ellos
cooperan para alcanzar una meta común, si bien, sus objetivos individuales no están
aparentemente coordinados.
La computación termina cuando se alcanza alguna condición deseada entre los resultados
escritos en la pizarra.
La pizarra tiene un doble papel. Por una parte, coordina a los distintos agentes y, por otra, facilita
su intercomunicación. El estado inicial de la pizarra es una descripción del problema que
resolver y el estado final será la solución del problema.
Los resultados generados por los agentes deben responder a un lenguaje y semántica común.
En general, se suelen utilizar formalismos lógicos o matemáticos, tales como expresiones
lógicas de primer orden.
Un evento puede ser definido como "un cambio significativo en un estado". Por ejemplo, cuando
un consumidor compra un coche, el estado del coche pasa de "se vende" a "vendido". La
arquitectura del sistema del vendedor de coches debe tratar este cambio de estado como un
evento, cuyo suceso puede ser conocido en otras aplicaciones en la arquitectura. Desde una
perspectiva formal, lo que es producido, publicado, propagado, detectado o consumido es un
mensaje (típicamente asíncrono) llamado notificación del evento, y no el evento en sí mismo, el
cual es el cambio de estado que disparó la emisión del evento. Los eventos no viajan, solamente
ocurren. Por otro lado, el término evento es frecuentemente usado para denotar el mensaje de
notificación en sí mismo, lo cual puede llevar a algún tipo de confusión.
Este patrón arquitectónico puede ser aplicado por el diseño e implementación de aplicaciones
y sistemas que transmitan eventos entre componentes software que estén emparejados
libremente y servicios. Un sistema dirigido por eventos está compuesto típicamente de emisores
de eventos (o agentes) y consumidores de eventos (o "sink" en inglés). Los consumidores tienen
la responsabilidad de llevar a cabo una reacción tan pronto como el evento esté presente. La
reacción puede o no puede ser completamente proporcionada por el consumidor en sí mismo.
Por ejemplo, el consumidor debe tener solamente la responsabilidad de filtrar, transformar y
reenviar el evento a otro componente o debe proporcionar una reacción propia a algún evento.
Construir aplicaciones y sistemas alrededor de una arquitectura dirigida por eventos permite a
estas aplicaciones y sistemas ser construidos de una manera que facilita un mayor grado de
reacción, debido a que los sistemas dirigidos por eventos están, por el diseño, más
normalizados para entornos no predecibles y asíncronos.
SOA 2.0 engloba las implicaciones de las arquitecturas SOA y EDA proporcionando a un más
rico y más robusto nivel, creando un nuevo patrón de eventos. Este nuevo concepto de
disparadores de patrones de inteligencia promueve a humanos autónomos o procesamiento
automático que añade valor exponencial al negocio. Esto se debe a que se inyecta información
de valor añadido en patrón reconocido que no podía haber sido obtenido previamente.
Peer-to-peer
Una red peer-to-peer, red de pares, red entre iguales o red entre pares (P2P, por sus siglas en
inglés) es una red de ordenadores en la que todos o algunos aspectos funcionan sin clientes ni
servidores fijos, sino una serie de nodos que se comportan como iguales entre sí. Es decir,
actúan simultáneamente como clientes y servidores respecto a los demás nodos de la red. Las
redes P2P permiten el intercambio directo de información, en cualquier formato, entre los
ordenadores interconectados.
El hecho de que sirvan para compartir e intercambiar información de forma directa entre dos o
más usuarios ha propiciado que parte de los usuarios lo utilicen para intercambiar archivos cuyo
contenido está sujeto a las leyes de copyright, lo que ha generado una gran polémica entre
defensores y detractores de estos sistemas.
Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los
demás usuarios de la red por medio de la conectividad entre los mismos, y obtienen así más
rendimiento en las conexiones y transferencias que con algunos métodos centralizados
convencionales, donde una cantidad relativamente pequeña de servidores provee el total del
ancho de banda y recursos compartidos para un servicio o aplicación.
Dichas redes son útiles para diversos propósitos. A menudo se usan para compartir ficheros
(archivos) de cualquier tipo (por ejemplo, audio, vídeo o software). Este tipo de red también
suele usarse en telefonía VoIP para hacer más eficiente la transmisión de datos en tiempo real.
Arquitectura orientada a servicios
La Arquitectura Orientada a Servicios (SOA, siglas del inglés Service Oriented Architecture) es
un estilo de arquitectura de TI que se apoya en la orientación a servicios. La orientación a
servicios es una forma de pensar en servicios, su construcción y sus resultados. Un servicio es
una representación lógica de una actividad de negocio que tiene un resultado de negocio
específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar
reportes de perforación)
Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo
real, estas actividades hacen parte de los procesos de negocio de la compañía.
El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en
el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2
grandes etapas:
Diseño orientado a servicios, El diseño orientado a servicios cuenta con 8 principios de diseño
que se aplican sobre cada uno de los servicios modelados, esto principios de diseño son:
Contrato de servicio estandarizado: Los contratos de servicio cumplen con los mismos
estándares de diseño.
Bajo acoplamiento: Los servicios evitan acoplarse a la tecnología que los implementa y a su vez
reducen el acoplamiento impuesto a los consumidores.
Autonomía: Los servicios deben tener un gran control de los recursos tecnológicos sobre los
cuales están implementados.
Sin estado: El servicio reduce el consumo de servicios al delegar el manejo de estados
(sesiones) cuando se requiera.
Preparado para ser usado en composiciones: Los servicios pueden hacer parte de una
composición sin importar el tamaño y complejidad de la misma.