Download - DRS_U1_EA_ROAG

Diseño y Arquitectura de SoftwareUnidad 1 Evidencia de Aprendizaje. Lenguaje descriptor y patrones de arquitectura de software

Como parte de la evaluación de esta unidad, es necesario realizar un reporte donde se explique y distinga los diferentes patrones de arquitectura de software, así como los lenguajes descriptores de arquitectura y su aplicación a cada modelo, de manera que investigues patrones y lenguajes que no se hayan incluido en el desarrollo de esta primer unidad.

1. Identifica y describe los diferentes lenguajes descriptores de arquitectura y agrega la utilidad que tiene.

LENGUAJE CARACTERÍSTICAS Y DESCRIPCIÓN

Acme - Armani

Capaz de soportar el mapeo de especificaciones.Intercambio entre arquitectura e integración de ADLs.Soporta la definición de cuatro tipos de arquitectura la estructura (organización de un sistema en sus partes constituyentes); las propiedades de interés (información que permite razonar sobre el comportamiento local o global, tanto funcional como no funcional).Componentes – representan elementos computacionales y almacenamientos de un sistema.Semántica – Muchos lenguajes de tipo ADL no modelan la semántica de los componentes más allá de sus interfaces.Estilos – Acme posee manejo intensivo de familias o estilos.Acme soporta una variedad de front-ends de carácter gráfico de los cuales he experimentado con tres.Es un lenguaje puramente declarativo que describe la estructura del sistema las restricciones a respetar, pero no hace referencia alguna a la generación del sistema o a la verificación de sus propiedades no funcionales o de consistencia.

C2(C2 SADL, C2SADEL, xArch,xADL) En una arquitectura de estilo C2, los NOMBRE: Roberto Álvarez GranadosMATRÍCULA: AL12501836CARRERA: Ingeniería en Desarrollo de Software

1


conectores transmiten mensajes entre componentes, los cuales mantienen el estado, ejecutan operaciones e intercambian mensajes con otros componentes a través de dos interfaces.Sitio de referencia – El sitio de ISR en la Universidad de CaliforniaImplementación de referencia – SADL se utilizó eficazmente para un sistema de control operacional de plantas de energía en Japón, implementado en Fortran 77. Suficientemente legible como para que aquí prescindamos de comentarios, se trata un stream como un stack.

CHAM

La arquitectura de un compilador. Se argumenta en efecto que CHAM proporciona una base útil para la descripción de una arquitectura debido a su capacidad de componer especificaciones para las partes y describir explícitamente las reglas de composición.CHAM es un modelo de máquina abstracta independiente de plataforma y del lenguaje o paradigma de programación que se vaya a utilizar en el sistema que se modela.

Darwin Darwin soporta la descripción de arquitecturas que se reconfiguran dinámicamente a través de dos construcciones.Darwin no proporciona una base adecuada para el análisis de la conducta de una arquitectura, debido a que el modelo no dispone de ningún medio para describir las propiedades de un Componente o de sus servicios más que como comentario.Darwin está orientado más que nada al diseño de arquitecturas dinámicas y cambiantes.Consisten en una colección de servicios que pueden ser provistos o requeridos.

NOMBRE: Roberto Álvarez GranadosMATRÍCULA: AL12501836CARRERA: Ingeniería en Desarrollo de Software

2


Semántica – Darwin proporciona una semántica para sus procesos estructurales mediante el cálculo.Darwin proporciona notación gráfica.Soporte de lenguajes.

Jacal

“Animación” de arquitectura - Jacal no cuenta con una notación particular para expresar estilos, aunque por tratarse de un lenguaje de propósito general.Interfaces – Cada componente cuenta con puertos ports) que constituyen su interfaz y a los que pueden adosarse conectores.Jacal no genera código de ningún lenguaje de programación.Disponibilidad de plataforma – La herramienta que actualmente está disponible para editar y animar arquitecturas en Jacal es una aplicación Win32, que no requiere instalación, basta con copiar el archivo ejecutable para comenzar a usarla.

LILEANNA Es oficialmente un lenguaje de interconexión de módulos (MIL), basado en expresiones de módulo propias de la programación parame trizada.Utilizar descriptivamente. Para especificar y analizar un diseño determinado. (Que describen módulos y relaciones entre ellos, y que pueden incluir código u otros objetos de software).Utiliza el lenguaje Ada para la implementación y Anna para la especificación.LILEANNA soporta diferentes estilos de comunicación.LILEANNA (que habla de teorías, axiomas, grafos, vistas, stacks, aserciones, estructuras verticales y horizontales, packages y máquinas virtuales en un sentido idiosincrático a ese paradigma).LILEANNA son poderosos, pero no


3


están en línea con el estilo de arquitectura orientada a servicios o con modelos igualmente robustos, como los de C2 y Wright.

MetaH/AADL

Así como LILEANNA es un ADL ligado a desarrollos que guardan relación específica con helicópteros.Está basado en la estructura textual de MetaH.Disponibilidad de Plataforma – MetaH está exclusivamente ligado a desarrollos hechos en Ada en el dominio de referencia.

UniCon

Soportan tipos particulares de conectores.Proporciona herramientas para desarrollar configuraciones ejecutables de caja negra y posee un número fijo de tipos de interacción.Generar código ejecutable a partir de una descripción, a partir de componentes primitivos adecuados.Interfaces – En UniCon los puntos de interfaces de los componentes se llaman players.UniCon sólo soporta cierta clase de información semántica en listas de propiedades.UniCon soporta notación gráfica.Archivos que contienen código fuente.Carece de la capacidad de definir nuevos tipos, soportado sólo una amplia variedad de tipos predefinidos.La distribución de UniCon no se encuentra actualmente activa.

2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen.

Patrones de arquitectura de software

Tipo de Patrón

Comentario problemas SolucionesFase de

desarrolloPatrones de Arquitectura

Relacionados a la

Problemas arquitectónico

Patrones de llamadas entre

Diseño inicial


4


interacción de objetos dentro o entre niveles arquitectónicos

s objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad

Patrones de Diseño

Conceptos de ciencia de computación en general, independiente de aplicación

Claridad de diseño multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc.

Comportamiento de factoría, Clase Responsabilidad – Contrato (CRC)

Diseño detallado

Patrones de Análisis

Usualmente específicos de aplicación o industria

Modelado del dominio completitud, integración y equilibrio de objetos múltiples, planeamiento para capacidades adicionales comunes

Modelado de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. Logging & reinicio)

Análisis

Patrones de Proceso o de Organización

Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización

Productividad, comunicación efectiva y eficiente

Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación

Planeamiento

Idiomas Estándares de codificación y proyecto

Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un

Siumamente específicos de un lenguaje, plataforma o ambiente

Implementación, Mantenimiento, despliegue


5


grupo. Legibilidad, predictibilidad

3. Elabora ejemplos de uso de la combinación de lenguajes y patrones y describe cada ejemplo (mínimo 2).

En un contexto informático un patrón de diseño es similar a conceptos como biblioteca de clases, frameworks, técnicas y/ herramientas de refactorización o programación extrema.La clasificación de los patrones de diseño en este contexto atiende a dos características como son:

Atendiendo a su propósitoo Creacionales: Resuelven problemas relativos a la creación de

objetoso Estructurales: Resuelven problemas relativos a la composición de

objetoso de Comportamiento: Resuelven problemas relativos a la

interacción entre objetos. Atendiendo a su ámbito

o Clases: Relaciones estáticas entre clases

o Objetos: Relaciones dinámicas entre objetos

Un ejemplo de lo que podría constituir un patrón de diseño aplicado a un contexto informático podría ser el siguiente:

Clases: relaciones estáticas entre clases. Objetos: relaciones dinámicas entre objetos. Nombre: Retroalimentación visual de navegación directa. Problema: El usuario tiene dificultades para acceder directamente a

las ventanas del sistema informático y desconoce cuál de entre ellas es la ventana actual de trabajo.

Principio de usabilidad: Guiar al usuario y dar el control de la interacción al usuario.

Contexto: Dada una gran cantidades de información facilitar al usuario los medios para navegar directamente entre las ventanas del sistema informático.

Fuerza: El sistema debe siempre mostrar la lista de ventanas navegables.


6


Solución: Permitir al usuario a seleccionar directamente las ventana de la interfaz y mostrar continuamente la ventana activa y desactivas.

Consecuencias: El acceso directo a las ventanas del sistema no solo beneficia la manipulación directa de ellas sino también la manipulación de los objetos que retienen ya que cada ventana es definida en términos de sus objetos de interacción (e. g. iconos, ítems de menú, radio botones) los cuales permiten la adquisición y la restitución de información que requiere el usuario.

Ejemplo 1

“Una tienda de conveniencia necesita automatizar sus procesos de compra, venta y seguimiento de clientes. Lo desea hacer a través de venta en línea para sus clientes y que sus proveedores puedan acceder a un sitio privado y vean automáticamente las existencias del producto que surten, al mismo tiempo los usuarios podrán comentar sobre su experiencia de compra en línea o en el sitio; estos comentarios los podrán hacer a través de un equipo de cómputo convencional o mediante un dispositivo móvil que será capaz de conectarse al sitio de la tienda. El gerente de la tienda necesita que se obtengan tendencias de ventas y que se haga una posible sugerencia a los compradores sobre la base a sus compras anteriores, y sobre todo considerando su perfil (se entiende que el sistema deberá generar ese perfil en el que se incluya la edad, el sexo, la ubicación, los amigos, las fotografías, su grado escolar y comentarios hechos). Deberá ser fácil de usar para todos los usuarios y deberá manejar diferentes tipos de roles (administrador del sitio, gerente general, gerente de tienda, vendedor, proveedor, usuario normal) y cada uno tendrá acceso a diferentes privilegios asignados por el administrador del sitio”

