• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Arquitecturas de software - Parte 2
 

Arquitecturas de software - Parte 2

on

  • 18,957 views

Material académico de Ingeniería de Software - Universidad de Medellín (Colombia)

Material académico de Ingeniería de Software - Universidad de Medellín (Colombia)

Statistics

Views

Total Views
18,957
Views on SlideShare
18,625
Embed Views
332

Actions

Likes
21
Downloads
1
Comments
5

7 Embeds 332

http://gc.scalahed.com 157
http://businessworldti.wordpress.com 106
http://aulavirtual.utel.edu.mx 47
https://eliademy.com 11
http://209.51.138.90 9
http://www.linkedin.com 1
http://localhost 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

15 of 5 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Arquitecturas de software - Parte 2 Arquitecturas de software - Parte 2 Presentation Transcript

    • Arquitecturas de Software Parte 2 - Características Generales - Atributos de Calidad - Patrones/Estilos de Arquitectura Material académico preparado por: Ph.D Marta Silvia Tabares B. Fecha última actualización 4-Sep-2011
    • Ingeniería de Software II(mapa conceptual de tópicos de conocimiento) Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Bibliografía Los conceptos utilizados en esta presentación fueron estudiados y tomados en su mayoría de las siguientes referencias bibliográficas.1. Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.2. OMG-UML. Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. 2005.3. Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison Wesley. 2000.4. Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.5. Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006.6. Bass, L., Clements, P., Kazman, R. Software Architecture in Practice Second Edition.7. Pressman, R. Ingeniería del Software un Enfoque Práctico.8. Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).9. www.sei.cmu.edu.co10. http://www.iso.org/iso/home.html11. http://iso25000.com/index.php/iso-iec-9126.html 3 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Arquitectura de Software Flujo de Definición Material académico preparado por Marta 4 Silvia Tabares B. UdeM
    • Pasos para definición de una arquitectura de software• Creación del caso de negocio para el sistema• Entendimiento de los requisitos• Creación y selección de la Arquitectura• Documentación y comunicación de la Arquitectura• Análisis o evaluación de la arquitectura• Implementación del sistema basado en la arquitectura• Aseguramiento de que la implementación esté acorde a la arquitectura Material académico preparado por Marta 5 Silvia Tabares B. UdeM
    • Arquitectura de Software• Por qué hay que hacer modelos de arquitectura? – Esto permite valorar hasta qué punto cumple el sistema los Atributos de Calidad. Material académico preparado por Marta 6 Silvia Tabares B. UdeM
    • Arquitectura de Software Calidad del Software• La Calidad de Software para Pressman (2002) es: – “la concordancia con los requisitos funcionales y de rendimiento establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado de forma profesional”. Material académico preparado por Marta 7 Silvia Tabares B. UdeM
    • Arquitectura de Software Atributos de Calidad• Según Barbacci et al. (1995) la calidad de software se define como el grado en el cual el software posee una combinación deseada de atributos. Tales atributos son requerimientos adicionales del sistema (Kazman et al., 2001), que hacen referencia a características que éste debe satisfacer, diferentes a los requerimientos funcionales.• Estas características o atributos se conocen con el nombre de atributos de calidad, los cuales se definen como las propiedades de un servicio que presta el sistema a sus usuarios (Barbacci et al. 1995). Material académico preparado por Marta 8 Silvia Tabares B. UdeM
    • Arquitectura de Software Norma ISO/IEC 9126• ISO/IEC (Intenational Standart Organitation u Organización Internacional de Estándares en español) define a la calidad de software como: – la totalidad de rasgos y atributos de un producto de software que le apoyan en su capacidad de satisfacer sus necesidades explícitas o implícitas (ISO/IEC 9126, 1998). Material académico preparado por Marta 9 Silvia Tabares B. UdeM
    • Arquitectura de Software Norma ISO/IEC 9126 http://iso25000.com/index.php/iso-iec-9126.html 10 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Arquitecturas de Software Norma ISO/IEC 9126• El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un conjunto estructurado de características y subcaracterísticas de la siguiente manera:• Funcionalidad - Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas. – Idoneidad – Exactitud – Interoperabilidad – Seguridad – Cumplimiento de normas.• Fiabilidad - Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido. – Madurez – Recuperabilidad – Tolerancia a fallos Material académico preparado por Marta 11 Silvia Tabares B. UdeM
    • Arquitecturas de Software Norma ISO 9126• Usabilidad - Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios. – Aprendizaje – Comprensión – Operatividad – Atractividad• Eficiencia - Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas. – Comportamiento en el tiempo – Comportamiento de recursos Material académico preparado por Marta 12 Silvia Tabares B. UdeM
    • Arquitecturas de Software Norma ISO 9126• Mantenibilidad - Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software. – Estabilidad – Facilidad de análisis – Facilidad de cambio – Facilidad de pruebas• Portabilidad - Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra. – Capacidad de instalación – Capacidad de reemplazamiento – Adaptabilidad – Co-Existencia Material académico preparado por Marta 13 Silvia Tabares B. UdeM
    • Arquitectura de Software Atributos de Calidad• Categorías de Atributos de Calidad Bass et al. (1998) : – Observables vía ejecución: aquellos atributos que se determinan del comportamiento del sistema en tiempo de ejecución. La descripción de algunos de – No observables vía ejecución: aquellos atributos que se establecen durante el desarrollo del sistema. Material académico preparado por Marta 14 Silvia Tabares B. UdeM
    • Arquitectura de SoftwareAtributos de Calidad – No observables vía ejecución Fuente: Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004). 15 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Arquitectura de SoftwareAtributos de Calidad – NO observables vía ejecución Fuente: Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004). 16 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Qué son RequisitosArquitectónicamente Significativos? • Captura la funcionalidad esencial del sistema • Tiene amplia cobertura (usa muchos elementos de arquitectura). • Es un desafío de implementación para la arquitectura. • Enfatiza o detalla problemas o riesgos identificados. • Ejemplifica demandas rigurosas en la arquitectura (p.ej exigencias de rendimiento (performance)). • Son susceptibles a cambios. • Involucran comunicación y sincronización con sistemas externos. 17 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Definición de una Arquitectura Candidata• Aunque una arquitectura muchas veces se define como un conjunto de componentes y conectores, es importante hacer la siguiente evaluación de los elementos que podrían determinar una arquitectura candidata: Naturaleza de los elementos – Cuál es el significado de su separación? – Ellos se ejecutan en procesadores separados, en tiempos diferentes? – Ellos se componen de procesos, programas o ambos? – Ellos representan la forma en la cual el que hacer de los proyectos será dividido? – Ellos se definen en el sentido de la separación de ejecución? – Ellos son los objetos, tareas, funciones, procesos, programas distribuidos, o alguna cosa parecida? Responsabilidades de los elementos – Qué es lo que ellos hacen? – Cuál es su función en el sistema? Material académico preparado por Marta 18 Silvia Tabares B. UdeM
    • Definición de una Arquitectura CandidataSignificado de las conexionesLas conexiones significan que los elementos entre si se comunican,controlan, envían datos, sincronizan, comparten alguna informaciónsecreta. – Algunas son combinaciones de estos u otras relaciones? – Cuales son los mecanismos para la comunicación? – Qué información fluye a través de los mecanismos?Significado de las capas (vistas)– Por qué el proceso de control está en un nivel separado?– Es este llamado por elementos de otras capas?– Hay restricciones de llamado entre los elementos de diferentes capas? Material académico preparado por Marta 19 Silvia Tabares B. UdeM
    • Definición de una Arquitectura Candidata Tipo de Arquitectura Ejemplos de Ejemplos de Elementos Relaciones Conceptual Componentes Conectores Modular Subsistemas, Exportaciones, módulos importaciones Código Archivos, directorios, Incluye, contiene bibliotecas Ejecución Tareas, líneas, Usos, llamadas interacciones de objetosCuatro aspectos de la arquitectura del software según Soni et al. (adaptado de Weir y Daniels, 1998) Material académico preparado por Marta 20 Silvia Tabares B. UdeM
    • La Arquitectura de Referencia Modelo de Referencia Arquitectura de Software de Referencia Arquitectura Patrón ArquitectónicoEstos son conceptos útiles que capturan elementos de una arquitectura,pero en sí ellos no son arquitecturas. Material académico preparado por Marta 21 Silvia Tabares B. UdeM
    • Modelo de Referencia Un modelo de Referencia es una división defuncionalidad junto con el flujo de datos entre las piezas. Es un estándar de descomposición de un problema conocido, en partes que cooperativamente resuelven el problema. Material académico preparado por Marta 22 Silvia Tabares B. UdeM
    • Arquitectura de ReferenciaEs un modelo de referencia mapeado en elementos de software que cooperativamente implementan lafuncionalidad definida en el modelo de referencia y flujos de datos entre ellos Material académico preparado por Marta 23 Silvia Tabares B. UdeM
    • Diseño Arquitectónico• Estructuras – Módulos: los elementos son módulos, los cuales son unidades de implementación. – Componentes-y-Conector: los elementos son componentes de ejecución (los cuales son principalmente unidades de computación) y conectores (los cuales son el vehículo de comunicación entre los componentes). – De Localización: muestran la relación entre los elementos de software y los elementos en uno o más ambientes externos en los cuales el software es creado o ejecutado. Material académico preparado por Marta 24 Silvia Tabares B. UdeM
    • Diseño Arquitectónico • Estructuras Localización Módulo Asignación ImplementaciónDescomposición Clase Componente-y- de trabajo Usos Conector Despliegue Capas Cliente- Proceso Servidor Concurrencia Datos compartidos Material académico preparado por Marta 25 Silvia Tabares B. UdeM
    • Diseño Arquitectónico• Los procesos de desarrollo basados en el Proceso Unificado están centrados en la arquitectura.• La elección de una arquitectura correcta implica que los arquitectos deben estar involucrados desde el principio del proyecto.• La elección de la arquitectura correcta al principio del proyecto también tiene que ver con la reducción de los riesgos del proyecto. Material académico preparado por Marta 26 Silvia Tabares B. UdeM
    • Diseño Arquitectónico• Las arquitecturas del sistema son usadas por diversos conjuntos de personas en tiempos diferentes en el ciclo de desarrollo, por esta razón es frecuente ver que estas arquitecturas son separadas en vistas diferentes.• El Proceso Unificado Racional (RUP) identifica un conjunto de vistas estándar llamado 4+1 Vistas de Arquitectura. Este enfoque permite que todos los grupos de participantes comuniquen las necesidades (es decir, requisitos), resuelvan los conflictos, y realicen los documentos de decisiones. Material académico preparado por Marta 27 Silvia Tabares B. UdeM
    • Patrones/Estilos ArquitectónicosUn patrón arquitectónico es una descripción de tipos de elementos y relaciones con un conjunto de restricciones de cómo ellos pueden ser usados. Material académico preparado por Marta 28 Silvia Tabares B. UdeM
    • Patrones/Estilos Arquitectónicos• Estilos de Flujo de Datos – Tubería y filtros• Estilos Centrados en Datos – Arquitecturas de Pizarra o Repositorio• Estilos de Llamada y Retorno – Modelo-Vista-Control (MVC) – Arquitecturas en Capas – Arquitecturas Orientadas a Objetos – Arquitecturas Basadas en Componentes Material académico preparado por Marta 29 Silvia Tabares B. UdeM
    • Patrones o Estilos Arquitectónicos• Estilos de Código Móvil – Arquitectura de Máquinas Virtuales• Estilos heterogéneos – Sistemas de control de procesos – Arquitecturas Basadas en Atributos• Estilos Peer-to-Peer – Arquitecturas Basadas en Eventos – Arquitecturas Orientadas a Servicios – Arquitecturas Basadas en Recursos Material académico preparado por Marta 30 Silvia Tabares B. UdeM
    • Patrón Arquitectónico: Cliente - Servidor Servidor Cliente ClienteCliente y Servidor son dos tipos de elementos y su coordinación se describe en términos del protocolo que el servidor usa para comunicarse con cada uno de sus cliente Material académico preparado por Marta 31 Silvia Tabares B. UdeM
    • Patrón Arquitectónico: Arquitectura Centrada en los Datos• Un almacén de datos (archivo o base de datos) se encuentra en el centro de la arquitectura, los otros componentes tienen acceso a el y cuentan con la opción de actualizar, agregar, eliminar o modificar datos de dicho almacén. Software Software Cliente Cliente Almacén de Datos Software Software Cliente Cliente Material académico preparado por Marta 32 Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Física Centrada en los Datos Material académico preparado por Marta 33 Silvia Tabares B. UdeM
    • Patrón Arquitectónico: Arquitectura por CapasCada capa (layer – Tier) es un nivel deabstracción del sistema. System Time (Time). This component allows the system to run at a userdefined time in a simulation mode. With multiple instances of this component, real time and simulated time can be used concurrently. Time Synchronization (TSync). With different parts of the system running on different hardware nodes, synchronizing the system time on each node is critical. Communication Protocols (Comm). This component includes components dealing with low- level communication protocols tailored for specific applications. Built-in Test (BiT). These modules handle hardware testing. Material académico preparado por Marta 34 Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura en o por Capas Fuente: imágenes de google Material académico preparado por Marta Silvia Tabares B. UdeM 35
    • Patrón Arquitectónico:Arquitectura Por Capas (Ej. 1) Material académico preparado por Marta 36 Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Por Capas (Ej. 2) 37 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Por Capas (Ej. 3) Material académico preparado por Marta 38 Silvia Tabares B. UdeM
    • Patrón Arquitectónico Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes) 39Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes) Los componentes se denominan FILTROS que son conectados por medio de TUBERÍAS las cuales transmiten los datos. Se aplica cuando los datos de entrada se habrán transformado en datos de salida mediante una serie de componentes para el cálculo o la manipulación. 40Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico Arquitectura Flujo de Datos – Filtros y Tuberías Un ejemplo de uso del patrón Filtros y Tuberías - Requisito de Seguridadclass Filtros y Tuberías User - id: int - name: varchar 1..* MemberOf 1..* Role ProtectionObj ect isAuthorizedFor - id: int - id: int - name: varchar - name: varchar Right - accessType: varchar + checkRights() : voidModelo de clases: Requisito de SeguridadFuente teórica : Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern. Fifth LACCEI International Latin American and Caribbean Conference for Engineering and Technology (LACCEI’2007)“Developing Entrepreneurial Engineers for the Sustainable Growth of Latin America and the Caribbean:Education, Innovation, Technology and Practice”29 May – 1 June 2007, Tampico, México. 41 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes) Un ejemplo de uso del patrón Filtros y Tuberías - Requisito de Seguridad sd Sistema :RefMonitor :Right :Filter_j :Pipe_i :Pipe_j :Role1 op3(role) checkRights() :decision :desicion op3() read (data) read (data) write (data) op3() write(data)Fuente teórica: Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern 42 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes) Un ejemplo de uso del patrón Filtros y Tuberías - Requisito de SeguridadFuente teórica: Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern 43 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Modelo – Vista - ControlUn Ejemplo: Material académico preparado por Marta 44 Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Orientada a Servicios Imagen tomada de «imágenes google» 45 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Orientada a Servicios Imagen tomada de «imágenes google» 46 Material académico preparado por Marta Silvia Tabares B. UdeM
    • Patrón Arquitectónico:Arquitectura Hibridas (Servicios – Capas – Plataformas) Sharepoint architectura Imagenes tomada de Avepoint Material académico preparado por Marta 47 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador Clase Interfaz <<Interface>>:• En UML Recepcionar peticiones al sistema. Mostrar respuestas del sistema. Se propone para el desarrollo del Modelo de Análisis de las aplicaciones, tres tipos de clases Clase Entidad <<Entity>>: fundamentales, con las cuales Gestionar datos (información) necesaria podemos expresar todas las para el sistema. Almacenar datos (información) funciones de cualquier software, persistentes del sistema. con sus respectivas Provee la funcionalidad principal de responsabilidades la aplicación Clase Controlador <<Controller>>: Procesar Información del sistema. Gestionar visualización de respuesta del sistema. Obtiene los datos del modelo. Material académico preparado por Marta 48 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador • Este patrón arquitectónico y de diseño fue descrito por primera vez por Trygve Reenskaug en 1979 y fue implementado en Smalltalk en los laboratorios Xerox. • MVC se basa en la separación de la aplicación en tres capas principales: Modelo, Vista y Controlador. • Se usa (él o alguna de sus variantes) en la gran mayoría de las interfaces de usuario. Material académico preparado por Marta 49 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-ControladorEjemplo del flujo de mensajes entre: Material académico preparado por Marta 50 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador• Vista: Se presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.• Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Material académico preparado por Marta 51 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador• Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos porque supone que está encapsulada por el modelo.• El objetivo primordial del MVC es la reutilización del código ya implementado.• Esta tarea se facilita mucho si a la hora de programar tenemos la precaución de separar el código en varias partes que sean susceptibles de ser reutilizadas sin modificaciones. Material académico preparado por Marta 52 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-ControladorEjemplos• Los datos de una hoja de cálculo pueden mostrarse de en formato tabular, con un gráfico de barras, con uno de sectores.• Los datos son el modelo.• Si cambia el modelo, las vistas deberían actualizarse en consonancia.• El usuario manipula el modelo a través de las vistas. (en realidad, a través de los controladores) Material académico preparado por Marta 53 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador Mas de una Vista de un Modelo de Datos Material académico preparado por Marta 54 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador• MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la página HTML, y el Controlador es el código que reúne la data dinámica y genera el contenido de la página.• El Modelo es representado por el contenido actual, que usualmente se encuentra almacenado en una base de datos o en archivos XML. Material académico preparado por Marta 55 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador Material académico preparado por Marta 56 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-ControladorFortalezas• Se presenta la misma información de distintas formas.• Las vistas y comportamiento de una aplicación deben reflejar las manipulaciones de los datos de forma inmediata.• Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de ejecución).• Permitir diferentes estándares de interfaz de usuario o portarla a otros entornos no debería afectar al código de la aplicación. Material académico preparado por Marta 57 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-Controlador Muchas interfaces gráficas de usuario, como Swing o MFC, hacen innecesario el uso de un controlador.• Definen su propio flujo de control y manejan los eventos internamente.• Integran, así, la vista y el controlador.• A esta variante se la suele denominar Document-View Material académico preparado por Marta 58 Silvia Tabares B. UdeM
    • Modelo de Referencia – Patrón Arquitectónico Modelo-Vista-ControladorUn controlador (controlador.java, por ejemplo) puede gestionar el clic en un botón, de tal forma que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet) para su actualización (vista.mostrar_texto( )):/****************************************************************Responde al click en botón "abrir" La respuesta al evento es hacer que se abra en la vistael archivo correspondiente a la referencia seleccionada en el combo box****************************************************************/void b_abrir_actionPerformed(ActionEvent e) {… String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo /*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/ if (texto_archivo != null) { vista.mostrar_texto(texto_archivo); // Mostrar texto vista.mostrar_aviso("Carga de " + path + " completada."); } else vista.mostrar_aviso("Error en la carga de " + path);} Material académico preparado por Marta 59 Silvia Tabares B. UdeM