Unidad II-Apoyo UML

Unidad II.
Diseño Orientado a
Objetos con UML
“Cualquier producto o sistema importante
vale la pena diseñar una Arquitectura. Antes
de comenzar a construirlo es mejor que
entienda el problema, diseñe una solución
factible, la implemente en una forma sólida y
la ponga a prueba ampliamente. Tal vez
tenga que controlar los cambios conforme el
trabajo avance y disponer de algún
mecanismo para asegurar la calidad del
resultado final”
2.1.1. Casos de Uso
Los casos de uso se emplean para capturar el comportamiento deseado del

sistema en desarrollo, sin tener que especificar cómo se implementa ese
comportamiento. Los casos de uso proporcionan un medio para que los
desarrolladores, los usuarios finales del sistema y los expertos del dominio
lleguen a una comprensión común del sistema.
Además, los casos de uso ayudan a validar la arquitectura y a verificar el
sistema mientras evoluciona a lo largo del desarrollo.
CASOS DE USO
 Un caso de uso describe un conjunto de secuencias,

donde cada secuencia representa la interacción de los
elementos externos al sistema (sus actores) con el
propio sistema (y con sus abstracciones claves).
 Estos comportamientos son funciones a nivel del

sistema que se utilizan durante la captura de requisitos y
el análisis para visualizar, especificar, construir y
documentar el comportamiento esperado del sistema.
 Un caso de uso representa un requisito funcional del

sistema.
Desarrollo de proyectos de Software
CASOS DE USO:
Terminología y Conceptos
 Un caso de uso describe un conjunto de secuencias de
acciones, donde cada secuencia representa la interacción
de los elementos externos al sistema (sus actores)

CASOS DE USO:
Terminología y Conceptos (cont…)
 Los comportamientos que representan los casos de uso,
en realidad son funciones a nivel del sistema que se
utilizan durante la captura de requisitos y el análisis para
visualizar, especificar, construir y documentar el
comportamiento esperado del sistema.
 Un caso de uso representa un requisito funcional del sistema.

 Un caso de uso SIEMPRE involucra la interacción de actores y el
sistema.
 Un actor pueden ser personas o pueden ser sistemas mecánicos.

CASOS DE USO:
 Un actor representa un rol que es jugado por una persona,
un dispositivo hardware o incluso otro sistema al
interactuar con nuestro sistema.
 Se pueden definir categorías generales de actores y
especializarlos a través de relaciones de generalización.

CASOS DE USO:
 Actores:
• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el
sistema
• Material externo: dispositivos materiales imprescindibles
que forman parte del ámbito de la aplicación y deben ser
utilizados
• Otros sistemas: sistemas con los que el sistema interactúa
 La misma persona física puede interpretar varios papeles
como actores distintos
 El nombre del actor describe el papel desempeñado

CASOS DE USO:
 Los actores sólo se pueden conectar a los casos de uso a
través de asociaciones.
 Una asociación entre un actor y un caso de uso indica que
el actor y el caso de uso se comunican entre sí, y cada
uno puede enviar y recibir mensajes.

CASOS DE USO:
 Un escenario es una secuencia específica de acciones
que ilustra un comportamiento del sistema.
 Los escenarios son a los casos de uso lo que las

instancias a las clases, es decir, un escenario es
básicamente una instancia de un caso de uso.
 Para cada caso de uso, puede haber escenarios

principales (definen secuencias esenciales) y escenarios
secundarios (definen secuencias alternativas).

CASOS DE USO:
Relaciones
 Se definen tres tipos de relación en los Casos de

Uso:
 Generalización
 Inclusión
 Extensión entre ellos.

CASOS DE USO:
Generalización
 La generalización entre casos de uso es como la

generalización entre clases. Aquí significa que el
caso de uso hijo hereda el comportamiento y el
significado del caso de uso padre; el hijo puede
añadir o redefinir el comportamiento del padre; el
hijo puede ser colocado en cualquier lugar donde
aparezca el padre.

CASOS DE USO:
Generalización

CASOS DE USO:
Generalización (Ejemplo)

CASOS DE USO:
Inclusión
 Una instancia del Caso de Uso origen incluye también el
