domingo, 23 de noviembre de 2014

4.1 ESTRATEGIA DE DISEÑO



El modelo de diseño es un refinamiento y formalización adicional del modelo del análisis, donde se toman en cuenta las consecuencias del ambiente de implementación. El resultado del modelo de diseño son especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo de diseño se basa en el diseño por responsabilidades. 


* Se requiere un modelo de diseño ya que el modelo de análisis no es lo suficiente formal para alcanzar el código fuente. Por tal motivo se refinan los objetos, incluyendo las operaciones y atributos. Además se debe considerar aspectos como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de programación, manejo de base de datos, etc. 

* Otro objetivo del diseño es validar los resultados de los modelos de requisitos y análisis. Durante el diseño, se ve si los resultados anteriores son apropiados para la implementación. Si se descubren aspectos que no están claros en algunos de los modelos anteriores, estos se aclaran, posiblemente regresando a etapas anteriores. 


En general, los cambios en la arquitectura del sistema para mejorar su rendimiento deben proponerse hasta que el sistema este (parcialmente). Construido. 
Se considera dos aspectos principales del modelo de diseño. 

* Diseño del objeto. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se describe cómo interactúan los objetos en cada caso de uso específico, especificando que debe hacer cada operación en cada objeto. Este paso genera las interfaces de los objetos, las cuales después deben implementarse mediante métodos. 


DISEÑO DE SISTEMA


El modelo se adapta al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben tomarse las decisiones de implementación estratégicas: como se incorporara una BD en el sistema: que y como se usaran las bibliotecas de componentes: que lenguajes de programación se utilizaran: como se manejaran los procesos incluyendo comunicación y requisitos de rendimiento: como se diseñaran el manejo de excepciones y recolección de basura, etc.
De manera homogénea entre los objetos permite que cada objeto sepa menos cosas. Esto produce objetos más pequeños y más fáciles de comprender. La desventaja es que la inteligencia del sistema va de la mano con la especialización de las clases. Si todas las clases son inteligentes, esto significara que estas serán muy especializadas dificultando la extensibilidad del sistema que requiere generalizar más las clases. 
El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogeneizar la inteligencia del sistema solo entre ciertas clases, como las de control. El resto de las clases, entidad y borde, serán tontas, generalmente sobreviviendo a modificaciones en el sistema y manteniendo la lógica introducida durante el modelo de requisitos y el modelo de análisis posterior para lograr una mayor robustez del sistema. 

La robustez de un sistema debe ser uno de los objetivos principales del diseño. El sistema debe estar protegido contra errores y ofrecer diagnósticos que permitan identificar fallas, en particular aquellas que son fatales. Durante el desarrollo, a veces es bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego se eliminen durante la producción. En general, se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son las siguientes: 
El sistema debe estar protegido contra parámetros incorrectos proporcionados por el usuario. Cualquier método que acepte parámetros del usuario debe validar la entrada para evitar problemas. El diseñador de métodos debe considerar dos tipos de condiciones de error: i) errores lógicos que se identifican durante el análisis y ii) errores de implementación, incluyendo errores del sistema operativo, como los errores de asignación de memoria, o errores de archivos de entrada y salida. 


El sistema no debe optimizarse hasta que este funcione de manera correcta. se debe estudiar las alternativas, como aspectos de memoria, velocidad y simplicidad de implementación. No se debe optimizar más de lo necesario, ya que la optimización compromete la extensibilidad, reusó y comprensión del sistema. 
* El sistema debe incluir estructuras de datos de tamaño variable, sin límites predefinidos. Durante el diseño es difícil predecir la capacidad máxima esperada para la estructura de datos en la aplicación. Por tanto, se deben escoger estructuras de datos como las listas, a diferencia de los arreglos. 
* El sistema debe instrumentar un monitoreo de rendimiento y búsqueda de errores. El esfuerzo para llevarlo a cabo depende del ambiente de programación. Si el lenguaje de implementación no proporciona ningún apoyo, se añaden métodos de impresión para cada clase. También se añaden mensajes de entrada y salida a los métodos imprimiendo selectivamente estos valores. 
El encapsulamiento es fundamental para la robustez del sistema. Ocultar la información interna, atributos e implementación de métodos de una clase, permite cambiarla sin afectar el resto del sistema. Únicamente la interface de los métodos afecta a las demás clases. 


Reuso:
* El reusó es en aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código será mejor la robustez del sistema las siguientes son algunas estrategias para mejorar las posibilidades del reusó de los diseño.
 
* A través de la herencia se incrementa el reuso del código. Se toman las aspectos comunes a clases similares utilizando superficies comunes. Este en enfoque es efectivo cuando las diferencias entre las clases son pequeñas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar que no se llegue a extremos donde la aplicación de la herencia sea inadecuada.
 
* El uso impropio de la herencia hace que los programas sean difíciles de mantener y extender. Como alternativa, la delegación provee un mecanismo para el reusó de código, pero sin utilizar la herencia. Esto se basa en el uso de agregación a través de clases intermediarias que ocultan la funcionalidad de las clases a las cuales se delega.

 
Extensibilidad:

* Se debe encapsular otra vez la clases, ocultando su estructura internas a las otras clases. Sólo los métodos de la clase deben accesar a sus atributos. 
* No se deben exportar estructuras de datos desde un método. Las estructuras de datos internas son específicas para el algoritmo del método. Si se exportan las estructuras se limita la flexibilidad para cambiar el algoritmo más adelante. 
* Una clase particular debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento abarcará únicamente las asociaciones entre ésta y sus clases vecinas directas. Cualquier interacción con un vecino indirecto, se deberá hacer mediante llamadas a los vecinos directos 

4.2 DISEÑO ORIENTADO A OBJETOS



•    Consiste en representar un modelo de datos que pueda ser fácilmente implantable con algún lenguaje de programación orientado a objetos.
•    Los objetos son componentes potencialmente reutilizables, lo que hace que el software sea más fácil de mantener.
•    El proceso general para el diseño orientado a objetos tiene varias etapas:
1.    Comprender y definir el contexto y los modos de utilización del sistema.
2.    Diseñar la arquitectura del sistema.
Identificar los objetos principales en el sistema
4.    Desarrollar los modelos de diseño.
5.    Especificar las interfaces de los objetos.
No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones.
El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos:
El contexto del sistema: es un modelo estático que describe a los otros sistemas en ese entorno.
El modelo que el sistema utiliza: es un modelo dinámico que describe cómo interactúa el sistema con su entorno.
Con el diseño de contexto se puede crear fácilmente el diseño arquitectónico de la aplicación. 
Existen diversas técnicas para identificar objetos:
•    Utilizar un análisis gramatical de la descripción en lenguaje natural de un sistema. 
•    Utilizar entidades tangibles (cosas). 
•    Utilizar un enfoque de comportamiento.
•    Utilizar un análisis basado en escenarios.





   Existen dos tipos de modelos de diseño para describir un diseño orientado a objetos:
•    Modelos Estáticos. 
•    Modelos Dinámicos. 
•    Ejemplos de algunos modelos:
•    Los modelos de subsistemas
•    Los modelos de secuencia
•    Los modelos de máquinas de estado
•    La encapsulación de las clases hace que los sistemas evolucionen de forma rápida y sencilla. 

4.3 Diseño del Sistema




Sin duda, realizar de manera adecuada cada una de las actividades que conlleva la Ingeniería del Software es indispensable para la realización de un proyecto software de calidad. Por lo tanto, no se puede decir que ninguna de estas actividades sea más importante que otra. Sin embargo, si podemos decir que la actividad de diseño es la más delicada y la más laboriosa de llevar a cabo.
Es delicada porque si no se lleva a cabo correctamente se hace imposible el codificar, de manera correcta, en la actividad de implementación el modelo obtenido en el análisis del sistema, lo que puede repercutir en el desperdicio de todo el esfuerzo realizado durante las primeras actividades de la Ingeniería del Software.
Y es laboriosa porque las estrategias a seguir para conseguir que esta traducción entre modelo y código se lleve a cabo correctamente son muy diversas y bastante complejas.
Se puede decir, por tanto, que el diseño del sistema es la actividad de la Ingeniería del Software en la que se identifican los objetivos finales del sistema y se plantean las diversas estrategias para alcanzarlos en la actividad de implementación.

Sin embargo, el sistema no se suele diseñar de una sola vez sino que hay que diferenciar entre el diseño y estructura de los datos que se van a manejar y el diseño de la interfaz entre la aplicación y el usuario. Estas dos fases del diseño no se realizan de forma consecutiva una detras de la otra sino que lo normal es realizarlas de manera concurrente y finalizarlas a la vez.

4.3.1 Diseño de los datos


La intención de esta fase del diseño software es determinar la estructura que poseen cada uno de los elementos de información del sistema, es decir, la estructura de los datos sobre los que va a trabajar. Estos elementos son:
- Las películas, de las que conocemos su nombre, su ano de producción, su fecha de estreno, el/los géneros a los que se adscribe y la URL de su entrada en IMDB.


- Los usuarios, de los que conocemos su edad, si es hombre o mujer, a que se dedica y su código postal además de su identificador del sistema y el número de películas que ha puntuado.
- Las puntuaciones, de las que conocemos el usuario que las hace, las películas que las reciben y, obviamente, el valor numérico de las mismas.
- Las películas alquiladas por los usuarios pero todavía no puntuadas.
Una vez determinados cuales son los elementos de información del sistema, se deben obtener sus representaciones en forma de tablas de una base de datos. Para ello, se debe realizar primeramente un diseño conceptual de la base de datos para, posteriormente, obtener las tablas requeridas. Para realizar este diseño conceptual se utilizara el modelo Entidad-Relación.


Modelo Entidad-Relación

El modelo Entidad-Relación (también conocido por sus iniciales: E-R) es una técnica de modelado de datos que utiliza diagramas entidad-relación. No es la única técnica de modelado pero si es la más extendida y utilizada.
Un diagrama entidad-relación está compuesto por tres tipos de elementos principales:
- Entidades: objetos (cosas, conceptos o personas) sobre los que se tiene información. Se representan mediante rectángulos etiquetados en su interior con un nombre. Una instancia es cualquier ejemplar concreto de una entidad.
- Relaciones: interdependencias entre uno o más entidades. Se representan
Mediante rombos etiquetados en su interior con un verbo. Si la relación es entre una entidad consigo mismo se denomina reflexiva, si es entre dos entidades se denomina binaria, ternaria si es entre tres y múltiple si es entre más (muy raro).
- Atributos: características propias de una entidad o relación. Se representan mediante elipses etiquetados en su interior con un nombre.

En los diagramas entidad-relación también hay que tener en cuenta otros aspectos como pueden ser:
- Entidades débiles: son aquellas que no se pueden identificar unívocamente solo con sus atributos, es decir, necesitan de estar relacionadas con otras entidades para existir. Se representan con dos rectángulos concéntricos de distinto tamañocon un nombre en el interior del mas pequeño.
- Cardinalidad de las relaciones: existen tres tipos de cardinalidades de una relaciónsegún el número de instancias de cada entidad que involucren:
- Uno a uno: una instancia de la entidad A se relaciona solamente con unainstancia de la entidad B. (1:1)
- Uno a muchos: cada instancia de la entidad A se relaciona con varias de laentidad B. (1:*)
- Muchos a muchos: cualquier instancia de la entidad A se relaciona concualquier instancia de la entidad B. (*:*)
- Claves: cada entidad de un diagrama entidad-relación debe tener una clave, debeestar formada por uno o más de sus atributos.
Una vez conocidos los elementos que forman parte de un diagrama entidad-relación podemos empezar a desarrollar el modelo entidad-relación. Los pasos a seguir son los siguientes:
1. Convertir el enunciado del problema (o, como es nuestro caso, los elementos delsistema software) en un Esquema Conceptual del mismo.
2. Convertir este Esquema Conceptual (o EC) en uno más refinado conocido como
Esquema Conceptual Modificado (ECM).
3. Obtener las tablas de la base de datos a partir del Esquema Conceptual
Modificado.




4.4.- REVICION DE DISEÑO


Durante la revisión del diseño, se comprobará que se trabaja según los requisitos iniciales y cumpliendo las normas y estándares que hayan sido programados con respecto a:
• Gestión de contraseñas.
• Gestión de perfiles de usuario de la aplicación.
• Registro de accesos.
• Funcionalidad definida para los distintos módulos de trabajo.

