UML - Comportamiento: Diagrama de actividades o flujo

Buenas, en la entrada de hoy hablaremos sobre el diagrama de actividades, también conocido como diagrama de flujo, es probable que usted ya lo conozca, es uno de los diagramas preferidos de la gente, aunque en lo personal concidero que para sistemas grandes este diagrama no aporta mucho, complica las cosas salvo que se lo haga muy generalizado.

El diagrama de flujos o actividades es una representación gráfica del proceso que realiza el programa, tiene una cierta cantidad de simbolos que representan situaciones posibles.

Este diagrama representa paso a paso el proceso que lleva a cabo el programa o la tarea en si a realizar.

Simbología
El diagrama comienza y finaliza con un ovalo o elipse que indica el comienzo y el final del diagrama.
Luego podemos apreciar ractángulos que representan una actividad o procedimiento.
El rombo representa una desición, una pregunta en particular y la bifurcación hacia dos posibles caminos.
El círculo representa un enlace de actividades con otras dentro de un procedimiento, el circulo puede conciderarse como un conector.
Luego se encuentran los triangulos, un triangulo boca arriba representa guardar un documento de forma temporal, mientras que el triangulo boca a bajo se refiere a guardar un documento de forma definitiva.

Hay distintos tipos de diagramas de flujo, podemos apreciar formatos verticales, horizontales o panorámicos, dependiendo de la forma en la que se establezca la disposición y el camino del diagrama.

Podemos apreciar a continuación el diagrama de flujo para un bucle For.

Un saludo y espero les haya gustado la entrada del día de hoy, pueden ver los diagramas anteriores como el diagrama de clases y el de casos de uso aquí.

Read More

UML - Comportamiento: Diagrama de casos de uso

Algunas entradas atras vimos el diagrama de clases, y hoy veremos el diagrama de casos de uso de UML, perteneciente a la categoría de diagramas de Comportamiento.

El diagrama de casos de uso permite establecer de forma gráfica el comportamiento del sistema para con los distintos actores que aparezcan en nuestro sistema.

Un diagrama de casos de uso realizado correctamente permite ver de forma simple y organizada nuestro sistema, de una forma visualmente rápida.

Este diagrama está compuesto por algunos pocos componentes y resulta de los diagramas más sencillos de realizar, no obstante para gran cantidad de actores puede volverse complejo y dificil de diagramar, bastante extenso.

Lo primero a conciderar en uno de éstos diagramas es la existencia de los actores, los actores son aquellas personas que utilizaran nuestro sistema, no las personas en particular, pero si el tipo de persona, en la imagen anterior vemos como sería un diagrama de un restaurante, los actores en este caso son el chef y el crítico, aunque se podrían agregar muchos más actores tales como el mesero, y los demás clientes regulares, todos los clientes estarían representados por un actor.

Luego tenemos las distintas tareas que se pueden realizar en nuestro sistema, dentro de un circulo, para indicar que tarea realiza cada actor se debe marcar con una linea.

Pueden haber tareas compartidas, pero no pueden existir dos circulos para la misma tarea.

El objetivo de este diagrama es entonces el de mostrar de forma ordenada las distintas tareas del sistema y quien las realiza, simple y sencillo.

En lo personal concidero que éste debería ser el primer diagrama que uno realize a la hora de diseñar un sistema, ya que le deja las cosas claras para el resto de los diagramas.

Un saludo lectores! y espero que les haya gustado,

Read More

UML - Estructura: Diagrama de clases

Buenas lectores, hoy hablaremos de UML (Lenguaje Unificado de Modelado) en particular sobre el diagrama de clases. UML se divide en tres grandes grupos de diagrama (Estructura, Comportamiento, Interacción) y veremos cada diagrama de cada grupo a lo largo de las futuras entradas. En particular recomiendo leer la entrada introductoria al tema aquí.