Se propone un patrón simple que es una tienda de convivencia y no se pretende tener una arquitectura muy compleja que no requiera de algún mantenimiento de la misma y también que no sea muy costosa.

También se requiere de una programación por capas para poder delimitar cada componente que compone a cada aplicación.

La programación por capas es la arquitectura cliente-servidor ya que permite contar con tipos de clientes (web o dispositivos móviles)

Cada capa tiene una función:


7


Capa de presentación.- Se desarrollan las interfaces del usuario.

Capa de negocio.- Son los requerimientos solicitados.

Capa de datos.- Acceso a los recursos de la información que se requiere con una base de datos, los datos pueden ser lectura, modificaciones, escritura.

Las bases de datos de cada capa contienen diferentes detalles:

Capa de presentación:

Una pantalla de los productos que se compraran.Productos de venta de productosSeguimiento de productosPedidosProveedoresSugerenciasRegistro de clientes.Registro de usuarios, clientes, proveedores.AyudaEn la capa de negocios.Buscar un producto.Carrito de compras.En la capa de datos.

Clientes Proveedores Empleados Productos Pedidos Inventario Comentarios

Ejemplo 2:

Una tienda de convivencia necesita también sus procesos de compra, venta y seguimiento de clientes. Lo cual necesita también el gerente de la tienda necesita que se obtenga tendencias de ventas y que se haga una posible sugerencia a los compradores sobre la base a sus compras anteriores y sobre todo considerando su perfil y que sea fácil para todos los usuarios en todos los departamentos de la tienda y cliente.

Requerimientos de softwareVenta en línea para sus clientesDatos del cliente y servidorCompra, venta y seguimiento de clientesNOMBRE: Roberto Álvarez GranadosMATRÍCULA: AL12501836CARRERA: Ingeniería en Desarrollo de Software

8


Sus proveedores puedan acceder a un sitio privadoVer automáticamente las existencias del productoSugerencias de la compraCada una tendrá acceso a diferentes privilegios por el administrador del sitioPropuesta de arquitecturaN-capas con orientación al dominioCapa de presentaciónClienteAplicación en diferentes dispositivos electrónicosCapa de servicios distribuidosCliente usuarioCuenta con el negocioCapa de aplicaciónEl cliente realiza revisión de productoDatos del usuarioSugerenciasCapa del modeloVendedorProveedorAdministradorCapa de la infraestructura de accesoGerente GeneralObtención de información

Conclusiones:

Los ADLs cuentan con cuatro criterios que los definen como una entidad: componentes, conectores, configuraciones y restricciones.

Lenguaje que pertenezca a la familia de ADLs debe soportar por lo menos los siguientes elementos:

ComponentesConexionesComposición jerárquicaParadigmas de computaciónParadigma de comunicaciónModelos formales subyacentesSoporte de herramientas para modelado, análisis, validación y verificaciónComposición automática de código aplicativoAbstracción de componentesRelatividadCapacidad para modelar componentesTipos y verificación de tipos


9


Componentes, conectores, Configuraciones o Sistemas, Propiedades, Restricciones, Estilos, Evolución, Propiedades no funcionales.

Los patrones arquitectónicos sirven también para describir las restricciones que tienen los módulos que comprenderán al sistema.

Debe considerarse a la AS como una conjunción de todos los elementos hasta ahora descritos (ADLs, patrones arquitectónicos, vistas)

La metodología RUP (Rational Unified Process) distingue varios pasos (fases) que se deben completar para poder decir que se realizó la administración del desarrollo de un proyecto de software:

VentasPlaneaciónAnálisisDiseñoConstrucciónPruebasImplementación

4. Investiga la aplicación de lenguajes y patrones que no se hayan presentado en el desarrollo de la unidad.

Patrones de diseño• Proxies de todo• Factorías• Adaptadores• Composición• Broker

Nombre e intención del patrón Referencia al patrón Incrementa el vocabulario de diseño Problema y contexto Cuándo aplicar el patrón Solución Estructura: elementos que conforman el diseño, sus relaciones,

responsabilidades y colaboraciones es una descripción abstracta de cómo una disposición de elementos

(clases y objetos) solucionan el problema Se ilustra con un ejemplo de código Consecuencias (positivas y negativas)


10


Necesidades (tiempo, memoria), aspectos de implementación y lenguaje de programación, flexibilidad, extensibilidad, portabilidad

Patrones relacionados

Categorías de patrones de diseño Patrones de creación Tratan de la inicialización y configuración de clases y objetos Patrones estructurales Tratan de desacoplar interfaz e implementación de clases y objetos:

o ¿Cómo se componen clases y objetos? Patrones de comportamiento Tratan de las interacciones dinámicas entre sociedades de clases y objetos:

o ¿Cómo interaccionan y se distribuyen responsabilidades los objetos?

Cómo seleccionar un patrón de diseño Considerar cómo los patrones de diseño solucionan problemas de diseño Buscar las intenciones de cada patrón Estudiar cómo se interrelacionan los patrones Estudiar patrones de propósito similar Examinar la causa de un rediseño Considerar qué debería ser variable en un diseño

Cómo usar un patrón de diseño1. Leer el patrón una vez para tener una visión general2. Volver y estudiar la estructura, los participantes y las colaboraciones3. Ver un ejemplo concreto codificado del patrón4. Elegir nombres para los participantes del patrón que sean significativos en

el contexto de la aplicación5. Definir las clases6. Definir nombres específicos de la aplicación para las operaciones en el

patrón7. Implementar las operaciones que realizarán las responsabilidades y

colaboraciones del patrón

Patrones de creación En Java para crear un objeto se utiliza el operador new unObjeto = new

ClaseObjetos (); Una clase Factoría puede ocuparse de los detalles de qué clase de

implementación utilizar para crear un objeto de un tipo determinado


11


Permiten que el sistema sea independiente de cómo se crean, componen o representan sus objetos Sistemas más dependientes de la composición de objetos que de la

herencia de clases Se trata de que el comportamiento se defina más por la composición

de un conjunto pequeño de comportamientos fundamentales que por la definición mediante herencia de todos los comportamientos posibles

Por tanto, la creación de objetos es algo más que instanciar una clase

Temas recurrentes en los patrones de creación: Encapsulan el conocimiento sobre las clases concretas que se van a

utilizar Ocultan la manera de crear objetos de estas clases y cómo se juntan

o La visión global de los objetos del sistema son sus interfaces (que pueden definirse como clases abstractas o interfaces)

o Se da independencia deo qué se creao quién lo creao cómo se creao cuándo se crea

Tipos de patrones de creación De clase: usa herencia para variar la clase del objeto creado

o Factoría abstractao Factoría para construir familias de objetoso Buildero Factoría para construir objetos complejos de forma

incremental De objeto: delega la creación en otro objeto

o Método Factoría Interfaz que permite que sean las subclases las que

determinen qué clase instanciar


12


o Prototype Factoría para clonar nuevos ejemplares copiando

de un prototipoo Singletono Object Pool

Factoría que asegura que sólo hay un miembro (singleton) o un conjunto determinado (object pool) de una clase, y proporciona un punto global de acceso a él

Patrones elementales(idioms)• Modularidad• Interfaces mínimas• Encapsulación• Objetos• Acciones y Eventos• Concurrencia

Lo fundamental son las relaciones de uso entre objetos Se trata de conseguir que cambios en los requisitos de la aplicación no

ocasionen cambios en las relaciones entre los objetos Las relaciones de uso están determinadas por las interfaces que soportan

los objetos Tipos de patrones estructurales

De clase: usa herencia para componer interfaces o implementacioneso Herencia múltiple: una clase que hereda de otras combina sus

propiedadeso Class Adapter

De objeto: composición de objetos en tiempo de ejecucióno Object Adaptero Bridgeo Compositeo Decoratoro Facadeo Flyweighto Proxy

Bibliografía:

http://www.fdi.ucm.es/profesor/jpavon/poo/2.14PDOO.pdfhttp://www.fdi.ucm.es/profesor/jpavon/poo/2.14PDOO.pdfhttp://www.um.es/ead/red/M10/caceres.pdf


13

http://www.um.es/ead/red/M10/caceres.pdf

http://www.fdi.ucm.es/profesor/jpavon/poo/2.14PDOO.pdf

http://www.fdi.ucm.es/profesor/jpavon/poo/2.14PDOO.pdf


5. En un archivo de texto, redacta un reporte con los elementos solicitados en los puntos 1, 2, 3 y 4.

6. Guarda la actividad con el nombre DRS_U1_EA_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido.

7. Envía el archivo a tu Facilitador(a) a través de la sección Evidencia de aprendizaje.

8. Consulta la escala de evaluación para conocer los parámetros de la actividad.


14