SlideShare una empresa de Scribd logo
1 de 22
Diseño Arquitectonico Decisiones y organizacion
Introducción La esencia del diseño de software es la toma de decisiones sobre la organización lógica del software. Esta organización por lo general se estructura en subsistemas  que proporcionan algún conjunto de servicios relacionados Tema 3 - Clase 1 Docente: ING. Wilson Gomez Guevara–  wgomez@cotecnova.edu.co 2 DISEÑO DE SISTEMAS Diseño Arquitectonico Informática empresarial
Definición Proceso de diseño inicial que identifica los subsistemas y establece un marco para el control y comunicación de estos. Tema 3 - Clase 1 Docente: ING. Wilson Gomez Guevara–  wgomez@cotecnova.edu.co 3 DISEÑO DE SISTEMAS Diseño Arquitectónico Informática empresarial
Ventajas  Comunicación entre los Stakeholders     La arquitectura puede ser usada como un foco de discusión por los stakeholders del sistema Análisis de sistemas     Ayuda a establecer si el sistema puede cumplir los requerimientos no funcionales. Reutilización a gran escala La arquitectura puede ser reutilizada a través de un rango de sistemas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 4
Requerimientos no funcionales Rendimiento Protección Seguridad Disponibilidad Mantenibilidad Profundizar Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 5
Stakeholders Término inglés utilizado por primera vez por R. E. Freeman en su obra: “Strategic Management: A StakeholderApproach”, (Pitman, 1984) para referirse a «quienes pueden afectar o son afectados por las actividades de una empresa». Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 6
Stakeholders Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 7
Proceso del diseño arquitectónico Estructuración del sistema 	El sistema se descompone en varios subsistemas principales y la comunicación entre estos subsistemas es identificada. Modelado del control Se establece un modelo de las relaciones de control entre las diferentes partes del sistema. Descomposición modular Los subsistemas identificados se descomponen en módulos Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 8
Subsistemas y módulos Un subsistema es un sistema por derecho propio cuya operación es independiente de los servicios provistos por otros subsistemas. Un módulo es un componente del sistema que provee servicios a otros componente pero no se consideraría normalmente como un sistema separado. Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 9
Modelos Arquitectonicos Modelo estático estructural es que muestra los componentes principales del sistema. Modelo dinámico del proceso que muestra la estructura de proceso del sistema Modelo de interfaz que define las interfaces de los subsistemas Modelo de relaciones tales como un modelo de flujo de datos Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 10
Estructuración del sistema Concerniente con la descomposición del sistema en subsistemas que interactúan. El diseño arquitectónico se expresa normalmente como un diagrama de bloques que representa una visión general de la estructura del sistema. Se pueden desarrollar modelos más específicos que muestran cómo los subsistema comparten datos, cómo se distribuyen y cómo se comunican entre si. Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 11
Diagrama de bloques Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 12
Decisiones de diseño arquitectonico Los arquitectos del sistema tienen que responder a las sigts preguntas fundamentales: ¿Existe una arquitectura de aplicación generica que pueda actuar como una plantilla para el sistema que se esta diseñando? Como se distribuira el sistema entre varios procesadores? ¿Qué estilo o estilos arquitectonicos son apropiados? ¿Cuál sera la aproximacion fundamental utilizada para estructurar el sistema ? ¿Cómo se descompondran en modulos las unidades estructurales? ¿Qué estrategia se usara para controlar el funcionamiento de las unidades del sistema? ¿Cómo se evaluara el diseño arquitectonico? ¿Cómo debería documentarse la arquitectura del sistema? Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 13
Organización del sistema Refleja la estrategia básica usada para estructurar dicho sistema. Estilos: Repositorio de datos Cliente-Servidor Capas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 14
Modelo de repositorio Los subsistemas deben intercambiar datos.  Esto puede ser hecho de dos formas: Los datos compartidos se mantiene en una base de datos central o depósito y puede ser accedida por todos los subsistemas Cada subsistema mantiene su propia base de datos y pasa datos explícitamente a otros subsistemas Cuando grandes cantidades de datos deben ser compartidos, el modelo de depósito es el más comúnmente usado Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 15
Herramienta Case Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 16
Características del modelo de depósito Ventajas • Forma eficiente de compartir grandes cantidades de datos • Los subsistemas no se deben preocupar sobre cómo los datos son producidos o usados. • Administración centralizada. Ej. Backup, seguridad • El modelo de compartición es visible a lo largo del esquema de depósito Desventajas • Los subsistemas deben acordar un modelo de datos del depósito. Lo cual es inevitablemente un compromiso. • La evolución de datos es difícil y cara • No hay campo para políticas de administración específicas • Es difícil distribuir el depósitos eficientemente Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 17
Arquitectura de cliente-servidor Modelo de sistema distribuido el cual muestra cómo los 	datos y el procesamiento se distribuyen a través de un 	rango de componentes Conjunto de servidores stand-alone que proveen servicios 	específicos tales como impresión, administración de 	datos, etc. Conjunto de clientes los cuales acceden a estos servicios Una red la cual permite la comunicación entre clientes y servidores Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 18
Biblioteca de videos y pintura Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 19
Características del modelo cliente-servidor Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 20 Ventajas • La distribución de datos es directa • Hace uso efectivo de sistemas interconectados. Podría requerir hardware más barato • Es fácil adicionar nuevos servidores o actualizar servidores existentes Desventajas • No hay un modelo de datos compartido, de manera que los subsistemas usan una organización de datos diferente. El intercambio de datos puede ser ineficiente • Administración redundante en cada servidor • No hay un registro central de nombres y servicios
Modelo de máquina abstracta o de capas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 21 Usado para modelar las interfaces en entre subsistemas Organiza el sistema en un conjunto de capas (o máquinas abstractas) cada una de la cuales provee un conjunto de servicios Soporta el desarrollo incremental de subsistemas en diferentes capas. Cuando la interfaz de una capa cambia, solo las capas adyacentes son afectadas Sin embargo, es difícil, en general, estructurar sistemas de esta forma
Sistema de manejo de versiones Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra  –  hramirez@cotecnova.edu.co 22

Más contenido relacionado

La actualidad más candente

IIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareIIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareFranklin Parrales Bravo
 
8.1.- IPO. Estilos y paradigmas de interacción
8.1.- IPO. Estilos y paradigmas de interacción8.1.- IPO. Estilos y paradigmas de interacción
8.1.- IPO. Estilos y paradigmas de interacciónDCU_MPIUA
 
Requerimientos funcionales y no funcionales PMBOK
Requerimientos  funcionales y no funcionales PMBOKRequerimientos  funcionales y no funcionales PMBOK
Requerimientos funcionales y no funcionales PMBOKIsmael Fernandez R
 
Modelo cocomo
Modelo cocomo Modelo cocomo
Modelo cocomo mireya2022
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetosyoiner santiago
 
Sistemas Operativos Mecanismos y Politicas
Sistemas Operativos Mecanismos y PoliticasSistemas Operativos Mecanismos y Politicas
Sistemas Operativos Mecanismos y PoliticasJuan Novelo
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosFranklin Parrales Bravo
 
UML
UMLUML
UML1da4
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 CapasFani Calle
 
Requerimientos funcionales de un sistema de reservas
Requerimientos funcionales de un sistema de reservasRequerimientos funcionales de un sistema de reservas
Requerimientos funcionales de un sistema de reservasHumberto Rojas
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREFranklin Parrales Bravo
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de SoftwareCamila Arbelaez
 
Diagrama UML de Clases
Diagrama UML de ClasesDiagrama UML de Clases
Diagrama UML de ClasesAdal Dg
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Usoutrilla
 

La actualidad más candente (20)

IIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de softwareIIS Unidad 3B Proceso de desarrollo de software
IIS Unidad 3B Proceso de desarrollo de software
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
8.1.- IPO. Estilos y paradigmas de interacción
8.1.- IPO. Estilos y paradigmas de interacción8.1.- IPO. Estilos y paradigmas de interacción
8.1.- IPO. Estilos y paradigmas de interacción
 
Requerimientos funcionales y no funcionales PMBOK
Requerimientos  funcionales y no funcionales PMBOKRequerimientos  funcionales y no funcionales PMBOK
Requerimientos funcionales y no funcionales PMBOK
 
Modelo cocomo
Modelo cocomo Modelo cocomo
Modelo cocomo
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
 
Sistemas Operativos Mecanismos y Politicas
Sistemas Operativos Mecanismos y PoliticasSistemas Operativos Mecanismos y Politicas
Sistemas Operativos Mecanismos y Politicas
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientos
 
UML
UMLUML
UML
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
 
MOD Unidad 1: Fundamentos de modelado
MOD Unidad 1: Fundamentos de modeladoMOD Unidad 1: Fundamentos de modelado
MOD Unidad 1: Fundamentos de modelado
 
Metodología WEB UWE
Metodología WEB UWEMetodología WEB UWE
Metodología WEB UWE
 
Diseño conceptual
Diseño conceptualDiseño conceptual
Diseño conceptual
 
Requerimientos funcionales de un sistema de reservas
Requerimientos funcionales de un sistema de reservasRequerimientos funcionales de un sistema de reservas
Requerimientos funcionales de un sistema de reservas
 
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWAREPSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
PSW Unidad 4 ESTIMACIÓN DE PROYECTOS DE SOFTWARE
 
25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software25 Estandares - IEEE Calidad de Software
25 Estandares - IEEE Calidad de Software
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
Bases de Datos - Parte 3/10 Modelo ER
Bases de Datos - Parte 3/10 Modelo ERBases de Datos - Parte 3/10 Modelo ER
Bases de Datos - Parte 3/10 Modelo ER
 
Diagrama UML de Clases
Diagrama UML de ClasesDiagrama UML de Clases
Diagrama UML de Clases
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
 

Similar a Diseño arquitectonico

Inv Aplicada 3
Inv Aplicada 3Inv Aplicada 3
Inv Aplicada 3rgv127
 
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De SistemasUnidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De SistemasSergio Sanchez
 
Arquitecturas de software
Arquitecturas de software Arquitecturas de software
Arquitecturas de software Anel Sosa
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorGregorio Tkachuk
 
Arquitectura aplicaciones clase2
Arquitectura aplicaciones clase2Arquitectura aplicaciones clase2
Arquitectura aplicaciones clase2Germania Rodriguez
 
Arquitectura de un sistema de informacion
Arquitectura de un sistema de informacionArquitectura de un sistema de informacion
Arquitectura de un sistema de informacionMauricio Duero
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIJimmyWilfredMassVerd
 
6 arquitectura desoftware
6 arquitectura desoftware6 arquitectura desoftware
6 arquitectura desoftwaregaston6711
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDat@center S.A
 
Ingenieria de sistemas basada en modelos
Ingenieria de sistemas basada en modelosIngenieria de sistemas basada en modelos
Ingenieria de sistemas basada en modelosBryan Thomas
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del softwaremrquaife
 
Jose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasJose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasAmerigled Salgado
 
Estilo arquitectonico
Estilo arquitectonicoEstilo arquitectonico
Estilo arquitectonicodamelis888
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidosTensor
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidosTensor
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetosChristian Leon
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidosTensor
 

Similar a Diseño arquitectonico (20)

Inv Aplicada 3
Inv Aplicada 3Inv Aplicada 3
Inv Aplicada 3
 
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De SistemasUnidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De Sistemas
 
Arquitecturas de software
Arquitecturas de software Arquitecturas de software
Arquitecturas de software
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidor
 
Arquitectura aplicaciones clase2
Arquitectura aplicaciones clase2Arquitectura aplicaciones clase2
Arquitectura aplicaciones clase2
 
Clase03
Clase03Clase03
Clase03
 
Arquitectura de un sistema de informacion
Arquitectura de un sistema de informacionArquitectura de un sistema de informacion
Arquitectura de un sistema de informacion
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas II
 
6 arquitectura desoftware
6 arquitectura desoftware6 arquitectura desoftware
6 arquitectura desoftware
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a Objetos
 
Ingenieria de sistemas basada en modelos
Ingenieria de sistemas basada en modelosIngenieria de sistemas basada en modelos
Ingenieria de sistemas basada en modelos
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del software
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Jose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasJose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemas
 
Estilo arquitectonico
Estilo arquitectonicoEstilo arquitectonico
Estilo arquitectonico
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidos
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidos
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
 
Modelos de sistemas distribuidos
Modelos de sistemas distribuidosModelos de sistemas distribuidos
Modelos de sistemas distribuidos
 