Para verificar el diseño y con ello comprobar su correcto funcionamiento, se efectuará el plan de pruebas. Este consistirá en sucesivas entradas de datos en diferentes situaciones, es decir, tanto situaciones rutinarias con operaciones comunes como acciones más complejas.
De su resultado se verificará el diseño del software o, por el contrario, en caso deser necesario se integrarán nuevos componentes y nuevas funcionalidades paraqueel software tenga el rendimiento esperado.
Para un mejor control de las aplicaciones y siempre buscando la mejora continua deesta fase, se empleará el Documento de Cambios donde se recogerá información delas distintas tipologías de las modificaciones a efectuar para que sirva deretroalimentación para futuros cambios.

Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad

Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el código. ¡Error¡ La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software  La SQA (Software QualityAssurance) engloba:
•          Un enfoque de gestión de calidad
•          Tecnología de Ingeniería de Software efectiva (métodos y herramientas)
•          Revisiones técnicas formales que se aplican durante el proceso del software
•          Una estrategia de prueba multiescalada
•          Un control de la documentación del software y de los cambios realizados
•          Un procedimiento que asegure un ajuste a los estándares de desarrollo de software
•          Mecanismos de medición y de generación de informes
El control de la calidad es una serie de revisiones, y pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.







4.5.- DIAGRAMAS DE SECUENCIA DE DISEÑO


El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequencediagram", "event-trace diagrams", "eventscenarios" o "timing diagrams".


Utilidad:
Un diagrama de casos de uso muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes
Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas
De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
·         Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

ESTRUCTURA
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

4.6 HERRAMIENTAS CASE PARA EL DISEÑO DEL SOFTWARE



Las computadoras afectan nuestras vidas nos guste o no. Utilizamos computadoras en nuestra vida diaria, la mayor parte del tiempo sin reconocer conscientemente que estamos haciéndolo.  Las utilizamos en aplicaciones domésticas como microondas, televisión, vídeo casseteras o fuera de nuestras casas en máquinas para tarjetas de crédito, por ejemplo. La verdad es que no podemos escapar de las computadoras. El rápido incremento en performance de las computadoras junto al dramático decremento en tamaño y costo, dio como resultado una explosión de tecnología, generándose una larga variedad de aplicaciones que éstas pueden soportar. Desde el inicio de la escritura de software, ha existido un conocimiento de la necesidad de herramientas automatizadas para ayudar al diseñador del software. Inicialmente, la concentración estaba en herramientas de apoyo a programas como traductores, recopiladores, ensambladores, procesadores de macros, y montadores y cargadores. Este conjunto de aplicaciones que pueden informatizarse, aumentó dramáticamente en un breve espacio de tiempo, causando una gran demanda por nuevo software a desarrollar.  A medida que se escribía nuevo software, habían ya en existencia millones y millones de líneas de código que necesitaban se mantenidas y actualizadas.


¿QUE SON LAS HERRAMIENTAS?

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar, Análisis, Diseño, Implementación e Instalación. CASE se define también como:

Conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas. Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. Se puede ver al
CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales.

La realización de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software.
La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compañías pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. También permite a las compañías competir más efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales.  En un mercado altamente competitivo, esto puede hacer la diferencia entre el éxito y el fracaso. Las herramientas CASE también permiten a los analistas tener más tiempo para el análisis y diseño y minimizar el tiempo para codificar y probar. La introducción de CASE integradas está comenzando a tener un impacto significativo en los negocios y sistemas de información de las organizaciones.
Con un CASE integrado, las organizaciones pueden desarrollar rápidamente sistemas de mejor calidad para soportar procesos críticos del negocio y asistir en el desarrollo y promoción intensiva de la información de productos y servicios. Estas herramientas pueden proveer muchos beneficios en todas las etapas del proceso de  desarrollo de software, algunas de ellas son:

♦ Verificar el uso de todos los elementos en el sistema diseñado.
♦ Automatizar el dibujo de diagramas.
♦ Ayudar en la documentación del sistema.
♦ Ayudar en la creación de relaciones en la Base de Datos.
♦ Generar estructuras de código.

La principal ventaja de la utilización de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organización y una metodología de trabajo, además de la propia herramienta. La mejora de calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis y diseño, inherentes a los proyectos de mediano y gran tamaño (lógica del diseño, coherencia, consolidación, etc.). La mejora de productividad se consigue a través de la automatización de determinadas tareas, como la generación de código y la reutilización de objetos o módulos.

CLASIFICACION DE LAS HERRAMIENTAS CASE

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:
• Las plataformas que soportan.
• Las fases del ciclo de vida del desarrollo de sistemas que cubren.
• La arquitectura de las aplicaciones que producen.

• Su funcionalidad. Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar