Modelo de Implementación

El Modelo de Implementación es comprendido por un conjunto de componentes y subsistemas que constituyen la composición física de la implementación del sistema. Entre los componentes podemos encontrar datos, archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe la relación que existe desde los paquetes y clases del modelo de diseño a subsistemas y componentes físicos.

Este artefacto describe cómo se implementan los componentes, congregándolos en subsistemas organizados en capas y jerarquías, y señala las dependencias entre éstos.

Para representar los diagramas del Modelo de Implementación se puede emplear el diagrama de UML de Componentes.

5.1 DIAGRAMAS DE COMPONENTES

Es una unidad autónoma que forma parte del sistema y proporciona la implementación de un conjunto de interfaces.

Un componente es fácilmente reemplazable

Es físico

Reemplazable

Parte del sistema

Proporciona un conjunto de interfaces

TIPOS DE COMPONENTES

COMPONENTES DE DESPLIEGUE: Son para formar un sistema ejecutable.

COMPONENTES DE PRODUCTO DE TRABAJO: Estos son generados en el proceso de desarrollo.

COMPONENTES DE EJECUCION: Consecuencia de la ejecución del sistema.

ELEMENTOS

REQUISITOS: Ayudan a documentar el comportamiento funcional de los elementos del software.

RESTRICCIONES: Son aquellos que indican el entorno en donde operan.

ESCENARIOS: Describe las acciones de los objetos a lo largo del tiempo y describe la forma en la cual un componente trabaja, además se pueden crear múltiples escenarios para describir tanto el camino básico como las excepciones errores y otras condiciones.

TRANZABILIDAD: Un componente puede implementar otro elemento del modelo (por ejemplo en un caso de uso) o puede ser implementado por otro elemento.

UTILIZACIÓN

Los diagramas de componentes son utilizados para:

Modelar l vista (lógica) de implementación estática en un sistema

Modelar código fuente

Modelar base de datos

Modelos sistemas adaptables

ESTEREOTIPOS EN LOS COMPONENTES

EJECUTABLES: Especifica un componente que se puede ejecutar en un nodo.

LIBRARY: Especifica una biblioteca de objetos estáticos o dinámicos.

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.

DOCUMENTO: Especifica un componente que representa un documento.

5.2 DIAGRAMA DE DESPLIEGUE

Es la etapa del desarrollo que describe la configuración del sistema para su ejecución en un ambiente del mundo real. Para el despliegue se deben tomar decisiones sobre los parámetros de la configuración funcionamiento, asignación de recursos distribución y concurrencia.

Un diagrama de despliegue muestra la configuración de nodos que participan en la ejecución y de los componentes que residen en ellos.

RELACIONES FISICAS

Muestran las relaciones entre los componentes del hardware y software en el sistema final así como su configuración.

Formados por instancias de componentes software que son los que representan manifestaciones de código el tiempo de ejecución

REPRESENTACION

Grafos de nodos unidos para conexiones de comunicación

Diagramas de clase que se encarga de modelar los nodos del sistema

USOS

SISTEMAS EMPOTRADOS: Colección de hardware con gran cantidad de software que controla los dispositivos.

SISTEMA CLIENTE – SERVIDOR: Conectividad de los clientes sobre los servidores y distribución física de los nodos.

SISTEMAS DISTRIBUIDOS: Incluyen varios niveles de servidores cambios continuos de topologías.

NODO: Es un objetos físico en tiempo de ejecución que representa un recurso computacional generalmente tiene memoria y capacidad de procesamiento. Los nodos pueden contener objetos, instancias, instancias del componente a de representar típicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes.

RELACIONES

Las relaciones entre los nodos permiten modelar:

Un canal de comunicación entre existentes entre nodos y el tipo.

La cardinalidad de la relación.

ARTEFACTOS: Son aquellos que representan las especificaciones de un elemento de implementación concreto y real.

5.3 MODELOS DE PRUEBA

OBJETIVOS DE LAS PRUEBAS

Encontrar defectos en el software

Una prueba tiene éxito si descubre un defecto

Una prueba fracasa si hay defectos pero no los descubre

PRUEBAS DE VERIFICACION

Ver si cumple las especificaciones de diseño

PRUEBAS DE VALIDACION

Ver si cumple los requisitos del análisis

El proceso de pruebas del software tiene dos objetivos

1.    Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.

