Ejercicio Analisis y Diseño

http://renorey.wordpress.com/files/2009/06/uml_blog1-dg.docx

Diagramas De Estado

Check out this SlideShare Presentation:

Diagramas De Estado

View more OpenOffice presentations from guest5ed375.

DIAGRAMAS DE ESTADO

DIAGRAMAS DE ESTADO DE USO EN UML

Estos diagramas se utilizan para describir el comportamiento de un sistema, representa los diferentes estados que puede adquirir una clase, como representarla a diferentes etapas de su vida
El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.

PARA QUE SIRVE (aplicación) EL DIAGRAMA DE
ESTADO:

Para identificar los estados o acciones por los que pasa un objeto para realizar una acción específica o llegar a un objetivo, describen el comportamiento del objeto.

SIMBOLOGIA O REPRESENTACION GRAFICA:

Lo siguiente son los elementos básicos de notación que pueden usarse para componer un diagrama:
1. Círculo lleno, apuntando a un estado inicial
2. Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final (si existiera)
3. Rectángulo redondeado, denotando un estado. En la parte superior del rectángulo está el nombre del estado. Puede contener una línea horizontal en la mitad, debajo de la cual se indican las actividades que se hacen en el estado
4. Flecha, denotando transición. El nombre del evento (si existiera) que causa esta transición etiqueta el cuerpo de la flecha. Se puede añadir una expresión de Guarda, encerrada en corchetes ( [] ) denotando que esta expresión debe ser cierta para que la transición tenga lugar. Si se realiza una acción durante la transición, se añade a la etiqueta después de "/". NombreDeEvento [Expresión Guarda]/acción
5. Línea horizontal gruesa con x>1 líneas entrando y 1 línea saliendo o 1 línea entrando y x>1 líneas saliendo. Estas denotan Unión/Separación, respectivamente.

Utiliza pocos elementos como: rectángulos de borde redondeado, que representa los estaos del objeto, y las fechas que representan la transición de un estado.

Inscrito en el rectángulo del Estado, pueden indicarse las actividades que ejecutaran los objetos de esa clase mientras se encuentra en ese estado. Todos comienzan con el estado inicial del objeto que comprende a su creación. Una vez creado el objeto comienza a cambiar de estado de acuerdo con las condiciones y actividades que se cumplen.

El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase.
El diagrama de estados y transiciones engloba todos los mensajes de un objeto, puede enviar o recibir. En un diagrama de estado un escenario representa un camino dentro del diagrama, también se puede representar como un nodo que son sus estados y cuyos arcos dirigidos sus transiciones etiquetadas con el nombre de los eventos.
En UML, los estados se representa mediante óvalos, las transiciones se representan mediante flechas con el nombre del evento respectivo. Se acostumbra poner en estado inicial en un circulo (circulo negro).

Es útil hacer diagramas de Estado para describir las secuencias permitidas de eventos en los casos de uso.
Como: Comprar producto, no esta permitido efectuar pago de tarjeta mientras no haya ocurrido el evento terminar venta.

Se encarga de mostrar la secuencia de Estados por los que pasa bien un caso de uso, un objeto o todo el sistema. En el se indica que cuantos hacen que se pase de un estado a otro y cuales son las respuestas y acciones que genera.
Existen dos formas de transicionar en un diagrama de Estado: la automáticamente y no automáticamente, se produce una transición automática cuando se acaba la actividad del estado origen, y la no automáticamente es cuando existe un evento que puede pertenecer a otro objeto del sistema.
En todo diagrama de estados existen por lo menos dos estados especiales inicial y final: start y stop. Cada diagrama debe tener uno y sólo un estado start para que el objeto se encuentre en estado consistente. Por contra, un diagrama puede tener varios estados stop.

CONCEPTOS RELACIONADOS CON DIAGRAMAS DE ESTADOS:
·

EVENTO: Un evento es una ocurrencia que puede causar la transición de un estado a otro de un objeto.·

ENVIO DE MESAJES: Además de mostrar la transición de estados por medio de eventos, puede representarse el momento en el cual se envían mensajes a otros objetos. Para ello se utiliza una línea punteada dirigida al diagrama de estados del objeto receptor del mensaje.·

TRANSICION SIMPLE: Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones cuando un evento ocurre y si ciertas condiciones son satisfechas.·

TRANSICION INTERNA: Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado.·

SUB-ESTADOS: Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior (superestado). Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.·

TRANSICION COMPLEJA: Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos.·

TRANSICION A ESTADOS ANIDADOS: significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera, a cualquier nivel de profundidad.

CARACTERISTICAS:

1 Son buenas para describir el comportamiento de un objeto.

2 Nos sirven para involucrar cierto numero de objetos que colaboran entre ellos.

3 Se deben considerar las tecnicas que sean necesarias para su utilizacion.

4 Cuando se usa un diagrama de estado no se debe dibujar uno por cada clase del sistema.

5 En un estado se identifica un periodo de tiempo de la vida del objeto durante el cual esta esperando alguna operacion.

CONCLUSIONES:

Los diagramas de estado resultan adecuados para describir el comportamiento de un objeto a través de diferentes casos de uso, sin embargo, no resultan del todo
adecuados para describir el comportamiento que incluye a una serie de objetos colaborando entre sí. Por lo tanto, resulta útil combinar los diagramas de estado con otras
técnicas. Por ejemplo, los diagramas de interacción son idóneos para la descripción del comportamiento de varios objetos en un único caso de uso, y los diagramas de
actividades muestran de forma adecuada la secuencia general de acciones en diferentes objetos y casos de uso


EL video lo podrán observar en el siguiente link




BIBLIOGRAFIA

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/n http://delta.cs.cinvestav.mx/~pmejia/softeng/tutorial.pptn http://mailweb.pue.udlap.mx/~ayalasan/programacionDeSistemas/uml/oo.1.1.htmln http://es.wikipedia.org/w/index.php?title=Especial:Buscar&search=DIAGRAMA+DE+ESTADOS&fulltext=Buscar&ns0=1&ns100=1&ns104=1&redirs=0n http://www.monografias.com/cgi-bin/search.cgi?substring=0&bool=and&query=DIAGRAMA+DE+ESTADO&x=60&y=9

Formatos Y Diagramas

Ejercicios

Ejercicios en Clase

Proponer un Ejercicio

Resumen

Resumen:

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software está respaldado por el OMG (Object Management Group). . Captura decisiones y conocimientos sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener, y controlar la información sobre tales sistemas. Esta pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en acercamiento estándar. UML incluye conceptos semánticas, notación y principios generales. Tiene partes estáticas, dinámicas, de entorno y organizativas. Esta pensando para ser utilizado en herramientas interactivas de modelado visual que tengan generadores de código así como generadores de informes. La especificación de UML no define un proceso estándar pero esta pensado para ser útil en un proceso de desarrollo iterativo. Pretende UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguajes de programación, así como construir modelos por ingeniería inversa a partir de programas existentesdar apoyo a la mayoría de los procesos de desarrollo orientados a objetos.

Historia de UML

UML fue desarrollado en un esfuerzo para simplificar y consolidar el gran número de métodos de desarrollo orientado a objetos que habían surgido.

Los métodos de desarrollo orientados a objetos.

Los métodos de desarrollo para los lenguajes de programación tradicionales, tales como Cobol y Fortran, emergieron en los años 70 y llegaron a ser ampliamente difundidos en los 80. Principalmente entre ellos estaba el Análisis estructurado y el diseño estructurado [Yourdon-79] y sus variantes tales como diseño estructurado de tiempo real [Ward-85] y otros. Estos métodos originalmente desarrollados por Constantine, DeMarco, Mellor, Ward, Yourdon, y otros, alcanzaron cierta penetración en el área de los grandes sistemas, especialmente para los proyectos contratados por el gobierno en los campos aeroespacial y de defensa, en los cuales los contratistas insistieron en un proceso de desarrollo organizado y en una amplia documentación del diseño e implementación del sistema. Los resultados no fueron siempre tan buenos como se esperaba – muchos sistemas de ingeniería de software asistidos por computador (CASE) fueron poco mas que generadores de informes que extraían diseños después de que la implantación estuviera terminada- pero los métodos incluían buenas ideas que fueron usadas eficientemente en algunos casos en la construcción de grandes sistemas.

Esfuerzo de Unificación

En 1996, el Object Management Group (OMG) publico una petición de propuestas para un enfoque estándar sobre el modelado orientado a objetos. Los autores de UML (Booch, Jacobson y Rumbaugh) empezaron a trabajar con metodologos y desarrolladores de otras compañías, para generar una propuesta atractiva a los miembros de OMG, así como también un lenguaje de modelado, que seria ampliamente aceptado por los fabricantes de herramientas, metodologos, y desarrolladores, quienes serian los usuarios eventuales.

Estandarización

El lenguaje Unificado de Modelado fue adoptado unánimemente por los miembros de OMG como estándar en noviembre de 1997. OMG asumió la responsabilidad de futuros desarrollos en el estándar de UML.

CASOS DE USO

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Historia de Caso de Uso

En 1986, Ivar Jacobson importante contribuyente al desarrollo de los modelos de UML y proceso unificado creó el concepto de caso de uso. Se han realizado muchas mejoras al concepto que se estableció entonces, pero probablemente la más influyente y significativa, en términos de definición del término caso de uso, fue la de Alistair Cockburn en el libro Escribir casos de uso efectivos publicado en el año 2000.
Durante los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

UML
Es un conjunto de herramientas, que permite modelar ,analizar y diseñar sistemas orientados a objetos.

CASOS DE USO:
son una técnica para especificar el comportamiento de un sistema; ademas es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.

1.De un ejemplo de caso de un caso de uso (practico)

2.Para que sirve UML.

Este permite que los usuarios vea la representacion del analisis y desarrollo del sistema que requiren; de esta manera no tendran confusiones asi mismo sacaran mas provecho a este.


*Para que sirve los Casos De Uso.

Este nos sirve para describir detallamente el sistema que se esta creando asi el usuario le dara mas valor al resultado final de la creacion.


3.Mensiones 4 ventajas y desventajas de un caso de uso.

Ventajas.

1. Probabilidad de mejorar la estructura.



2. facilidad de interpretacion.



3. Plantear el diseño del sistema.



4. Permite organizar ideas acerca de el requrimiento hecho del usuario para el proceso.
   

Desventajas.

1. Para el usuario puede ser un poco compleja su compresiòn.



2. Puede que no tenga una total secuencia.



3. Puede que el proceso tenga que reorganizarse para su interpretacion.



4. Creacion de varios casos para adicionar nuevos pasos.
   

5.Mencionar Temas vistos con sergio.

1. Casos de Uso



2. Diagramas de Clase



3. Uso de Relaciones