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.

Representación grafica:

 

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.

Interfaces.

•          Es el lazo de unión entre varios componentes.

•          Las interfaces pueden representarse de varias formas, como vemos en la grafica: 

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.

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

 En este punto se describen un conjunto de modelos de prueba independientes y
dependientes de la plataforma (PITs y PDTs).

Las líneas entre modelos implican las dependencias y las futuras transformaciones. Todos los modelos siguen el Testing Profile de UML 2.0 [15] siempre que ha sido posible. Los modelos de la figura 2 se describen en los siguientes puntos.

4.1 ESTRATEGIAS DE DISEÑO

A través de la historia de la ingeniería de software ha evolucionado un conjunto de conceptos fundamentales de diseño de software. Cada uno ofrece al ingeniero de software un fundamento sobre el cual pueden aplicarse métodos de diseño más elaborados. Los conceptos fundamentales del diseño de software ofrecen el marco de trabajo necesario para hacer las cosas del “modo correcto”.

Estrategias de diseño – Abstracción
Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado deabstracción una solución se establece en términos generales con el lenguaje de entorno del problema. En losgrados de menor abstracción se proporciona una solución más detallada de la solución. Una abstracción procedimental se refiere a una secuencia de instrucciones que tiene una función específica y limitada.

Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos.  Por ejemplo, se puede decir que la abstracción procedimental abrir emplearía la información contenida en los atributos de la abstracción de datos puerta. 

Estrategias de diseño – Arquitectura
La arquitectura del software alude a la estructura general del software y las formas en las que la estructura proporciona una integridad conceptual para un sistema. La arquitectura es la estructura u organización de los componentes del programa (módulos), la manera en que estos componentes interactúan, y la estructura de datos que utilizan los componentes. 

Estrategias de diseño – Patrones
Un patrón de diseño describe una estructura de diseño que resuelve un problema recurrente de diseño particular dentro de un contexto específico y en medio de fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el patrón. 

Estrategias de diseño – Modularidad
Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el software se divideen componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del problema. La modularidad se basa en la estrategia divide y vencerás (es más fácil resolver un problema complejo cuando éste se divide en piezas más manejables).

Estrategias de diseño – Ocultación de información
El principio de ocultación de información sugiere que los módulos se caracterizan por las decisiones de diseño que cada uno oculta a los otros. Los módulos deben especificarse y diseñarse de manera que la información (procedimientos y datos) que está dentro del módulo sea inaccesible para otros módulos que no necesiten esta información.

 
Estrategias de diseño – Independencia funcional
Es la suma de directa de la modularidad y de los conceptos de abstracción y ocultación de información. Laindependencia funcional se consigue al desarrollar módulos con una función determinante y una aversión a la interacción excesiva con otros módulos. Los módulos independientes son más fáciles de mantener, probar, modificar y se reduce la propagación de errores. 

 
Estrategias de diseño – Refinamiento
El refinamiento es una estrategia de diseño descendente. El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales.  El refinamiento hace que el diseñador trabaje sobre elenunciado original y que proporcione más y más detalles conforme se realiza cada refinamiento sucesivo. Laabstracción y el refinamiento son conceptos complementarios.

 
Estrategias de diseño
La meta del diseño es crear un modelo de software que implemente todos los requisitos del cliente de manera correcta y complazca a aquéllos que lo usen. El proceso de diseño avanza de una visión general del software a una visión más estrecha que define el detalle requerido para implementar un sistema.

El proceso de diseño comienza con un enfoque en la arquitectura. Se definen los subsistemas, se establecen mecanismos de comunicación entre los subsistemas; se identifican los componentes y se realiza una descripción detallada de cada componente. Además, se diseñan las interfaces internas, externas y del usuario.

            

                          BIBLIOGRAFIA :

       

                http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase1.pdf

4.2 DISEÑO DE OBJETOS

Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienenellos mismos su estado local y proveen operaciones sobre su estado. La representación del estado es privada y no se puede acceder a ella directamente desde fuera del objeto. El proceso de diseño de objetos comprende el diseño de clases de objetos y las relaciones entre estas clases. El diseño orientado a objetos comprende el desarrollo de un modelo orientado a objetos de un sistema de software para implementar los requerimientos identificados. 

Los objetos en un diseño orientado a objetos están relacionados con el problema a resolver. Un proceso general para el diseño orientado a objetos puede contener las siguientes etapas:

1.  Comprender y definir el contexto y los modos de utilización del sistema. 
2. Diseñar la arquitectura del sistema. 
3. Identificar los objetos principales del sistema.  
4. Desarrollar los modelos de diseño.  
5. Especificar las interfaces de los objetos.

         Todas estas actividades se pueden ver como actividades entrelazadas que influyen entre sí. Los objetos se identifican y las interfaces se especifican completa o parcialmente en el momento de definir la arquitectura del sistema.

B  BIBLIOGRAFIA:

     http://indalog.ual.es/mtorres/LP/DOO.pdf

Ç

4.3 DISEÑO DEL SISTEMA

Durante el diseño de objetos, se ha desarrollado un diseño detallado con base en la arquitectura especificada. En general, el diseño de sistemas incluye aspectos como los siguientes:

• Selección del lenguaje de programación a utilizarse.
• Incorporación de bibliotecas (para interfaces gráficas, estructuras de datos, etc.) 
• Incorporación de una base de datos. 
• Incorporación de archivos en sus diferentes formatos. 
• Consideraciones de procesamiento,  como concurrencia, paralelismo, distribución y tiempo real.

Estos aspectos pueden variar entre un sistema y otro. Además, pueden afectar de manera importante laarquitectura final del sistema. Existen diferentes enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:

