miércoles, 29 de mayo de 2013

3.6 HERRAMIENTA CASE PARA EL ANALISIS

3.6 HERRAMIENTA CASE PARA EL ANALISIS


1.            Borland Caliber Analyst

Se trata de un producto que está compuesto por dos aplicaciones desarrolladas por la compañía Borland.

Por un lado está el Caliber DefineIT (la última de las herramientas en cuanto a fecha de lanzamiento) que permite definir los requisitos del sistema así como capturar los diferentes escenarios de negocio a través de diferentes herramientas visuales; es necesario señalar que este software es compatible con gran número de herramientas existentes en el mercado.

Por el otro está Caliber RM que nos permite gestionar dichos requisitos durante el ciclo de vida del producto, si bien no ayudaba al usuario a visualizar los requerimientos y por lo tanto no resultaba tan efectiva como ellos demandaban.

El paquete que incluye ambas aplicaciones nos permitirá realizar las siguientes tareas: representar y especificar los escenarios de manera visual, permitiendo el uso de un lenguaje común; generar diagramas de casos de pruebas y UML, mejorando tanto la velocidad como la exactitud de la definición de los requisitos; rastrear los requisitos software durante el ciclo de vida del proyecto, respondiendo de manera rápida a cualquier cambio que se produzca.

La compañía Seilevel Inc., una de las más fuertes en cuanto a los servicios relacionados con los requisitos del software, ha seleccionado esta herramienta como la mejor de este tipo. Según palabras de un directivo de la compañía ven características únicas en esta herramienta así como una experiencia de usuario excelente y una oportunidad para mejorar el trabajo de sus clientes en cuanto al análisis y gestión de requisitos se refiere.

2.            CASE Spec

Esta herramienta está desarrollada por la empresa Goda Software, siendo esta una aplicación comercial de uso exclusivo para el sistema operativo Windows. Las principales características que avalan a esta herramienta son las siguientes:

Especificación: posibilidad de realizar las especificaciones tanto con las técnicas tradicionales como con los diagramas de casos de uso. Además, nos permite crear diagramas UML y de flujo de datos.

Seguimiento de los requisitos: a través del uso combinado de un procesador de textos y una hoja de cálculo, el usuario será capaz de realizar el seguimiento de los requisitos así como hacer un informe acerca de los mismos.

Capacidad de rastreo: mediante la existencia de una matriz se representan de manera sencilla las diferentes relaciones existentes entre los requisitos definidos y otra serie de elementos incidentes en el proyecto.

Capacidad de importar y exportar archivos.

Generación automática de la documentación del proyecto así como posibilidad de realizar amplios informes.

3.            IRQA 4

Herramienta desarrollada por Visure y que tiene la meta de servir como aplicación para proporcionar un soporte integral en la ingeniería de requisitos de un proyecto de informática.

A parte de incluir las tareas más básicas de la ingeniería de requisitos (captura, análisis, modelado, organización y seguimiento), esta aplicación dispones de las siguientes características:

Reutilización de requisitos: permite que los requisitos definidos en un proyecto puedan ser utilizados en otros proyectos realizados por la organización, a través del uso de librerías. De esta manera se consigue ofertar una pequeña ventaja a la hora de realizar líneas de productos.

Vista documental: esta nueva opción ofrece un agrupamiento de los requisitos que permite al usuario observar una diferenciación clara entre los mismos así como facilitar toda labor relacionada con estos.

Ingeniería de requisitos: además de la gestión de los requisitos, esta aplicación proporciona funcionalidades relacionadas con la ingeniería de requisitos, lo que permite centralizar en una sola herramienta todas las actividades relacionadas con los requisitos (incluyendo las pruebas de validación y aceptación).

Al ser esta una herramienta integrada, se ofrece al usuario la libertad de seleccionar aquellas otras aplicaciones más adecuadas para la realización de otras tareas relacionadas con el ciclo de vida de un proyecto, lo que hace que no se dependa de un solo proveedor de aplicaciones.

4.            Tiger Pro

Estamos ante una herramienta shareware desarrollada para facilitar al usuario la tarea de redactar los requerimientos de un proyecto. Este aplicativo es capaz de solucionar algunos de los defectos que aparecen a la hora de definir los requisitos de un programa. También ayuda al usuario a aclarar algunos de los requerimientos desde el punto de vista de las pruebas a realizar, señalando aquellos requerimientos cuya verificación pueda resultar complicada.
La herramienta, que se va actualizando con el paso del tiempo, permite exportar el trabajo realizado en archivos bajo el formato CSV. Los usuarios que utilicen esta herramienta podrán trabajar en los requisitos tomando como referencia los siguientes conceptos: palabras claves relacionadas con el mismo (hasta 3 palabras para cada requisito), criterio de aceptación del requisito, seguimiento del mismo (tanto hacia la fuente como hacia otros lugares), prioridad del requerimiento, riesgo que trae consigo el requisito y coste del mismo. Además, a la hora de realizar los informes correspondientes, la herramienta nos proporcionará la opción de redactar los mismos en forma textual o bien nos presentará la información de forma gráfica.

5.            GatherSpace

A la hora de realizar la definición de los requisitos para un proyecto de informática, el trabajo conjunto de todo el equipo de desarrollo es una parte fundamental para conseguir un buen resultado. Esta herramienta de definición y gestión de requisitos utiliza Internet como su lanzadera, ya que no es necesario instalar ningún programa para utilizarla: bastará con crear una cuenta en el sitio web de la misma y comenzar a definir el proyecto que se quiere desarrollar. De esta manera, la aplicación consigue que la colaboración de todos los miembros del grupo de desarrollo sea posible de una manera mucho más eficaz.

Las características más representativas de esta herramienta son las siguientes:

Creación de una jerarquía de requerimientos: permite crear paquetes funcionales para después relacionarlos con componentes de más alto nivel para después permitir asociar casos de uso más detallados y requisitos del software a dichos componentes.

Manipular varios proyectos al mismo tiempo, controlando el acceso de los usuarios para que estos puedan ver solo alguno de los proyectos.

Posibilidad de visualizar la documentación generada a partir de los requisitos en tres formatos diferentes: HTML, PDF y Microsoft Word.
Además de contar con todas estas opciones, la compañía ha dispuesto un buen sistema de seguridad que protegerá los datos introducidos en la herramienta. Para asegurar la integridad del trabajo realizado se realizan copias de seguridad diaria de la información introducida en la herramienta y además existe la posibilidad de encriptar los datos introducidos en la misma. También es necesario señalar que el usuario podrá descargarse la información desde el servidor de la empresa tantas veces como le sea necesario.

6.            IBM Rational RequisitePro

Esta herramienta, desarrollada por una de las compañías más importantes dentro del campo de la informática, se considera una de las herramientas más completas y potentes dentro del análisis y la gestión de los requisitos.

Una de las grandes ventajas que aporta este producto es la compatibilidad existente entre su software y algunos de los programas más utilizados. Por ejemplo, esta herramienta es capaz de comunicarse de manera muy eficiente con el Microsoft Word, de manera que la realización de los informes es más sencilla al tiempo que se ofrece al usuario una interfaz conocida para el desarrollo de su labor. Además de esta compatibilidad, el programa también se comunica con gran eficiencia con algunos de los sistemas de bases de datos más utilizados en el mundo de la informática (DB2 de IBM, Microsoft SQL Server, Microsoft Access y Oracle) de manera tal que se controla el acceso a los datos existentes en el sistema al tiempo que se tiene un repositorio central de datos.

Por si esto no fuera suficiente, la comunicación entre la base de datos utilizada y el Microsoft Word permite al usuario gestionar los requisitos desde la base de datos seleccionada al tiempo que estos se mantienen dentro de su contexto en el procesador de textos.

Al igual que la herramienta estudiada anteriormente, Racional RequisitePro ofrece la posibilidad de trabajar mediante acceso Web. De esta manera se logra tener tanto un acceso remoto como un acceso distribuido y además no se necesita que el software esté instalado en el cliente. También es necesario mencionar que la herramienta dispone de una matriz de seguimiento de los requisitos (al igual que la herramienta CASE Spec); en este caso, dicha matriz puede representarse tanto de forma gráfica como de forma textual. Además, en este caso se incorpora al seguimiento de los requisitos la existencia de un árbol de seguimiento global.

7.            RaQuest
Se trata de la herramienta de gestión de requisitos desarrollada por la empresa Sparx Systems, desarrolladora también de la herramienta de análisis y modelado Enterprise Architect, utilizada en la Escuela.

Las características principales de esta herramienta son las siguientes:

Definición y gestión de los elementos relacionados con los requisitos, entre los que se encuentran el tipo, el estado, la dificultad del requisito, las relaciones existentes entre diferentes requisitos, etc.

Creación de paquetes para gestionar de manera más sencilla y completa los requisitos.
Generación de documentación del proyecto (tanto parcial como total) en los siguientes formatos: HTML, CSV, Word, Excel, RTF
Además de estas características, la herramienta nos ofrece una serie de vistas diferentes, dependiendo de la vista que queramos obtener del proyecto. Estas vistas son: vista del tipo lista (permite ordenar los requisitos, mostrar diferentes listas, filtrar las listas en relación a diferentes palabras y buscar en el proyecto) y vista del tipo árbol (se pueden mostrar los árboles de proyecto y miembro así como mostrar los árboles por el tipo y por el estado).
Elección de la Herramienta a Utilizar
Debido a la gran compatibilidad existente con el Enterprise Architect, a la variedad de formatos para generar la documentación y a las numerosas opciones existentes en cuanto al tipo de vistas y la definición de los elementos relacionados con los requisitos, me he decantado por utilizar la herramienta RaQuest. 



3.5 DICCIONARIO DE CLASES SEGUN MODULOS

3.5 DICCIONARIO DE CLASES SEGUN MODULOS

Esta es la ultima estapa del modelo de analisis, en esta etapa se actualiza el diccionario de clases segun modulos, originalmente descrito en el dominio del problema, aunque no es necesario ordenarlos por relevancia, a cada clase y caso de uso se le pueden asignar modulos adicionales, que estos a su vez pueden tener otros modulos  o paquetes principales de importancia, estos ayudan a analisar de una mejor manera.

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema. Si se examina una muestra de diagramas de flujo de datos para el procesamiento de pedidos, es probable que se tengan pocas dificultades para comprender qué datos representan a la factura y al cheque. Los dos son términos comunes en el mundo de los negocios y muchas personas conocen su significado. Los diccionarios de datos registran detalles adicionales relacionados con el flujo de datos en el sistema de tal forma que todas las personas participantes puedan localizar con rapidez la descripción de flujos de datos, almacenes de datos o procesos.

fuente:
http://books.google.com.mx/books?id=MOviEp0ApQcC&pg=PA327&lpg=PA327&dq=diccionario+de+clases+segun+modulos&source=bl&ots=OWzNkgPuiy&sig=d2U43tOGBuuYN0VYW9_spn7xrG0&hl=es&sa=X&ei=T5V0UfjuEM-k2gWi9oC4Bg&ved=0CDUQ6AEwAQ 


3.4 DIAGRAMAS DE SECUENCIAS

3.4 DIAGRAMAS DE SECUENCIAS



El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso 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 pasados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "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 vectores horizontales. 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.


 Diagrama de Secuencia para un escenario
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 case instanciada por el objeto en la recepción final del mensaje.

3.3 CLASES

3.3 CLASES


Los objetos se representan y agrupan en clases que son óptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase. Por ejemplo, los registros de los estudiantes en la sección de un curso almacenan información similar para cada estudiante. Se podría decir que los estudiantes constituyen una clase. Los valores podrían ser diferentes para cada estudiante, pero el tipo
de información es el mismo. Los programadores deben definir las diversas clases en el programa que escriben. Cuando el programa corre, los objetos se pueden crear a partir de la clase establecida. El término instanciar se usa cuando un objeto se crea a partir de una clase. Por ejemplo, un programa podría instanciar a un estudiante llamado Peter Wellington como un objeto de la clase denominada estudiante.
Lo que hace a la programación orientada a objetos, y por consiguiente al análisis y diseño orientado a objetos, diferente de la programación clásica, es la técnica de poner todos los atributos y métodos de un objeto en una estructura independiente, la propia clase. Ésta es una situación común en el mundo físico. Por ejemplo, un paquete con harina para pastel empacado es similar a una clase ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Un suéter de lana es similar a una clase porque incluye una etiqueta con instrucciones del cuidado que advierten que se debe lavarlo a mano y ponerlo a
secar extendido. Cada clase debe tener un nombre que la distinga de todas las demás. Los nombres declase normalmente son sustantivos o frases cortas y empiezan con una letra mayúscula. En la figura 18.1 la clase se llama RentaAuto. En el UML, una clase se representa como un rectángulo. El rectángulo contiene otras dos características importantes: una lista de atributos y una serie de métodos. Estos elementos describen una clase, la unidad de análisis que es una parte principal de lo que llamamos análisis y diseño orientado a objetos. 

Un atributo describe alguna propiedad de todos los objetos de la clase. Observe que la clase RentaAuto posee los atributos tamaño, color, marca y modelo. Todos los automóviles poseen estos atributos, pero los atributos de cada automóvil tendrán diferentes valores. Por ejemplo, un automóvil puede ser azul, blanco o de algún otro color. Más adelante demostraremos que es posible serrnás específico acerca del rango de valores para estas propiedades. Al especificar atributos, normalmente la primera letra es minúscula. 

Un método es una acción que se puede solicitar a cualquier objeto de la clase. Losmétodos son los procesos que una clase sabe cómo realizar. Los métodos también se llaman operaciones. La clase RentaAuto podría tener los siguientes métodos: inicioRenta( ), entregaAutof ) y servicio( ). Al especificar métodos, normalmente la primera letra es minúscula.




Fuente: analisis de diseño y diseño de sistemas – kendall & kendall, pag 258- 259.

3.2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS

3.2 IDENTIFICACION DE CLASES SEGUN ESTEREOTIPOS


Para llevar a cabo la transicion del modelo de requisitos al modelo de analisis 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 mas 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 dificiles de administrar, ya que ésta puede abarcar todos los tipos de objetos.
 bordes
Toda 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, pues a traves de ellso se comunican los actores con el sistema. 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 presentacion comperensible 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. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
 Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a 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.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que  se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.
 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. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.




unidad 3.1 : MODELO DE ANÁLISIS

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.
http://mundokramer.wordpress.com/2011/05/20/modelo-de-analisis-software/

4.6 Herramientas para el diseño

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.
v  Análisis de datos  y procesos integrados mediante un repositorio
v  Generación de interfaces entre el análisis y el diseño
v  Generación de código a partir del diseño
v  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.