Diseño arquitectonico

  • 2. Introducción La esencia del diseño de software es la toma de decisiones sobre la organización lógica del software. Esta organización por lo general se estructura en subsistemas que proporcionan algún conjunto de servicios relacionados Tema 3 - Clase 1 Docente: ING. Wilson Gomez Guevara– wgomez@cotecnova.edu.co 2 DISEÑO DE SISTEMAS Diseño Arquitectonico Informática empresarial
  • 3. Definición Proceso de diseño inicial que identifica los subsistemas y establece un marco para el control y comunicación de estos. Tema 3 - Clase 1 Docente: ING. Wilson Gomez Guevara– wgomez@cotecnova.edu.co 3 DISEÑO DE SISTEMAS Diseño Arquitectónico Informática empresarial
  • 4. Ventajas Comunicación entre los Stakeholders La arquitectura puede ser usada como un foco de discusión por los stakeholders del sistema Análisis de sistemas Ayuda a establecer si el sistema puede cumplir los requerimientos no funcionales. Reutilización a gran escala La arquitectura puede ser reutilizada a través de un rango de sistemas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 4
  • 5. Requerimientos no funcionales Rendimiento Protección Seguridad Disponibilidad Mantenibilidad Profundizar Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 5
  • 6. Stakeholders Término inglés utilizado por primera vez por R. E. Freeman en su obra: “Strategic Management: A StakeholderApproach”, (Pitman, 1984) para referirse a «quienes pueden afectar o son afectados por las actividades de una empresa». Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 6
  • 7. Stakeholders Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 7
  • 8. Proceso del diseño arquitectónico Estructuración del sistema El sistema se descompone en varios subsistemas principales y la comunicación entre estos subsistemas es identificada. Modelado del control Se establece un modelo de las relaciones de control entre las diferentes partes del sistema. Descomposición modular Los subsistemas identificados se descomponen en módulos Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 8
  • 9. Subsistemas y módulos Un subsistema es un sistema por derecho propio cuya operación es independiente de los servicios provistos por otros subsistemas. Un módulo es un componente del sistema que provee servicios a otros componente pero no se consideraría normalmente como un sistema separado. Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 9
  • 10. Modelos Arquitectonicos Modelo estático estructural es que muestra los componentes principales del sistema. Modelo dinámico del proceso que muestra la estructura de proceso del sistema Modelo de interfaz que define las interfaces de los subsistemas Modelo de relaciones tales como un modelo de flujo de datos Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 10
  • 11. Estructuración del sistema Concerniente con la descomposición del sistema en subsistemas que interactúan. El diseño arquitectónico se expresa normalmente como un diagrama de bloques que representa una visión general de la estructura del sistema. Se pueden desarrollar modelos más específicos que muestran cómo los subsistema comparten datos, cómo se distribuyen y cómo se comunican entre si. Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 11
  • 12. Diagrama de bloques Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 12
  • 13. Decisiones de diseño arquitectonico Los arquitectos del sistema tienen que responder a las sigts preguntas fundamentales: ¿Existe una arquitectura de aplicación generica que pueda actuar como una plantilla para el sistema que se esta diseñando? Como se distribuira el sistema entre varios procesadores? ¿Qué estilo o estilos arquitectonicos son apropiados? ¿Cuál sera la aproximacion fundamental utilizada para estructurar el sistema ? ¿Cómo se descompondran en modulos las unidades estructurales? ¿Qué estrategia se usara para controlar el funcionamiento de las unidades del sistema? ¿Cómo se evaluara el diseño arquitectonico? ¿Cómo debería documentarse la arquitectura del sistema? Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 13
  • 14. Organización del sistema Refleja la estrategia básica usada para estructurar dicho sistema. Estilos: Repositorio de datos Cliente-Servidor Capas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 14
  • 15. Modelo de repositorio Los subsistemas deben intercambiar datos. Esto puede ser hecho de dos formas: Los datos compartidos se mantiene en una base de datos central o depósito y puede ser accedida por todos los subsistemas Cada subsistema mantiene su propia base de datos y pasa datos explícitamente a otros subsistemas Cuando grandes cantidades de datos deben ser compartidos, el modelo de depósito es el más comúnmente usado Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 15
  • 16. Herramienta Case Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 16
  • 17. Características del modelo de depósito Ventajas • Forma eficiente de compartir grandes cantidades de datos • Los subsistemas no se deben preocupar sobre cómo los datos son producidos o usados. • Administración centralizada. Ej. Backup, seguridad • El modelo de compartición es visible a lo largo del esquema de depósito Desventajas • Los subsistemas deben acordar un modelo de datos del depósito. Lo cual es inevitablemente un compromiso. • La evolución de datos es difícil y cara • No hay campo para políticas de administración específicas • Es difícil distribuir el depósitos eficientemente Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 17
  • 18. Arquitectura de cliente-servidor Modelo de sistema distribuido el cual muestra cómo los datos y el procesamiento se distribuyen a través de un rango de componentes Conjunto de servidores stand-alone que proveen servicios específicos tales como impresión, administración de datos, etc. Conjunto de clientes los cuales acceden a estos servicios Una red la cual permite la comunicación entre clientes y servidores Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 18
  • 19. Biblioteca de videos y pintura Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 19
  • 20. Características del modelo cliente-servidor Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 20 Ventajas • La distribución de datos es directa • Hace uso efectivo de sistemas interconectados. Podría requerir hardware más barato • Es fácil adicionar nuevos servidores o actualizar servidores existentes Desventajas • No hay un modelo de datos compartido, de manera que los subsistemas usan una organización de datos diferente. El intercambio de datos puede ser ineficiente • Administración redundante en cada servidor • No hay un registro central de nombres y servicios
  • 21. Modelo de máquina abstracta o de capas Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 21 Usado para modelar las interfaces en entre subsistemas Organiza el sistema en un conjunto de capas (o máquinas abstractas) cada una de la cuales provee un conjunto de servicios Soporta el desarrollo incremental de subsistemas en diferentes capas. Cuando la interfaz de una capa cambia, solo las capas adyacentes son afectadas Sin embargo, es difícil, en general, estructurar sistemas de esta forma
  • 22. Sistema de manejo de versiones Tema 1 - Clase 1 Docente: CPT Heynar Ramírez Becerra – hramirez@cotecnova.edu.co 22