comportamiento descrito por el Caso de Uso destino.
<<include>> reemplazó al denominado <<uses>>

CASOS DE USO:
Inclusión (Ejemplo)

CASOS DE USO:
Extensión
 El Caso de Uso origen extiende el comportamiento del
Caso de Uso destino.
 Una relación de extensión se utiliza para modelar la parte
de un caso de uso que el usuario puede ver como
comportamiento opcional del sistema. De esta forma, se
separa el comportamiento opcional del obligatorio.
 Una relación de extensión se representa como una
dependencia, denominada extend.
<<extend>>
Caso de Uso Origen Caso de Uso Destino

CASOS DE USO:
Extensión (Ejemplo)

CASOS DE USO:
Extensión e Inclusión (Ejemplo)

CASOS DE USO:
Extensión e Inclusión (Ejemplo)

CASOS DE USO
Ejercicio
¿Que relación se establece entre los siguientes casos
de uso?
Crear
usuario
Crear usuario
administrador
Administrar
usuarios
Modificar
Administrador de Sistema usuario
Eliminar Validar
usuario Información
de usuario

CASOS DE USO:
Técnicas comunes de Modelado
 Los casos de uso, se utilizan generalmente para

realizar tres tipos de modelado:
 Modelado del comportamiento

 Modelado del contexto del sistema
 Modelado de los Requisitos de un sistema

CASOS DE USO
Modelado del comportamiento
 La mayoría de las veces, los casos de uso se utilizan

para el modelado del comportamiento de un elemento,
ya sea un sistema completo, un subsistema o una clase.
 Cuando se modela el comportamiento de estos

elementos, es importante centrarse en lo que hace el
elemento, no en cómo lo hace.

CASOS DE USO
Modelado del comportamiento
 Para modelar el comportamiento:
 Hay que identificar los actores que interactúan con el
elemento.
 Hay que organizar los actores identificando tanto los roles
más generales como los más especializados.
 Hay que considerar las formas más importantes que tiene
cada actor de interactuar con el elemento.
 Hay que considerar también las formas excepcionales en
las que cada actor puede interactuar con el elemento.
 Hay que organizar estos comportamientos como casos de
uso, utilizando las relaciones de inclusión y extensión para
factorizar el comportamiento común y distinguir el
comportamiento excepcional.

CASOS DE USO
Modelado del comportamiento (Ejemplo)

CASOS DE USO
Modelado del contexto del sistema
 Todos los elementos
externos que interactúan
con el sistema constituyen
su contexto. Este contexto
define el entorno en el que
reside el sistema.
 En UML se puede modelar
el contexto de un sistema
con un diagrama de casos
de uso, destacando los
actores en torno al
sistema.

CASOS DE USO
Modelado de los requisitos del sistema
 Un requisito es una característica de diseño, una
propiedad o un comportamiento de un sistema.
 Cuando se enuncian los requisitos de un sistema se está
estableciendo un contrato entre los elementos externos
al sistema y el propio sistema, que establece lo que se
espera que haga el sistema. La mayoría de las veces no
importa cómo lo hace, sólo importa que lo haga.
 Un sistema con un comportamiento correcto llevará a
cabo todos sus requisitos de manera fiel, predecible y
fiable.

CASOS DE USO
Modelado de los requisitos del sistema
La sig. Figura extiende
el anterior diagrama de
casos de uso. Aunque
omite las relaciones
entre los actores y los
casos de uso, añade
casos de uso
adicionales que son
invisibles para el
cliente normal, aunque
son comportamientos
fundamentales del
sistema.

DIAGRAMA DE CASOS DE USO

Errores al realizar Diagramas de
Casos de Uso

Diagrama de Casos de Uso
Ejemplo 1…

Caso de uso textual : Sacar dinero

Caso de uso textual : Sacar dinero
(continuación)

Diagrama de Casos de Uso
Ejemplo 2

2.1.2 Diseño del sistema en
base a procesos/actividades
2.1.2. Diagrama de Actividades

Un diagrama de actividades es fundamentalmente un
diagrama de flujo que muestra el flujo de control entre
actividades.
DIAGRAMAS DE ACTIVIDADES:
Técnicas comunes de Modelado
 Los diagramas de actividades se utilizan para modelar
