miércoles, 10 de junio de 2015

DIAGRAMA DE CLASE

Fecha de Clase: 8 -12 de junio del 2015
INTRODUCCIÓN
Para el desarrollo de un proyecto de software, es importante por esto detallar o especificar o determinar cuáles son los principales requisitos del sistema, es por esto que hay que desarrollar soluciones que permitan cliente o al programador tengan claro que va hacer el sistema.
Dentro de los diagrama de UML, uno de los más reconocido es el diagrama de clases,  este tipo de diagramas es estático en él se representa mediante tablas los atributos, métodos y relaciones entre objetos. Lo que permite que el desarrollador del proyecto reconozca todas las características del sistema.

OBJETIVO
Identificar cual es la funcionalidad de los diagramas de clases y donde se pueden implementar.

MARCO TEÓRICO
DIAGRAMAS DE CLASE
Según García y Pardo (2002), el propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema.
Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden utilizar los diagramas de clase:
Conceptual: El diagrama de clase representa los conceptos en el dominio del problema que se está estudiando. Este modelo debe crearse con la mayor independencia posible de la implementación final del sistema.
Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que un tipo representa una interfaz que puede tener muchas implementaciones diferentes.
Implementación: Esta vista representa las clases tal cual aparecen en el entorno de implementación.

ELEMENTOS ESENCIALES DE LOS DIAGRAMAS DE CLASE
CLASES
Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”.
Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que representan las asociaciones o maneras en que las clases se relacionan entre sí. Estos rectángulos tienen tres comportamientos:
NOMBRE DE LA CLASE: En la parte superior se encuentra el nombre que se le da a una clase o como se la va a conocer.
ATRIBUTOS:son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso. (Leon et al., 2013)
OPERACIONES: son aquellas actividades o verbos que se pueden realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc. (Leon et al., 2013)

ASOCIACIÓN
En un diagrama de clases UML, puede dibujar asociaciones entre cualquier par de tipos. Un tipo es una clase, interfaz o enumeración.
Una asociación indica que el sistema que está desarrollando almacena vínculos de algún tipo entre las instancias de los tipos asociados. Por lo general, esto no conlleva nada para la implementación de los vínculos. 
Una asociación es un método en forma de diagrama para mostrar un atributo o un par de atributos. Por ejemplo, si definió una clase Restaurant para que tenga un atributo de tipo Menu, puede establecer la misma definición dibujando una asociación entre Restaurant y Menu. (Microsoft, 2015)
Las asociaciones pueden ser binarias (conectan dos clases) o n-arias (conectan n clases), aunque lo más normal en un modelo es utilizar sólo relaciones binarias (en general, y sin entrar en detalles, se puede afirmar que una relación n-aria puede modelarse mediante un conjunto finito de relaciones binarias).
La forma de representar las asociaciones binarias en UML es mediante una línea que conecta las dos clases. En general, las asociaciones son bidireccionales, esto es, no tienen un sentido asociado.


AGREGACIÓN
La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición.
La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el “todo”. (Megino, 2013.)


COMPOSICIÓN
Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
El símbolo de composición es un diamante de color negro colocado en el extremo en el que está la clase que representa el “todo” (Compuesto). (Megino,  2013)


EJERCICIO PRÁCTICO
Una línea aérea ofrece distintos vuelos. Los vuelos están compuestos de segmentos de vuelo que son los destinos o paradas intermedias. Es decir un vuelo es una sucesión de segmentos de vuelo. Los pasajeros tienen un asiento por cada segmento de vuelo.  Un segmento de vuelo necesita un avión, un aeropuerto de salida, uno de llegada, así como un piloto y copiloto.



CONCLUSIÓN
Los diagramas de clase son muy conocido ya que nos dan a conocer los atributos métodos y los objetos de las clases que se encuentran relacionadas entre sí. Los diagramas de clases son conocidos como un modelo o un bosquejo básico de una base de datos. Estos diagramas se relacionan entre si cumpliendo con ciertas relaciones como la agregación y la composición que estas depende de las clases que se vayan a relacionar. Están basados en la programación orientada a objeto, y son de gran ayuda al momento de desarrollar un proyecto de software para el desarrollador, sirven como guía y para documentar el proyecto.

BIBLIOGRAFÍA
Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

García, F y Pardo, C.2002. Diagramas de Clase en UML. Universidad de Burgos.

Leon, M; Vidal, M; Linares, J. 2013.Diagrmas de Clases. Formato HTML.

Megino, J. 2013. Agregación Vs Composición en diagramas de clases. UML.

Microsoft. 2015. Propiedades de las asociaciones de diagramas de clases de UML.


Popkin Software and Systems. 2002. Modelado de sistemas con UML. Formato PDF.

miércoles, 3 de junio de 2015

DIAGRAMA CASO DE USO

Fecha de Clase:  1-5 de junio del 2015
INTRODUCCIÓN
En esta clase se trató sobre unos de los diagrama de comportamiento, sin duda uno de los más populares, y más reconocido por el cliente como lo son los casos de usos. El diagrama de Caso de Uso es muy utilizados, para demostrarle al cliente como va a funcionar el sistema de manera general, mostrando las acciones y los usuarios que van a intervenir en el sistema. Este diagrama representa de manera gráfica como va a trabajar nuestro sistema, para que sea más fácil de entender para el cliente y para presentar de manera visual los requisitos que debe tener el sistema. La importancia de los casos de usos dentro del desarrollo de sistema, es fundamental para tener en claro que va hacer en sistema.

OBJETIVO
Conocer el funcionamiento y la importancia del diagrama caso de uso para su implementación en el desarrollo de proyecto de un sistema.

MARCO TEÓRICO
CASOS DE USOS
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML. (Popkin Software and Systems, 2002)
El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. (Hernández, 2002).

PARTES DE LOS CASOS DE USOS
Actor: Algo con comportamiento (persona, otro programa, organización), que interactúa con el sistema o también conocido como un rol.

Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del sistema

Caso de Uso= Colección de escenarios (éxito y fracaso) que describen actores que usan el sistema para conseguir un objetivo.

Relaciones entre dos casos de uso:
·     Generalización: Es un caso particular entre los  casos de usos,  también se puede tener esta relación entre dos actores
·    Inclusión: Una relación "incluir" indica que un caso de uso es necesitado por otro para poder cumplir una tarea.
·       Extensión: Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original.


PASOS PARA LA CREACION DE LOS CASOS DE USOS
Según la Escuela Politécnica Superior (2009), los pasos para desarrollar un buen diagrama de caso de uso  son:
1.   Identificar los límites del sistema.
2.    Identificar los actores principales.
3.    Para cada uno, identificar sus objetivos.
4.    Definir casos de uso que satisfagan sus objetivos.


EJEMPLO PRÁCTICO
Según el proceso de atención de pacientes en la unidad de cuidados intensivos UCI, se han realizado los siguientes diagramas de caso de uso que tratan de modelar este sistema:
  • Registro de ingreso de pacientes a la unidad


 Registro de medicamentos y procedimientos en pacientes

  • Registro de especialistas en la unidad para la atención de pacientes

  • Registro de diagnósticos de los pacientes que ingresan al hospital



CONCLUSIÓN
Puedo concluir que el diagrama de caso de uso, es uno de los diagramas más importante dentro de los diagramas de comportamiento, ya que permite conocer al usuario el funcionamiento del sistema, indicándole a través de los actores los usuarios que van a interactuar con el sistema, y las acciones que van a realizar los usuarios a través de los casos de usos y las relaciones que estas van a tener. Este diagrama es uno de los más implementados al momento de desarrollar un sistema, porque permite al usuario o al cliente tener en claro que es lo que va a hacer el sistema, detallando los requisitos básico que va tener el sistema.

BIBLIOGRAFÍA
Booch, G; Rumbaugh, J; Jacobson, I. 2004. El lenguaje unificado de modelado UML. Formato PDF.

Hernandez, E. 2002?. El lenguaje unificado de modelado UML. Formato PDF.

Escuela Politécnica Superior. 2009. UML: Lenguaje Unificado Modelado. Formato PDF.

Ferre, X y Sanchez, M. 2010?. Desarrollo orientado a objetos con UML. UPM.

Popkin Software and Systems. 2002. Modelado de sistemas con UML. Formato PDF.