2.    Descubrir defectos en el software que su comportamiento es incorrecto, no deseable o no cumple su especificación.

PRUEBAS DE CAJA BLANCA

Pruebas en que se conoce el código a probar caja blanca (clear box: clara o transparente). Se procura ejercitar cada elemento del código.

CLASES DE PRUEBAS

Pruebas de cubrimiento

Pruebas de condiciones

Pruebas de bucles

PRUEBAS DE CAJA NEGRA

Pruebas en que se conoce solo la interfaz caja negra (black box: caja opaca). Se procura ejercitar cada elemento de la interfaz.

CLASES DE PRUEBA

Cubrimiento: Invocar todas las funciones (100%)

Clases de equivalencia de datos

Pruebas de valores limite

PRUEBAS DE VALORES

Complemento a las particiones de equivalencia

Varios casos de prueba por cada partición

Valores típicos, intermedios

Valores primero y segundo del rango

Valores penúltimo y último

Valores vecinos fuera del rango (en otra partición)

ESTARTEGIAS DE PRUEBA DE SOFTWARE

PRUEBAS DE UNIDADES: Se concentra en el esfuerzo de la verificación de la unidad más pequeña del diseño del software, el componente o modulo del software. Las pruebas de unidad se concentran en la lógica del procesamiento interno.

PRUEBAS DE INTEGRACION: Es una técnica sistemática para construir la arquitectura del software, mientras al mismo tiempo se aplican las pruebas para descubrir errores asociados con la interfaz.

PRUEBAS DE REGRESION: Repetir las pruebas tras cada modificación

REPETIR SOLO PRUEBAS DE VERIFICACION

PRUEBAS DE UNIDADES

PRUEBAS DE INTEGRACION

Conservar y actualizar los programas de prueba usar herramientas de ejecución automática de las pruebas.

PRUEBAS DE VALIDACION: Esto empieza tras la culminación de la prueba de integración, cuando se han ejercitado los componentes individuales. Se ha terminado de ensamblar el software como paquete y se han descubierto y corregido los errores de interfaz

http://www.blogger.com/blogger.g?blogID=2362182259085223872#editor

UNIDAD IV. MODELO DE DISEÑO

La fase de diseño (y los modelos de UML resultantes) expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones. El propósito del diseño es especificar una solución que trabaje y pueda fácilmente se convierta en código fuente y construir una arquitectura simple y fácilmente entendibles. Las clases definidas en el análisis fueron detalladas y se añaden nuevas clases para manejar áreas técnicas como base de datos, interfaces del usuario.

4.1 ESTRATEGIA DE DISEÑO

ABSTRACION: Para un problema determinado se pueden considerar muchos grados de abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema en los grados de menor abstracción. En un alto grado de abstracción una solución se establece en términos generales con el lenguaje de entorno del problema.

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.

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.

MODULARIDAD: Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el software se divide en 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).

OCULTACION DE INFORMACION: 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.

4.2 DISEÑO DE OBJETOS

Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienen ellos 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:

•Comprender y definir el contexto y los modos de utilización del sistema

•Diseñar la arquitectura del sistema

•Identificar los objetos principales del sistema

•Desarrollar los modelos de diseño

•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.

                                                           

4.3 DISEÑOS DE SISTEMAS

El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones).

El proceso de diseño de un sistema complejo se suele de forma descendente:

· Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).

·      Diseño e implementación de cada uno de los subsistemas

o Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.

o   Desarrollo según la especificación.

o   Prueba.

·       Integración de todos los subsistemas.

·     Validación del diseño

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo.

En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente.

De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento).

Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural.

4.4 REVISION DEL DISEÑO

Según la IEEE 61012 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 de proyecto, a los administradores, usuarios, clientes u otra parte interesada para su comentario o aprobación.

La revisión del diseño de los productos de software se realiza 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. Una recisión es una forma de aprovechar la diversidad de un grupo de personas.

·        Señalar las necesidades de mejoras en el producto de una sola persona o equipo

·        Confirmar las partes del producto en las que no es necesario o no es deseable una mejora

·        Conseguir un trabajo de mayor calidad maximizando los criterios de correctitud y completitud.

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 de estas inspecciones el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software.

4.5 DIAGRAMAS DE SECUENCIA DE DISEÑO

El diagrama de secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores de sistema. Su creación forma parte de la investigación para conocer el sistema, se fluye dentro de la etapa del análisis.