•  Agregar clases abstractas o interfaces que luego se  especializarán según el ambiente de implementación. 
• Instanciar objetos especializados para la administración del ambiente de implementación 
• Configurar múltiples versiones del sistema correspondientes a diferentes plataformas.

 Diseño de sistema - Lenguajes de programación

 
Es importante señalar que un diseño orientado a objetos no necesariamente se tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es más natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a objetos tienen un apoyo directo a los conceptos del análisis orientado a objetos(encapsulamiento, generalización, polimorfismo). Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a objetos a otros existentes en los lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su conveniencia, mantenimiento y protección contra errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y extensión de los programas sea más fácil y segura.

 
Cabe mencionar que no todos los lenguajes de programación orientados a objetos implementan de la misma forma los conceptos de la metodología orientada a objetos.  Aspectos como manejo de encapsulamiento, referencias, herencia múltiple varían de manera importante entre los lenguajes de programación.
 

 Diseño de sistema – Interfaces gráficas
Las interfaces gráficas tienen como objetivo principal administrar la interacción entre el usuario mediante elementos gráficos, como son botones, menús y textos. Las aplicaciones interactivas donde el control del ratón y teclado desempeñan un papel importante se conocen como sistemas controlados o dirigidos por eventos. Estos eventos comprenden: mover el ratón, oprimir uno de sus botones, oprimir una tecla, etc. 

Desarrollar un sistema dirigido por eventos significa que la aplicación desde un inicio debe considerar un diseño adecuado. Por ejemplo, en Java se escoge alguna de las bibliotecas gráficas (AWT o Swing) para utilizar el manejo apropiado de interfaces mediante sus clases (JFrame, Jpanel, JButton). Más allá de estas bibliotecas o clases también se afecta la lógica del diseño, ya que se debe contemplar el momento de procesar eventos. 

Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada evento mediante una clase para cada pantalla. Otra solución es usar un JFrame para todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que los eventos sean recibidos por parte de la clase y las pantallas se vuelven más pasivas y fáciles de manipular.

Diseño de sistema – Bases de datos
Las bases de datos son fundamentales en los sistemas de información. Una decisión estratégica importante en tal contexto es si debe utilizar bases de datos relacionales u orientadas a objetos. 

En general se consideran tres modelos de bases de datos principales:

•Modelo relacional: se define una colección de tablas donde cada una tiene un número específico de columnas y un número arbitrario de filas. Cada objeto se representa como una fila en una tabla y donde cada columna corresponde a un atributo distinto en el objeto.
•Modelo relacional extendido: el modelo relacional se extiende mediante procedimientos, objetos, versiones y otras nuevas capacidades. No hay un solo modelo relacional extendido, más bien hay una variedad de ellos, aunque todos comparten las tablas y consultas básicas del modelo relacional.
•Modelo orientado a objetos: se define un modelo orientado a objetos donde varía el tipo de encapsulamientode datos y los procedimientos en el objeto. El término
orientado a objetos varía según cada autor.   

Las bases de datos son depósitos de datos guardados en uno o más archivos. Existen sistemas de manejo de bases de datos (DBMS) y orientados a objetos (OOBDMS). Las bases de datos dan apoyo en los siguientes aspectos:

•  Múltiples usuarios 
• Múltiples aplicaciones 
• Seguridad 
• Integridad 
• Distribución de datos

La tarea del diseño se simplifica, creando una tabla correspondiente a cada clase entidad del dominio delproblema y manteniendo las asociaciones entre clases. Obviamente el diseño de tablas puede optimizarse para un acceso más eficiente.

 
Diseño de sistema – Archivos
Aunque es más efectivo trabajar con bases de datos, es posible utilizar archivos, sobre todo cuando la especificación del sistema así lo requiera. En el caso de usar una base de datos, regularmente una clase se comunica con el DBMS para hacer solicitudes a cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo que el proceso se hace manualmente.

BIBLIOGRAFIA:

http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase1.pdf

4.4 REVISIÓN DEL DISEÑO

Según la IEEE 610.12, una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

•         Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo

•         Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.

•         Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud  y Completitud principalmente.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos.

Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal  técnico es una forma de revisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, que  llamaremos Inspección de Software.

El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar  que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el  descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno).

BIBLIOGRAFIA:

http://www.scielo.br/pdf/rlae/v15n3/es_v15n3a22.pdf

4.5 DIAGRAMAS DE SECUENCIA DEL DISEÑO

El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Su creación forma parte de la investigación para conocer el sistema; se incluye dentro de la etapa del análisis.

En UML los Diagrama de Secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

• Actividades y dependencias

Los Diagramas de Secuencia de un sistema se preparan durante la fase del análisis. Para su creación, debemos formular antes los Casos de Uso.

• Comportamiento del sistema

Antes de iniciar el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como una “caja negra”. El comportamiento del sistema es una descripción de lo quehace, sin explicar la manera en que lo hace. Una parte de la descripción es un Diagrama de la Secuencia del sistema.

• Diagrama de secuencia del sistema

Los casos de uso indican cómo los actores interactúan con el Sistema de Software. Durante esa interacción un actor genera eventos dirigidos al sistema, solicitando alguna operación a cambio.

Conviene aislar y explicar gráficamente las operaciones que un actor solicita al sistema, porque ello contribuye a entender el comportamiento del sistema.

En UML los Diagramas de Secuencia dan una descripción gráfica de las interacciones del actor y de las operaciones que las mismas originan.

DIAGRAMA DE SECUENCIA => Representación que muestra, en un determinado Caso de Uso, los eventos generados por actores externos, su orden y los eventos internos del sistema.

A todos los sistemas se los trata como una caja negra; los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas.

BIBLIOGRAFIA:

http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2008-2009/Apunts/IS.6.pdf