UNIDAD I

Metodología
Concepto:
Planteamiento paso a paso completo, para el tratamiento de sistemas, que guían en el
proceso de desarrollo e influyen en la calidad del producto final.

Proceso Unificado Racional: RUP

Es una metodología de desarrollo de software orientada a objetos, creada por Rational
Software Corporation. Sus creadores son los mismos de UML: Ivar Jacobsson, Grady
Booch y James Rumbaugh.

Características de RUP:
1. Está basada en componentes. Estos, a su vez, están conectados entre sí a través
de interfaces.
2. Utiliza el UML como notación básica.
3. Dirigido por casos de uso.
4. Centrado en la arquitectura.
5. Ciclo de vida interactivo e incremental.

Objetivo:
Asegurar la producción de software de calidad dentro de plazos y presupuestos prede-
cibles.

Fases:
1. Inicio (o concepción)
2. Elaboración
3. Construcción
4. Transición

Características de cada Fase y productos que se entregan:

1. Inicio
 Se establece la oportunidad y el alcance del proyecto.
 Se notifica las entidades externas con las que se trata (actores) y se defi-
ne la interacción a un alto nivel de abstracción: se identifican todos los
casos de uso y se describen algunos en detalle.
 La oportunidad del negocio incluye: criterios de éxito, identificación de
riesgos, estimación de recursos necesarios, plan de las fases, incluyendo
hitos.

Productos que se entregan:

 Un documento de visión general (informe).
 Requerimientos generales del proyecto.
 Modelo inicial de casos de uso/……
 Características principales.
  Restricciones.
 Glosario.
 Caso de uso del negocio (contexto).
 Identificación general de riesgos.
 Plan de proyecto.
 Uno o más prototipos.

2. Elaboración
 Analizar el dominio del problema.
 Establecer una arquitectura base sólida.
 Desarrollar un plan de proyecto.
 Eliminar los elementos de riesgo para el desarrollo exitoso del proyecto.
 A partir de aquí, la arquitectura, los requerimientos y las fases de desa-
rrollo son estables.
 Ya hay nuevos riesgos.

Productos que se entregan:

 Modelos de casos de usos (80% completo) con descripciones detalladas.
 Otros requerimientos no funcionales o no asociados a cada caso de uso.
 Descripción de la arquitectura del software.
 Un prototipo ejecutable de la arquitectura.
 Lista revisada de riesgos.
 Plan de desarrollo para el resto del proyecto.
 Un manual de usuario preliminar.

3. Construcción
 Aquí se desarrollan los componentes restantes y se incorporan al produc-
to.
 Todo se prueba en profundidad.
 Puede hacerse construcción en paralelo, pero exige una planificación de-
tallada y una arquitectura muy estable.

Productos que se entregan:

 El producto de software integrado y corriendo en la plataforma adecuada.
 Manual del usuario.
 Manual de procesos.

4. Transición
 El objetivo es traspasar el software desarrollado a la comunidad de usua-
rios. Una vez instalado surgirán nuevos elementos que implicarán nuevos
desarrollos (ciclos).

Productos que se entregan:

 Incluyen pruebas beta para validar el producto con las expectativas del
cliente.
 Ejecución paralela con software antiguo.
 Conversión de datos.
 Entrenamiento de usuarios.
 Distribuir el producto.
Lenguaje Unificado de Modelado
Historia de UML.:
El Lenguaje Unificado de Modelado nace en 1.994 (es el primer lenguaje) y y su ob-
jetivo fue la unificación de los métodos existentes y la estandarización.
El UML es un lenguaje de modelado bien definido, expresivo, potente y aplicable a
un amplio espectro de dominio de problema. Es un lenguaje estándar de modelado.
Si bien UML fue “diseñado” por tres autores como Booch, Jacobson y Rumbaugh, su
creación fue un esfuerzo de equipo entre todas las organizaciones que participaron en su
construcción (Oracle, Microsoft, IBM, etc.).

Por qué modelamos?

