Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 5. Aspectos avanzados de...

Dr. Juan José Aranda Aboy

Aspectos Avanzados de la

Tecnología de Objetos

5. Aspectos avanzados de programación orientada a objetos


Contenidos

• Análisis arquitectural y el Documento de la Arquitectura del Software (Software Architecture Document – SAD).

• Diseño de un entorno de trabajo (framework) de persistencia con patrones.


Objetivos específicos

• Conocer y aplicar prácticamente cómo se diseña la arquitectura de los sistemas.

• Explicar y manejar apropiadamente la arquitectura lógica.

• Mostrar la arquitectura utilizando los diagramas de paquetes de UML.

• Conocer como se diseña un framework.


Estructura de los sistemas

• Un sistema típico está integrado por muchos paquetes lógicos:– Interfaz de usuario– Acceso a bases de datos– Etc.

• Cada paquete agrupa un conjunto cohesionado de responsabilidades, lo que constituye la práctica básica de aplicar la modularidad para dar soporte a la separación de intereses.


Arquitectura del software

Una arquitectura es el conjunto de decisiones significativas sobre la organización del sistema de software, la selección de los elementos estructurales y sus interfaces, con los que se compone el sistema, junto con su comportamiento tal y como se especifica en las colaboraciones con otros elementos, la composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente mas amplios, así como el estilo de arquitectura que guía esta organización: estos elementos y sus interfaces, sus colaboraciones y su composición.


Comentarios

En el desarrollo de software:• Como nombre, Arquitectura comprende la organización y

estructura de los elementos importantes del sistema:– Incluye el comportamiento en función de responsabilidades

y sus colaboraciones. – En cuanto a descripción, comprende las motivaciones ó

fundamentos de porqué el sistema está diseñado de cierta manera.

• Como verbo, la arquitectura es parte:1. Investigación arquitectural: Identificación de requisitos

funcionales y no funcionales que influyen de manera significativa en el desarrollo del sistema: tendencias del mercado, rendimiento, costo, mantenimiento y evolución.

2. Diseño de arquitectura: Es la resolución de estas influencias y requisitos en el desarrollo del software, el hardware y las redes, operaciones, políticas, etc.


Análisis arquitectural

• Trata de la identificación y resolución de los requisitos no funcionales del sistema en el contexto de los requisitos funcionales.

• En el Proceso Unificado (UP), el término comprende tanto la investigación como el diseño de arquitectura.

• En el UP, los factores de arquitectura se recogen en la Especificación Complementaria mientras que las decisiones de diseño que los resuelven se recogen en el Documento de la Arquitectura del Software (Software Architecture Document – SAD).


Cuestiones importantes

• Algunas cuestiones que se tienen que identificar y resolver al nivel de la arquitectura son:

1. ¿Cómo afectan en el diseño los requisitos de fiabilidad y tolerancia a fallos?

2. ¿Cómo afecta en la rentabilidad el costo de las licencias de los subcomponentes comprados?

3. ¿Cómo afecta la distribución de los servicios en los requisitos de calidad y los requisitos funcionales?

4. ¿Cómo afectan al diseño los requisitos de adaptabilidad y de configuración?


Pasos comunes en el análisis arquitectural

1. Identificar y analizar requisitos no funcionales que influyen en la arquitectura. Los requisitos funcionales son relevantes también –especialmente en términos de variabilidad ó cambio-. Todos éstos pueden llamarse factores ó controladores de la arquitectura.

2. Para aquellos requisitos que influyen de manera significativa en la arquitectura, analizar alternativas y crear soluciones que resuelvan el impacto: decisiones sobre la arquitectura


Requisitos significativos para la arquitectura

Los factores que influyen con mayor fuerza en la arquitectura tienden a encontrarse en las categorías de:

• Alto nivel de funcionalidad• Fiabilidad• Rendimiento• Soporte• Implementación• Interfaz


Prioridades

Existe una jerarquía de objetivos que guían la toma de decisiones:

1. Restricciones inflexibles, entre las que se encuentran las normas legales y los requerimientos de seguridad.

