martes, 21 de mayo de 2013

4.1 ESTRATEGIAS DE DISEÑO


Unidad 4  Modelo de Diseño
  4.1 Estrategias de diseño

 Los principales pasos del proceso de desarrollo son los siguientes:

• Análisis del problema: da como resultado un modelo de objeto y una lista de operaciones.
• Diseño: da como resultado un modelo de objeto de código, un diagrama de dependencia de módulos y especificaciones de módulos.
• Implementación: da como resultado un código ejecutable.

El resultado principal del análisis de un problema es un modelo de objeto que describe las entidades fundamentales del mismo y sus relaciones con otro problema. (El libro de texto del curso utiliza el término "modelo de datos" para referirse a esto). Conviene escribir descripciones breves para cada uno de los conjuntos y cada una de las relaciones del modelo de objeto, explicando lo que significan. Aunque nos parezcan evidentes en el momento de escribirlas, es fácil olvidar más tarde el significado de algún término. Además, muchas veces una descripción que nos parecía clara resulta no serlo tanto cuando la vemos por escrito. Por ejemplo, en mi grupo de trabajo estamos diseñando un nuevo componente de control de tráfico aéreo, y hemos descubierto que en nuestro modelo de objeto el término Flight resulta bastante confuso y que es importante describirlo con claridad.

La fase de diseño produce como resultado principal un modelo de objeto de código que muestra la forma en la que se implementa el estado del sistema, y un diagrama de dependencia de módulos que representa la división del sistema en módulos y el modo en que éstos se relacionan entre sí. En el caso de módulos que presenten complicaciones, resulta también conveniente disponer de un esquema con las especificaciones del módulo antes de comenzar la codificación.
Estas propiedades clave son:

• Extensibilidad. El diseño debe ser capaz de soportar nuevas funciones. Aunque sea perfecto en todos los demás aspectos, un sistema que no muestre disposición a integrar el más ligero cambio o perfeccionamiento resulta inservible. Quizás no haya necesidad de añadir nuevas funciones, pero siempre es posible que se produzcan alteraciones en el dominio del problema que exijan introducir cambios en el programa.
• Fiabilidad. El sistema debe tener un comportamiento fiable, lo que no significa solamente que no se bloquee ni corrompa los datos; debe además realizar todas sus funciones correctamente y de la forma prevista por el usuario. (Lo que, por cierto, quiere decir que tampoco basta con que el sistema satisfaga una especificación confusa; debe satisfacer una que el usuario comprenda fácilmente, de forma que

éste pueda predecir su comportamiento). La disponibilidad es una característica importante si el sistema es distribuido, mientras que en los sistemas en tiempo real tiene más importancia el tiempo: no tanto que el sistema sea rápido, sino que complete las tareas en el tiempo previsto. La forma de contemplar la fiabilidad varía mucho de un sistema a otro. Así, la falta de precisión a la hora de presentar imágenes es menos grave en un navegador que en un programa de edición electrónica. Los conmutadores telefónicos, por su parte, deben cumplir estándares de disponibilidad extraordinariamente altos, si bien ello ocasiona de vez en cuando errores de desvío de llamadas. Los pequeños retrasos quizás no importen mucho cuando se trata de un cliente de correo electrónico, pero son inaceptables en el caso del controlador de un reactor nuclear.

• Eficiencia. El consumo de recursos por parte del sistema debe ser racional, lo que una vez más depende del contexto. Una aplicación que se ejecuta en un teléfono móvil no puede asumir la misma disponibilidad de memoria que la que se ejecuta en un ordenador de consola. Los recursos más específicos son el tiempo y el espacio que consume el programa que se ejecuta. Pero no hay que olvidar que, como ha demostrado Microsoft, el tiempo empleado en el desarrollo del programa puede tener idéntica importancia, al igual que otro recurso que no se debe pasar por alto: el dinero. Un diseño que se implemente de modo económico puede ser preferible a otro que funcione mejor conforme a otros parámetros pero que resulte más caro. 

