Diseño de Sistemas Arquitectura de 

Sistemas 

Programa Profesional Administración y Sistemas 

Marco Arce Enriquez

Objetivos l  Proveer lineamientos que se deben considerar cuando se 

seleccione un arquitectura de sistema l  Describir servidores, procesamiento basado en el servidor, 

clientes y procesamiento basado en los clientes l  Explicar la arquitectura cliente/servidor, incluyendo capas, 

costo/beneficio, y consideraciones de performance. l  Describir el impacto de el Internet en la arquitectura de un 

sistema. l  Explicar la diferencia entre procesamiento en linea y 

procesamiento en lotes l  Definir la topología de red, y proveer ejemplos de modelos de 

redes, jerárquicas, estrella, bus, y anillo. l  Explicar los protocolos de red. l  Describir la especificación de diseño de sistemas.

Introducción l Un sistema efectivo combina elemento en una arquitectura, o diseño, el cual es flexible, de costo efectivo, y escalable, capaz de soportar las necesidades de información para el negocio. 

l  La arquitectura de sistemas, traduce el diseño lógico, de un sistema de información en una estructura física, que incluye hardware, soporte de redes, métodos de procesamiento, y seguridad.

Lineamientos de Arquitectura l Un analista de sistemas debe aproximarse a una arquitectura utilizando lineamientos de diseño. l  Enterprise resource planning (ERP) l  Costo Total e Inicial de Propiedad (TCO) l  Escalabilidad l  Integración Web l  Interface con Sistemas Legados l  Seguridad de Sistemas l  Opciones de Procesamiento

Lineamientos de Arquitectura l  Enterprise Resource Planning (ERP) 

l  El objetivo de ERP es establecer una estrategia de negocio que utiliza con efectividad los recursos de tecnología de información 

l  Describe el entorno – plataforma l  Supply chain management  (SCM) 

l  Costo Inicial y TCO l  Durante el diseno se tiene que decidir, que tendrá un mayor impacto en el costo inicial 

y en el TCO para el nuevo sistema l  Revisar costos anteriores. l  Algunas Preguntas 

l  Si el desarrollo es in­house, es esta la mejor elección? l  Si un paquete especifico fue seleccionado inicialmente para ser comprado, es este 

todavia la mejor opción? l  Existen nuevos tipos de outsourcing disponbles? 

l  Estas respuesta pueden afectar el costo inicial y el TCO para el sistema. l  Escalabilidad 

l  Escalabilidad, también llamada “extensibilidad” l  Permite el crecimiento de un sistema con el menor impacto posible. 

l  Integracíón en Web l  Un sistema de información incluye programas de aplicación l  Arquitectura centrada en Web

Lineamientos de Arquitectura l  Interface con sistemas legados 

l  Un nuevo sistema tiene interface(interconexion) con sistemas existentes de la empresa. 

l  Las interfaces de un nuevo sistema con los sistemas legados involucra que analicemos los datos, su formato y compatibilidad. 

l  El analista debe conocer si la nueva aplicación evenetualmente reemplazará al sistema legado. 

l  Opciones de Procesamiento l  En el planeamiento de la arquitectura, los diseñadores, deben considerar 

como el sistema procesará los datos, en linea o por lotes. l  24/7 l  Preveer procesos de backup y recuperación inmediata cuando el sistema 

falle. l  Seguridad 

l  La seguridad debe ser evaluada en todas las etapas del desarrollo del sistema, y en cada una de las partes de la arquitectura del sistema. 

l  Considerar que la seguridad esta vinculada con el diseño del sistema.y determina como se conducirá la organización. 

l  Sistemas basados en Web necesitan consdieraciones mas detalladas de seguridad

Planificando la arquitectura l Cada sistema de infromación involucra tres funciones: almacenamiento y acceso a datos, la aplicación que maneja la lógica de procesamiento, y una interface que permite a los usuarios interactuar con el sistema. 

l Dependiendo de larquitectura, las tres funciones serán desempeñadas en un servidor en un cliente o serán divididas entre el servidor y el cliente

Planificando la arquitectura l  Servidores l  Servidor l  Cliente l  Arquitectura Mainframe l  Sistemas Centralizados l  Background 

l  Centros de Procesamientos de Datos l  Uuarios no tienen capacidad de ingreso o salida de datos, excepto 

reportes impresos, los cuales son distribuidos por la coorporación. l  Procesamiento basado en el servidor 

l  Terminal l  En un diseño centralizado, las señales de usuario remotas, son 

trasmitidas a un mainframe o sistema central , el cual responde enviando pantallas de salida. 

l  Una operación menuda basada en internet debe usar una administración que centralice los datos.

Planificando la arquitectura l  Clientes l  La tecnología PC existe desde los 1980s, microcomputadores, 

rapidamente despues aparecieron las estaciones de trabajo, workstations, computadores de escritorio o desktop 

l  Los usuarios encuentran que ellos puede ejecutar sus propios procesadores de texto, hojas de calculo, y aplciaciones de base de datos. 

l  Muchas compañias adoptaron mecanismos de conexion en redes. 

l  Computación Stand­Alone l  Local and wide area networks LAN y WAN 

l  Muchas compañias resolvieron sus problemas de la computación aislada uniendo a sus clientes en una local area network (LAN) 

l  Una wide area network (WAN) expande a grandes distancias, la conexión de una o varias LAN. 

l  La red es transparente l  Sistemas Distribuidos

Planificando la arquitectura l Clientes l  Procesamiento basado en el Cliente l  En una tipica LAN, los clientes comparten datos, que son almacenados en un servidor local. 

l  En un servidor de archivos, un cliente de la LAN individual tiene una copia del programa de aplciación instalada localmente, mientras los datos, estan almacenados en un servidor central de archivos. 

l  Un servidor de archivos requiere significativos recursos de red.

Arquitectura Cliente/Servidor l  Necesitamos interconectar negocios, a través de arquitecturas de sistemas de 

información que expandan a la empresa entera. l  Es importante pensar en computación distribuida bajo un esquema de cliente 

servidor l  Arquitectura Cliente/Servidor

Arquitectura Cliente/Servidor l Overview l  Datos Legados 

l Estilos de Diseño Cliente/Servidor l  El diseño en cliente servidor puede tomar muchas formas, dependiendo de el tipo de servidor, y la relación entre el servidor y los clientes(capas).

Arquitectura Cliente/Servidor l  Tipos de Clientes:  Gordo y Flaco 

l  Cliente Gordo – Cliente Denso l  Cliente Flaco l  Muchos expertos en TI, concuerdan que el diseño  cliente flaco provee un 

mejor desempeño, porque la aplicación reside en el servidor, más cerca de los datos. 

l  En contraste, un cliente gordo permite tener mas procesamiento, y puede accesar y actualizar datos con mucha mayor frecuencia. 

l  Capas Cliente/Servidor l  Diseño en 2 Capas l  Diseño en 3 Capas l  Es indispensable considerar una capa intermedia(middleware), la cual 

provea la lógica de la aplciación, o lógica de negocio l  El diseño en 3 capas, también es llamado  n­Capas. l  La capa intermedia es mas eficiente y permite tener un costo efectivo en 

sistemas que son a l l  La capa intermedia es más eficiente y en costo mucho más efectiva.

Arquitectura Cliente/Servidor l Costo­Beneficio l  Sistemas C/S capaces de escalar y de rapida adaptabilidad en un entorno cambiante. 

l  Tambien permiten a las empresas trasferir sus aplicaciones desde costosos mainframes a plataformas de cliente menos costosas. 

l  Reducen la carga y el tráfico  de red, mejorando los tiempos de respuesta.

Evoluación de la Arquitectura 

Distribuida 

Reglas 

Presentación 

Datos 

3 Capas 

Datos 

Reglas 

Presentación 

Datos 

Reglas 

Presentación 

Monolítica 

Reglas 

Presentación 

Datos 

Cliente/ Servidor 

Datos 

Presentación 

Reglas

Arquitectura en 3 Capas l  Dividida físicamente l  Servidor de Base de datos l  Servidor de Aplicaciones l  Servidor Web l  Cliente 

l  Dividida lógicamente l  En tres capas l  Presentación l  Reglas del negocio l  Acceso a datos 

l  Basada en Componentes l  Representativos de las reglas de negocio y el acceso a 

datos l  Que pueden distribuirse entre servidores