2. Objetivos del negocio, como por ejemplo, fecha en que debe estar concluido.

3. Restantes objetivos


Diseño orientado a objetos

Incluye dos partes:

1. Diseño del sistema = (Diseño arquitectónico)

2. Diseño de objetos = (Diseño detallado)

• Aunque estos temas son muy extensos y abarcan muchos conceptos, se introducirán conceptos esenciales y bibliografía para profundizarlos.


Diseño arquitectónico

• Independientemente del tipo de diseño, estructurado u orientado a objetos, hay una primera fase que consiste en la división del sistema en subsistemas. Los apartados a tener en cuenta son:

1. Descomposición estructural: Descomposición en subsistemas.

2. Intercambio de información entre subsistemas: Hay dos opciones: con una base de datos central o por medio de mensajes.

3. Forma de realizar el control: Centralizado o basado en eventos.


Principios básicos de diseño de la arquitectura

• Los principios básicos de diseño:

– Bajo acoplamiento,

– Alta cohesión y

– Variaciones protegidas,

son de gran influencia al nivel de la arquitectura a gran escala.

• La granularidad de los componentes es mayor, ya que se trata de bajo acoplamiento entre aplicaciones, subsistemas ó procesos.


Separación de intereses

• Los intereses transversales son aquellos con amplia utilización ó influencia en el sistema, como la persistencia de datos y la seguridad.

• El diseño separa el soporte a la persistencia y a la seguridad: un objeto tiene únicamente lógica de la aplicación, no de persistencia ó de seguridad.

• Un subsistema de persistencia se centra sólo en cuestiones de persistencia, mientras que otro de seguridad gestiona solamente este aspecto.


Técnicas para separación

1. Tratar el interés como un módulo en un componente separado e invocar sus servicios.

2. Utilizar decoradores: Enfoque muy común, dado a conocer por los Servidores de Transacciones de Microsoft y empleado por los EJBs, donde el decorador recibe el nombre de contenedor.

3. Utilizar a) Postcompiladores, como ocurre con los EJBs: Otro

compilador se ejecuta después para añadir soporte a la persistencia; y

b) Tecnologías orientadas a aspectos (Ejemplo: AspectJ): Soportan entrelazado post compilación de intereses de manera transparente para el desarrollador.

• Estos enfoques mantienen la ilusión de la separación durante el trabajo de desarrollo, y entrelazan el interés antes de la ejecución.

http://www.eclipse.org/aspectj/


Vistas de la arquitectura

• La idea esencial de una vista de la arquitectura del sistema es, desde una perspectiva dada, centrarse sobre todo en la estructura y modularidad de los componentes fundamentales y en los principales flujos de control.

• Un aspecto importante de la vista es la motivación: debe explicar por qué la arquitectura es de cierta manera.

• Una vista de la arquitectura es una ventana sobre el sistema desde una perspectiva particular que destaca la información relevante ó ideas claves, ignorando el resto.


Vistas en SAD

• Las vistas de la arquitectura, formadas por textos y diagramas, no describen todo el sistema, sólo ideas destacadas desde cada perspectiva.

• Las contempladas en el Proceso Unificado son:

1. Lógica

2. Proceso

3. Despliegue

4. Datos

5. Casos de uso

6. Implementación


1. Vista Lógica

• Organización conceptual del software en función de las capas, subsistemas, paquetes, frameworks, clases e interfases mas importantes. También resume la funcionalidad de los elementos del software importantes, como cada subsistema.

• Muestra los escenarios de realización de casos de uso destacados, como diagramas de interacción, que ilustran los aspectos claves del sistema.

• Se visualiza mediante diagramas de paquetes, clases e interacción de UML.


2. Vista de Proceso

• Procesos e hilos de ejecución, sus responsabilidades, colaboraciones y la asignación a ellos de los elementos lógicos (capas, subsistemas, clases, …)

• Visualizada mediante diagramas de clases e interacción de UML, utilizando la notación para procesos e hilos.


3. Vista de Despliegue

• Despliegue físico de los procesos y componentes sobre los nodos de proceso y la configuración de la red física entre los nodos.

• Visualizada mediante los diagramas de despliegue de UML.


4. Vista de Datos

• Vista global del esquema de datos persistentes, la correspondencia del esquema de objetos a datos persistentes (normalmente es una base de datos relacional), el mecanismo de correspondencia de objetos a una base de datos, procedimientos almacenados y disparadores (triggers).

• Visualizada mediante diagramas de clase UML, que se utilizan para describir un modelo de datos.


5. Vista de Casos de Uso

• Resumen de los casos de uso mas significativos para la arquitectura y sus requisitos funcionales: aquellos casos de uso que, mediante su implementación, cubren una parte significativa ó influencian en muchos elementos de la arquitectura.

• Se expresa textualmente, con el apoyo de los diagramas UML de casos de uso.


6. Vista de Implementación

• El Modelo de Implementación es el código fuente real, ejecutables, etc. Tiene dos partes:

1. Entregables2. Cosas que crean a los entregables: código fuente y

gráficos. • Está integrado por cosas tales como: páginas Web,

DLLs, paquetes Java, etc.• La vista de implementación es una descripción

resumida de la organización relevante de los entregables, así como de las cosas que les crean.

• Se expresa textualmente y se apoya para visualizarse en los diagramas de paquetes y de componentes de UML.


Creación de vistas

Puede realizarse:• Después de que se construya el sistema, como

resumen ó ayuda de aprendizaje para futuros desarrolladores.

• Al final de ciertos hitos dentro de cada iteración del proyecto, para que sirva de ayuda para el aprendizaje del equipo de desarrollo actual y de nuevos miembros.

• De manera especulativa, durante las primeras iteraciones, como ayuda en el trabajo de diseño creativo, reconociendo que la vista original cambiará cuando prosiga el diseño y la implementación.


Fases

• Inicio: Si no existe claridad sobre la posibilidad técnica de satisfacer los requisitos significativos de la arquitectura, el equipo debe implementar una Prueba de Concepto (PDC) para determinar la viabilidad, lo que se denomina Síntesis de la Arquitectura. Un PDC de la arquitectura cubre ligeramente muchos de los requisitos significativos para evaluar su viabilidad combinada.

• Elaboración: Su principal objetivo es implementar los elementos centrales de la arquitectura de riesgo, de manera que el análisis arquitectural se complete durante la elaboración.


Fases (2)

• Transición: El SAD necesitará ser revisado al final de la fase de transición al usuario para asegurarse de que describe de manera precisa el sistema de despliegue final.

• Ciclos de evolución siguientes: Es común revisar los factores de la arquitectura y las decisiones antes de diseñar nuevas versiones. Se permite que la arquitectura cambie para utilizar nuevos elementos, lo que facilita tolerancia a fallos y mejoras en el rendimiento.


Patrones y Frameworks

Patrones:

• Consisten en la identificación de problemas usuales en el análisis, diseño, codificación, etc. Suelen incluir una plantilla de solución.

Frameworks:

• Son otro mecanismo de reutilización, pero un framework se puede componer de varios patrones. Generan aplicaciones para un dominio.


Patrones y categoríasUna clasificación sencilla puede ser:1. Patrones de arquitectura: Relacionados con el diseño a

gran escala y de grano grueso. Se aplican en las primeras iteraciones –fase de elaboración-, cuando se establecen las estructuras y conexiones mas importantes.

2. Patrones de diseño: Relacionados con el diseño de los objetos y frameworks de pequeña y mediana escala. Aplicables al diseño de una solución para conectar los elementos de gran escala definidos mediante los patrones de arquitectura y durante el trabajo de diseño detallado para aspectos del diseño local. También se conocen como patrones de micro – arquitectura.

3. Estilos: Soluciones de diseño de bajo nivel orientadas a la implementación ó al lenguaje.Existen otras categorías de patrones: para el proceso de desarrollo, de interfaz del usuario y de pruebas.


Patrón de arquitectura Capas (Layers)• Una capa es un elemento de gran escala, compuesto de

varios paquetes ó subsistemas.• Sus ideas esenciales son:1. Organizar la estructura lógica de gran escala de un

sistema en capas separadas con distintas responsabilidades y relacionadas, con una separación clara y cohesiva de intereses: – las capas mas bajas son servicios de bajo nivel, y – las capas mas altas son específicas de la aplicación.

2. La colaboración y el acoplamiento es desde las capas mas altas hacia las mas bajas. Se evita el acoplamiento de las capas mas bajas a las mas altas.

• Se relaciona con la arquitectura lógica: describe la organización conceptual de los elementos del diseño en grupos, independientemente de su empaquetamiento ó despliegue físico.


Capas comunes en una arquitectura lógica de un sistema de información

• Presentación: Ventanas de la GUI, informes, interfaz de voz, HTML, XML, XSLT, JSP, JavaScript, …

• Aplicación: Gestiona las peticiones de la capa de presentación. Maneja el flujo de trabajo y mantiene el estado de la sesión. Convierte transacciones a ventanas ó páginas. Concentra y transforma diferentes datos para presentación.

• Dominio: Gestiona las solicitudes de la capa de aplicación. Implementa las reglas y servicios del dominio.

• Infraestructura del negocio: Servicios de bajo nivel, muy generales, que se utilizan en muchos dominios de aplicación.

• Servicios técnicos: De relativamente alto nivel y frameworks: Persistencia, Seguridad, …

• Base: De bajo nivel, utilidades, etc. Ejemplo: estructuras de datos, hilos de ejecución, librerías de funciones, archivos, bases de datos y entrada / salida de redes.


Problemas de la arquitectura en capas• Los cambios del código fuente se propagan a lo largo de todo el

sistema, porque muchas partes del mismo están fuertemente acopladas.

• La lógica de la aplicación se entrelaza con la interfaz de usuario, y entonces no puede reutilizarse con otra interfaz diferente, ni distribuirse a otro modo de proceso.

• La lógica específica de la aplicación se entrelaza con los servicios técnicos ó la lógica del negocio, por lo que no puede reutilizarse, distribuirse a otro nodo ó reemplazarse fácilmente con una implementación diferente.

• Existe alto acoplamiento entre diferentes áreas de interés, por lo que es difícil dividir el trabajo para distintos desarrolladores mediante límites claros.

• Debido al alto acoplamiento y a la mezcla de intereses, es difícil que la funcionalidad evolucione, que el sistema crezca de forma proporcionada ó que se actualice para emplear nuevas tecnologías.


Principio de separación Modelo - Vista

Motivado por:• Dar soporte a definiciones de modelos cohesivos que se centren

en los proceso del dominio, en lugar de preocuparse de las interfaces de usuario.

• Permitir la separación del desarrollo de las capas del modelo y la interfaz de usuario.

• Minimizar el impacto de los cambios de los requisitos de la interfaz sobre la capa del dominio.

• Permitir que se conecten fácilmente otras vistas a una capa de dominio existente sin afectar a la misma.

• Permitir múltiples vistas simultáneas sobre el mismo modelo de dominio.

• Permitir la ejecución de la capa del modelo de manera independiente de la interfaz del usuario.

• Permitir trasladar fácilmente la capa del modelo a otro framework de interfaz de usuario.


Arquitectura basada en modelado (MDA)

• Constituye un estándar para un paradigma.• Define una arquitectura común para que las

diferentes herramientas de modelado y construcción de código puedan interoperar de manera más sencilla: – La arquitectura está basada en diferentes

niveles de abstracción de la tecnología. • El paradigma y estándar MDA es público y controlado

por la organización OMG. • Tiene varios subestándares como los Activos de

Software reutilizable (Reusable Software Assets – RAS), que facilita el intercambio de activos reutilizables: patrones, transformaciones, documentación, etc.

http://www.omg.org/docs/ad/03-10-12.pdf



Reglas generales de estilo para escribir código reutilizable

• Construir métodos cohesivos. Un método es cohesivo si realiza una única función o varias íntimamente relacionadas. En caso contrario hay que dividirlo.

• Métodos pequeños. Un método es grande si sobrepasa una o dos páginas, en cuyo caso habrá que dividirlo, con lo que además de hacerlo más sencillo puede que uno de los trozos sea reutilizable.

• Mantener la congruencia de los métodos. Un método se dice que es congruente si tiene un nombre similar a métodos similares, condiciones, orden de argumentos, valor proporcionado y condiciones de error.


Reglas … (2)

• Separar la política de la implementación. Los métodos de política son los de alto nivel y toman decisiones de control. Son dependientes de la aplicación, se entienden y se escriben fácilmente. Son los módulos que deben comprobar el estado y los errores. Los métodos de implementación son los que hacen el “trabajo sucio”, es decir, son los que tienen definidos los algoritmos; pero no son los que toman la decisión de ejecutar o no esos algoritmos. Si encuentran un error durante la ejecución deben dar un informe a los módulos superiores, pero no deben tomar acciones por su cuenta, como son métodos autocontenidos son fácilmente reutilizables.

• Proporcionar una cobertura uniforme. Consiste en redactar métodos que sean capaces de tratar todas las combinaciones de las posibles entradas que se puedan dar, y no sólo las actuales.


Reglas … (3)

• Generalizar los métodos. Es similar al punto anterior pero en referencia al modo de funcionamiento y al contexto. Cuando los valores estén vacíos o sean extremos o estén un poco más allá del límite.

• Evitar el acoplamiento. Por ejemplo, el que se da cuando se accede a objetos globales y hay que tener conocimiento de los mismos para poder utilizarlos.

• Evitar los modos. Una operación con modos tiene una forma de funcionamiento según el modo en el que esté. Lo aconsejable es tener un método distinto para cada modo.


Otras formas de reutilización

• Otra forma de reutilizar es escribir código de forma que se pueda heredar. Las reglas de estilo en este sentido son:

Métodos comunes: Se pone el código común en un método al que invocan los diferentes métodos. Si ese código común está en varias clases, se pone en un método de una clase antecesora.

• Factorización. Cuando tenemos dos métodos muy parecidos de clases diferentes se puede utilizar otra aproximación: El código común se pone en un método distinto de una clase antecesora, y es ese método el que, en función de la clase en la que estemos, llama a un método u otro. Es corriente utilizar la factorización con clases abstractas.


Otras … (2)

• Delegación. Si se tiene que ejecutar un método en una clase A que ya está implementado en la clase B, heredar de B sólo para poder utilizar su método es un error, en vez de eso se delega enviando la operación a B desde A.

• Código externo encapsulado. Si se utiliza código de otra aplicación con una interfaz diferente, en vez de hacer llamadas directas a ese código es mejor hacer un método o una clase que se encargue de ello. De esta forma, si hay que hacer modificaciones, estas estarán más localizadas.


Extensibilidad • Consiste en añadir nuevas funcionalidades al código. • Normas a seguir para facilitarla:• Encapsular las clases. Esto significa que sólo una clase

puede acceder a sus propios datos e implementación. • Ocultar las estructuras de datos. El motivo es que las

estructuras de datos son propias de los algoritmos. Si se hacen públicas, será más difícil cambiar el algoritmo más adelante.

• Ley de Demeter : Evitar recorrer múltiples enlaces o métodos. Si a través de las asociaciones un método llega a una clase vecina, no deben utilizarse los enlaces de ésta para acceder a una tercera clase, más bien debería utilizar un método de su clase vecina para esta operación. De esta forma, no es necesario que el método tenga conocimiento de todas las asociaciones del modelo, sólo de las clases relacionadas con la propia.


Extensibilidad (2)

• Evitar sentencias “case” basadas en el tipo de objeto. En su lugar se pueden utilizar métodos. Sólo se deben usar dichas sentencias si van a tener en cuenta los atributos de cada objeto.

• Distinguir los métodos públicos de los privados. Se debe minimizar el número de métodos públicos para disminuir la complejidad de la interfaz y porque, si se modifican, esto afectará a las clases que los utilicen. Por eso, deben ser diseñados con más cuidado. Los métodos privados añaden modularidad, dependen de la implementación de la clase, y pueden modificarse sin que dichos cambios causen efectos secundarios fuera de la clase.