En primera instancia tengo que aclarar que es uno de los diagramas que más me gustan y uno de los pocos que realmente utilizo, no es precisamente el primero a realizar, pero es bueno que conozcan su existencia desde el principio.

El diagrama de clases representa las clases que tendrá nuestro sistema (siempre y cuando el sistema sea orientado a objetos), creando una visión simple y sencilla de las distintas clases del sistema, podemos apreciar en la siguiente imagen extraída de wikipedia como se ve un diagrama de clases.

 Cada clase se ve representada por un recuadro el cual en su cabecera debe estar su nombre en un recuadro interno, luego en el siguiente recuadro interno se encuentra la lista de atributos de la clase, (propiedades) los cuales deben su nombre estar precedido por un + o - dependiendo si son públicos o privados, en los anteriores casos la primer letra debe estar en mayusculas, luego sigue la lista de funciones en un recuadro interno nuevo, también deben ser precedidos por un + o - dependiendo si son publicos o privados, el +/-nombre_funcion() debe tener ese formato, se deben agrupar aquellas funciones publicas por un lado y privadas por el otro escribiendo primero los púlbicos y luego los privados, lo mismo ocurre con las propiedades. De esta forma se representan las distintas clases.

Ahora veremos las relaciones que hay entre las clases y como se representan, usaremos la imagen de arriba para especificar de que hablamos.

Las clases pueden tener relaciones simples como lo vemos entre la clase universidad y trabajador, al lado de la tabla trabajador hay un 1 lo que significa que esa clase esta relacionada de forma que solo 1 de esas pueda estar relacionada con una universidad, de modo que un trabajador pueda estar relacionado con una sola universidad y no más de una. En cambio el asterisco al costado de universidad indica que en esa relación la universidad en si puede tener 0, 1 o la cantidad que sea de trabajadores, también se podría escribir 1..* lo que significaría que podría tener 1 o más trabajadores, 0..1 por lo que podría tener ninguno o un solo trabajador, etc. Para relaciones simples la dirección se indica con una flecha sobre la linea de relación.

La siguiente relación que veremos es la que indica una flecha vacía (sin relleno) como se puede apreciar entre trabajador y persona, y estudiante y persona, ambas indican una flecha hacia persona, esta relacion representa "es un" quiere decir, trabajador es una persona, estudiante es una persona, o entre doctor y trabajador, doctor es un trabajador, en este caso la dirección está indicada por la flecha vacía, también puede significar "es un tipo de".

Luego tenemos la relación "tiene un" conocida como agregación, está representada por un diamante vacío, en el diagrama podemos ver como trabajador tiene un departamento.

 Luego para continuar tenemos composición, es una relación que representa el todo/parte, podemos ver entonces como funciona en la relación departamento/universidad, todos los departamentos pertenecen a una universidad.

La flecha con la linea punteada, es una relación de dependencia donde una clase depende de la otra, como por ejemplo en la imagen doctor depende de departamento.

Eso es todo para esta entrada y espero les haya gustado, un saludo!

Read More

Conceptos y diagramas de UML

Hola, buenas tardes, bienvenidos a otra publicación diaria de mi blog, la idea de ésta publicación es seguir el hilo de "Diseñando Software", en la publicación del día de hoy realizaré un resumen de los conceptos generales y de los diagramas que conforman UML.

Pero antes de comenzar y como siempre voy a comentarles...

Read More

UML lo que se debe conocer antes de diseñar soft

Buenas tardes, otra nueva entrada en nuestro blog, para seguir la tradición de "una publicación por día" voy a presentar hoy otro nuevo hilo, si esperaban que siguiera con bases de datos, o el arte de la programación, lo siento mucho pero hoy abriré el hilo de "Diseñando software", y con ustedes... la presentación de UML.
Responderemos preguntas tales como ¿Qué es UML?, ¿Para qué sirve?, ¿Por qué debería usarlo?, ¿Cómo apareció?, ¿Quien lo abala?

pero antes, como siempre voy a aclarar...

Read More