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. Existen diversas arquitecturas que se pueden utilizar, 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.

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

El modelo de análisis es una serie de modelos, que apoyan de texto y diagramas para representar los requisitos de los datos.

Referencia : http://es.scribd.com/doc/52037161/jaimeantero-Cap7-Analisis

Elaborado por: Efraín Martínez Hernández  Semestre: 4to  modulo:1

3.2 Identificación de clases según análisis

Clases con Estereotipos

El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de información la arquitectura del sistema según nuestro modelo de análisis se basa en tres estereotipos básicos de objetos:

·         El estereotipo entidad para objetos que guarden información sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.

·         El estereotipo interface para objetos que implementen la presentación o vista correspondiente a las interfaces del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto interface es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.

·         El estereotipo control para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el resultado a un objeto interface. Un ejemplo típico de objeto control es analizar el uso del sistema por parte de algún usuario registrado y presentar tal información posteriormente. Este comportamiento no le pertenece a ningún objeto entidad u objeto interface específico.

Referencia: http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20VII/7.1.htm

Elaborado por: Efraín Martínez Hernández  Semestre: 4to  modulo:1

3.3 clases

Un diagrama de clases es un tipo estático que describe la estructura de un sistema, mostrando sus clases atributos y las relaciones entre ellos. Los diagramas de clases son utilizados en el proceso de análisis y diseño de los sistemas.

Entidades:  

·         Modelan información perdurable , entre casos de uso.

·         “modelo” que captura los datos.

Interfaz:

·         Transporta la acción del actor a los eventos del sistema

·         Transporta al actor los eventos del sistema

·         Cada actor puede tener su conjunto de interfaces

·         que pueden ser “vistos” de múltiples formas ...

Control:

·         Unen otros componentes para formar un caso de uso

·         mediante los “controladores”, que proporcionan formas de actualizar y extraer información del modelo.

  

Referencia:  http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2007-2008/Apunts/IS.7.pdf

Elaborado por: Efraín Martínez Hernández  Semestre: 4to  modulo:1

3.4 Diagramas de secuencia

Representación que muestra, para un determinado caso de uso, los eventos generados por los actores externos, su orden y los eventos del sistema.

·         Al sistema se le considera una caja negra

·         Los diagramas se centran en los eventos que transcienden las fronteras del sistema y que fluyen de los actores al sistema.

·         Inicialmente, los diagramas deberían prepararse para el escenario principal de un caso de uso Ingeniería del Software

Diagrama de secuencia del sistema

Objetivo:

·          Identificar los eventos y las operaciones (comportamiento) del sistema

·         Partimos de los casos de uso

·          Describen cómo interaccionan los actores con el sistema

·         Los actores generan eventos hacia el sistema que requieren de la ejecución de alguna operación como respuesta.

Definimos un diagrama de interacción para cada curso relevante de los eventos de un caso de uso mostrando:

ü  Los eventos generados por los actores externos y su orden

ü  Los eventos internos del sistema (operaciones) que resultan de la invocación Ingeniería del Software

Diagrama de secuencia del sistema

ü  Crear un diagrama de secuencia del sistema para cada caso de uso.

ü  Cada evento en el diagrama debe corresponder a una interacción con el sistema especificado en el caso de uso completo.

ü  Dibujar una línea vertical que representa el sistema

ü  Dibujar una línea para cada actor que interacciona directamente con el sistema

ü  A partir del curso de eventos de los casos de uso, identificar y mostrar los eventos externos generados por los actores

ü  Para identificar los eventos del sistema es necesario delimitar claramente la frontera del sistema. 

Escenario principal (o curso normal de los eventos):

1. Cliente: Llega a un TPV con productos que desea comprar.

2. Cajero: Comienza una nueva venta.

3. Cajero: Introduce el identificador del artículo. Si hay varios productos de una

misma categoría, el Cajero también puede introducir la cantidad.

4. Sistema: Registra la línea de la venta, y presenta la descripción del artículo,

precio y suma parcial.

El Cajero repite los pasos 3 a 4 hasta terminar los artículos del Cliente.

5. Cajero: Indica al TPV que se concluyó la captura de productos.

6. Sistema: Calcula y presenta el total con impuestos de la venta.

7. Cajero: Le indica el total de la venta al Cliente.

8. Cliente: Efectúa un pago.

9. Cajero: Gestiona el pago.

10. Sistema: Registra la venta. Genera un recibo.

11. Cajero: Da al Cliente el recibo impreso.

12. Cliente: Se marcha con los artículos comprados.

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

Elaborado por: Efraín Martínez Hernández  Semestre: 4to  modulo: 1

3.5 Diccionario de clases según módulos

La etapa del modelo de análisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de análisis. Separamos estas clases en diferentes módulos para lograr una mejor correspondencia entre clases y casos de uso. Aquellas clases que participan en varios casos de uso se pueden asignar a distintos módulos.

Diccionario de datos.

Contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

Razones para su utilización:

Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles. Por eso se registra la información, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseñados específicamente para el análisis y diseño de software.

Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos.

Los diccionarios de datos proporcionan asistencia para asegurar significados comunes para los elementos y actividades del sistema y registrando detalles adicionales relacionadas con el flujo de datos en el sistema, de tal manera que todo pueda localizarse con rapidez.

Para asignarle un solo significado a cada uno de los elementos y actividades del sistema.

Para documentar las características del sistema, incluyendo partes o componentes así como los aspectos que los distinguen. También es necesario saber bajo que circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. Produciendo una comprensión mas completa. Una vez que las características están articuladas y registradas, todos los participantes en el proyecto tendrán una fuente común de información con respecto al sistema.

Para facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema.

referencia:http://www.monografias.com/trabajos5/inso/inso2.shtml

Elaborado por: Efraín Martínez Hernández  Semestre: 4to  modulo:1

3.6 Herramientas CASE Para el análisis

Las  Herramientas  de Ayuda al Desarrollo de Sistemas de Información, surgieron para intentar dar  solución  a los problemas inherentes a los proyectos de generación de  aplicaciones  informáticas: plazos y presupuestos incumplidos, insatisfacción del  usuario , escasa productividad y baja calidad de los desarrollos, entre otros. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE.

Actualmente existe un gran desarrollo y una gran cantidad de este tipo de herramientas, por lo que se hace difícil la elección de una de ellas para el trabajo, tanto personal como corporativo.

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.

Tipos de Herramientas CASE

No existe una única clasificación de herramientas CASE, 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 abarca.

·         La arquitectura de las aplicaciones que produce.

·         Su funcionalidad.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

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.

Las herramientas I-CASE se basan en una metodología. Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipo.

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.

Una estrategia posible es utilizar una U-CASE para análisis y diseño, combinada con otras herramientas más modernas para las fases de construcción ypruebas. En este caso, habría que vigilar cuidadosamente la integración entre las distintas herramientas.

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.

Juegos de herramientas o toolkits, son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de estegrupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.

Otra posible clasificación, utilizando la funcionalidad como criterio principal, es la siguiente:

·         Herramientas de gestión de proyectos

·         Herramientas de gestión y configuración de software (SCM)

·         Herramientas de calidad y seguridad de software

·         Herramientas de análisis y diseño

·         Herramientas de desarrollo de interfaz de usuarios

·         Herramientas para la Ingeniería de Software Orientada a Objetos

·         Herramientas de integración y prueba

·         Herramientas de métodos formales

·         Herramientas Cliente/Servidor

·         Herramientas de Ingeniería WEB

·         Herramientas de Reingeniería

Beneficios de las Herramientas CASE

1.    Facilidad para la revisión de aplicaciones

2. Soporte para el desarrollo de prototipos de sistemas

3. Generación de código

4. Mejora en la habilidad para satisfacer los requerimientos del usuario

5. Soporte interactivo para el proceso de desarrollo

Referencia: http://www.monografias.com/trabajos73/herramientas-case-proceso-desarrollo-software/herramientas-case-proceso-desarrollo-software2.shtml

Elaborado por: Efrain Martinez Hernandez     semestre:4to                        modulo:1