Robustez

• Un método es robusto si no falla incluso ante parámetros incorrectos.

• Algunas directrices para construir programas robustos son: • Protección contra errores. Debe tenerse en cuenta que el

usuario puede producir entradas incorrectas. El sistema debería dar un mensaje de error y no “colgarse”. El sistema operativo, el hardware u otra librería pueden contener errores también, para lo cual se deben instalar comprobaciones internas. Las comprobaciones de errores aumentan el tamaño y la lentitud del código. Las relativas al usuario deberían estar siempre, las demás pueden eliminarse en la versión final que se entregue.


Robustez (2)

• Optimizar después de que funcione el programa. • Evitar los límites predefinidos. Es decir, utilizar memoria

dinámica en vez de estructuras de datos de tamaño fijo. Esto brinda mayor flexibilidad (y algún que otro error).

• Disponer el programa para la depuración y la monitorización del rendimiento. En función de las facilidades suministradas por la herramienta de programación, tendremos que añadir sentencias de depuración, que se ejecutan en función de una variable que indique el nivel de depuración. También es posible añadir código que recoja estadísticas sobre por ejemplo el número de invocaciones a una función.


Grandes sistemas • Al trabajar en grupo hay que pensar que son otras personas las

que van a utilizar, depurar, modificar o mantener el código. • Las directrices que se indican a continuación son aplicables

también para un proyecto unipersonal: • No empezar a programar de forma prematura. Es decir, antes

de empezar el proceso de implementación hay otras cosas como la especificación o el diseño.

• Crear métodos comprensibles. Un método es comprensible si terceras personas pueden entender lo que hace.

• Hacer que los métodos sean legibles. Esto significa: – Que los nombres de las variables sean significativos (mejor

no utilizar abreviaturas). – Evitar un nivel de anidamiento excesivo. – No utilizar una misma variable temporal para diferentes

propósitos en lugares diferentes. – Comprobar la ortografía de los nombres.


Grandes sistemas (2)• Utilizar los mismos nombres que en el modelo de objetos.• Seleccionar cuidadosamente los nombres. Deben ser

descriptivos y no ambiguos para no confundir. No se debe asignar nombres iguales a métodos semánticamente distintos. Para los métodos se puede tomar como procedimiento de asignación de nombres el formato nombre_objeto, por ejemplo, borrar_pantalla. Dos clases que tengan métodos con el mismo nombre deberían tener un mismo ancestro y los métodos la misma signatura, es decir, el mismo número y tipo de parámetros.

• Utilizar normas comunes de programación. Se referencia a cosas tales como la indentación de párrafos, forma de hacer los comentarios, poner todos los nombres en minúsculas, etc.

• Documentar las clases y métodos. Deben existir comentarios en la cabecera de cada clase o método para explicar su cometido, precondiciones y postcondiciones. Así mismo debe haber aclaraciones dentro de cada método acerca de los pasos seguidos en los algoritmos.


Referencias

• Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004

• Evitts,P. “A UML Pattern Language” (archivo en PDF: [157870118x]uml pattern language.pdf)

• Real Frameworks for a Service-Oriented World• Applying Robustness Analysis on the

Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML

• Pragmatic Design• Comparison of EAI Frameworks• Aplicación paso a paso con Struts• OMG Membership Approves Adoption of

Reusable Software Assets (RAS) Standard

http://msdn2.microsoft.com/en-us/library/bb286670.aspx









http://www.codeproject.com/aspnet/ModelViewController.asp


















http://www.theserverside.com/tt/articles/article.tss?l=PragmaticDesign



http://www.jot.fm/issues/issue_2005_05/article1





http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=webstruts

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=webstruts

http://xml.coverpages.org/ni2004-05-07-a.html









Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 5. Aspectos avanzados de...

Documents

Transcript of Dr. Juan José Aranda Aboy Aspectos Avanzados de la Tecnología de Objetos 5. Aspectos avanzados de...