Para producir Soft que satisfaga las necesidades, hay que conocer e involucrar a los
usuarios para poder extraer los requisitos reales del sistema.
El modelado es una parte central de todas las actividades que conducen a la produc-
ción de un buen Soft. Construimos modelos para visualizar y controlar la arquitectura
del Sistema.
“El modelo en síntesis, podemos decir que es una simplificación de la realidad”. Pro-
porcionamos los planes de un sistema ya sea detallados o generales.

Visión General de UML

UML es un lenguaje para:
 Visualizar.
 Especificar.
 Construir.
 Documentar.

Los artefactos de un sistema con gran volumen de datos.

UML es un lenguaje:
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese
vocabulario con el objeto de posibilitar la comunicación.
 UML lenguaje para visualizar: Porque facilita la comunicación ya que es
un lenguaje grafico fácil de comprender y también porque detrás de cada
símbolo grafico hay una semántica bien definida.
 UML lenguaje para especificar: Porque construye modelos precisos no
ambiguos y completos, y cubre la especificación de todas las necesidades de
análisis, diseño y por ende la implementación.
 UML lenguaje para construir: Si bien no es un lenguaje de programación
visual sus modelos pueden conectarse de forma directa a una gran variedad
de lenguajes de programación.
 UML lenguaje para documentar: UML cubre la documentación de la ar-
quitectura de un sistema y todos sus detalles.
Objetos
Concepto:
Es una unidad atómica formada por la unión de un estado y de un comportamiento,
que proporciona una relación de encapsulación que asegura a la vez la cohesión interna
muy fuerte y un débil acoplamiento con el exterior. El objeto se manifiesta por medio
del envió de mensajes dándose de esta manera la comunicación.
Un objeto se representa bajo la forma de:

Nombre

El diagrama siguiente representa varios clientes de un banco y las cuentas asocia-

das a cada uno de esos clientes, los lazos representan los enlaces que existen entre
un cliente particular y una cuenta particular. El rectángulo cuya esquina esta plegada
representa una norma, a fin de facilitar la comprensión del diagnóstico. Ejemplo:

Los clientes Cuenta Corriente

de bancos

Juan

Libreta de ahorro

Características Fundamentales de un Objeto:

Todo objeto presenta tres características: estado, comportamiento e identidad.
Objeto = estado + comportamiento + identidad.
Estado: agrupa los valores instantáneos de todos los atributos de un objeto. Ejemplo:

Un automóvil

azul

979 Kg

12 cv

Comportamiento: agrupa todas las competencias de un objeto y describe las acciones

y reacciones de ese objeto. Las operaciones de un objeto se desencadenan como conse-
cuencia de un estimulo externo, representado en forma de un mensaje enviado por otro
objeto. Ejemplo:
 Un Objeto Otro Objeto

Operación 1 (…) Operación 2 (…)

La presencia de enlaces ( ) significa que un objeto ve o conoce a otro objeto. Los

mensajes navegan por los enlaces, a priori en ambas direcciones.
El estado y el comportamiento están relacionados, el comportamiento en un instante
dado depende del estado actual y el estado puede ser modificado por el comportamiento.

Identidad: además de su estado un objeto posee una identidad que caracteriza su pro-
pia existencia. La identidad permite distinguir a los objetos independientemente de su
estado, aun poseyendo dos estados idénticos. Ejemplo: todos los automóviles se identi-
fican por su numero de matricula, nosotros mismos nos identificamos por nuestro núme-
ro de DNI.

Categorías de Comportamiento:
Según la dirección de los mensajes intercambiados hay tres categorías de comporta-
miento: los actores, los servidores y los agentes. Ejemplo:

Un Agente

Un Actor Un Servidor

Mensaje
Concepto:
La unidad de comunicación entre objetos se llama mensaje. Es el soporte de una rela-
ción de comunicación que vincula de forma dinámica los objetos que han sido separa-
dos por el proceso de descomposición.
Los mensajes se representan por flechas ubicadas a lo largo de los enlaces que unen
los objetos. Un mensaje agrupa los flujos de control y los flujos de datos dentro de una
entidad única. Ejemplo:
mensaje
Objeto1 Objeto 2

Dato A Dato B
 La flecha simple indica el flujo de control y las decoradas con un pequeño circulo in-
dican el flujo de datos.

Categorías de mensajes:
 Los constructores que crean objetos.
 Los destructores que destruyen objetos.
 Los selectores que devuelven todo o parte del estado de un objeto.
 Los modificadores que cambian todo o parte del estado de un objeto.
 Los iteradotes que visitan el estado de un objeto o el contenido de una es-
tructura de datos que contiene varios objetos.

Clases de Categorías de envío de mensajes:

1. Mensaje Simple: para sistemas de un solo flujo de ejecución en los que esta ac-
tivo un solo objeto a la vez.

Expeditor Destinatario

2. Mensaje Síncrono: solo desencadena una operación cuando el destinatario

acepta el mensaje.

Expeditor Destinatario

3. Mensaje Esperado: desencadena una operación solo si el destinatario esta pre-

viamente esperando el mensaje.
En este caso a diferencia del Síncrono, el destinatario acepta esperar, en cambio
en el síncrono el expeditor acepta esperar.

Expeditor Destinatario

4. Mensaje Cronometrado: bloquea al expeditor durante un tiempo dado, espe-

rando que sea atendido por el destinatario. El expeditor se libera si no ha sido
atendido al cabo del tiempo especificado en la descripción del envío del mensaje
cronometrado.

Expeditor Destinatario

(reloj)
5. Mensaje Asíncrono: no interrumpe la ejecución del expeditor. El expeditor en-
vía el mensaje sin saber cuando, ni siquiera si el mensaje será tratado por el des-
tinatario (desde el punto de vista del destinatario lo atenderá en cualquier mo-
mento).

Expeditor Destinatario
 UNIDAD II
Clases
Concepto:
La Clase describe el ámbito de definición de un conjunto de objetos, cada objeto per-
tenece a una clase. Las generalidades están contenidas en una clase y las particularida-
des en un objeto. Los objetos informáticos se construyen a partir de la clase por un pro-
ceso llamado instanciación. De este modo, todo objeto es una instancia de clase.

Representación Gráfica de las Clases:

Cada clase se representa bajo la forma de un rectángulo dividido en tres comparti-
mentos: el primero contiene el nombre de la clase, el segundo los atributos y el tercero
las operaciones. De modo predeterminado los atributos son ocultos y las operaciones
visibles. Los compartimentos pueden suprimirse para agilizar los diagramas.

Nombre
Atributos
Operaciones

Ejemplo: la clase motocicleta contiene atributos, color, cilindrada y velocidad y tam-

bién operaciones como arrancar, acelerar, frenar.

Motocicleta
Color
Cilindrada
Velocidad máx.

Arrancar
Acelerar
Frenar

Descripción de las Clases:

1. La especificación: que describe el ámbito de definición y las propiedades de las
instancias de esta clase y corresponde a la noción de tipo tal como se define en los
lenguajes de programación clásicos.
2. La realización: describe como se realiza la especificación y que contiene el cuer-
po de las operaciones y los datos necesarios para su funcionamiento.

La separación entre la especificación y la realización de las clases participa en el nivel

de abstracción. Los trazos destacables se describen en las especificaciones y los detalles
en las realizaciones. La ocultación de los detalles se llama encapsulamiento.
 Los niveles de encapsulamiento son:
1. + Público
2. = Protegido
3. - Privado

Relaciones entre las Clases:

Al igual que los objetos son instancias de las clases, los enlaces entre objetos son ins-
tancias de las relaciones entre clases.
 Asociación: expresa una conexión semántica bidireccional entre clases. Es una abs-
tracción de los enlaces que existen entre los objetos instancias de las clases asocia-
das. Ejemplo:

enlace
California Universidad Gastón Estudiante

Gabriela Estudiante
enlace
Estamburgo Universidad
José Estudiante
enlace

Universidad Asociación Estudiante

Los enlaces entre las universidades y los estudiantes son instancias de la asociación
entre la clase Universidad la clase Estudiante.
Para mejor legibilidad, la asociación puede ir acompañada por una forma verbal activa
o pasiva usando el signo “>”. Ejemplo

Universidad Alberga > Estudiante

Universidad < Estudia en Estudiante

Tabla de Valores de Multiplicidad más Habituales:

1 Uno y solo uno

0..1 Cero a uno
M..N De M a N (entero naturales)
* De cero a varios
0..* De cero a varios
1..* De uno a varios
  Agregación: la agregación es una forma particular de asociación que expresa un
acoplamiento más fuerte entre clases. Una de las clases cumple una función más im-
portante que la otra en la relación. Ejemplo:

1
Automóvil Motor
1

Ejemplo de Agregación reflexiva:

Persona padre

hijos *

Reglas que gobiernan la transición entre los Diagramas de Clases y los Diagramas de
Objetos:
 Cada objeto es instancia de una clase y la clase del objeto no puede cambiar du-
rante la vida del objeto.
 Ciertas clases llamadas abstractas no pueden ser instanciadas.
 Cada enlace es instancia de una relación.
 Los enlaces vinculan los objetos, las relaciones vinculan las clases.
 Un enlace entre dos objetos implica una relación entre las clases de los dos obje-
tos.
 Un enlace entre dos objetos indica que estos se conocen y que pueden intercam-
biar mensajes.
 Los diagramas de objetos que contienen objetos y enlaces son instancias de dia-
gramas de clases que contienen clases y relaciones.

Jerarquía de Clases
Las jerarquías de clases o clasificaciones permiten gestionar la complejidad, ordenan-
do los objetos dentro de árboles de clases de abstracción creciente.
 Generalización y Especialización: son puntos de vista centrados en las jerarquías
de clases.
La generalización consiste en factorizar los elementos comunes (atributos, operacio-
nes y restricciones) de un conjunto de clases en una clase más general llamada supercla-
se. Las clases se ordenan según su jerarquía, una superclase es una abstracción de sus
subclases. Ejemplo:
 Vehículo

Vehículo Terrestre Vehículo Aéreo

Automóvil Camión Avión Helicóptero

La generalización y la especialización expresan en que sentido se utiliza una jerarquía

de clases. En toda aplicación real las dos se implementan simultáneamente. La generali-
zación se amplia preferentemente una vez que los elementos han sido identificados.

Superclases y Subclases
Resulta más difícil encontrar las superclases, pero los programas son más simples de
desarrollar. Es más fácil encontrar las subclases, pero es difícil realizarlas. La generali-
zación no recibe ni nombre particular ni valor de multiplicidad.

Características o Propiedades
 La generalización es una relación No Reflexiva: una clase no puede derivar de si
misma. Ejemplo:

Imposible

 La generalización es una relación No Simétrica: si una clase B deriva de una clase

A, entonces la clase A no puede derivar de la clase B. Ejemplo:

B Imposible

 La generalización es una relación Transitiva: si C deriva de una clase B que deriva

a su vez de una clase A entonces C deriva también de A. Ejemplo:

C
Sobre la dificultad de Clasificar
La determinación de los criterios de clasificación es difícil y en ciertos casos no es po-
sible determinarla.
Las clasificaciones deben ante todo, discriminar claramente los objetos. Las clasifica-
ciones se efectúan según criterios dependientes del punto de vista. No hay pues una sola
clasificación, son diversas y cada una adaptada a un uso dado. Ejemplo: para los anima-
les pueden observarse numerosos criterios:
 Estación
 Tipo de alimentación
 Protección

Una vez establecidos los criterios hay que seguirlos de manera coherente y uniforme
según el orden determinado, siendo este último arbitrario. En este caso el criterio de la
estación se ha aplicado antes del criterio de alimentación.

Animal

Estación Alimentación Protección

Bípedo Cuadrúpedo Herbívoro Plumas Pelo

Conejo

Ejemplo de Clasificación Desequilibrada:

Vehiculo Terrestre

Según función del vehículo Marca de moto

Automóvil Camión Harley Davison

La Delegación
La Herencia no es una necesidad absoluta y siempre puede remplazarse por la delega-
ción. La Delegación presenta la ventaja de reducir el acoplamiento en el modelo: por
una parte el cliente no conoce directamente el proveedor, por otra el proveedor puede
ser modificado sobre la marcha. Esta aproximación permite implementar la generaliza-
ción múltiple con los lenguajes que solo poseen la herencia simple. Ejemplo:
 Animal

Estación Alimento

Bípedo Cuadrúpedo Herbívoro Carnívoro

Principio de Sustitución
El Principio de Sustitución afirma que “debe ser posible sustituir cualquier instancia
de una superclase por cualquier objeto instancia de una subclase sin que la semántica
del programa escrito en los términos de la superclase sea afectado”. Ejemplo:

CP :CP :CP
:CP :CP
:CP
CE :CE

Un programa escrito según los

términos de la clase madre

El Polimorfismo
Describe la característica de un elemento que puede tomar varias formas. Un nombre
de objeto puede designar instancias de clases diferentes surgidas de un mismo árbol.

Principio General: las interacciones entre los objetos se escriben según los términos de
las especificaciones definidas, en sus superclases.
El polimorfismo permite desencadenar operaciones diferentes en respuesta a un mis-
mo mensaje. Cada subclase hereda de la especificación de las operaciones de sus super-
clases, pero tiene la posibilidad de modificar localmente el comportamiento de estas
operaciones, a fin de tener en cuenta mejor las peculiaridades relacionadas con un nivel
de abstracción dado.
Los beneficios del polimorfismo se recogen principalmente durante el mantenimiento.
El polimorfismo no influye en el análisis, pero depende de él, no hay que pensar el aná-
lisis en términos de polimorfismo hay que pensarlo en términos de abstracción y así por
efecto secundario beneficiarse de esta abstracción, hacer posible el polimorfismo.
Ejemplo: el siguiente Diagrama representa una colección polimorfa: el zoológico.
El zoológico contiene muchos animales. El nombre Animal conocido de la clase
ZOO, describe colectivamente todos los tipos de animales. El programa al nivel de abs-
tracción del ZOO no necesita conocer los detalles propios de cada animal.
 ZOO Animal

León Tigre Oso

Todos los animales del ejemplo saben dormir pero cada raza tiene sus costumbres par-
ticulares. La especificación del animal dice que los animales pueden dormir. Las subcla-
ses particularizan la operación Dormir, según los gustos de cada raza. Ejemplo:

ZOO Animal
1

Dormir
*

León Tigre Oso

Dormir () Dormir () Dormir ()

{ { {
Sobre el Sobre las En un
vientre espaldas árbol
} } }
 UNIDAD III
Modelo Conceptual UML
Para comprender UML, se requiere aprender tres elementos principales:
1. Bloques básicos de construcción
2. Reglas
3. Mecanismos comunes

BLOQUES DE CONSTRUCCIÓN:
1. Elementos
2. Relaciones
3. Diagramas

Elementos de UML:
1. Estructurales
2. De Comportamiento
3. De Agrupación
4. De Anotación

Elementos Estructurales
Son las partes estáticas de un modelo y representan cosas que son conceptuales o ma-
teriales. Son siete tipos:

1. Clase. Gráficamente se representa:

Nombre
Atributos
Operaciones

2. Interfaz. Gráficamente se representa:

Nombre

3. Colaboración. Gráficamente se representa:

Nombre
 4. Caso de Uso. Gráficamente se representa:

Nombre

5. Clase Activa. Gráficamente se representa:

Nombre
Atributos
Operaciones

6. Componente. Gráficamente se representa:

Nombre

7. Nodo. Gráficamente se representa:

Nombre

Elementos De Comportamiento
Son las partes dinámicas de un modelo y representan comportamientos en el tiempo y
el espacio. Son dos tipos:
1. Interacción. Gráficamente se representa:
Nombre

2. Máquina de Estados. Gráficamente se representa:

Nombre
Elementos De Agrupación
Son las partes organizativas de un modelo y representan las cajas en las que puede
descomponerse un modelo. Hay un tipo:
1. Paquete. Gráficamente se representa:

Nombre

Elementos De Anotación
Son las partes explicativas de un modelo son comentarios que se pueden aplicar para
describir, clasificar y hacer observaciones sobre cualquier elemento del modelo. Hay un
tipo:
1. Nota. Gráficamente se representa:

Nota

Relaciones de UML:
1. Dependencia
2. Asociación
3. Generalización
4. Realización

Diagramas de UML:
1. De Clases
2. De Objetos
3. De Casos de Uso
4. De Secuencia
5. De Colaboración
6. De Estados
7. De Actividades
8. De Componentes
9. De Despliegue
REGLAS:
1. Nombre: como llamar a los elementos, relaciones y diagramas.
2. Alcance: el contexto que da un significado al nombre.
3. Visibilidad: como pueden ser vistos esos nombres por otros.
4. Integridad: como se relacionan apropiada y consistentemente unos ele-
mentos con otros.
5. Ejecución: que significa ejecutar o simular un modelo dinámico.

MECANISMOS COMUNES:
1. Especificaciones
2. Adornos
3. Divisiones comunes
4. Mecanismos de extensibilidad

Divisiones Comunes:

Juan: Cliente

: Cliente

Elisa

Mecanismos de Extensibilidad:
1. Estereotipos
2. Valores Etiquetados
3. Restricciones

ARQUITECTURA:
La Arquitectura de UML comprende:
 La organización de un sistema software.
 La selección de elementos estructurales y sus interfaces a través de las
cuales se construye el sistema.
 Su comportamiento, cómo se especifica en las colaboraciones entre esos
elementos.
 La composición de esos elementos estructurales y de comportamiento en
subsistemas progresivamente más grandes.
 El estilo arquitectónico que guía esta organización; los elementos estáti-
cos y dinámicos y sus interfaces, sus colaboraciones y su composición.
Modelado de la Arquitectura de un Sistema:

Vista de Vista de Im- Ensamblado del

Funcionalidad sistema. Gestión de
Diseño plementación configuraciones
Vista de
Comportamiento Casos de Uso
Funcionamiento. Vista de Vista de Topología del siste-
Capacidad de ma. Distribución,
crecimiento. Procesos Despliegue entrega e instalación
Rendimiento

Ciclo de Vida de desarrollo de Software:

Para optimizar UML se considera un proceso que fuere:
 Dirigido por Casos de Uso.
 Centrado en la Arquitectura.
 Interactivo e Incremental.
 Tipos de diagramas UML

1) Diagramas de estructura o estáticos

Diagrama de clases

Una clase está representada por un rectángulo que dispone de tres apartados, el
primero para indicar el nombre, el segundo para los atributos y el tercero para los
métodos.

Cada clase debe tener un nombre único, que las diferencie de las otras.

Un atributo representa alguna propiedad de la clase que se encuentra en todas las

instancias de la clase. Los atributos pueden representarse solo mostrando su nombre,
mostrando su nombre y su tipo, e incluso su valor por defecto.

Un método u operación es la implementación de un servicio de la clase, que muestra

un comportamiento común a todos los objetos. En resumen es una función que le
indica a las instancias de la clase que hagan algo.
Diagrama de objetos

En este diagrama se modelan las instancias de las clases del diagrama de clases.
Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema.
Estos diagramas contienen objetos y enlaces. En los diagramas de objetos también se
pueden incorporar clases, para mostrar la clase de la que es un objeto representado.

Para realizar el diagrama de objetos primero se debe decidir qué situación queremos
representar del sistema. Es decir si disponemos de un sistema de mensajería,
deberemos decidir que representaremos el sistema con dos mensajes entrantes, los
dos para diferentes departamentos, dejando un departamento inactivo. Para el
siguiente diagrama de clases:

Diagrama de componentes

Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las

dependencias entre un conjunto de componentes. No es necesario que un diagrama
incluya todos los componentes del sistema, normalmente se realizan por partes. Cada
diagrama describe un apartado del sistema.

En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte

del sistema.

Uno de los usos principales es que puede servir para ver que componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.

Como ya hemos indicado antes todo objeto UML puede ser modificado mediante
estereotipos, los estándares que define UML son:
  Executable
 Library
 Table
 File
 Document

Aunque por suerte no estamos limitados a estas especificaciones. Qué pasa si

queremos modelar un proyecto de Internet donde nuestros componentes son ASP,
HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo.
Existen ya unos definidos WAE (Web Applications Extensión).

Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes

entidades que no tiene nada que ver entre ellas.

 Ejecutables y bibliotecas
 Tablas
 API
 Código fuente
 Hojas HTML

Diagrama de despliegue

En el diagrama de despliegue se indica la situación física de los componentes lógicos

desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada
Hardware se representa como un nodo.

Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los

componentes, representan el despliegue físico de estos componentes.

Aquí tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene
componentes. El componente del cliente utiliza un interface de uno de los
componentes del servidor. Se muestra la relación existente entre los dos Nodos. Esta
relación podríamos asociarle un estereotipo para indicar que tipo de conexión
disponemos entre el cliente y el servidor, así como modificar su cardinalidad, para
indicar que soportamos diversos clientes.

Como los componentes pueden residir en más de un nodo podemos situar el

componente de forma independiente, sin que pertenezca a ningún nodo, y relacionarlo
con los nodos en los que se sitúa.

2) Diagramas de comportamiento o dinámicos

Diagrama de casos de uso

Se emplean para visualizar el comportamiento del sistema, una parte de él o de una

sola clase. De forma que se pueda conocer cómo responde esa parte del sistema. El
diagrama de uso es muy útil para definir como debería ser el comportamiento de una
parte del sistema, ya que solo especifica cómo deben comportarse y no como están
implementadas las partes que define.

En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas
relaciones entre ellas:

 Casos de uso: representado por una elipse, cada caso de uso contiene un
nombre, que indique su funcionalidad. Los casos de uso pueden tener
relaciones con otro caso de uso. Sus relaciones son:
o Include: Representado por una flecha, en el diagrama de ejemplo
podemos ver como un caso de uso, el de totalizar el coste incluye a dos
casos de uso.
o Extends: Una relación de una caso de Uso A hacia un caso de uso B
indica que el caso de uso B implementa la funcionalidad del caso de
uso A.
o Generalization: Es la típica relación de herencia.
 Actores: se representan por un muñeco. Sus relaciones son:
o Communicates: Comunica un actor con un caso de uso, o con otro
actor.
  Parte del sistema (System boundary): Representado por un cuadro, identifica
las diferentes partes del sistema y contiene los casos de uso que la forman.

Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de

un sistema, y para modelar los requisitos del sistema.

Modelado del contexto

Se debe modelar la relación del sistema con los elementos externos, ya que son estos
elementos los que forman el contexto del sistema.

Los pasos a seguir son:

 Identificar los actores que interactúan con el sistema.

 Organizar a los actores.
 Especificar sus vías de comunicación con el sistema.
Modelado de requisitos

La función principal, o la más conocida del diagrama de casos de uso es documentar

los requisitos del sistema, o de una parte de él.

Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se

espera que realice el sistema, sin definir su funcionamiento interno. Es el paso
siguiente al modelado del contexto, no indica relaciones entre autores, tan solo indica
cuales deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos
de uso necesarios que no son visibles desde los usuarios del sistema.

Para modelar los requisitos es recomendable:

 Establecer su contexto, para lo que también podemos usar un diagrama de

casos de uso.
 Identificar las necesidades de los elementos del contexto (Actores).
 Nombrar esas necesidades, y darles forma de caso de uso.
 Identificar qué casos de uso pueden ser especializaciones de otros, o buscar
especializaciones comunes para los casos de uso ya encontrados.
Diagrama de estado

Los diagramas de estado describen gráficamente los eventos y los estados de los
objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los
eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un
estado es la condición de un objeto en un momento determinado: el tiempo que
transcurre entre eventos. Una transición es una relación entre dos estados, e indica
que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

Diagrama de actividad

Un diagrama de actividades muestra el flujo de actividades, siendo un actividad una

ejecución general entre los objetos que se está ejecutando en un momento dado
dentro de una máquina de estados, el resultado de un actividad es una acción que
producen un cambio en el estado del sistema o la devolución de un valor. Las
acciones incluyen llamadas a otras operaciones, envío de señales, creación o
destrucción de objetos o simples cálculos. Gráficamente un diagrama de actividades
será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama
de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de
culminar con un flujo de control total que se corresponde con la consecución de un
proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán
acciones y actividades correspondientes a distintas clases. Colaborando todas ellas
para conseguir un mismo fin. Ejemplo: Hacer un pedido.

Contenido del diagrama de actividades

Básicamente un diagrama de actividades contiene:

 Estados de actividad
 Estados de acción
 Transiciones
 Objetos

Estados de actividad y estados de acción

La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo

interior se representa bien una actividad o bien una acción. La forma de expresar tanto
una actividad como una acción, no queda impuesta por UML, se podría utilizar
lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc. La
idea central es la siguiente: “Un estado que represente una acción es atómico, lo que
significa que su ejecución se puede considerar instantánea y no puede ser
interrumpida”, Al igual que en el diagrama de estados, el de actividad cuenta con un
punto inicial (representado por un círculo) y uno final (representado como dos círculos
concéntricos). En la siguiente figura, podemos ver ejemplos de estados de acción.

Figura 46: Estados de Acción

En cambio un estado de actividad, sí puede descomponerse en más sub- actividades

representadas a través de otros diagramas de actividades. Además estos estados sí
pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de
actividad podemos encontrar otros elementos adicionales como son: acciones de
entrada (entry) y de salida (exit) del estado en cuestión, así como definición de
submáquinas, como podemos ver en la figura siguiente:
Figura 47: Submaquinas

Transiciones

Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de

acción. Esta transición se produce como resultado de la finalización del estado del que
parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar
y terminar en algún momento, podemos indicar esto utilizando dos disparadores de
inicio y fin tal y como queda reflejado en el ejemplo siguiente.

Figura 48: Transiciones

Bifurcaciones

Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos
alternativos. Para poder representar dichos caminos alternativos o bifurcación se
utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y
dos o más de salida. En cada transición de salida se colocará una expresión booleana
que será evaluada una vez al llegar a la bifurcación, las guardas de la bifurcación han
de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del
flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se
puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado
estado cuando el resto de guardas han fallado. Veamos un ejemplo de bifurcación.
Figura 49: Bifurcaciones

División y unión

No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los
que se requieren tareas concurrentes. UML representa gráficamente el proceso de
división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de
control secuencial, por una línea horizontal ancha. Podemos ver cómo se representa
gráficamente.

Figura 50: División y unión

Calles

Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir

los estados de actividades en grupos, cada grupo tiene un nombre concreto y se
denominan calles. Cada calle representa a la parte de la organización responsable de
las actividades que aparecen en esa calle. Gráficamente quedaría como se muestra a
continuación.

Diagramas de interacción (Subgrupo dentro de los diagramas de

comportamiento): Describen cómo los grupos de objetos colaboran para producir un
comportamiento. Son los siguientes:

 Diagrama de secuencia

Se modelan las llamadas entre clases desde un punto concreto del

sistema. Es útil para observar la vida de los objetos en sistema,
identificar llamadas a realizar o posibles errores del modelado
estático, que imposibiliten el flujo de información o de llamadas
entre los componentes del sistema.

En el diagrama de secuencia se 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 de
secuencia todas las secuencias posibles del sistema, por ello se
escoge un punto de partida. El diagrama se forma con los objetos
que forman parte de la secuencia, estos se sitúan en la parte
superior de la pantalla, normalmente en la izquierda se sitúa al 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 está activo.
 Diagrama de colaboración

El diagrama de colaboraciones describe las interacciones entre los

objetos en términos de mensajes secuenciados. Los diagramas de
colaboración representan una combinación de información tomada
de los diagramas de clases, de secuencias y de casos de uso,
describiendo el comportamiento, tanto de la estructura estática,
como de la estructura dinámica de un sistema.