En UML los diagramas de secuencia muestran gráficamente los eventos que pasan de los actores al sistema.

ACTIVIDADES Y DEPENDENCIA

Los diagramas e 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 de cómo funcionara 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 que hace. Una parte de la descripción es un diagrama de secuencia del sistema

DIAGRAMA DE SECUENCIA DEL SISTEMA

Los casos de unos indican los actores interactúan con el sistema del software. Durante esa interacción un actor genera eventos dirigidos al sistema solicitando alguna operación a cambio conviene aísla, 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 grafica de las integraciones del actor, y de las operaciones que los mismos originan. A todos los sistemas se los trata como “caja negra”, los diagramas se encuentran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas.

El diagrama de secuencia debe prepararse para el curso normal de los eventos de un caso de uso y los cursos opcionales más interesantes. DIAGRAMA DE SECUENCIA = Representación que muestra en un determinado caso de uso, los eventos generados por actores extremos, su orden y los eventos internos del sistema.

4.6 HERRAMIENTAS PARA EL DISEÑO

Son un conjunto de métodos, utilidades y técnicas que facilita la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguno de sus fases.

El empleo de las HERMIENTAS CASE permite integrar el proceso de ciclo de vida.

·        Análisis de datos  y procesos integrados mediante un repositorio

·        Generación de interfaces entre el análisis y el diseño

·        Generación de código a partir del diseño

·        Control de mantenimiento

Actualmente, la tendencia en el desarrollo de software está enfocada hacia las microcomputadoras como plataforma de ingeniería de software, que se interconectan mediante redes para que puedan comunicarse de forma efectiva. La base de datos del proyecto, la arquitectura de entorno, compuesta por la plataforma hardware y el soporte del sistema operativo (incluida la red y la gestión de  la base de datos). Constituye la base del CASE, pero el entorno CASE en si mismo necesito otros componentes. Un conjunto de servicios de portabilidad constituye un puente entre las herramientas CASE y su marco de investigación en un conjunto de programas especializados que permite cada herramienta CASE comunicarse con las demás para crear una base de datos de proyectos y muestra una apariencia homogénea al usuario final (el ingeniero de software).

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 calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis, inherentes a los proyectos de mediano y gran tamaño (lógica del coherente, consolidación).

La mejora productividad se consigue a través de la automatización de determinadas tareas como la generación de códigos y la reutilización de objetos o módulos.

TIPOS DE 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 de ciclo de vida del desarrollo de sistemas que cubren.

·        La arquitectura de las aplicaciones que producen su funcionalidad.

UNIDAD III

Modelo de Análisis

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

Análisis de requisitos

El análisis de requisitos le proporciona al diseñador de software una representación de datos, función y comportamiento que puede trasladar a diseños arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.

Objetivos generales del modelo de análisis

El modelo de análisis debe cumplir tres objetivos primarios:

1.- Describir los que requiere el cliente

2.- Establecer una base para la creación de un diseño de software

3.- Definir un conjunto de requisitos que pueda validarse una vez construido el software.

3.1 Arquitectura de Clases

El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Como se discutió en la introducción del libro, dependiendo del tipo de aplicación existen diversas arquitecturas que se pueden utilizar, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas interfaces de usuario y accesos a base de datos como aspectos fundamentales de la arquitectura.

En término de las propias arquitecturas, éstas se distinguen según la organización de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y base de datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado, entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que la arquitectura es de una sola dimensión.

Aunque estas dimensiones no son del todo ortogonales, si son lo suficientemente independientes se puede limitar el efecto de posibles cambios. En relación al número de dimensiones, esto depende de la funcionalidad que la arquitectura debe manejar, algo que a su vez depende del tipo de aplicación que se está desarrollando.

En el caso de los sistemas de información, uno de las tipos de arquitecturas más importantes es la arquitectura MVC – Modelo, Vista, Control (Model, View, Control) popularizada por los ambientes de desarrollo de Smalltalk. Esta arquitectura se basa en tres dimensiones principales: Modelo (información), Vista (presentación) y Control (comportamiento).

Diagrama de tres dimensiones correspondiente a la arquitectura MVC – Modelo, Vista, Control.

La vista o presentación de la información corresponde a las interfaces que se le presentan al usuario para el manejo de la información, pueden existir múltiples vistas sobre un mismo modelo.

