Modelo de analisis

                    Instituto Tecnológico de Huejutla

                  Fundamentos de Ingeniería de Software.

                         Unidad 3  Modelo de analisis.

             Docente: M:C Maria Guadalupe Rivera Garcia

                                                                  Presenta:
                                              Francisca Coronel Hernández.
                                             Cuarto semestre       Módulo 1
                                      Ingenieria en Sistemas Computacionales





Bibliografia unidad 3 Modelo de análisis.

http://books.google.com.mx/books?id=MOviEp0ApQcC&pg=PA254&lpg=PA254&dq=arquitectura+de+clases&source=bl&ots=OWzMnfQrcu&sig=v9SmNjXc0EsCwy4v9ycFhnGDWUA&hl=es&sa=X&ei=W8JpUdaZFMWg2QXfxYHYBA&ved=0CEoQ6AEwBg

http://www.slideshare.net/chiki.carito/modelado-del-anlisis

http://tecsistemas2012.blogspot.mx/2011/12/fundamentos-de-ingenieria-de-software.html

3.1 Arquitectura de Clases

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, siendo de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas de información, las cuales involucran ricas bordes 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 bordes y base de datos, si existen distintos  tipos 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.

Si aplicamos el concepto de dimensión a los métodos estructurados, podemos ver que estos consisten de dos dimensiones, correspondientes a funciones y datos.

Las funciones representan un eje de comportamiento que no guarda información, mientras que los datos se ubican en un eje de información que no contiene comportamiento. En general, ejes de funcionalidad pueden corresponder a distintos tipos de funcionalidades, como se ve al contrastar funciones y datos, manejo de bordes y bases de datos.

 Sin embargo, la pregunta más importante que uno se hace respecto al número y tipo de dimensiones es: ¿Si se diseña un sistema con múltiples dimensiones, se obtendría un sistema más robusto y sensible a modificaciones? Ante todo esta pregunta se relaciona con el concepto de modularidad, siendo muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su robustez y extensibilidad.

 La respuesta particular a la pregunta tiene que ver con qué tan independiente sea un eje de funcionalidad del otro, ya que en el caso de los métodos estructurados, usualmente se debe modificar las funciones cada vez que se modifica la estructura de información, lo cual no es algo deseable. Si logramos ejes de funcionalidad ortogonales, el efecto de cambios en una dimensión no debe afectar a las otras dimensiones. Y 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

3.2- Identificación de clases según estereotipos

3.2 -Identificación de clases según estereotipos

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  (“entity” en inglés) 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 o borde (“boundary” en inglés) para objetos que implementen la presentación o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.

El estereotipo control (“control” en inglés) 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 borde. 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 borde específico. Nótese que no hay ninguna restricción a los diferentes estereotipos que puedan utilizarse, no solamente las tres anteriores.

La notación de UML para un estereotipo se muestra en la Figura.

3.3 Clases

3.3 Clases

Clases: son declaraciones o abstracciones de objetos, lo que significa, que una clase es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase. Las clases pueden definirse como estructuras, uniones o clases pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Las clases son agrupaciones de objetos que describen su comportamiento.

Clase de análisis: una clase de análisis  representa la abstracción  de una o varias  clases y subsistemas del diseño del sistema. Esta abstracción  posee las siguientes características:       

v  Una clase de análisis se centra  en el tratamiento de los  requisitos funcionales.

v  Una clase da análisis también define atributos.

v  Las clases de análisis  siempre encaja en uno de tres estereotipos básicos: interfaz, control, entidad.

Clase  de interfaz:

Se utiliza para modelar  la interacción  entre el sistema y los actores.

Las clases de interfaz modelan  las partes del sistema  que dependen de sus actores  lo cual implica  que clasifican y reúnen los requisitos en los límites del sistema.

Las clases interfaz representan a menudo abstracciones  de ventanas, formularios, paneles, interfaces de comunicación.

Clase de entidad:

La clase entidad modelan la información y el comportamiento asociado  de algún fenómeno o concepto, como persona o un objeto.

Las clases entidad reflejan la información de un modo que beneficia  a los desarrolladores  al desarrollar e implementar   el sistema, incluyendo su soporte de persistencia. Estas suelen mostrar  una estructura  de latos lógica  y contribuyen a comprender de qué información depende el sistema.

Clase  de gestor :

Las clases de gestor o control representan coordinación, secuencia,  transacciones,  y control de otros objetos , todo esto se usa con frecuencia para encapsular  el control de un caso de uso en concreto.

Los aspectos dinámicos  del sistema se modelan con clase de control, debido a que ellas  manejan y coordinan  las acciones y los flujos  de control principales y delegan trabajos a  otros objetos

3.4 Diagrama de secuencia

3.4 Diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML.

•         Los diagramas de secuencia ilustran la interacción entre objetos y el orden secuencial en el que ocurren dichas interacciones, es decir cómo se comunican los objetos entre sí.

•         Los objetos se comunican mediante interfaces, para poder invocar a un operación.

•         En los Casos de Uso se modelan las características del sistema y se desarrollan escenarios.

•         El diagrama de secuencias proporciona un camino a partir de los escenarios para describir las operaciones en una forma más detallada

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

Los diagramas de secuencias se modelan a nivel de objetos y utilizan tres elementos fundamentales: objetos, mensajes/estímulos y líneas de vida de los objetos.

MENSAJES:

El primer mensaje de un diagrama de secuencia siempre inicia hasta arriba del lado izquierdo del diagrama.  Los demás se van aumentando ligeramente más abajo.

Para mostrar un objeto (línea de vida) que manda un mensaje a otro objeto, se usa una línea con una punta de flecha sólida (operación síncrono).

  El mensaje (nombre del método) se coloca arriba de la flecha.  El mensaje que se envía representa una operación/método que la clase objeto receptora va a implementar. 

Para construir el diagrama

•         Identificar a los objetos participantes

•         Dibujar una línea vertical bajo cada objeto, que representa la línea de tiempo

•         Cada mensaje se convierte en una línea horizontal del objeto que manda al que recibe.

•         Para un mensaje síncrono o procedimiento de llamada se requiere una respuesta.

•         Los asíncronos no necesitan respuesta.

3.5 Diccionario de clases según modulos.

3.5 Diccionario de clases  según modulo.

Como última etapa del modelo de análisis, se actualiza el diccionario de clases organizada según módulos, para incluir todas las clases identificadas durante el modelo de análisis.

Las clases se separan en diferentes módulos con el fin de lograr una mejor organización y correspondencia entre clases y casos de uso.

Aquellas clases que participan en varios casos de uso se pueden asignar a módulos adicionales.

módulos o paquetes principales

Interface Usuario

 Principal

Registros

Servicios

Módulos principales del sistema de reservaciones de vuelo.

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

Manejador Principal-Clase Control

Registro

El modulo registro se divide en los siguientes módulos:

Usuario: Pantalla Crear Registro Usuario, Pantalla Obtener RegUsuario,  Registro Usuario y Manejador Registro Usuario.

Tarjeta: Pantalla Crear RegTarjeta, Pantalla Obtener RegTarjeta, Registro Tarjeta y Manejador Registro Tarjeta.

InterfaceBD: Está compuesto por la clase encargada de interactuar con la base de datos. InterfaceBaseDatosRegistro .Donde BD corresponde a la base de datos.

Servicios

Se divide en los siguientes módulos(MÓDULOS ADICIONALES):

DOMINIO: Vuelo, reservación, horario, aerolínea, aeropuerto, tarifa,asiento, pasajero, avión y viajero Frecuente.

INTERFACE BD: incluye una clase para el acceso a la base de datos. Interface BaseDatosReserva.

CONSULTAS: Pantallas Consultas, Manejador Consultas.

HORARIOS: PantallaConsultaHorarios, PantallaResultadoHorarios y ManejadorConsultaHorarios.

TARIFAS: Pantalla Consulta Tarifas, Pantalla Resultado Tarifas y Manejador ConsultaTarifas.

ESTADO: PantallaConsultaEstado,PantallaResultadoEstado y ManejadorConsultaEstado

PAGOS: Pantalla Pagar RegTarjeta, Pantalla Reembolsar RegTarjeta y

Manejador Pagos.

3.6 herramientas CASE para el análisis.

3.6 herramientas CASE para el análisis.

Las herramientas de análisis: nos Permiten  crear  modelos del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación.

Cuando se analiza  una  base de datos nos permite escoger una herramienta CASE para llevar de forma eficaz y posible las tareas.

La tecnología CASE es la automatización del desarrollo software para mejorar la calidad del sistema de información.

•          Permitir aplicaciones prácticas de metodologías estructuradas, al ser realizadas con una herramienta consigue agilizar el trabajo.

•          Facilitar la realización de prototipos y desarrollo conjunto de aplicaciones.

•          Simplificar el mantenimiento de los programas.

•          Mejorar y estandarizar la documentación

•          Aumentar la portabilidad de las aplicaciones.

•          Facilitar la reutilización de componentes software.

•          Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.

Componentes de una herramienta CASE:

Una herramienta case podemos decir que se compone de:

•          Un diccionario donde se almacenan los elementos creados por la herramienta, cuya gestión se realiza mediante el apoyo de un sistema de Gestión de base de datos (SGBD).

•          El meta modelo, que constituye el marco para la definición de técnicas y metodologías soportadas por la herramienta. No siempre es visible.

•          La carga o descarga de datos, permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o generan a partir de la propia herramienta esquemas de base de datos, programas, pueden alimentar otros sistemas. Este elemento proporciona un medio de comunicación con otras herramientas.

•          Una comprobación de errores que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.

•          Una interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices.