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.

http://mmc.geofisica.unam.mx/LuCAS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x194.html

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. 

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.