Architectural Design

Diseo de la Arquitectura de Sistemas11Arquitecturas Paralelas.Los Arquitectos son la interfase tcnica entre el cliente y el contratista que construye el sistema. Un mal diseo de arquitectura de un edificio no podr ser rescatado mediante una buena construccin, lo mismo sucede para el Software.Existen especialistas para construccin de edificios as como para arquitecturas de software. Existen escuelas o estilos de construccin y arquitectura de software24Proceso de Diseo de la ArquitecturaEstructuracin del Sistema.El sistema se descompone en varios subsistemas principales y se identifican las comunicaciones entre estos subsistemas.Modelos de Control.Un modelo de control establece las relaciones entre las diferentes partes de un sistema.Descomposicin Modular.Los subsistemas identificados son descompuestos en mdulos.35Subsistemas y Mdulos.Un subsistema es un sistema por si mismo y puede operar independientemente de los servicios proporcionados por otros subsistemas. Un modulo es un componente del sistema que proporciona servicios a otros componentes y normalmente no puede considerarse como parte separada del sistema.46Modelos de ArquitecturaLa estructura, control y descomposicin modular puede ser basada en un modelo o estilo de arquitectura particular. Sin embargo, muchos sistemas son heterogneos, diferentes partes del sistema se basan en diferentes modelos y en algunos casos, el sistema puede seguir un modelo compuesto.El modelo de arquitectura utilizado afecta el desempeo, la robustez, distribucin y la mantenibilidad del sistema.57Estructurando un SistemaSe refiere a la descomposicin del sistema interactuando con subsistemas.El diseo de arquitectura es normalmente expresado como un diagrama de bloque, el cual, presenta una vista de la estructura del sistema.Muchos modelos especficos muestran como los subsistemas comparten los datos, son distribuidos y la interfase con otros subsistemas puede ser desarrollada.68Sistema de Control de un Robot EmpaquetadorSistema deVisinSistema deIdentificacinde ObjetosSistema de Seleccin dePaquetesSistemaEmpaquetadorControladorConvoyControladordel BrazoControladorGripper79El Modelo RepositorioMuchos Subsistemas intercambian datos. Esto puede darse de dos maneras:Los datos compartidos se colocan en una base de datos central o repositorio y pueden ser accedidos por todos los subsistemas. Cada subsistema mantiene su propia base de datos y pasa datos explcitos a otros subsistemas.Cuando grandes cantidades de datos son compartidos, el modelo repositorio es el ms utilizado comnmente.810Arquitectura de una herramienta CASEDiseodel EditorGenerador deCdigoDiseo delTrasladadorProyecto RepositorioEditor deProgramaAnalizadorde diseoGenerador de Reporte911Caractersticas del Modelo RepositorioVentajasEs una forma eficiente de compartir grandes cantidades de datos. Los Subsistemas no necesitan proporcionar un manejo centralizado de como los datos son producidos. Por ejemplo: respaldo, seguridad, etc.El modelo de compartimiento se conoce como Modelo Repositorio. DesventajasLos subsistemas deben coincidir en modelo de datos del repositorio, lo cual es inevitablemente un compromisoLa evolucin de los datos es difcil y cara.No existen polticas para un manejo especfico.Se dificulta una distribucin eficiente. 1012Arquitectura Cliente-ServidorModelo de Sistemas Distribuido, el cual muestra como los datos y procesamiento estn distribuidos entre un rango de componentes. Conjunto de servidores stand-alone, los cuales proporcionan servicios especficos como impresin, manejo de datos, etc. Conjunto de clientes que llaman a estos servicios. Redes que permiten que los clientes accedan a los servidores 1113Pelcula y Librera de PelculasCliente 1Cliente 2Cliente 3Cliente 4Ancho de Banda de la redServidor deCatlogo

CatlogoServidor deVdeo

Archivos clip de PelculaServidor deFotografaFotografaDigitalizadaServidor deHipertexto

Hipertexto WEB1214Caractersticas Cliente-ServidorVentajasLa Distribucin de datos es directa.Permite el uso efectivo de sistemas de red. Puede requerir hardware barato. Es fcil aadir nuevos servidores o actualizar los existentes. DesventajasEl modelo no comparte datos con los diferentes subsistemas empleados en la organizacin. El intercambio de datos puede ser ineficiente.Administracin redundante en cada servidor.No existen registros centrales de nombres y servicios - esto hace difcil encontrar los servidores y servicios disponibles.1315Modelo de Mquina AbstractaEl modelo es utilizado para interfaces de subsistemasEl sistema se organiza en base a un conjunto de capas (o mquinas abstractas) cada una de las cuales proporcionan un conjunto de serviciosSoporta el desarrollo incremental de subsistemas en las diferentes capas. Cuando una interfase cambia en una capa, solamente la capa adyacente se ve afectadaSin embargo, ofrece dificultad para sistemas estructurados de esta manera.1416Sistema Administrador de VersionesAdministrador de VersionesAdministrador de ObjetosSistema de Base de DatosSistemaOperativo1517Modelos de ControlSe refieren al control de flujo entre subsistemas. Es diferente al modelo de descomposicin de sistemasControl CentralizadoUn subsistema tiene sobretodo la responsabilidad de controlar, iniciar y detener otros subsistemasControl basado en Eventos (Manejadores de eventos)Cada subsistema puede responder a eventos generados externamente por otros subsistemas o por el ambiente del sistema1618Control CentralizadoEl control de un subsistema es responsable del manejo de la ejecucin de otros subsistemasModelo Call-returnUn modelo de subrutina Top-down donde el control inicia en lo ms alto de la jerarqua de una subrutina y se mueve hasta la parte ms baja en la jerarqua. Es aplicable a sistemas secuencialesModelo AdministradorEs aplicable a sistemas concurrentes. Un componente del sistema controla el inicio, coordinacin y el alto de procesos de otro sistema. Puede ser implementado en sistemas secuenciales como una instruccin case1719Modelo Call-ReturnPrograma PrincipalRutina 1Rutina 2Rutina 3Rutina 1.1Rutina 1.2Rutina 3.1Rutina 3.21820Sistema de Control en Tiempo RealProceso de SensorProceso ActuadorControlador del SistemaProcesos de ComputacinInterfase de UsuarioManejador de Fallas1921Sistemas Manejadores de EventosManejador de eventos generador externamente donde el tiempo del evento est fuera del control de los subsistemas que lo procesanDos de los principales modelos manejadores de eventosModelo de Transmisin (Broadcast). Un evento es transmitido a todos los subsistemas. Cualquier subsistema puede manejar el eventoModelos manejadores de interrupciones. Utilizados en sistemas en tiempo real donde una interrupcin es detectada por un manejador de interrupciones y es pasada a otros componentes para ser procesadaOtros modelos manejadores de eventos incluyen hojas de clculo y sistemas de produccin2022Modelo de Transmisin (Broadcast)Es efectivo en la integracin de subsistemas en diversas computadoras en una redLos subsistemas registran la peticin de eventos especficos. Cuando esto ocurre, el control es transferido a los subsistemas que pueden manejar el eventoLas polticas de control no estn contenido dentro del evento o del manejador de eventos. Los subsistemas deciden cuales eventos son de su intersNo obstante, los subsistemas no saben cuando un evento ser manejado2123Transmisin SelectivaSubsistema 1Subsistema 2Subsistema 3Subsistema 4Manejador de Eventos y Mensajes2224

Sistemas Manejados por InterrupcionesUtilizado en Sistemas de tiempo real donde una respuesta rpida es esencialHay tipos de interrupciones con un manejador definido para cada tipoCada tipo est asociado con una localidad de memoria y un switch de hardware ocasiona transferencias al manejadorUna respuesta rpida pero compleja de programar y difcil de validar2325Control de Manejo de InterrupcionesInterrupcionesVector deInterrupcionesManejador 1Manejador 2Manejador 3Manejador 4Proceso 1Proceso 2Proceso 3Proceso 42426Descomposicin ModularEs otro nivel de estructura donde los subsistemas son descompuestos en mdulosDos modelos de descomposicin modular sonUn modelo de objeto donde el sistema es descompuesto en objetos interactuando.Un modelo de flujo de datos donde el sistema es descompuesto en mdulos funcionales, los cuales, transforman entradas en salidas. Esto es conocido como el modelo pipeline.Es posible tomar decisiones acerca de la concurrencia la cual ser retrasada hasta que los mdulos sean implementados2527Modelos de ObjetosEstructura el sistema en un conjunto de objetos dbilmente acoplados con interfaces bien definidasLa descomposicin orientada a objetos se refiere a la identificacin de clases de objetos, sus atributos y operacionesCuando estn implementados, los objetos son creados de esas clases y algunos modelos de control se emplean para coordinar operaciones de los objetos2628Sistema de Procesamiento de FacturasClienteCliente #NombreDireccinPerodo de CrditoReciboFactura #FechaCantidadCliente #PagoFactura #FechaCantidadCliente #FacturaFactura #FechaCantidadClienteEmisinEnvo de RecordatorioAceptacin de PagoEnvo de Recibo

