UNIDAD 5 Modelo de Implementación

 5.1 Diagrama de componentes

Los diagramas de componentes describen la descomposición  físicos de los elementos de un sistema (modulo, base de datos, programa ejecutable, etc.) y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable, pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente, etc.

Elementos

›  Normalmente los DC contienen los siguientes elementos:

›  Componentes

›  Interfaces

›  Relaciones de dependencia, generalización, asociación y realización.

›  Paquetes o subsistemas.

 Relaciones de dependencia de los DC.

›  Se pueden agrupar en paquetes así como los objetos de clases, además pueden tener entre ellos relaciones,  tales como:

›            Generalización

›            Asociación

›            Agregación

›             Realización

  Dependencia 

Estereotipos de los componentes.

UML define cinco estereotipos estándar que se aplican a los componentes:

•          Executable: Especifica un componente que se puede ejecutar en un nodo.

•          Library: Especifica una biblioteca de objetos estática o dinámica.

•          Table: Especifica un componente que representa una tabla de una base de datos.

•          File: Especifica un componente que representa un documento que contiene código fuente o datos.

•          Document: Especifica un componente que representa un documento.

Dependencias entre componentes.

Se utilizan en los DC para indicar que un componente se refiere a los servicios ofrecidos por otro componente.

Subsistemas:

•          Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación.

•          Son paquetes estereotipados en <<subsistemas>>.

Funcionalidad de los subsistemas.

•          Los subsistemas organizan la vista de realización de un sistema.

•          Cada subsistema puede contener componentes y otros subsistemas.

•          La descomposición en subsistemas no es necesariamente una descomposición funcional.

•          La relación entre paquetes y clases en el nivel lógico es el  que existe entre subsistemas y componentes en el nivel físico.

•          Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico.

Pasos para elaborar un diagrama de componentes:

1.                  Previamente al diagrama de componentes debemos de tener hecho el diagrama de clases.

2.                 Se debe identificar a todos las clases que participaran en el sistema o subsistema a desarrollar.

3.                 Una vez identificado las clases, se procede a identificar sus métodos.

4.                 Estos métodos pasaran a ser módulos con líneas de código independientes.

5.                  Estos módulos serán los componentes de nuestro diagrama.

6.                 Estos componentes se relacionan entre si por medio de sus interfaces.

5.2 Diagrama de despliegue

          

Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardwarey softwareen el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software(procesos y objetos que se ejecutan en ellos).

    Los diagramas de despliegue representan a los nodos y sus relaciones.

    Los nodos son conectados por asociaciones de comunicación tales como enlaces de red, conexiones TCP/IP, microondas, etc.

Los diagramas de despliegue son los complementos de los diagramas de componentes que unidos, proveen la vista de implementación del sistema.

Características

Describen la arquitectura física del sistema durante la ejecución, en términos de:

–procesadores

–dispositivos

–componentes de software

-Describen la topología del sistema: la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.

Componentes de diagrama de despliegue

 Nodo: son objetos físicos que existen en tiempo de ejecución, y que representan algún tipo de recurso computacional (capacidad de memoria y procesamiento):

            * Instancia de nodo.

            * Estereotipo de nodo.

   Artefactos: es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso Ej: archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario y más.

 Asociación: Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación va incluida con misma dependencia  del diagrama de componentes.

Usos

•          Sistemas cliente-servidor

•          Sistemas completamente distribuidos

5.3 Modelos de prueba

La fase de pruebas del sistema tiene como objetivo verificar el sistema software para comprobar si este cumple sus requisitos.

Dentro de esta fase pueden desarrollarse varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc.

Este trabajo se centra en pruebas funcionales de aplicaciones con interfaces gráficas. Estas pruebas verifican que el sistema software ofrece a los actores humanos la funcionalidad recogida en su especificación.

Una de las técnicas más empleadas para la especificación funcional de sistemas software sonlos casos de uso. Las principales ventajas de los casos de uso son que ocultan los detalles internos del sistema, son rápidos de construir, fáciles de modificar y entender por los clientes y futuros usuarios del sistema  y pueden aplicarse a distintos tipos de sistemas  y.

Actualmente, existe un amplio número de propuestas que describen cómo generar pruebas del sistema a partir de los casos de uso. Aunque la generación de pruebas se adapta a la filosofía propuesta por MDA.

Este trabajo se centra en la definición de un conjunto de modelos que den soporte al proceso de generación de pruebas del sistema desde una perspectiva MDA.

Las pruebas deben de hacerse en todas las fases del desarrollo.

Tipos de Pruebas:

·                     ›  Pruebas de Aceptación à Casos de Uso 

·                     Pruebas de Integración/Sistema à Diagramas de Secuencia/Escenarios 

·                     Pruebas Unitarias à Clases/Módulos 

·                     Pruebas de Regresión

·                      Pruebas de Facilidad de Uso 

·                     Pruebas de Cobertura 

·                     Pruebas de Rendimiento (profile)                                                                                                                                                                    

                                                                                                                                                                                                                                         

Formato Plan de Pruebas

ID: 1	Nombre: Enviar artículo
Probado por: Fulanito
Descripción: Se introducen los datos del artículo y de los autores.
Condiciones de Entrada: nombreArticulo=“Calidad del Sw” … emailAutor=“olivar@itmorelia.edu.mx”
Resultado Esperado: El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.
Resultado Obtenido: Se generan bien userid y password pero el correo no llegó.
Criterio de Aceptación: No.

UNIDAD 4 MODELOS DE DISEÑO

4.1 ESTRATEGIAS DE DISEÑO

El diseño se define como la búsqueda de una solución en cualquier campo, sin embargo las soluciones no llegan de una manera simple, muchas veces realizamos soluciones complejas a problemas sencillos o en otras ocasiones una gran solución conlleva a otro problema.

La cuestión está en cómo abordamos esos retos de diseño. Estudios demuestran que nos enfocamos en resolver los problemas de manera individual alejándonos cada vez más del sistema completo en el que estamos trabajando, “es como diseñar una ventana sin el edificio”, recuerden todo tiene un impacto y en un sistema todo está relacionado.

Así que por otro lado que tal si vemos todo el sistema y así planeamos mejor nuestro diseño, haciendo que las soluciones de una parte no perjudiquen a la otra, o mejor que se complementen entre si. Esto nos ayudara a ver qué lugar social, ambiental y técnico nuestro producto hace parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que resuelvan varios problemas, colaboración a través de diferentes disciplinas, establecer parámetros base, definir la vida útil, iniciar desde cero los diseños, usar datos medibles y no asumir reglas entre otros.

En las siguientes imágenes podemos ver un sencillo pero útil flujo de trabajo para iniciar nuestros diseños o la mejora de ellos

Diseñar es una tarea que involucra muchos aspectos, diseñar es divertido así que si utilizamos las herramientas adecuadas podremos crear productos de una mejor calidad!

Antes de poder resolver el diseño es necesario tomar decisiones generales sobre las estrategias de diseño a seguir. Algunas de las decisiones a tomar se presentan a continuación y se relacionan con aspectos que incluyen la arquitectura, robustez, reúso y extensibilidad del sistema. 

ARQUITECTURA 

El término arquitectura se refiere, en nuestro caso, a la organización de las clases dentro del sistema. Durante el modelo de análisis se generó una arquitectura de clases para el sistema y se definió la funcionalidad “conceptual” ofrecida por las distintas clases dentro de la arquitectura. Durante el diseño esta arquitectura debe detallarse, pudiéndose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada clase, e incluso las propias clases, como hemos mencionado al inicio del capítulo.

El conocimiento y funcionalidad asignada a cada clase puede ser vista como la “inteligencia” de cada clase dentro del sistema. En otras palabras, algunas clases pueden ser vistas como más inteligentes que otras según el conocimiento y control que tengan sobre las demás clases. 

ROBUSTEZ 

La robustez de un sistema debe ser uno de los objetivos principales del diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego sean removidas durante la producción. En general se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones 

REÚSO 

El reúso es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reúso del diseño:

A través de la herencia se puede incrementar el reúso de código. Se toman los aspectos comunes a clases similares utilizando.

4.2 DISEÑO DE OBJETOS

¿Qué es el diseño? Es el proceso previo de configuración mental en la búsqueda de una solución en cualquier área.

Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecución, la memoria y el costo. 

En particular, las operaciones identificadas durante el análisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas.

Las clases, atributos y asociaciones del análisis deben de implementarse en forma de estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos. 

La optimización del diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la extensibilidad son también objetivos importantes. La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque. 

La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.

4.3 DISEÑO DE SISTEMAS

Se adapta el modelo al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben ser tomadas las decisiones de implementación estratégicas: 

·                      cómo se incorporará una base de datos en el sistema, 

·                      qué bibliotecas de componentes se usarán y cómo, 

·                      qué lenguajes de programación se utilizarán, 

·                      cómo se manejarán los procesos, incluyendo comunicación y requisitos de rendimiento, 

Durante el diseño se debe decidir cómo mecanismos abstractos como la asociación, serán implementados. Similarmente, si el lenguaje de programación no ofrece ninguna técnica para apoyar herencia, se debe especificar cómo ésta será implementada.