los aspectos dinámicos de un sistema. La mayoría de las
veces, esto implica modelar los pasos secuenciales (y
posiblemente concurrentes) de un proceso
computacional.
 Los diagramas de actividades pueden utilizarse para

visualizar, especificar, construir y documentar la
dinámica de una sociedad de objetos, o pueden
emplearse para modelar el flujo de control de una
operación.
DIAGRAMAS DE ACTIVIDADES
 Gráficamente, un diagrama de actividades es una

colección de nodos y arcos.
 Generalmente los diagramas de actividades

contienen:
 Estados de actividad y estados de acción
 Transiciones
 Objetos
 Bifurcaciones (Desición)
 Inicio/Fin
Elementos del Diagrama
de Actividades
Actividad División
(Sincronización)
Flujo (Unión)
Inicio
Bifurcación
Fin
Separador (Unión)

Decisiones en el Diagrama de
Actividades
 Casi siempre en un Diagrama de Actividades se llegara
a un punto donde se realizara alguna decisión, donde
una lo llevara por un camino y otra por otro camino.
 Existen dos formas de representar los puntos de

decisión:
 La primera es mostrar las rutas posibles que parten
directamente una actividad.
 La segunda es llevar la transición hacia un rombo.

Decisiones en el Diagrama de
Actividades

Rutas Concurrentes en el
Diagrama de Actividades
 Conforme como se
modele las actividades,
se tendrá la oportunidad
de separar la transición
en dos rutas que se
ejecutan al mismo tiempo
(en forma concurrente) y
luego se reúna.

Indicaciones en el
 También es posible enviar
una indicación. Cuando se
reciba, la indicación
provocara que se ejecute
una actividad.
 El símbolo para enviar la

indicación es un
pentágono convexo y el
que recibe un pentágono
cóncavo.

Proceso de Creación de un Documento

Diagrama de Actividades Hibrido
Proceso de Creación de un Documento

Ejemplo: Máquina para hacer café/jugo
Buscar Bebida [ no hay café ] [ no zumo ]
[ hay café ]
[ hay zumo ]
Poner café Añadir agua Coger taza

en filtro al depósito Coger
zumo
Poner filtro
en máquina
Encender
máquina
/ cafetera.On
Café en
preparación
indicador de fin
Servir café Beber
Marcos de Responsabilidades
(Calles)
 Una cosa especialmente útil cuando se modelan flujos

de trabajo de procesos de organizaciones, es dividir
los estados de actividad de un diagrama de
actividades en grupos, donde cada uno representa la
parte de la organización responsable de esas 74
actividades. En UML cada grupo se denomina una
calle porque, visualmente, cada grupo se separa de
sus vecinos por una línea vertical continua.

Proceso de una Aerolínea con marcos de Responsabilidades
(Calles)

Solicitar cotización de materiales
Cliente Vendedor Almacenero
Realizar
Recepcionar solicitud de
cotización
cotización
Elaborar oferta
Recibir oferta Entregar oferta
Ok
Solicitar Elaborar
prefactura Prefactura
Recibir Reservar
prefactura producto

2.2. DISEÑO DE LA
LÓGICA
CLASES Y OBJETOS
VISTA ESTRUCTURAL
CLASES Y OBJETOS

Clases
 Una clase es una descripción de un conjunto de objetos

que comparten los mismos atributos, operaciones,
relaciones y semántica.
 Gráficamente, una clase se representa como un
rectángulo.

Atributos
Un atributo es una propiedad

de una clase identificada con
un nombre, que describe un
rango de valores que pueden
tomar las instancias de la
propiedad.

Operaciones
 Una operación es la implementación de un servicio que

puede ser requerido a cualquier objeto de la clase par que
muestre un comportamiento, es una abstracción de algo
que se puede hacer a un objeto y que es compartido por
todos los objetos de la clase.

Responsabilidades
 Una responsabilidad es un contrato o una obligación de

una clase. Al crear una clase, se está expresando que
todos los objetos de esa clase tienen el mismo tipo de
estado y el mismo tipo de comportamiento.

Distintos niveles de detalle para clases

Mensajes, enlaces y secuenciamiento
Una interacción es un comportamiento que comprende un

conjunto de mensajes intercambiados entre un conjunto de
objetos dentro de un contexto para lograr un propósito. Un
mensaje es la especificación de una comunicación entre
objetos que transmite información, con la expectativa de que
se desencadenará una actividad.

Enlaces y Asociaciones

Nombre de la Asociación, dirección y
multiplicidad
 El nombre de la asociación es opcional y se muestra como un
texto que está próximo a la línea.
 Se puede añadir un pequeño triángulo negro sólido que indique
la dirección en la cual leer el nombre de la asociación.
 La multiplicidad es una restricción que se pone a una
asociación, que limita el número de instancias de una clase que
pueden tener esa asociación con una instancia de la otra clase.
Rol

Herencia
 La relación de herencia se representa mediante un triángulo

en el extremo de la relación que corresponde a la clase más
general o clase “padre”.

Elementos derivados
 Un elemento derivado es aquel cuyo valor se puede calcular

a partir de otros elementos presentes en el modelo, pero que
se incluye en el modelo por motivos de claridad o como
decisión de diseño. Se representa con una barra “/”
precediendo al nombre del elemento derivado.

Diagrama de Clases
 El Diagrama de Clases es el diagrama principal para el

análisis y diseño.
 Un diagrama de clases presenta las clases del sistema con
sus relaciones estructurales y de herencia.
 La definición de clase incluye definiciones para atributos y
operaciones.
 El modelo de casos de uso aporta información para
establecer las clases, objetos, atributos y operaciones.
 Los diagramas de clases son utilizados para ilustrar las
relaciones entre clases y son el fundamento para el proceso
de diseño
Diagrama de Clases
 Modela los conceptos del dominio de la aplicación.

 Un diagrama de clases esta compuesto por los siguientes
elementos:
 Clases: atributos, operaciones y visibilidad.
 Relaciones: Herencia, Composición, Agregación,
Asociación y Uso.
 Responsabilidades

Diagrama de Clases

Objetos

Diagrama de Objetos
 El Diagrama de Objetos es una instancia de un Diagrama
de Clases y presenta los detalles de un estado del sistema
en un punto del tiempo determinado. Se utilizan para
validar el modelo del dominio.
 Para validar el modelo del dominio es necesario ejecutar
los siguientes pasos:
 Elegir uno o más casos de uso que estén altamente
relacionados con el modelo del dominio.
 Elegir uno o más escenarios de los casos de uso
seleccionados en el punto anterior. Es recomendable
elegir escenarios que exploren diferentes situaciones.

Diagrama de Objetos
 Ir a través de cada escenario en forma separada, y

construir los objetos con los datos mencionados en
el escenario.
 Comparar cada diagrama de objetos con el modelo
del dominio para analizar si se han violado algunas
restricciones.

Diagrama de Objetos
Ejemplo Sistema Académico
Creando el diagrama de objetos desde el escenario: Juan

ingresa su identificación 91558899 la cual el sistema
valida.

Diagrama de Objetos
De un catálogo de cursos disponibles, Juan selecciona como

cursos principales Inglés, Geología, Historia y Algebra.
También selecciona Música y Java como materias
alternativas. El sistema determina que Juan cumple con los
pre-requisitos necesarios y lo agrega a la lista de
estudiantes de ese curso.

Diagrama de Objetos
El sistema indica que la actividad se ha completado, imprime el

horario del estudiante y le envía la información correspondiente al
sistema financiero.

VISTA DE
COMPORTAMIENTO
DIAGRAMAS DE INTERACCIÓN
DIAGRAMAS DE ESTADO
Diagramas de Secuencia
Tipos de Clases
Cada Clase en UML tiene su propia notación.
Clase Clase Clase

Entidad Interfaz Control
(Servicio)

Tipos de Clases
Clase de Entidad
 Representa la información que va a ser persistente.
 Para ser utilizada en tareas internas del sistema.
 Su comportamiento es independiente
 El valor de sus atributos generalmente es proporcionado
por un actor.
Clase
Entidad

Tipos de Clases
Clase de Límite (Interfaz)
 Modelan la comunicación entre los límites del sistema y

sus entradas de trabajo: formas, ventanas de diálogo,
protocolos de comunicación, dispositivos.
 También usadas para la comunicación entre otros
sistemas.
Clase
Interfaz

Tipos de Clases
Clase de Control (Servicio)
 Modela el comportamiento específico de uno o más
casos de uso.
 Una clase de control:
 Crea, inicializa y elimina objetos controlados.
 Controla la secuencia o coordinación de ejecución
de los objetos controlados.
 Es la implementación de un objeto intangible.
Clase
Control
(Servicio)
Interacción entre Objetos
 Diagramas de Secuencia: interacción a través del

tiempo
 Diagramas de Colaboración: encadenamiento entre

objetos.

Diagrama de Secuencia
 Representa los mensajes intercambiados por un

conjunto de objetos durante un escenario
 Consta de Actores, Objetos o Clases, mensajes y

tiempo, donde se enfocan en los diferentes estados
de un Objeto.

 Los Mensajes es la comunicación existente entre un
Objeto a otro.
 Los mensajes pueden ser:
 Simple: es la transferencia normal del control entre
un Objeto a otro.
 Sincrónico: Es la espera la respuesta de un mensaje
antes de continuar con su trabajo.
 Asincrónico: no espera respuesta de un mensaje
para continuar con su trabajo.

 El Tiempo representa la duración de la ejecución de un
mensaje.
 Se representa con una barra vertical.
 Puede mostrar los Estados de un Objeto.
 En ocasiones un objeto cuenta con una operación que
se invoca así misma, esto se llama “Recursividad”.

Ejemplo Caso de Uso Matricular
Vista Comportamiento:Colaboraciones
Diagrama de Colaboración
 Este Diagrama es Similar al Diagrama de Secuencia,

pero de una mirada diferente.
 Es la forma de cómo los Objetos se colaboran entre si,
tal como se muestra en el Diagrama de Secuencia.
 Destaca la organización de los Objetos que participan
en una interacción y sus relaciones.

 Cuenta con dos características que lo diferencia del

Diagrama de Secuencia:
 El Camino: Indica como se enlaza entre un Objeto a
otro.
 Numero de Secuencia: Indica la ordenación temporal
de un mensaje, se precede de un número y que
incrementa secuencialmente por cada nuevo mensaje
en el flujo de control. También se cuenta la
representación por anidamiento, utilizando la
numeración decimal de Dewey.

Diferencias entre el Diagrama de
Secuencia y Colaboración
 El Diagrama de Secuencia muestra la sucesión de las

interacciones y el de Colaboración destacan el Contexto y
la Organización general de los Objetos que interactúan.
 El Diagrama de Secuencia se organiza de acuerdo al

tiempo y el de Colaboración de acuerdo al espacio.

Ejemplo Caso de Uso Matricular

Vista Comportamiento: Estados
Diagrama de Estado
 Muestra el conjunto de estados por los cuales pasa un

objeto durante su vida en una aplicación, junto con los
cambios que permiten pasar de un estado a otro.
 Presenta los Estados que puede encontrarse un Objeto

junto con las transiciones entre los estados, y muestro los
puntos inicial y final de una secuencia de cambios de
estados.

Diagrama de Estado
 También se conoce como Diagrama de Transición.
 Es usado para mostrar la vida de una clase

determinada a través de todo el sistema, los eventos
causan una transición de un estado a otro, y las
acciones que resultan del cambio de estado.
 Un estado de un objeto es una de las posibles
condiciones en las cuales puede existir.

Diagrama de Estado
 Los Elementos de un Estado son:

 Estado: Es una condición o situación en la vida de un
objeto durante la cual se satisface alguna condición,
realiza alguna actividad o espera algún evento.
 Evento. Es la especificación de un acontecimiento
significativo que ocupa un lugar en el espacio y en el
tiempo.
 Transición. Es la relación entre dos estados, en la
que se indica cómo se pasa de uno a otro.

Diagrama de Estado
 Actividad. Ejecución atómica en curso dentro de una

máquina de estado.
 Acción. Computación atómica ejecutable que produce