Arquitectura en 3 Capas:Fisica 

Aplicaciones Aplicaciones Externas Externas 

Sistemas “ Legacy”  Sistemas “ Legacy”  

Bases de Datos Bases de Datos 

Cliente Cliente Liviano Liviano 

Cliente Cliente “ Rico”  “ Rico”

Arquitectura en 3 Capas:Lógica 

l  Presentación l  Lógica de Negocios l  Servicios de datos 

l  Las capas agrupan componentes con funciones similares 

l  Mejoran la separación clara de funciones y la reusabilidad

Arquitectura en 3 Capas:Lógica 

Componentes IU 

Componentes de Procesos de IU 

Comp. de Acceso a Datos 

“Workflows”  de Negocios 

Componentes de Negocio 

Usuarios 

Entidades de Negocios 

Agentes de Servicios 

Adm

inistración de operaciones 

Seguridad 

Com

unicación 

Interfaz de Servicios 

Fuentes De Datos  Servicios

Arquitectura en 3 Capas:Lógica l  Componentes de Interfaz de Usuario. Están compuestos por 

las pantallas, páginas Web, controles y otras tecnologías utilizadas para desplegar y dar formato a los datos presentados a los usuarios y para capturar y validar la información ingresada por estos. Dependiendo de los componentes de interfaz de usuario implantados puede considerarse utilizar “caching” y otras optimizaciones para mejorar la experiencia del usuario. 

l  Componentes de Procesos de Usuario. Estos componentes ayudan a orquestar el flujo de interacciones con el usuario, manejando la secuencia de los diálogos o páginas, flujos de estado y proveen de un mecanismo más simple de implantación para aplicaciones desconectadas o aplicaciones donde se requiere manejar interacciones de usuarios más complejas separadas de los datos de negocio. Por ejemplo, un Asistente de Tareas puede reiniciarse y continuar su ejecución en diferentes sesiones, el proceso de llenar un formulario de maestro­detalle en el cliente sin interacción con el servidor, o un proceso complejo de múltiples pasos que debe ser ejecutado desde múltiples dispositivos.

Arquitectura en 3 Capas:Lógica l  Componentes de Negocio. Implantan la lógica necesaria para llevar a cabo las tareas relacionadas con las reglas del negocio a través de llamados a funciones. 

l  Flujos de Procesos de Negocios. Los procesos de negocios definen el “flujo de conversación” entre los componentes de negocio de la aplicación y servicios externos. Los procesos de negocios, a diferencia de los componentes, pueden tomar una gran cantidad de tiempo en ejecutarse (desde segundos hasta meses). Los procesos de negocios pueden ser internos de la aplicación o pueden involucrar servicios externos en intercambios predefinidos.

Arquitectura en 3 Capas:Lógica l  Interfaz de Servicios. Con la finalidad de exponer la lógica de negocio como un servicio, es necesario crear interfaces que soportan los mecanismos de comunicación a través de mensajes, los formatos, protocolos, seguridad, etc., que son requeridos para las aplicaciones que consumen estos servicios. 

l  Agentes de Servicios. Estos componentes aíslan la necesidad de llamar diversos servicios desde la aplicación y pueden proveer de servicios adicionales como transformación entre lo que la aplicación necesita consumir y lo que el servicio externo provee, además de otras optimizaciones necesarias para consumir el servicio externo.

Arquitectura en 3 Capas:Lógica l  Componentes de Acceso a Datos. Abstraen las operaciones 

básicas en los datos. Idealmente un componente de acceso a datos solo debe acceder una sola fuente de datos, pero no necesariamente a una sola tabla o consulta. 

l  Componentes de Entidades de Negocios. La mayoría de las aplicaciones requieren que los datos sean pasados entren los diferentes componentes o capas. Los datos son utilizados para representar entidades de negocios, como productos u órdenes. Las entidades de negocios utilizadas internamente en las aplicaciones son usualmente estructuras de datos, como “DataSets”, “DataReaders” o XML, pero también pueden ser representadas como clases dentro de la aplicación. 

l  Componentes de Servicios Comunes (Seguridad, Comunicaciones, Manejo de Excepciones, etc.). La aplicación utiliza un conjunto de componentes que brindan servicios que son comunes a través de todas las capas y componentes de la misma. Estos componentes realizan ciertas tareas como autorización de usuarios, manejo de excepciones y manejo de la comunicación con otras aplicaciones y servicios.

Consideraciones a tener en cuenta en Arquitectura en Web l  El internet ha tenido un enorme impacto en la arquitectura de los 

sistemas l  Estratégias como e­commerce que aplican la tecnología disponible 

para integrar los requerimientos de negocios de las organizaciones. 

l  Soluciones E­Commerce In­House l  Considerar un plan estratégico en el alcance de los objetivos 

organizacionales l  Requiere mayor inversión inicial, pero provee más flexibilidad, para que las 

empresas se puedan adaptar rápidamente a un entorno de comercio electronico. 

l  Soluciones en empaquetadas y Proveedores de servicio E­Commerce l  Muchos vendedores ofrecen pequeños sistemas (llavero) a las empresas. l  Otra alternativa es usar un servicio proveedor de aplicaciones. (ASP) l  Considerar la ventaja del menor costo inicial compensa la desventaja de 

tener una poca flexibilidad posteriormente l  Portales Corporativos 

l  Un portal es una puerta de entrada a un Web Site multifuncional l  Este puede proveer acceso para los clientes, empleados, proveedores, y el 

público.

Métodos de Procesamiento l  Procesamiento en Linea 

l  Un sistema de procesamiento en linea, maneja transacciones cuando y donde ellas ocurren, y proveen una salida directa e inmediata al usuario. 

l  Tienen las siguientes caracteristicas: 1.  El sistema procesa la transacciones completamente 

cuando ellas ocurren. 2.  Los usuarios interactuan directamente con el sistema 

de información 3.  Usuarios pueden accesar a los datos en cualquier 

momento 4.  El sistema de infromación debe estar disponible 

cuando sea necesario para soportar las funciones del proceso de negocio.

Métodos de Procesamiento 

l Procesamiento en Lotes l  En un procesamiento en lotes, los datos son almacenados y procesados por grupos o por lotes de datos. 

l Procesamiento en linea y en lote(combinado) l  Punto de Venta: Point­of­sale (POS)

Modelos de Redes l  Modelo de referencia OSI l  El modelo OSI consiste de 7 capas l  Capa de aplicación: provee los servicios de red, solicitados por la estación de trabajo local. 

l  Capa de presentación: asegurar los datos estructurados uniformemente y formateados para la transmisión de red. 

l  Capa de sesión: define las estructuras de control, que manejan las comunicaciones entre las computadoras. 

l  Capa de Transporte: provee un flujo de datos confiable y recuperación de errores. 

l  Capa de Red : Define el direccionamiento de Red, y determina como los datos serán direccionados en la red. 

l  Capa de Enlace de Datos: define métodos especificos para transmitir datos, sobre la capa física, como definir el inicio y fin del bloque de datos. 

l  Capa Física: contiene componentes físicos que lleven datos, cables y conectores.

Modelos de Redes l Topología de Red l  Redes Jeráquicas

Modelos de Redes l Topología de Red l  Red Estrella

Modelos de Redes l Topología de Red l  Red en Bus

Modelos de Redes l  Red Anillo

Modelos de Redes l  Protocolos de Red l  La red debe usar un protocolo l  Un protocolo muy popular es Transmission Control 

Protocol/Internet Protocol (TCP/IP) l  Otro protocolo que permite la transferencia de archivos es 

file transfer protocol (FTP) l  Redes Inalámbricas (Wireless) l  Una wireless local area network, o WLAN l  Estándar de red 802.11 l  Institute of Electrical and Electronics Engineers (IEEE) l  802.11b l  802.11 High Rate – Wi­Fi

Consideraciones al Diseñar los Sistemas l  Especificaciones de diseño técnico l  Especificaciones de diseño detallado l  La especificación de diseño de la arquitectura del sistema 

es la linea base a partir de la cual el sistema será estimado y medido en tiempo y costo. 

l  Un diseño de un sistema típico, usa una estructura similar a la siguiente: 1.  Resumen ejecutivo 2.  Componentes del Sistema 3.  Entorno del Sistema 4.  Requerimientos de Implementación 5.  Estimación en tiempo y costo