Durante el diseño de sistema se toman consideraciones en base al ambiente de implementación teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al código final. Estos objetos deben ser vistos como abstracciones del código a ser escrito donde, por ejemplo, un típico objeto sería representado por un archivo en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno correspondiente a la interface del objeto y el otro a su implementación. En general, el diseño de sistema incluye diversos aspectos como:

·                      Selección del lenguajes de programación a utilizarse, típicamente estructurados u orientados a objetos;

·                       Incorporación de una base de datos, típicamente relacionales, relacionales extendidos u orientados a objetos; 

·                      Acceso a archivos, en sus diferentes formatos; 

Estos aspectos pueden variar radicalmente entre uno y otro sistema y también pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema: 

Agregando clases abstractas o interfaces que luego serán especializadas según el ambiente de implementación particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programación, como en el caso de Java, es común a los diversos ambientes. 

Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementación particular. Esto puede significar una integración parcial o completa de componentes adicionales a la arquitectura del sistema. Por ejemplo, una integración con las interfaces nativas de Java (JNI) para manejo de aspectos de bajo nivel del ambiente.

Configurando múltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque más flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programación incluyendo diseños para lenguajes estructurados. 

INTERFACES GRÁFICAS 

Las interfaces gráficas tienen como aspecto esencial que toda interacción con el usuario es a través de elementos gráficos, como lo son los botones, menús y textos. En lo que se refiere a la aplicación, todo sistema que interactúe mediante interfaces gráficas está dirigido por eventos. Estos eventos corresponden al movimiento del ratón, el oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa.
El desarrollar un sistema dirigido por eventos significa que la aplicación debe desde un inicio considerar un diseño adecuado. 

BASES DE DATOS 

El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de información. La decisión estratégica más importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilización y la situación actual en el mercado, escogeremos para nuestro desarrollo una base de datos relacional utilizando el lenguaje SQL estándar. Simplificaremos al máximo el diseño de la base de datos para minimizar su efecto sobre el sistema completo. Más bien, demostraremos cómo es posible diseñar buenas clases que permitan en un futuro cambiar de manejadores de bases de datos.

4.4.- REVISIÓN DEL DISEÑO

Cuando el diseño se completa se mantienen reuniones con los clientes para revisarlo antes de avanzar al desarrollo.

El proceso de revisión se realiza en tres etapas en correspondencia con los pasos del proceso de diseño:

1.      Revisión del diseño preliminar.

2.      Revisión crítica del diseño.

3.      Revisión del diseño de programas.

Revisión del diseño preliminar

Los clientes y usuarios se reúnen para validar el diseño conceptual. Se asegura que todos los aspectos relativos a los requerimientos han sido apropiadamente contemplados en el diseño.

Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis.

Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas.

Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.

Revisión crítica del diseño

Realiza una revisión crítica del diseño, donde se presenta una vista general del diseño técnico. Se tratan dos puntos:

·         si el diseño implementa todos los requerimientos y si es un diseño de calidad. Usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño.

·         Si se identifican problemas mayores el diseño se rehace.

Revisión del diseño de programas

Cuando el diseño técnico resulta satisfactorio, los diseñadores de programas estarán en posición de interpretarlo como el conjunto  de descripciones de diseño para los componentes reales, que deben ser codificados y probados.

Después de completar los diseños de programas, pero antes de comenzar la codificación, presentan sus planes. Este proceso se centra en la detección de defectos más que en su corrección. Además se esta evaluando el diseño no a los diseñadores.

El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.

Documentando el diseño

Una parte de la documentación esta dirigida a clientes y usuarios, en lenguaje natural para describir que es lo que el sistema hará.

La segunda parte usa la terminología técnica para escribir la estructura del sistema, datos y funciones.

Pauta de los informes:

1.            Justificación racional del diseño: donde se delinean las cuestiones críticas y compromisos que fueron considerados en la generación del diseño.

2.            Descripción de los componentes del sistema: una de las secciones debería indicar cómo interactúan los usuarios con el sistema incluyendo: 

·         Menús y otros formatos de presentación en pantalla.

·          Interfaces hombre – máquina.

·          Formatos de los informes.

·          Entrada: sobre los datos.

·          Salida: sobre los datos.

·          Características funcionales generales.

·          Exigencias de performance.

·          Procedimientos de archivos.

·         Enfoque del tratamiento de defectos

Por lo general, un conjunto de diagramas o de notaciones formales describe la organización y estructura global del sistema, incluyendo todos los niveles de abstracción.