un cambio de estado en el modelo o devuelve un
valor.
 Cuando se crea un objeto, se entra en un estado
inicial y cuando se destruye, se llega a un estado

final.
 Acciones: De entrada, salida y durante
la actividad.

Diagrama de Estado
Ejemplo para el Objeto Empleado:

Diagrama de Estado
Ejemplo para la Clase Curso_Verano:

Agregar
estudiante/numest=0 Agregar
estudiante(numest<30)
No Asignado
Do: Asignar profesor al curso
Iniciado Abierto
Do: Iniciar el objeto curso Entry: Matricular un estudiante
Cancelar Curso
Cancelar Curso
Cancelado Cupo Incompleto

Matrícula
Do: Enviar mensaje de cancelación Do: Eliminar estudiantes matriculados Finalizada
(numest>=20)
Curso lleno
Finalización Matrícula
Cerrado
Do: Generar lista de clase
Do: Reporte curso lleno
Diagrama de Estado
Interpretación para la Clase Curso:

Clase
- atributo1:
+ accion1() : void
+ accion2() : void
+ accion3() : void
State1 State2 State3

acción 1 acción 2
acción 3

Diagrama de Estado
Ejemplo para el Caso de Uso Comprar Productos:

Diagrama de Estado
Ejemplo Protector de Pantalla:
Sub Estado del proceso Operación

Diagrama de Estado
Ejemplo Protector de Pantalla:

Sub Estado Concurrente del proceso Operación
VISTA DE IMPLEMENTACION
Diagrama de Componentes
Diagrama de Despliegue
 Un Componente de Software es una parte física de

un Sistema y se encuentra en la Computadora y no
en la mente del Analista.
 Se puede tomar como Componente: tabla, archivo de

datos, html, ejecutable, biblioteca de vínculos
dinámicos, documentos, etc.

 Los Diagramas de Componentes se utilizan para:

 Los Clientes puedan ver la estructura del Sistema
finalizado.
 Los Desarrolladores cuenten con una estructura con la
cual trabajar en adelante.
 Quienes escriban las notas técnicas y la documentación
puedan entender lo que escriben.
 Ustedes se alisten para volver a utilizar los
Componentes.

 Los Diagramas de Componentes se utilizan para:
 Modelar Código Fuentes.
 Modelar Versiones Ejecutables.
 Modelar Base de Datos Físicas.
 Modelar Sistemas Adaptables.
 Los componentes representan todos los tipos de
elementos software que entran en la Fabricación de
aplicaciones informáticas.

 Muestra la organización y las Dependencias entre un
conjunto de Componentes.
 Cubren la vista de la Implementación Estática y se
relacionan con los Diagramas de Clases ya que en un
Componente suele tener una o mas Clases, interfaces o
Colaboraciones.
 Cuando se habla del Diagrama de Componentes, se trata
obviamente de, Componentes, Interfaces y Relaciones.
agentefraudes.dll
agente.java system::dialog.dll Realiza

AgenteFraudes
Nombre {version = 2.0.1}
PoliticaFraudes
BuscarPatrones

Componentes y Clases
 Las clases representan abstracciones lógicas. Los

componentes son elementos físicos del mundo real.
 Un componente es la implementación física de un conjunto
de otros elementos lógicos, como clases y colaboraciones.
agentefraudes.dll
AgenteFraudes BuscarPatrones
PoliticaFraudes

Componentes y Clases
UML definen cinco Estereotipos estándar que se aplican a los

Componentes:
 Executable: Especifica un componente que se puede ejecutar
en un Nodo.
 Library: Especifica una biblioteca de Objetos Estática o
Dinámica.
 Table: Especifica un Componente que representa una tabla de
una Base de Datos.
 File: Especifica un Componente que representa una Archivo de
Código Fuente o Archivo de Datos.
 Document: Especifica un Componente que representa un
documento.

Dependencias entre Componentes
La dependencia entre dos componentes se muestra como una

flecha punteada. La dependencia quiere decir que una
componente necesita de la otra para completar su definición,
ósea, los Servicios ofrecidos por otro Componente .
<<page>>
home.html
<<file>>
animlogo.java
<<file>>
animator.java Desarrollo de proyectos de Software
Ejemplo

Ejemplo

Sub Sistemas
 Los distintos componentes pueden agruparse en paquetes

según un criterio lógico y con vistas a simplificar la
implementación.
 Son paquetes estereotipados en <<subsistemas>> para
incorporar la noción de biblioteca de compilación.

Sub Sistemas
 Los subsistemas organizan la vista de realización de un

sistema.
 Cada subsistema puede contener componentes y otros
subsistemas.
 La descomposición en subsistemas no es una
descomposición funcional.
 La relación entre paquetes y clases en el nivel lógico es
el que existe entre subsistemas y componentes en el
nivel físico.

VISTA DE AMBIENTE: Despliegue

o Distribución
 Los Diagramas de Despliegue o Distribución muestran la
disposición física de los distintos nodos que componen un
sistema y el reparto de los componentes sobre dichos
nodos.
 Los Diagramas de Despliegue o Distribución modelan la
topología del hardware sobre el que se ejecuta el Sistema
Software.
 Este tipo de diagramas suele utilizarse para modelar
Sistemas Distribuidos o Sistemas Empotrados. En los
sistemas monolíticos, generalmente, resultan innecesarios.
o Distribución
 Representa los Dispositivos y Equipos, mostrar sus
interconexiones y el Software que se encuentra en cada
maquina
.
 Modela la distribución en tiempo de ejecución de los
elementos de procesamiento y componentes de
software, junto a los procesos y objetos asociados.

o Distribución
 Un nodo es un recurso de ejecución, representa un
recurso de ejecución tal como:
 Dispositivos
 Procesadores
 Memoria
 Sistema Operativos
 Bases de Datos

o Distribución
 Un Nodo es un elemento físico, que existe en tiempo de
ejecución y representa un recurso computacional que
generalmente tiene alguna memoria y, a menudo,
capacidad de procesamiento.
 Cada nodo puede contener instancias de componentes.
 Los nodos se interconectan mediante soportes

bidireccionales que pueden a su vez estereotiparse.
 Esta vista permite determinar las consecuencias de la
distribución y la asignación de recursos.
Diagrama de Despliegue o
Distribución

o Distribución

o Distribución
DBServer
App
Server
Serverlets
Jsp
Jdbc
Cliente
Web Browser
Relación entre Nodos y Componentes

o Distribución

o Distribución
terminal
Despliega
user.exe
servidor unidad RAID
Despliega
dbadmin.exe
terminal
user.exe
consola
Despliega
admin.exe
config.exe
servidor unidad
RAID
admin.exe
consola
dbadmin.exe
config.exe

Unidad II-Apoyo UML

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad II-Apoyo UML

Cargado por

Copyright:

Formatos disponibles

Unidad II.

Los casos de uso se emplean para capturar el comportamiento deseado del

 Un caso de uso describe un conjunto de secuencias,

 Estos comportamientos son funciones a nivel del

 Un caso de uso representa un requisito funcional del

Desarrollo de proyectos de Software

 Un caso de uso representa un requisito funcional del sistema.

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

 Los escenarios son a los casos de uso lo que las

 Para cada caso de uso, puede haber escenarios

Desarrollo de proyectos de Software

 Se definen tres tipos de relación en los Casos de

Desarrollo de proyectos de Software

 La generalización entre casos de uso es como la

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

<<include>> reemplazó al denominado <<uses>>

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Caso de Uso Origen Caso de Uso Destino

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

 Los casos de uso, se utilizan generalmente para

 Modelado del comportamiento

Desarrollo de proyectos de Software

 La mayoría de las veces, los casos de uso se utilizan

 Cuando se modela el comportamiento de estos

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

2.1.2. Diagrama de Actividades

 Los diagramas de actividades pueden utilizarse para

 Gráficamente, un diagrama de actividades es una

 Generalmente los diagramas de actividades

Desarrollo de proyectos de Software

 Existen dos formas de representar los puntos de

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

 El símbolo para enviar la

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software

Poner café Añadir agua Coger taza

 Una cosa especialmente útil cuando se modelan flujos

Desarrollo de proyectos de Software

Desarrollo de proyectos de Software