2729Modelos de Flujo de DatosLas entradas a procesos de transformaciones funcionales producen salidasPuede ser referido como un tubo (pipe) o modelo de filtro (como un shell de UNIX)Las variaciones de este enfoque son muy comunes. Cuando las transformaciones son secuenciales nos encontramos con un modelo batch (en lotes) secuencial, el cual es muy utilizado en sistemas de procesamiento de datos sobre todo los ms antiguosNo es realmente conveniente para sistemas interactivos2830Sistema de Procesamiento de FacturasLectura de Emisin de FacturasIdentificacin dePagosEmisin deRecibosEncontrar pagosduplicadosEmisin delRecordatorio dePagoRecordatoriosPagosFacturasRecibos2931Arquitecturas de Dominio EspecficoSon modelos de Arquitectura los cuales son especficos para algn dominio de aplicacinDos tipos de modelo de dominio especfico son:Modelos Genricos, los cuales, son abstracciones de un nmero de sistemas reales y que encapsulan las caractersticas principales de estos sistemasLos modelos de referencia son ms abstractos, son modelos idealistas. Proporcionan un significado de informacin con respecto a sistemas de clases y comparacin de diversas arquitecturas.Los modelos genricos son usualmente modelos bottom-up; los modelos de Referencia son modelos top-down.3032Modelos GenricosUn modelo de Compilador es un ejemplo conocido a travs de otros modelos que existen en dominios de aplicaciones especializadas:Analizador LxicoTabla de SmbolosAnalizador de SintaxisArbol de SintaxisAnalizador SemnticoGenerador de CdigoUn modelo de compilador Genrico puede ser organizado de acuerdo a diversos modelos de arquitectura3133Modelo CompiladorTabla de SmbolosAnalizadorLxicoAnalizadorSintcticoAnalizadorSemnticoGeneracinde Cdigo3234Sistema de Procesamiento de un LenguajeRepositorioArbol de Sintaxis AbstractoDefinicin de la Gramtica Tabla de SmbolosDefinicin de la SalidaOptimizadorGenerador de CdigoImpresorEditorAnalizador Lxico Analizador SintcticoAnalizadorSemntico3335Arquitecturas de ReferenciaLos modelos de referencias son derivados del estudio del dominio de una aplicacin, en lugar del estudio de sistemas existentes. Pueden ser utilizados como una base para la implementacin de un sistema o para comparar sistemas diversos. Actan como un estndar en contraste con sistemas que pueden ser evaluados.El modelo OSI es un modelo en capas para sistemas de comunicacin.3436Modelo de referencia OSI1 23 4 567PresentacinSesinTransporteRedLiga de DatosFsicoPresentacinSesinTransporteRedLiga de DatosFsicoAplicacinMedio de ComunicacinRedLiga de DatosFsicoAplicacin3537ANTECEDENTES DE LA ESTRUCTURACION DE LOS PROCESOS Y TAREAS

EN LA PRIMER ETAPA DE LA UTILIZACION DE LOS SISTEMAS DE COMPUTACION LA UNICA MANERA DE ESTRUCTURAS LOS PROGRAMAS, TAREAS Y PROCESOS ERA SECUENCIAL ES DECIR: ORGANIZAR EL PROCESO EN BASE A LA SUCESIN SECUENCIAL DE PROGRAMAS QUEEJECUTABAN SU COMPUTACION MEDIANTE INTERFASES DE ARCHIVOS DE DATOS

EN LA DECADA DEL 70 SE PUDO COMENZAR A ESTRUCTURAR LOS PROCESOS CON EL CONCEPTO JERARQUICO MEDIANTE EL USO DE MENUES DE OPOCIONES ES DECIRQUE LOS PROCESOS SE EJECUTABAN UNO A LA VEZ Y DENTRO DEL PROCESO SE ESTRUCTURABAN SECUENCIALMENTE

EN LA DECADA DEL 80 COMIENZA A SER POSIBLE ESTRUCTURAR LOS PROCESOS DE MANERA CONCURRENTE ES DECIR VARIOS PROCESOS EJECUTANDO EN LA MEMORIACOMPITIENDO POR RECURSOS Y COLABORANDO ENTRE SI MEDIANTE INTERFASES ENTRE PROCESOS CON MEMORIA COMPARTIDA

EN LA DECADA DEL 90 LA ESTRUCTURACION CLIENTE SERVIDOR SE PUEDE EFECTUARPOR LA APARICION DEL CONCEPTO DE DESCENTRALIZACION DE LOS PROCESOS Y LA COMUNICACIN ENTRE LOS MISMOS PUEDE SER EFECTUADA MEDIANTE COMUNICACINDE DATOS POR CONEXIN DIRECTA O POR TELECOMUNICACIONES

ACTUALMENTE, LA ESTRUCTURACION SE BASA EN EL CONCEPTO DE CAPAS O LAYERSDONDE CADA CAPA ATIENDE ESPECIFICAMENTE UNA PARTE BIEN DISTINGUIDA DEL SISTEMA, EL CLIENTE, EL SERVICIO, LA BASE DE DATOS, LAS COMUNICACIONES Y LOS ALGORITMOS.36ResumenLa arquitectura de software es la responsable de la derivacin de un modelo de sistema estructural, un modelo de control y un modelo de descomposicin en subsistemas.Los sistemas grandes rara vez conforman un modelo simple de arquitectura.Los modelos de descomposicin de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de mquina abstracta.Los modelos de control incluyen control centralizado y modelos manejadores de eventos3738ResumenLos modelos de descomposicin incluyen modelos de flujo de datos y objetos.Los modelos de Dominio de arquitectura especfica son abstracciones sobre el dominio de una aplicacin. Estos pueden ser construidos mediante la abstraccin de sistemas existentes o pueden ser modelos de referencia idealizados.3839