Por otro lado el control corresponde a la manipulación de la información a través de sus diversas presentaciones. Aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la información es independiente de la propia información y de cómo esta se controla.

En el modelo de análisis descrito aquí utilizaremos como base la arquitectura MVC para capturar estos tres aspectos de la funcionalidad.

Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razón de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollará en el modelo de análisis.

Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de análisis basado en el modelo de casos de uso.

 

3.2 Identificación De Clases Según Estereotipos

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases BORDE, las clases ENTIDAD y finalmente las de CONTROL.

En general, los cambios más comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde. Los cambios a la funcionalidad son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de objetos.

BORDES

La funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación comprensible para el actor.

Las clases borde en otras palabras, describen la comunicación bidireccional entre el sistema y los actores.

Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:

1. Se pueden identificar con base a los actores.

2. Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.

3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

Estrategia correspondiente a los actores: Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde.

ENTIDAD

Utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. CORTO PLAZO existe durante la ejecución de un caso de uso, mientras que la información a LARGO PLAZO trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.

La identificación de objeto entidad, se encontrara que objetos similares aparecen en varios casos de uso.

CONTROL

En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad.

 

 

3.3 Clases

Una clase orientado a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos.

Las clases se manifiestan de la siguiente forma:

Entidades: Externos sucesos o eventos, cosas, papeles, unidades organizacionales, sitios y estructuras

Modelo CRC (Clase-Responsabilidad-Colaborador)

El modelo de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio siempre ara identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una colección de tarjetas índices estándares que representan clases el objeto es describir una presentación organizada de las clases.

Las clases tienen diferentes categorías

·         Clase de Entidad: Llamadas clases de modelos o negocios se extraen de manera directa del enunciado del problema

·         Clase de Frontera: Se utiliza para crear la interfaz que el usuario ve y con la cual interactúa cuando se utiliza el software

·         Clase de Controlador: Maneja una “unidad de trabajo” desde el inicio hasta el final

·         Responsabilidad: Son los atributos y las operaciones relevantes para la clase

·         Colaboradores: Son aquellos que se requieren para que una clase reciba la información necesaria para completar una responsabilidad

·         Agregación: Son las subclases que forman parte de una clase, se conecta a través de una relación de tipo estandarte de Modelo de Comportamiento; diagrama de estado y diagrama de secuencia.

3.4 Diagrama de Secuencia

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.

3.5 Diccionario de Clases de Modelo

Como última etapa del modelo de análisis se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir (análisis) todas las clases identificadas durante el modelo que análisis separamos estas clases en diferentes modelos para lograr una mejor correspondencia entre clases y casos de uso. Aquellas clases que se participan en varios casos de usos.

MODELOS O PAQUETES PRINCIPALES

·         Interface Usuario

·         Principal

·         Registros

·         Servicios

Interface Usuario: Modulo compuesto por una clase utilizada para el manejo general de las interfaces de usuario

Interface Usuario: Clase Borde, toda la interacción con el usuario se hace por medio del borde de usuario

Principal: Está compuesto por clases comunes a la funcionalidad general del sistema: Pantalla principal- Clase borde, Manejado principal- Clase control

Registro: El modulo registros se divide en los siguientes módulos

Usuario: Pantalla Crear, Registro Usuario, Pantalla Obtener Registro Tarjeta, Registro Tarjeta y Manejador Registro con la base de datos interface Base Datos Registro donde BD corresponde a la base de datos

3.6 Herramientas Case para el Análisis

Las herramientas case (Ingeniero de Software asistida por ordenador). Son diversas aplicaciones informáticos destinados a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y dinero.

Estas herramientas es de gran ayuda en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto cálculo de costes, implementación de parte del código automáticamente con el diseño dado compilación automática documentación o detención de errores entre otras.

En un sistema de software que ayuda al automatizar a las actividades del proceso de software

Para su clasificación considera los siguientes parámetros

·         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

CLASIFICACIÓN

·         UPPER CASE (U-CASE) Ayuda en las fases de planificación, análisis de requisitos y estrategia de desarrollo, usando entre otros diagramas UML.

·         MIDDLE CASE (M-CASE) Herramienta para utilizar tareas en el análisis y diseño de la aplicación.

·         LOWER CASE (L-CASE) Semi-automatizan la generación de código crean programas de detención de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación.