Base de Datos Docente: Ing. Emilio Rearte



Descargar 0,66 Mb.
Página7/7
Fecha de conversión12.01.2017
Tamaño0,66 Mb.
1   2   3   4   5   6   7

Elementos
Un diagrama de casos de uso consta de los siguientes elementos:
Actor

Un actor es un rol que tiene un usuario con respecto al sistema. Es decir, sería un usuario del sistema. Es importante destacar el uso de la palabra “rol”, ya que esto especifica que un actor no necesariamente representa a una persona en particular, si no la labor que realiza frente al sistema.



Por ejemplo, en un sistema de ventas, el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

D
ebe tener un nombre significativo y se representa mediante el siguiente gráfico:
Caso de Uso

Es una operación o tarea específica que se realiza tras una orden o estímulo de un agente externo, puede ser un actor o desde la invocación desde otro caso de uso.



S
e representa mediante el siguiente gráfico:
Relaciones

Asociación

Es el tipo de relación más básica, indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple:




Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada:




Generalización

Este tipo de relación es una de las más utilizadas, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>).

Este tipo de relación esta orientado exclusivamente para casos de uso.

extends: se recomienda utilizar cuando un caso de uso es similar a otro (en características).

uses: se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

Se representa con la siguiente flecha:




Diagrama de Secuencia
Este diagrama (también llamado diagrama de interacción) muestra las interacciones entre un conjunto de objetos (clases, actores), ordenadas según el tiempo en que tienen lugar. Es decir, muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama la secuencia de todas las llamadas posibles del sistema, es por ello que se escoge un punto de partida. El diagrama se compone con los objetos que forman parte de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente a la izquierda se sitúa el que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando él esta activo.

El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción.

En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. El diagrama de secuencia puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o desde el de Casos de Usos.
Elementos
Los componentes de un diagrama de interacción son:

Línea de vida



Un objeto (o actor) se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de la línea principal que denotan la ejecución de métodos (activación). El rectángulo de encabezado contiene el nombre del objeto y el de su clase.


Activación

Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.


Mensajes

El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Representa la llamada de un método (operación) de un objeto en particular.



También es posible visualizar llamadas a métodos desde el mismo objeto en estudio.


El presente diagrama es útil para observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores del modelo estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema.
Diagrama de Colaboración
Este diagrama muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Elementos
Los elementos que intervienen en éstos diagramas son: objetos, enlaces y flujos de mensajes.
Objeto

Un objeto se representa con un rectángulo, que contiene el nombre y la clase del objeto. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.


Enlace

Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una línea continua que une a dos objetos en este diagrama. Esta acompañada por un número que indica el orden dentro de la interacción y por un estereotipo que indica que tipo de objeto recibe el mensaje. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.


Flujo de mensajes

Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos.

Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.
Diagrama de actividad
Son similares a los diagramas de flujos de otras metodologías OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.


Diagrama de estado
Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento.

Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un estímulo o evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición.


Herramientas Case que soporta UML


El Rational Unified Process describe cómo modelar visualmente aplicaciones para capturar la estructura y el comportamiento de la arquitectura y de los componentes. Rational Rose es la mejor herramienta para llevar a cabo el modelado visual. Permite ocultar y mostrar los detalles según el nivel de abstracción requerido y escribir la aplicación mediante bloques de construcción gráficos. Las abstracciones visuales permiten comunicar los diferentes aspectos del software; mostrar cómo los elementos del sistema encajan entre sí; asegurar que los bloques sean consistentes con el código; mantener la consistencia entre el diseño y la implementación; y promover una comunicación clara entre todos los participantes del proyecto.

Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificación del UML.

Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno lógico y otro físico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del problema y el sistema de software.



System Architect 2001

Popkin software ofrece soporte para modelar sistemas con UML en System Architect 2001. Ofrece todas las características descriptas arriba para permitir el modelado eficiente de sistemas.


Implementación de Sistemas modelados en UML

Durante el análisis se ha descrito el problema mediante tres Diagramas, Diagrama de Objetos, Diagrama de Actividades y Diagrama de Estados, separados pero relacionados. En conjunto describen qué hace el sistema con las mínimas restricciones de cómo debe ser implementado.

Cuando un sistema de software se diseña Orientado a Objeto, el Diagrama de Objetos es la base en torno a la cual se construye el diseño. Es por esto, que el diseñador debe transferir las operaciones de los Diagramas de Actividad y de Estado al Diagrama de Objetos. De esta forma, cada proceso del Diagrama de Actividad equivaldrá a una operación asignada a una clase en el Diagrama de Objetos; asimismo, los eventos del Diagrama de Estado pueden convertirse en una operación sobre un objeto, dependiendo de la implementación del control. Obteniendo como resultado final un Diagrama de Objetos con las operaciones de cada clase.

Durante el diseño debemos resolver aquellos temas que han quedado abiertos y expandir los detalle de las operaciones que no se han especificado completamente. Debemos transformar y optimizar también el modelo de análisis de tal forma que sea lo suficientemente eficiente para la implementación.

Y por último, durante la implementación, debemos pasar el diseño a un lenguaje de programación específico y satisfacer todas las reglas y convenciones del lenguaje escogido.
Veamos un ejemplo

Presentamos a continuación un Diagrama de Objetos con las operaciones de cada clase, resultado de la etapa de diseño. Lo suficientemente detallado para luego, haciendo uso, en este caso, del Lenguaje de Programación Clarion 5.5 - Enterprise Edition - de SoftVelocity Inc, lograr construir una Base de Datos física.

En siguiente esquema se muestran 5 clases extraídas de un sistema de información de una universidad.


Una vez obtenido el diagrama presentado anteriormente y conociendo el Lenguaje de Programación a utilizar. Podemos proceder con la implementación.



L
a siguiente imagen muestra el diseño de las tablas necesarias para lograr obtener una Base de Datos física en el lenguaje ya mencionado.

Como podrá observarse al comparar los dos esquemas anteriores, en el segundo, al estar ya en la implementación del sistema, aparecen identificadores que hacen único a un objeto en un registro físico, y atributos que me permiten relacionar las tablas.


Recordemos un caso prestado cuando se hablo de la identidad de los objetos en la sección Diagrama de Objetos.

  • Los objetos se distinguen por su propia existencia, su identidad, aunque internamente los valores para todos sus datos sean iguales. Todos los objetos se consideran diferentes.

Ejemplo: Si tenemos una biblioteca llena de libros, cada uno de esos libros, como La Ilíada, Hamlet, La Casa de los Espíritus, etc., se consideran e identifican como objetos diferentes. Dos manzanas aunque sean exactamente del mismo color y forma, son diferentes objetos.
Esto no sucede en una Base de Datos física. Si los libros de una biblioteca no tienen un atributo que los identifique unívocamente, serán vistos por la Base de Datos como un mismo objeto (libro), a pesar de que el resto de sus atributos, conceptualmente, los muestre como objetos distintos.

Recuérdese que las computadoras manejan 0 y 1, y es por esto, que no comprenden la diferencia entre las características de los libros de la biblioteca que para nosotros (humanos) es tan simple hacerlo, necesitando así un atributo que los identifique.



Conclusión

A nuestro parecer UML es la mejor solución para todos los profesionales relacionados con el Análisis de Sistemas, ya que si nos tocara trabajar en un proyecto de software, en el cual sabemos que el número de integrantes no es para nada reducido (si se trabajase en empresas grandes), sin la aplicación de UML, se hace engorroso ponerse de acuerdo en las metodologías que se utilizarán, en las notaciones que se emplearán para cada modelo (ya sea de análisis o de implementación). Es por ello que este nuevo paradigma de diseño nos posibilita unificar todos nuestros criterios, para un posterior entendimiento, y mejor organización de los proyectos.

Como desventaja podemos destacar (aunque para algunos o muchos no lo sería) que UML permite especificar, visualizar y construir software's, pero orientado a objetos. Para aquellos que prefieran las metodologías estructuradas deberán esperar que surja un Lenguaje Unificado de Modelado Estructurado.

Pensamos que esto no sucederá, a lo sumo aparecerá alguna extensión de UML para considerar algún aspecto del modelo estructurado, pero a nuestro parecer no sería muy justificable, por que a lo que se apunta en la actualidad es a la aplicación de metodologías orientadas a objetos, pues éstas brindan muchas ventajas y solucionan muchos de los problemas que surgen en las metodologías estructuradas.

Bibliografía
El lenguaje de unificado de modelado. de Grady Booch, James Rumbauch e Ivar Jacobson. Edit:Addison Wesley. 1º edición en español 1999
Modelos y diseños orientados a objetos - Metodología OMT - . De James Rumbaugh, Michael Blaha, William Premeralni, Frederick Hedí y William Lorensen. Editorial: PRENTICE HALL. 1996.
Curso de Ingeniería del Sofware - Unidad 5.1 Diseño de Bases de Datos Relacionales y Conceptos de la Orientación a Objetos - . De J. Pedro Caraca, Valiente y Hernández. ITBA (Instituto Tecnológico de Buenos Aires - Universidad Privada -). 1997.

Sitios Consultados
http://cavirtual.ing.ula.ve/JornadasVirtuales/XIIIJornadas/edu214/edu214.htm
http://lucas.hispalinux.es/Tutoriales/doc-modelado-sistemas-UML/multiple-html/index.html
http://sigma.poligran.edu.co/politecnico/apoyo/sistemas/inve/docs_012/uml_03/queesuml.htm
http://usuarios.lycos.es/oopere/uml.htm
http://www.creangel.com/uml/intro.html
http://www.cs.ualberta.ca/~pfiguero/soo/metod/uml-met.html


http://www.dcc.uchile.cl/~psalinas/uml/interaccion.html
http://www.docirs.cl/uml.htm
http://www.dte.us.es/personal/pruiz/investigacion/trabajo_investigacion/html/node22.html


http://www.embarcadero.com/support/what_is_uml.asp

http://www.mcc.unam.mx/~cursos/Objetos/Cap8/cap8.html
http://www.monografias.com/trabajos5/insof/insof.shtml


http://www.omg.org/gettingstarted/what_is_uml.htm

http://www.rational.com/uml/index.jsp


http://www.sparxsystems.com.au/UML_Tutorial.htm



http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html

http://www.vico.org
http://www25.brinkster.com/educarodo/articulos/articulo0031.asp
http://www-gris.det.uvigo.es/~avilas/UML/node49.html
y otros mas...
para mayor información escribe a unlar@yahoo.com.ar
1   2   3   4   5   6   7


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal