Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

24
Universidad Católica de Honduras “Nuestra Señora Reina de la Paz” Campus Santiago Apóstol Diagrama de Actividades y Diagrama de Clases IF-314 Desarrollo de Software Sección: 1301 Catedrático: Ing. Jeffrey Coello Alumno: Diego Enrique Cruz #0801199011495 Cristian Antonio Janineh #0703199002488 Rony Onan Galo #0703198800122 Carlos Alfredo Borjas #0705199000107 Danlí, El Paraíso 01\10\2010

Transcript of Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Page 1: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Universidad Católica de Honduras

“Nuestra Señora Reina de la Paz” Campus Santiago Apóstol

Diagrama de Actividades y Diagrama

de Clases

IF-314

Desarrollo de Software

Sección:

1301

Catedrático:

Ing. Jeffrey Coello

Alumno:

Diego Enrique Cruz #0801199011495

Cristian Antonio Janineh #0703199002488

Rony Onan Galo #0703198800122

Carlos Alfredo Borjas #0705199000107

Danlí, El Paraíso 01\10\2010

Page 2: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

1

Índice

Pag.

1. Introducción…………………………………………………………………………..2

2. Resumen Ejecutivo…………………………………………………………………..3

3. Diagrama de Actividades………………………………………………………….4

a. Descripción……………………………………………………………………4

b. Definición y Usos……………………………………………………………..4

c. Composición………………………………………………………………….5

d. Elementos……………………………………………………………………..6

4. Diagrama de Clases……………………………………………………………….10

a. Definiciones………………………………………………………………….10

b. Elementos de una clase………………………………………………..…11

c. Asociación básica entre clases…………………………………….…..13

i. Agregación………………………………………………………….14

ii. Composición………………………………………………………..15

iii. Agregación y composición………………………………….…..16

iv. Dependencia……………………………………………………….16

v. Orientación a objetos……………………………………………..17

d. Ejemplos de Diseño………………………………………………………..17

5. Bibliografía…………………………………………………………………………..19

Anexos………………………………………………………………………….………..21

Page 3: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

2

Introducción

Para entender de mejor manera que es un diagrama de actividades y que

es un diagrama de clases, debemos conocer una definición y descripción

básica de lo que es el UML (Unified Modeling Language).

UML o “Lenguaje de Modelado Unificado” es una especificación de

notación orientada a objetos, y divide cada proyecto de software en un

número de diagramas que representan las diferentes vistas del proyecto.

Estos diagramas juntos son los que representa la arquitectura del proyecto,

y ayudan a representar una visión dinámica del sistema. Es decir, gracias al

diseño de la parte dinámica del sistema podemos darnos cuenta en la

fase de diseño de problemas de la estructura al propagar errores o de las

partes que necesitan ser sincronizadas, así como del estado de cada una

de las instancias en cada momento.

UML también intenta solucionar el problema de propiedad de código que

se da con los desarrolladores, al implementar un lenguaje de modelado

común para todos los desarrollos se crea una documentación también

común, que cualquier desarrollador con conocimientos de UML será capaz

de entender, independientemente del lenguaje utilizado para el desarrollo.

En el Lenguaje de Modelado Unificado, un diagrama de actividades

representa los flujos de trabajo paso a paso de negocio y operacionales

de los componentes en un sistema. Un Diagrama de Actividades muestra el

flujo de control general.

Un diagrama de clases es un tipo de diagrama estático que describe la

estructura de un sistema mostrando sus clases, atributos y las relaciones

entre ellos. Los diagramas de clases son utilizados durante el proceso de

análisis y diseño de los sistemas, donde se crea el diseño conceptual de la

información que se manejará en el sistema, y los componentes que se

encargaran del funcionamiento y la relación entre uno y otro.

Con UML nos debemos olvidar del protagonismo excesivo que se le da al

diagrama de clases, este representa una parte importante del sistema,

pero solo representa una vista estática, es decir muestra al sistema parado.

Sabemos su estructura pero no sabemos que le sucede a sus diferentes

partes cuando el sistema empieza a funcionar.

Page 4: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

3

Resumen Ejecutivo

La presente investigación trata acerca de dos de los tipos de diagramas

UML: El Diagrama de Actividades y el Diagrama de Clases.

En primer lugar se comenzara con una descripción detallada de cada

uno, seguida de la definición y uso de los mismos. Posteriormente se le

hablara de los diferentes componentes y elementos que los conforman así

como una breve descripción de los mismos, principalmente referentes al

diagrama de actividades. Así mismo, cada uno ira representado

gráficamente con una imagen. Por último, en los anexos se presentan

varias ilustraciones gráficas, como ejemplos de diagramas de Actividades y

de Clases completos.

El objetivo de la presente investigación es el de permitirle comprender y

conocer todos los diversos aspectos referentes a los Diagramas de

Actividades y de Clases que son muy importantes e indispensables a la

hora de realizar un proyecto de desarrollo de Software. Por otro lado,

mediante las ilustraciones se pretende darle a conocer su apariencia y

forma y así permitirle familiarizarse con el tema y proporcionarle la

habilidad de identificarlos y ponerlos en práctica.

Un aspecto importante que se debe tomar en cuenta como “Nota” de

esta investigación, y específicamente en relación al diagrama de clases,

es que a pesar de que continua siendo de los más importantes, se debe

tener en cuenta que su representación es limitada, y que ayuda a diseñar

un sistema robusto con partes reutilizables, pero no a solucionar problemas

de propagación de mensajes ni de sincronización o recuperación ante

estados de error. En resumen, un sistema debe estar bien diseñado, pero

también debe funcionar bien.

Page 5: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

4

DIAGRAMA DE ACTIVIDADES

Un Diagrama de Actividades es una representación de:

Una serie de acciones

Dentro de uno o varios hilos de proceso

Condicionadas por unos nodos de control

Descripción

En UML 1.x, un diagrama de Actividades es una variación del Diagrama de

estados UML donde los "estados" representan operaciones, y las

transiciones representan las actividades que ocurren cuando la operación

es completa.

El diagrama de Actividades UML 2.0, mientras que es similar en aspecto al

diagrama de Actividades UML 1.x, ahora tiene semánticas basadas en

redes de Petri. En UML 2.0, el diagrama general de Interacción está basado

en el diagrama de Actividades.

Diagrama de actividad. Es una forma especial de diagrama de estado

usado para modelar una secuencia de acciones y condiciones tomadas

dentro de un proceso.

La especificación del Lenguaje de Modelado Unificado OMG define un

diagrama de actividad como: “… una variación de una máquina estados,

lo cual los estados representan el rendimiento de las acciones o

subactividades y las transiciones se provocan por la realización de las

acciones o subactividades. El propósito del diagrama de actividad es

modelar un proceso de flujo de trabajo (workflow) y/o modelar

operaciones. Una Operación es un servicio proporcionado por un objeto,

que está disponible a través de una interfaz. Una Interfaz es un grupo de

operaciones relacionadas con la semántica.

Definición y Usos

Un diagrama de Actividad demuestra la serie de actividades que deben

ser realizadas en un uso-caso, así como las distintas rutas que pueden irse

desencadenando en el uso-caso.

Es importante recalcar que aunque un diagrama de actividad es muy

similar en definición a un diagrama de flujo (tipicamente asociado en el

diseño de Software), estos no son lo mismo. Un diagrama de actividad es

utilizado en conjunción de un diagrama uso-caso para auxiliar a los

miembros del equipo de desarrollo a entender como es utilizado el sistema

y como reacciona en determinados eventos.Lo anterior, en contraste con

Page 6: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

5

un diagrama de flujo que ayuda a un programador a desarrollar codigo a

través de una descripción lógica de un proceso. Se pudiera considerar que

un diagrama de actividad describe el problema, mientras un diagrama de

flujo describe la solución.

En la siguiente sección se describen los diversos elementos que componen

un diagrama de Actividad.

Composición

Inicio: El inicio de un diagrama de actividad es representado por un círculo

de color negro sólido.

Actividad : Una actividad representa la acción que será realizada por el

sistema la cual es representada dentro de un ovalo.

Transición: Una transición ocurre cuando se lleva acabo el cambio de una

actividad a otra, la transición es representada simplemente por una linea

con una flecha en su terminación para indicar dirección.

Ramificación (Branch) : Una ramificación ocurre cuando existe la

posiblidad que ocurra más de una transición (resultado) al terminar

determinada actividad.Este elemento es representado a través de un

rombo.

Unión (Merge) : Una unión ocurre al fusionar dos o más transiciones en una

sola transición o actividad.Este elemento también es representado a través

de un rombo.

Expresiones Resguardadas (Guard Expressions) : Una expresió resguardada

es utilizada para indicar una descripción explicita acerca de una

transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y

es colocada sobre la linea de transición.

Fork : Un fork representa una necesidad de ramificar una transición en más

de una posibilidad. Aunque similar a una ramificación (Branch) la

diferencia radica en que un fork representa más de una ramificación

obligada, esto es, la actividad debe proceder por ambos o más caminos,

mientras que una ramificación (Branch) representa una transición u otra

para la actividad (como una condicional). Un fork es representado por una

linea negra solida, perpendicualar a las lineas de transición .

Join : Una join ocurre al fusionar dos o más transiciones provenientes de un

fork, y es empleado para dichas transiciones en una sola,tal y como ocurria

antes de un fork .Un fork es representado por una linea negra solida,

perpendicualar a las lineas de transición .

Page 7: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

6

Fin : El fin de un diagrama de actividad es representado por un círculo, con

otro circulo concentrico de color negro sólido.

Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama

de actividad se expanda a lo largo de más de un entidad o actor, cuando

esto ocurre el diagrama de actividad es particionada en canales

(swimlines), donde cada canal representa la entidad o actor que esta

llevando acabo la actividad.

Elementos de un diagrama de Actividad

Inicio de un flujo

Secuencia de un flujo

Page 8: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

7

Condición lógica [Guard Condition]

Sincronización hilos de proceso

Page 9: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

8

Fusión hilos de proceso

Decisión booleana

Page 10: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

9

Fin de un flujo

Page 11: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

10

DIAGRAMA DE CLASES

El Diagrama de Clases es una representación de:

Requerimientos en entidades y actuaciones.

La arquitectura conceptual de un dominio.

Soluciones de diseño en una arquitectura.

Componentes de software orientados a objetos.

¿Para qué usamos un diagrama de Clases?

Para modelar los aspectos estáticos de un sistema

Realizar la abstracción de un dominio

Formalizar el análisis de conceptos

Definir una solución de diseño

Construir componentes de software

Definiciones

En primer lugar debemos iniciar definiendo qué es una Clase:

Una clase es un artefacto de modelado que Describe un conjunto de

objetos que comparten los mismos:

Atributos (conocimiento)

Operaciones (responsabilidad)

Relaciones (entrelazamiento)

Semántica (relevancia)

Propiedades también llamados atributos o características, son valores que

corresponden a un objeto, como color, material, cantidad, ubicación.

Generalmente se conoce como la información detallada del objeto.

Suponiendo que el objeto es una puerta, sus propiedades serían: la marca,

tamaño, color y peso.

Operaciones comúnmente llamados métodos, son aquellas actividades o

verbos que se pueden realizar con/para este objeto, como por ejemplo

abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que

el nombre de un atributo, 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.

Page 12: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

11

Interfaz es un conjunto de operaciones que permiten a un objeto

comportarse de cierta manera, por lo que define los requerimientos

mínimos del objeto. Hace referencia a polimorfismo.

Herencia se define como la reutilización de un objeto padre ya definido

para poder extender la funcionalidad en un objeto hijo. Los objetos hijos

heredan todas las operaciones y/o propiedades de un objeto padre. Por

ejemplo: Una persona puede especializarse en Proveedores, Acreedores,

Clientes, Accionistas, Empleados; todos comparten datos básicos como

una persona, pero además cada uno tendrá información adicional que

depende del tipo de persona, como saldo del cliente, total de inversión del

accionista, salario del empleado, etc.

Elementos de una Clase

Page 13: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

12

Page 14: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

13

Asociación básica entre Clases

Define una determinada vinculación entre dos tipos. El conector puede

indicar el rol de la asociación fuente y destino, la cardinalidad y el tipo de

navegabilidad (bidireccional o unidireccional).

Generalización

El elemento destino es una especialización del elemento fuente.

Dentro de una escala de abstracción variable, el elemento fuente es el

más abstracto.

Page 15: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

14

Agregación

El elemento destino “forma parte” del elemento fuente.

Dicha relación puede romperse sin restricciones.

Patrón Agente

Page 16: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

15

Composición

El elemento destino “forma parte” del elemento fuente. Dicha relación sólo

puede romperse cumpliendo unas restricciones determinadas.

Page 17: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

16

Agregación & Composición

Dependencia

La clase A depende de la clase B y puede verse afectada si se producen

cambios en la clase B.

Page 18: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

17

Orientación a objetos

Ejemplos de diseño:

Al diseñar una clase se debe pensar en cómo se puede identificar un

objeto real, como una persona, un transporte, un documento o un

paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un

sistema se diseña. Durante el proceso del diseño de las clases se toman las

propiedades que identifican como único al objeto y otras propiedades

adicionales como datos que corresponden al objeto. Con los siguientes

ejemplos se definen tres objetos que se incluyen en un diagrama de clases:

Ejemplo 1: Una persona tiene número de documento de identificación,

nombres, apellidos, fecha de nacimiento, género, dirección postal,

posiblemente también tenga número de teléfono de casa, del móvil, FAX y

correo electrónico.

Ejemplo 2: Un sistema informático puede permitir administrar la cuenta

bancaria de una persona, por lo que tendrá un número de cuenta,

número de identificación del propietario de la cuenta, saldo actual,

moneda en la que se maneja la cuenta.

Page 19: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

18

Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dónde las

operaciones bancarias de una cuenta (como en el ejemplo 2) se

manejarán realizando diferentes operaciones que en el diagrama de

clases de balurdes sólo se representan como operaciones, que pueden ser:

Abrir

Cerrar

Depósito

Retiro

Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen

propiedades y/u operaciones que contienen un contexto y un dominio, los

primeros dos ejemplos son clases de datos y el tercero clase de lógica de

negocio, dependiendo de quién diseñe el sistema se pueden unir los datos

con las operaciones.

El diagrama de clases incluye mucha más información como la relación

entre un objeto y otro, la herencia de propiedades de otro objeto,

conjuntos de operaciones/propiedades que son implementadas para una

interfaz.

Page 20: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

19

Bibliografía

http://usuarios.multimania.es/oopere/uml.htm

http://es.wikipedia.org/wiki/Diagrama_de_clases

http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UM

LTRAD_101A/LinkedDocuments/UML_diagClases.pdf

http://es.wikipedia.org/wiki/Diagrama_de_actividades

http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UM

LTRAD_101A/LinkedDocuments/UML_diagActividad.pdf

Page 21: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

20

Anexos

Page 22: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

21

Jerarquía de los diagramas UML

Page 23: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

22

Ejemplo de diagrama de clases de una

Universidad.

Diagrama de Actividades para un loop (bucle).

Page 24: Diagrama de Clases y Actividades (Gr#1) (Desarrollo de Software)

Diagrama de Clases/Diagrama de Actividades

IF-314 Desarrollo de Software UNICAH

Grupo #1

23

Mapa de procesos de negocio