Your SlideShare is downloading. ×
01 conceptos de diseño
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

01 conceptos de diseño

483

Published on

Published in: Education, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
483
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1-Conceptos de Diseño
    Dr. Ricardo Quintero
  • 2. La Metáfora de la Célula
    Alan Kay utiliza la metáfora del Sistema Biológico para para explicar lo que deben ser los Objetos Software.
    Como las células, los Objetos Software no saben que es lo que sucede internamente en cada objeto, pero secomunican y trabajanen conjunto para realizar tareas complejas.
    En contraste, un Software Monolítico, es como un reloj mecánico que contiene innumerables engranes que funcionan sin inteligencia y en relación únicamente con los engranes adyacentes.
    “Cuando construyes un reloj de engranes, eventualmente alcanzas un nivel de complejidad que pone límites en si mismo” dice Alan Kay.
  • 3. La Metáfora de la Célula
    Un Objeto Software puede ser como una máquina que:
    Toma decisiones.
    Hace cosas.
    Conoce cosas.
    Colabora con muchos otros objetos potenciales.
    Viviendo en una máquina encerrada:
    Es un Todo en un nivel.
    Y una Parte en otro.
    El comportamiento del objeto está estrictamente limitado a aquello para lo que se le diseñó.
    Pero el comportamiento dinámico del Sistema Software surge a partir de las interacciones de muchos objetos (cada uno contribuyendo y jugando un rol responsable).
  • 4. La Maquinaria de Objetos
    Una Aplicación Software debe estar construida a partir de partes (los objetos).
    Estas partes interactúan enviando mensajes para solicitar alguna informacióno acción de otras partes.
    A lo largo de su tiempo de vida, cada objeto se mantiene responsable de responder a un conjunto fijo de solicitudes.
    Para atender estas peticiones, los objetos encapsulan respuestas y la información en la que se basan para estas respuestas.
  • 5. El objeto encapsulando respuestas e información …
    Ejecuta Servicios
    Conoce información
    Un Objeto
    Toma decisiones
    (para hacer lo correcto)
    Mantiene conexiones (a otros objetos)
  • 6. Pregunta clave…
    ¿Cómo inventamos estas Máquinas Software?
  • 7. Respuesta clave …
    Construir una Aplicación Orientada a Objetos significa inventar la maquinaria apropiada en la cual representamos:
    Información del mundo real.
    Procesos.
    Interacciones.
    Relaciones.
    Errores
    Objetos que no existen en la realidad (damos vida a cosas inanimadas).
    Descomponemos en objetos simples a objetos complejos (y difíciles de entender).
  • 8. Respuesta clave …
    La medida del éxito es: que tan claramente inventamos la realidad del software que satisface los requisitos de la aplicación (y no que tanto se asemeja al mundo real).
    Al conectarse los objetos entre sí deben trabajar en concierto para construir máquinas muy complejas.
    Para manejar la complejidad, debemos repartirlos comportamientos del sistema en objetos que jueguen roles bien definidos.
  • 9. Perspectivas complementarias para el diseño de aplicaciones
    Enfocados en el comportamiento, es posible diseñar una aplicación usando varias perspectivas complementarias:
    Una Aplicación = Un conjunto de objetos que interactúan
    Un Objeto = Una implementación de uno o más roles
    Un Rol = Un conjunto de responsabilidades relacionadas
    Una Responsabilidad = Una obligación para realizar una tarea o conocer una información
    Una Colaboración = Una interacción de objetos o roles (o ambos)
    Un Contrato = Un acuerdo enmarcando los términos de la colaboración.
  • 10. Roles
    Dentro de la maquinaría cada objeto tiene un propósito específico (el rol que juega dentro de un cierto contexto).
    Objetos que juegan el mismo rol pueden ser intercambiados.
    Así podemos definir Rol:
    “Un conjunto de responsabilidades que se pueden utilizar de forma intercambiable”
    Un rol es un slot en la maquinaría del software a ser llenado con un objeto apropiado conforme el programa se ejecuta.
  • 11. Estereotipos de Roles de Objetos
    Para enfocarse en las responsabilidades del objeto podemos utilizar Estereotipos de Roles.
    Los Estereotipos son caracterizaciones de los roles necesarios de las aplicaciones.
    A fin de construir objetos consistentes y fáciles de utilizar, es ventajoso estereotipar objetos ignorando los detalles específicos de los comportamientos y pensando en ellos a alto nivel.
  • 12. Estereotipos útiles
    Los siguientes son estereotipos útiles:
    InformationHolder: conoce y provee información.
    Structurer: mantiene relaciones entre los objetos, así como también información de estas relaciones.
    ServiceProvider: realiza trabajo y, en general, ofrece servicios de cómputo.
    Coordinador: reacciona a eventos delegando tareas a otros.
    Controller: toma decisiones y dirige otras acciones.
    Interfacer: transforma información y solicitudes entre diferentes partes del sistema.
    Un objeto podría satisfacer más de un estereotipo, aunque podría tener asignada más de 1 responsabilidad (Un objeto ServiceProvider que maneja de forma privada la información necesaria para éste rol: 1 Rol con 2 Responsabilidades).
  • 13. Roles, Responsabilidades y Colaboraciones
    Una Aplicación implementa un sistema de Responsabilidades.
    Las Responsabilidades son asignadas a los Roles.
    Los Roles colaboran para llevar a cabo las Responsabilidades.
    Una buena aplicación está estructurada para satisfacer efectivamente estas responsabilidades.
    Diseñar colaboraciones obliga a considerar objetos como participantes colaboradores y no como entidades aisladas.
    El Diseño es un proceso iterativo e incremental de visualizar objetos y sus responsabilidades e inventar colaboraciones flexibles dentro de pequeños vecindarios.
  • 14. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …
    Ejecuta Servicios
    Conoce información
    Toma decisiones
    (para hacer lo correcto)
    Un Objeto
    Mantiene conexiones (a otros objetos)
    “Una aplicación es una comunidad de objetos trabajando juntos. Colaboran enviando mensajes y recibiendo respuestas. Contribuyen con su Conocimiento y Servicios”
    Mensaje solicitando ayuda
    Un Objeto
  • 15. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …
    Un objeto puede ser más inteligente si hace algo con lo que conoce.
    Entre más inteligente el objeto, menos detalles debe conocer el cliente que utiliza sus servicios.
    Así los clientes se enfocan a resolver el problema, no en poner atención a detalles que sus colaboradores pueden resolver.
    Hacer objetos inteligentes tiene un efecto neto de elevar el IQ de toda la sociedad de objetos.
  • 16. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …
    Parte del valor de un objeto está determinado por sus vecinos.
    Al concebir el diseño hay que considerar constantemente (respecto los vecinos):
    ¿Provee un servicio útil?
    ¿Es fácil hablar con él?
    ¿Es una “carga” porque continuamente solicita ayuda?
    ¿Sus efectos son los deseados?
    Entre menos demandas hace un objeto, más fácil será de utilizar.
    Entre más tome cuidado, más útil será.
  • 17. Contratos de Objetos
    Un Contrato de un Objeto describe las condiciones bajo las cuales se garantiza su trabajo y los efectos que dejará una vez que el trabajo se complete.
    El Contrato de un Objeto responde a las preguntas:
    ¿Con cuales objetos interactúa?
    ¿Bajo que circunstancias es utilizado?
    ¿Cuáles son los efectos a largo plazo que tendrá el objeto con su ambiente?
    Profundiza nuestro conocimiento de las responsabilidades del objeto y soporta nuestra confianza respecto a su diseño.
    Todo esto sin indicar como se cumplen con las responsabilidades.
  • 18. Condiciones de Uso y Garantías de Efecto Posterior
    Las Condiciones de Uso y las Garantías de Efecto Posterior definen los contratos.
    Las Condiciones de Uso responden a la pregunta:
    ¿Bajo que condiciones puede el objeto garantizar sus servicios?
    Las Garantías de Efecto Posterior responden a la pregunta:
    ¿Qué esperan los demás objetos de mí?
    Cuando un objeto se utiliza fuera de sus Condiciones de Uso no está obligado a satisfacer la petición.
    Las Condiciones de Uso en Diseño OO se reducen a las condiciones correctas bajo las cuales serán invocados los servicios aglutinados en las interfases de los objetos.
  • 19. Objetos de Dominio
    Los Objetos de Dominio ofrecen una base común sobre la cual desarrolladores y usuarios pueden converger y discutir la aplicación.
    Los Objetos de Dominio representan conceptos que son familiares a usuarios y expertos en un campo específico de interés.
    Ej.- En una aplicación bancaria: cuentas, depósitos, tasas de interés, etc.
    Para los desarrolladores estos objetos del dominio son solamente el punto inicial para construir un Modelo del Dominio útil para desarrollar las representaciones internas de éstos y conceptos adicionales que existirán en la maquinaria del software.
  • 20. Modelo de Dominio
    Un Producto
    Relaciones
    Procesos
    Una Orden
    Una Revisión del Stock
    Una Historia Crediticia
    Un Cliente
    Información
    Reglas
    Un Descuento
    Una Regla de Embarque
    Servicios
  • 21. Modelo de Dominio
    Los objetos en el Modelo de Dominio incorporan la lógica de la aplicación y sus interacciones.
    El M. de D. captura, al nivel más abstracto, la semántica de la aplicación y sus respuestas al ambiente.
    No se representan todos los conceptos del dominio solamente los que son necesarios para soportar la aplicación.
  • 22. Objetos Específicos de la Aplicación
    Similarmente, necesitamos objetos para traducir las entradas del usuario (clics de mouse, tecleo) a comandos para objetos apropiados de la aplicación.
    Estos objetos transforman o filtran la información de usuario y después llaman a los objetos apropiados para la acción.
    Podrían también secuenciar al movimiento de pantallas, cambiar vistas o refrescar imágenes.
    Estos objetos específicos de aplicación proveen al Modelo de Dominio de comportamientos específicos del programa y se aglutinan con la aplicación.
  • 23. Objetos Específicos de la Aplicación
    Al iniciar una típica aplicación existe al menos 1 objeto de arranque que crea la población inicial de objetos y luego les pasa el control.
    Conforme el usuario navega a través de la aplicación, este grupo inicial de objetos responde a acciones de usuario ya sea satisfaciendo requisitos de la aplicación o creando y delegando trabajo a nuevos grupos de objetos diseñados para propósitos específicos.
    Conforme la ejecución continua, nuevos ciudadanos de esta comunidad de objetos nacen, viven y mueren (acorde a las necesidades –y diseño- de la aplicación).
  • 24. Modelo de Dominio
    Un Producto
    Relaciones
    Control
    Procesos
    Un gestor de órdenes
    Una Orden
    Un verificador de crédito
    Una Revisión del Stock
    Una Historia Crediticia
    Coordinación
    Un Cliente
    Información
    Una ventana
    Interfases
    Reglas
    Un Descuento
    Una Regla de Embarque
    Servicios
  • 25. Vista del Usuario y Vista del Diseñador
    Ambas vistas representan dos niveles diferentes de pensamiento sobre aplicaciones y objetos.
    La Vista del Usuario maneja una representación de conceptos del alto nivel (la información, servicios y reglas del dominio).
    La Vista del Diseñador inventa aspectos de coordinación y conectividad a otros sistemas y dispositivos, razona sobre la aplicación a un nivel diferente, más bajo: procesos de computadora, computaciones, traducciones, ejecución condicional, delegación, entradas, salidas.
    La clave para desarrollar una aplicación exitosa recae en nuestra habilidad para vincular estas dos vistas sin comprometer ninguna.
  • 26. Interfases
    Eventualmente un objeto expresa sus responsabilidades sobre conocer (know) y hacer (do) a otros en métodos que contienen código.
    Una Interfase describe el vocabulario utilizado en el diálogo entre un objeto y sus clientes:
    “Bolea mis zapatos. Dame mis zapatos. Serán cinco pesos. Aquí está tu recibo”.
    La Interfasemanifiesta los servicios y explica como solicitarlos.
    Frecuentemente es importante conocer, además, las condiciones bajo las cuales un servicio puede ser invocado.
    Entre más se publique sobre el comportamiento de un objeto, más probable será que se utilice de acuerdo a su intención en el diseño.
    La interfase debe ser pública, la implementación privada u oculta.
  • 27. Clases
    El término Clase se utiliza en matemáticas y en la vida real para describir “conjuntos de cosas”.
    Las clases son abstractas y conceptuales, las instancias concretas, objetos físicos.
    Esta noción aplica también a los objetos software, aunque las clases software poseen características que son específicas al mundo del software.
  • 28. Dos roles
    Si una clase software ofrece dos conjuntos distintos de servicios (usualmente a dos tipos de clientes), la clase se dice que juega dos roles:
    Primero, juega un rol que no tiene analogía en el mundo real: la clase actúa como una fábrica para crear las instancias requeridas del programa.
    Segundo, actúa como un objeto en sí mismo, con su propio conjunto de responsabilidades. Ofrece información y servicios a otros objetos a través de su propia interfase.
  • 29. Dos roles: la clase actuando como Fábrica
    Un cliente
    Un cliente
    Un cliente
    Clase
    Cliente
    Un objeto
    new
  • 30. Dos roles: la clase actuando como Fábrica
    Solicitudes por
    Información y Servicios
    relacionados con el Cliente
    Clase
    Cliente como colaborador
    Un objeto
    Necesita ayuda
    Ofrece ayuda como cualquier
    otro objeto
  • 31. Dos roles
    Cada instancia realiza sus tareas en dos contextos:
    Se comporta de acuerdo a reglas establecidas por la comunidad donde vive.
    Controla sus acciones de acuerdo a sus reglas y datos privados.
    Las reglas suelen estar representadas en condicionales en métodos.
    Los datos representan el estado del objeto. Incluyen, además, referencias a otros objetos las cuales permiten que pueda “ver” a otros y, subsecuentemente, interactuar con ellos.
  • 32. Relaciones entre objetos
    Existen sólo dos tipos de relaciones entre objetos:
    Composición
    Herencia
    Tienen analogía con el árbol familiar:
    La Composición es como un Matrimonio entre Objetos: es dinámica, sucede durante el tiempo de vida de los objetos y puede cambiar.
    La Herencia es como los Nacimientos en la familia: una vez que sucede es para siempre.
    Así como ambos existen en el árbol familiar, ambos también existen en cualquier sistema orientado a objetos.
  • 33. Composición
    Es posible extender las capacidades de un objeto a través de su composición con otros.
    Cuando carece de alguna característica que requiere para satisfacer sus responsabilidades, se delega simplemente a algún objeto con el cual tenga referencia (o conexión).
    Esto ofrece un escenario muy flexible: conforme el programa continua su ejecución los componentes se conectan entre sí, dinámicamente, de acuerdo a las condiciones de la aplicación.
    La Composición es uno de los mecanismos básicos para lograr la comunicación entre objetos; otros incluyen el paso de objetos ayuda en solicitudes o la creación de objetos.
  • 34. Herencia
    La Herencia es otra forma de extender las capacidades de un objeto.
    A diferencia de la Composición, que es dinámica (en tiempo de ejecución), la Herencia es estática (en tiempo de compilación).
    En ocasiones las clases delegan su responsabilidad de crear objetos a sus subclases. Estas clases abstractas definen muchas de las características de las instancias, pero requieren de las subclases para completar algunos detalles y realizar la manufactura actual.
  • 35. Organizaciones de Objetos
    Conforme se descompone la aplicación en piezas lógicas se pueden identificar objetos o roles y definir clases que implementen roles específicos.
    Se pueden diseñar elementos que posean cierta integridad lógica, pero que se puedan descomponer en piezas más pequeñas.
    Estos agrupamientos lógicos de colaboradores (confederaciones de objetos) suelen llamarse subsistemas o vecindades de objetos.
    Los subsistemas sirven a propósitos mayores de los que en lo individual pudieran realizar cualquier objeto.
    La sinergia de los esfuerzos corporativos entre los miembros del subsistema crea una nueva entidad conceptual, de más alto nivel.
  • 36. Confederación de objetos
    Un solo objeto que representapúblicamente a todos los objetos
    Empresa Financiera
    ACME
    Ley ACME
    Tu proveedor de servicio
    Licenciado
    Tu Agente
    Su asistente
    Conceptualmente no
    hay diferencia entre
    las responsabilidades
    de un Objeto y un Subsistema
  • 37. Componentes
    Son piezas de elementos de diseño cuya intención es utilizarlas en diferentes aplicaciones.
    Se pueden actualizar o reemplazar un componente sin reconfigurar el resto del sistema.
    Los aspectos internos del componente están ocultos, sus servicios están disponibles a través de una interfase bien definida.
    Para adaptarlos para su uso, un componente puede proveer interfases que permitan a sus clientes conectar componentes de ayuda o establecer propiedades para controlar aspectos de su operación.
  • 38. Patrones
    Los pioneros de tecnología de objetos generaron muchas aplicaciones y estrategias de objetos para resolver problemas.
    Esta experiencia puede ser transmitida a las siguientes generaciones mediante Patrones.
    Un Patrón captura la experiencia de practicantes expertos presentando soluciones a problemas recurrentes comunes en un formato predecible y fácil de leer.
  • 39. Frameworks
    Un Framework es un diseño general para resolver un problema de software.
    A diferencia de un patrón (una idea para resolver un problema familiar), un Framework ofrece una biblioteca de clases que los desarrolladores pueden particularizar o extender para satisfacer una situación particular.
    El éxito del Framework depende de que tan útil es a los desarrolladores y que tan fácil se pueden particularizar sus servicios a las necesidades.
    Problemas donde se han aplicado con éxito los Frameworks: GUI, Simulación, Ambientes de Programación (Eclipse), Aplicaciones Web.
  • 40. Frameworks-Ventajas
    Ventajas al desarrollador:
    Eficiencia: menos diseño y codificación.
    Riqueza: el expertise del dominio se captura en el Framework.
    Consistencia: los desarrolladores se familiarizan con la filosofía impuesta por el Framework.
    Predecibilidad: el Framework lleva consigo varias iteraciones de desarrollo y pruebas.
  • 41. Frameworks-Desventajas
    Desventajas al desarrollador:
    Complejidad: suelen tener una curva de aprendizaje pronunciada.
    Suelen requerir una estrategia específica para resolver un problema (si lo único que tienes es un martillo, todo parecerá clavo).
    Rendimiento: suele intercambiar flexibilidad y reusabilidad por rendimiento.
  • 42. Frameworks
    Los Frameworks ofrecen soluciones genéricas pero carecen de comportamientos específicos que varían de aplicación en aplicación.
    Los comportamientos que se dejan incompletos son llamados hooks: implementaciones que se difieren a los programadores para aplicaciones específicas.
    Al codificar los hooks el programador debe aceptar una inversión en el control: nuestro código llama a otros objetos y se les pide que hagan el trabajo a favor nuestro.
  • 43. Arquitectura
    No hay una única definición de Arquitectura de una aplicación.
    Una Arquitectura es una colección de comportamientos y un conjunto de descripciones sobre como se impactan unos a los otros.
    La Arquitectura, entonces, debe incluir aspectos estructurales y dinámicos.
    Los detalles internos de cómo un grupo de objetos realizan una tarea no deberían considerarse al diseñar una Arquitectura. En Arquitectura las interfases deben decirlo todo.
  • 44. Estilos Arquitectónicos
    Representan estilos para organizar los objetos software.
    Hay 2 aspectos que se deben considerar cuando se piensa en un estilo arquitectónico:
    Estilos de Interacción de Componentes: muestran componentes o capas del sistema y describen como se les permite interactuar (capas, pipes & filters, blackboard).
    Estilos de Control: enfoques para distribuir responsabilidades para toma de decisiones y coodinación dentro y entre capas o componentes (desde altamente centralizado hasta distribuido).
  • 45. Estilos Arquitectónicos
    Cada combinación de Estilo Arquitéctonico soporta 1 o más características de calidad en un proyecto:
    Usabilidad
    Disponibilidad
    Seguridad
    Rendimiento
    Mantenibilidad
    Flexibilidad
    Portabilidad
  • 46. Estilos Arquitectónicos
    Para soportar estos y otros atributos de calidad antes de realizar cualquier análisis, diseño, codificación podemos empezar seleccionando el Estilo Arquitectónico que los soportará.
    Seleccionar el Estilo Arquitectónico puede tener un alto impacto.
  • 47. Estilo de Control Centralizado
    Hace una clara distinción entre datos y algoritmos.
    Cuando 1 Objeto Inteligente Central requiere computar datos, la pide a los Repositorios de Datos, los procesa y los regresa al mismo repositorio o a otro.
    La lógica de la aplicación está centralizada en los objetos inteligentes. El código puede ser difícil de leer porque está incrustado en una gran cantidad de lógica no afín, aunque sólo buscas en 1 solo lugar.
  • 48. Estilo de Control Centralizado
    Los objetos manejan información…
    La lógica inicia y termina aquí …
  • 49. Estilo de Control Disperso: no centralizado
    En el otro extremo, se dispersa la lógica a través de toda la población de objetos, manteniendo cada objeto pequeño y construyendo la menor dependencia entre ellos. No hay una entidad central.
    Para determinar el funcionamiento, se debe trazar la secuencia de solicitudes a servicios a través de muchos objetos, por esto no es muy reutilizable.
  • 50. Estilo de Control Disperso: no centralizado
    La lógica inicia aquí …
    La lógica finaliza aquí …
  • 51. Estilo de Control Delegado
    Establece un compromiso (o balance) entre los 2 extremos mencionados.
    Cada objeto encapsula mucho de lo que se necesita para realizar las responsabilidades, pero en ocasiones requiere la ayuda de otros objetos capaces.
    Cada objeto tiene una pieza sustancial del pastel.
    Como cada objeto es muy capaz de realizar sus responsabilidades, por tanto es más usable.
    Las Funciones del Sistema se organizan en pools de responsabilidad que pueden utilizarse en forma relativamente aislada.
  • 52. Estilo de Control Delegado
    Los Objetos conocen y hacen algún sub-paso…
    Los coordinadores manejan cada paso…
    La lógica inicia aquí …
    La lógica termina aquí …
  • 53. Estilo de Capas
    Agrupa responsabilidades en capas.
    Cada capa tiene un número bien definido de capas vecinas (1 o 2).
    Los objetos que viven en cada capa se comunican principalmente con objetos de la misma capa.
    Si los servicios que un objeto requiere no están en la capa los buscará en la capa adyacente.
    El Estilo de Capas contribuye a simplicidad, mantenibilidad y reusabilidad.
  • 54. Estilo de Capas (aplicación Web)
    Browsers…
    Presentación
    Control y Coordinación de Aplicación
    Servidor Web…
    Servidor de Aplicaciones…
    Servicios e Información del Dominio
    Servidor de Base de Datos…
    Servicios de Base de Datos y Sistemas Legados
  • 55. Cada capa tiene roles de objetos característicos…
    Interfases (ventanas y widgets)
    Presentación
    Eventos
    Resultados
    Coordinadores y Controladores (de Aplicación)
    Servicios de Aplicación
    Contenedores de Información, Proveedores de Servicios, Estructuradores, Coordinadores y Controladores de Dominio
    Mensajes
    Resultados
    Servicios del Dominio
    Mensajes
    Resultados
    Servicios Técnicos
    Intefases
  • 56. Comunicando objetos en/entre capas
    La comunicación entre objetos tiende a seguir estas reglas:
    Los Objetos colaboran principalmente dentro de su propia capa.
    Cuando residen en capas diferentes, los objetos cliente suelen estar arriba de los objetos servidores. Los mensajes (peticiones) fluyen hacia “abajo”.
    La información (resultados) fluye hacia “arriba”.
    Cuando los mensajes fluyen hacia “arriba” los objetos cliente están en las capas bajas están débilmente acoplados a los servidores. Esto generalmente mediante un mecanismo de eventos.
    Sólo las capas más altas y bajas están expuestas al mundo “exterior”. Suelen manejar objetos específicos de plataforma (widgets en la capa alta,; interfases a redes, dispositivos y sistemas externos en las capas bajas).

×