4.2 DISEÑO DE OBJETOS


4.2 Diseño de 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.
  3. 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 diversas metodologías para la realización de análisis y diseño orientado a objetos como:
      Método de Booch: abarca un microproceso de desarrollo y un macroproceso de desarrollo.
      Método OMT (Rumbaugh)
      Objectory (Jacobson)
      Método de Coad-Yourdon
      Método UML

4.3 DISEÑO DE SISTEMAS


4.3 Diseño de Sistemas
Las fases se suceden en orden estrictamente secuencial
· Nada está hecho hasta que todo este terminado
· Las fallas más triviales se encuentran al comienzo del período de prueba y las
más graves al final
· La eliminación de fallas suele ser extremadamente difícil durante las últimas
etapas de prueba del sistema

Actividades del Análisis
La actividad de Análisis parte de los requerimientos observados durante el proceso de relevamiento y estudio del domino del problema y arroja como resultado lo QUE debe hacer el sistema para brindar una solución al problema del usuario, independientemente de la naturaleza de la tecnología que se use para su implementación.
 El análisis transforma las políticas del usuario y el esquema del proyecto en una especificación estructurada.
La actividad de Diseño se dedica a asignar porciones de la especificación estructurada resultante del proceso de análisis (también conocida como modelo esencial) a procesadores adecuados (sean máquinas o humanos), y a labores apropiadas (tareas, particiones, etc.) dentro de cada procesador. Dentro de cada labor, la actividad de diseño se dedica a la creación de una jerarquía apropiada de módulos de programas y de interfaces entre ellos, para implantar la especificación creada durante el análisis. Además la actividad del diseño se ocupa de la transformación del modelo de datos de entidad-relación en un diseño de base de datos.
La actividad de Implementación o implantación incluye la codificación y la integración de módulos en un esqueleto progresivamente más completo del sistema final. Por eso,
esta actividad incluye tanto programación estructurada como implantación descendente.
Los Modelos del Análisis

Declaración de Propósitos
Modelo ambiental Lista de Acontecimientos
Diagrama de Contexto
El Modelo Esencial
Modelo Preliminar
Modelo de (1 DFD por c/acontecimiento)
comportamiento Modelo Terminado
(nivelac. Ascendente/descendente)

El Modelo de Implantación del Usuario

Es el punto de inflexión entre la etapa de análisis y la etapa de diseño. El modelo de implementación del usuario especifica un conjunto de restricciones que el usuario deseará imponer al grupo de desarrollo y condicionarán al diseñador.

Los Modelos del Diseño

La actividad de diseño implica la realización de una serie de modelos.
Los modelos más importantes del diseño son:
· Modelo de Implantación de Sistemas
- Modelo de Procesadores
- Modelo de Tareas
· Modelo de Implantación de Programas
· Modelo de Implantación de Almacenes

4.4. REVISION DEL SISTEMA


4.4 Revisión del Sistema

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:

·         Revisión del diseño preliminar.
·         Revisión crítica del diseño.
·         Revisión del diseño de programas.

Revisión del diseño preliminar

Se recomienda que el número de integrantes sea pequeño de modo que facilite las discusiones.
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

Este grupo es más técnico que el anterior. Ya que la revisión trata de aspectos técnicos.

El moderador conduce la reunión para que se traten 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

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. 

4.5 REVISION DE SECUENCIAS DE DISEÑO


4.5 Revisión de Secuencias del 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 "sequence diagram", "event-trace diagrams", "event scenarios" 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.

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


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.

Variaciones en el significado de

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 de la forma siguiente:

1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):
abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son
llamadas también CASE workbench.

2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o
front-end, orientadas a la automatización y soporte de las actividades
desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o
back-end, dirigidas a las últimas fases del desarrollo: construcción e
implantación.

4. Juegos de herramientas o Tools-Case, son el tipo más simple de
herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro