2. Modelamiento de Software
El Software
Definición: Conjunto de instrucciones que cuando se ejecutan
proporcionan la FUNCIÓN y el RENDIMIENTO deseado, las
estructuras de datos que permiten a los programas manipular
adecuadamente la información y los documentos que describen
la operación y uso de los programas.
Caracteristicas: El software se desarrolla, no se fabrica. Ejemplo: En
el Software es fácil corregir los errores de la fase de diseño, en el
hardware en cambio es muy difícil.
El Software no se estropea o desgasta (“pero si pasa de moda”).
La mayoría del Software se construye A LA MEDIDA, en vez de
ensamblar componentes existentes.
Profesor Rodrigo Cabello S.
3. Modelamiento de Software
¿Qué es un proyecto de Software?
• Desarrollo de un sistema
• Estudio de factibilidad
• Análisis
• Diseño
• Evaluaciones de aplicaciones
• Cursos de entrenamiento
• Instalación (equipo, software, redes, etc…)
Profesor Rodrigo Cabello S
4. Modelamiento de Software
¿Tipos de aplicaciones de Software?
• Software de sistemas
• Software de tiempo real
• Software de gestión
• Software de cómputos y cálculos
• Software de inteligencia
• Software basado en la web
• etc…
Profesor Rodrigo Cabello S.
5. Modelamiento de Software
¿Por qué un proyecto falla?
• Fallos en el final:
• Aplicaciones entregadas sin ser probadas y depuradas
• Coste de mantenimiento demasiado alto
• No es funcional
• Fallos en el desarrollo:
• Análisis y diseño defectuosos
• Mala selección de herramientas
• Mala asignación de tareas
• Falta de seguimiento y control sobre las tareas
Profesor Rodrigo Cabello S
7. Modelamiento de Software
Ingeniería del Software
ISW = Ingeniería del software
Inicialmente la programación de los computadores
era un arte que no disponía de métodos
sistemáticos en lis que poder basarse para la
realización de productos de software. Se
realizaban sin ninguna planificación.
Profesor Rodrigo Cabello S.
8. Modelamiento de Software
Ingeniería del Software
Evolución de la ISW (60´)
El esfuerzo requerido para el mantenimiento de los software era en la
mayoría de los casos tan elevado que hacia imposible su
mantenimiento.
A continuación, surge una etapa que se caracteriza por la aparición de una
serie de técnicas como la programación estructurada y las
metodologías de diseño que solucionan los problemas anteriores.
A finales de esta etapa aparecen las herramientas CASE, aunque muy
rudimentarias.
Profesor Rodrigo Cabello S
9. Modelamiento de Software
Ingeniería del Software
• Evolución de la ISW (70´)
• Surgen diversas técnicas y metodologías formales de diseño de sistemas.
• Cada una introdujo notaciones propias, visiones distintas, sin embargo todas
introducían características comunes:
• Mecanismos de traducción de necesidades a una representación del diseño
• (Ej. Diagramas de contexto).
• Notaciones para representar funcionalidades e interfaces
• Refinamiento y partición(Modularidad)
• Criterios de valorización de la calidad
Profesor Rodrigo Cabello S.
10. Modelamiento de Software
Ingeniería del Software
• Evolución de la ISW (80´ - 90´)
• A final de los años 80´s surgió el diseño orientado a objetos
(DOO).
• En los 90´ s se afianza la tecnología orientada a objetos.
• Evolución de las herramientas CASE.
• Explosión del fenómeno WWW, INTRANETS, JAVA.
• Como producto de lo anterior surge UML.
Profesor Rodrigo Cabello S
13. Modelamiento de Software
Ingeniería del Software
• Afirmaciones de las áreas responsables de desarrollar el
software
• Área gestión:
• Tenemos libros que contiene estándares y procedimientos
para construir software
• Los programadores disponen de herramientas de desarrollo
mas avanzadas y los equipos mas modernos por eso se
espera que desarrollen software de calidad.
• Si se falla en la planificación, podemos añadir mas
programadores y se resuelve.
Profesor Rodrigo Cabello S.
14. Modelamiento de Software
Ingeniería del Software
• Afirmaciones de las áreas responsables de desarrollar el
software
• Área Desarrolladores:
• El software es fácil de desarrollar
• El software consiste en programas ejecutables
• El desarrollo del software es solo una labor de programación
• Es natural que el software contenga errores
• Hasta que no tengo el ejecutable no tengo posibilidad de
comprobar la calidad
Profesor Rodrigo Cabello S
15. Modelamiento de Software
Ingeniería del Software
• Afirmaciones de las áreas responsables de desarrollar el
software
• Cliente:
• Una declaración básica del requerimiento es suficiente para
que puedan empezar a desarrollar mi software, los detalles
los podemos ver mas adelante.
• Los requisitos del negocio cambian continuamente pero el
software es flexible y estos cambios se pueden agregar
fácilmente
Profesor Rodrigo Cabello S.
17. Modelamiento de Software
UML
¿Qué es UML?
es un Lenguaje de Modelado Unificado
basado en una notación gráfica la cual permite:
especificar, construir, visualizar y documentar los
objetos de un sistema programado.
Este lenguaje es el resultado de la unificación de
los métodos de modelado orientados a objetos de
Booch, Rumbaugh (OMT: Object Modeling
Technique) y Jacobson (OOSE: Object−Oriented
Sotfware Engineering).
Profesor Rodrigo Cabello S
18. Modelamiento de Software
UML
¿Por qué es necesario el UML?
• Es necesario con un plan bien analizado
• El cliente debe entender lo que realizara la empresa y los
desarrolladores
• El desarrollo es orientado a equipo, por lo tanto cada uno de
los miembros tiene que saber qué lugar toma trabajo en la
solución.
• Poder organizar el proceso de diseño de tal forma que los
analistas, clientes, desarrolladores y otras personas
involucradas en el desarrollo, puedan comprender e
interferir en el.
Profesor Rodrigo Cabello S.
19. Modelamiento de Software
UML
¿Para que sirve UML?
El lenguaje unificado de diagrama o notación (UML) sirve para especificar,
visualizar y documentar esquemas de sistemas de software orientado a
objetos. UML no es un método de desarrollo, lo que significa que no
sirve para determinar qué hacer en primer lugar o cómo diseñar el
sistema, sino que simplemente le ayuda a visualizar el diseño y a
hacerlo más accesible para otros.
Profesor Rodrigo Cabello S
20. Modelamiento de Software
UML
UML cubre la documentación de un sistema:
– Requisitos
– Arquitectura
– Diseño
– Código fuente
– Planificación
– Pruebas
– Prototipos
– Versiones
Profesor Rodrigo Cabello S.
21. Modelamiento de SW
Profesor Rodrigo Cabello S.
Modelos o Diagramas de UML,
descripción, características y ejemplos
22. Modelamiento de Software
Modelos y Diagramas
Un proceso de desarrollo de software debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las
perspectivas de interés
El código fuente del sistema es el modelo más detallado del
sistema (y además es ejecutable). Sin embargo, se requieren otros
modelos
Cada modelo es completo desde su punto de vista del sistema, sin
embargo, existen relaciones de trazabilidad entre los diferentes
modelos
Profesor Rodrigo Cabello S.
23. Modelamiento de Software
Modelos y Diagramas
• Modelo: Captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema, considerando un cierto propósito.
• Diagrama: Representación gráfica de una colección de
elementos de modelado, a menudo dibujada como un grafo con
vértices conectados por arcos.
Profesor Rodrigo Cabello S
24. Modelamiento de Software
Modelos y Diagramas
Diagramas del UML
La finalidad de los diagramas es presentar diversas perspectivas de un
sistema, a las cuales se les conoce como modelo. El modelo UML de un
sistema es similar a un modelo a escala de un edificio junto con la
interpretación del artista del edificio. Es importante destacar que un
modelo de UML describe lo que supuestamente hará un sistema, pero no
dice como implementar dicho sistema.
Profesor Rodrigo Cabello S.
25. Modelamiento de Software
• Diagramas UML
Profesor Rodrigo Cabello S.
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboración
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
Diagrams
Component
Diagrams
Diagramas de
Distribución
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Modelo
26. Modelamiento de Software
Diagramas UML
Diagrama de clases
Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes
que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos.
Muestra de una manera estática la estructura de información del sistema y la visibilidad
que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.
Profesor Rodrigo Cabello S
Nom de la
clase
Atributos
Métodos
27. Modelamiento de Software
Diagramas UML
• Diagrama de interacción
• Estos son modelos que describen como los grupos de objetos que colaboran
en algunos ambientes. Por lo general, un diagrama de interacción captura el
comportamiento de un único caso de uso
• Hay dos tipos de diagramas de interacción:
• diagramas de secuencia
• diagramas de colaboración
Profesor Rodrigo Cabello S.
28. Modelamiento de Software
Diagramas UML
Diagrama de secuencia
Un diagrama de secuencia muestra la interacción de un conjunto de
objetos de una aplicación a través del tiempo. Esta descripción es
importante porque puede dar detalle a los casos de uso, aclarándolos
al nivel de mensajes de los objetos existentes, como también muestra
el uso de los mensajes de las clases diseñadas en el contexto de una
operación.
Profesor Rodrigo Cabello S
30. Un diagrama de secuencia representa una interacción como
un gráfico bidimensional.
La dimensión vertical: es el eje del tiempo
La dimensión horizontal muestra los roles de clasificador
que representan objetos individuales en la colaboración
Un rol de clasificador:
Es la descripción de un objeto que desempeña un determinado
papel dentro de una interacción, distinto de los otros objetos de
la misma clase.
31. Cuando está implementado el comportamiento,
cada mensaje en un diagrama de secuencia
corresponde a:
Una operación en una clase,
A un evento disparador, o
A una transición en una máquina de estados.
32. ACTIVACION:
Es la ejecución de un procedimiento, incluyendo el tiempo
que espera a los procedimientos anidados para
ejecutarse.
Muestra el periodo de tiempo en el cual el objeto se
encuentra desarrollando alguna operación, bien sea por sí
mismo o por medio de delegación a alguno de sus
atributos.
Se denota como un rectángulo delgado sobre la línea
de vida del objeto.
34. Mensaje
El mensaje denota el hecho de aportar
información de un objeto (u otra instancia) a otro.
Puede ser una señal o llamadas a una operación.
La notación para UML del envío de mensajes
entre objetos es con una flecha dirigida, desde el objeto
que emite el mensaje hacia el objeto que lo ejecuta.
35. Tipos de flujos de control:
Los envíos síncronos (flujos de control plano)
Muestran la progresión al próximo paso de la secuencia.
Son envíos secuenciales, en los que el emisor está
bloqueado y espera que el receptor haya terminado de
tratar el mensaje;
36. Los envíos o flujos de control asíncronos:
En los que el emisor no está bloqueado y puede continuar
su ejecución.
Llamada a procedimiento u otro flujo de control anidado
La secuencia anidada completa debe finalizar antes de
reanudar la secuencia de nivel externo.
Se puede emplear en llamadas normales a procedimiento.
También se puede usar con objetos activos
concurrentemente cuando uno de ellos envía una señal y
espera a que finalice una secuencia de comportamiento
anidada.
37. Retorno de una llamada a procedimiento
La flecha de retorno puede suprimirse, por cuanto queda
implícita al final de la activación
39. Modelamiento de Software
Diagramas UML
Diagrama de colaboración
Es una forma de representar interacción entre los objetos, es decir,
las relaciones entre ellos y la secuencia de los mensajes de las
iteraciones que están indicadas por un número A diferencia de los
diagramas de secuencia, pueden mostrar el contexto de la
operación (cuáles objetos son atributos, cuáles temporales, etc) y
ciclos en la ejecución. Muestra como varios objetos colaboran en
un solo caso de uso.
Profesor Rodrigo Cabello S
40. Modelamiento de Software
Diagramas UML
El Diagrama de Colaboración modela la interacción
entre los objetos de un Caso de Uso
Los objetos están conectados por enlaces (links) en los
cuales se representan los mensajes enviados
acompañados de una flecha que indica su dirección
El Diagrama de Colaboración ofrece una mejor visión del
escenario cuando el analista está intentando
comprender la participación de un objeto en el sistema
Profesor Rodrigo Cabello S
41. Modelamiento de Software
Diagramas UML
• Son útiles en la fase exploratoria para
identificar objetos
• La distribución de los objetos en el diagrama
permite observar adecuadamente la
interacción de un objeto con respecto de los
demás
• La estructura estática viene dada por los
enlaces; la dinámica por el envío de
mensajes por los enlaces
Profesor Rodrigo Cabello S
42. Modelamiento de Software
Diagramas UML
Un mensaje desencadena una acción en
el objeto destinatario
Profesor Rodrigo Cabello S
Interacciones
Los objetos interactúan entre sí pasándose mensajes.
Los objetos se conectan a través de enlaces
Mensaje: especifica transmisión de información entre objetos.
Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje
a otro objeto.
Es una conexión semántica entre objetos.
Es una instancia de una relación.
Puede contener los adornos de la relación.
43. Las Interacciones modelan aspectos dinámicos del
sistema
Llamada Invoca una operación sobre un objeto. Puede ser a sí
mismo.
Retorno.-El receptor de una llamada devuelve un valor al emisor
si es necesario.
Envío.- Envía una señal a un objeto.
44. Ejemplo: Un lector solicita un libro al bibliotecario, y le
brinda su título. El bibliotecario busca el libro en un índice y
solicita al asistente que le alcance el libro.
Diagrama de secuencia
Solicita un libro
brindándole el titulo
busca el libro
devuelve información
solicita que le alcance el libro
el libro es entregado
entrega el libro
LECTOR BIBLIOTECARIO ASISTENTE
INDICE
45. Diagrama de colaboración
5:El libro es entregado()
4:Solicita que le alcance el libro ()
2:Busca el libro ()
3:devuelve información ()
6:Entrega libro ()
1:Solicita libro ()
dándole el titulo ()
LECTOR
BIBLIOTECARIO
ASISTENTE
INDICE
46. Modelamiento de Software
Diagramas UML
Diagrama de estados
Muestra el conjunto de estado 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. Esta representado principalmente por
los siguientes elementos:
Estado.
Elemento.
Transición.
Profesor Rodrigo Cabello S
48. Modelos en UML
• Modelado de Casos de Uso
– Diagrama de Casos de Uso
• Modelado Estructural
– Diagrama de Clases
• Modelado de Comportamiento
– Diagramas de Interacción: Secuencia y Comunicación
– Diagramas de Estados
• Modelado de flujos de actividades (p.e. Modelo del Negocio)
– Diagramas de actividades
• Modelado Implementación
– Diagrama de Componentes
• Modelado de Despliegue
– Diagramas de Artefactos
– Diagramas de Despliegue
49. Modelo
• Un modelo captura una vista de un sistema físico.
• Es una abstracción de ese sistema con cierto
propósito, para cierto conjunto de personas
interesadas y a cierto nivel de abstracción.
• Un modelo contiene todos los elementos de
modelado necesarios.
• Un modelo y sus elementos se representan mediante
diagramas, que expresan una vista del modelo.
50. Vistas UML: 4 + 1
Vista de Diseño
Vista de Implementacion
Vista de Interacción Vista de Despliegue
Vista de casos de uso
vocabulario
funcionalidad
ensamblado
gestion conf.
topología
entrega
distribución
instalación
capacidad de procesamiento
escalabilidad
rendimiento
comportamiento
51. Vistas UML: 4 +1
Vista de Diseño
Vista de Implementacion
Vista de Interacción Vista de Despliegue
Vista de casos de uso
clases
interfaces
colaboraciones
componentes
nodos
clases activas
casos de uso
52. Vistas UML
Vista de Diseño
Vista de Implementación
Vista de Interacción
Vista de Despliegue
Vista de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado
Diagramas de componentes
Diagrama de interacción
Diagramas de estado
Diagramas de despliegue
Diagramas de casos de uso
Diagramas de clase
Diagramas de interacción
Diagramas de estado
53. Modelamiento de Software
Diagramas UML
Diagrama de Actividades
Generalmente modelan los pasos de un algoritmo y puede dar detalle a un
caso de uso, un objeto o un mensaje en un objeto.
Sirven para representar transiciones internas, sin hacer mucho énfasis en
transiciones o eventos externos.
Los elementos que conforman el diagrama son:
Acción
Transición.
Objetos
Profesor Rodrigo Cabello S
54. Diagramas de Actividad
• Representa una actividad.
• Formado por nodos conectados por arcos:
– nodos acción y actividad
– nodos de control, como control de
concurrencia y decisión
– nodos objeto
– flujos de control y de flujo de objetos
• Una actividad o una acción produce algún
efecto que provoca algún cambio en el
sistema o retorna un valor.
55. Nodos de Actividad
• Nodos de acción
– Realizan un trabajo: llamadas a operaciones,
actividades, comportamiento, envío de
señales, aceptar un evento.
• Nodos de control
– Controlan el flujo de la actividad
• Nodos de objetos
– Objetos o datos utilizados en la actividad
• Flujo de control de la actividad
• Flujo de objetos en la actividad
57. Bifurcación
Obtener orden
de trabajo
Volver a
planificar
[ material no disponible ]
Asignar tareas
[ material disponible ]
Obtener siguiente
orden de trabajo
Nodo de
fusión
Nodo de
decisión
69. Utilidad de los diagramas de
actividad
• Modelado de flujos de trabajo (workflow) como son los
procesos de negocio (business process).
• Se puede asociar a cualquier elemento de modelado, pero
lo más normal es asociarlo a una operación: diagrama de
flujo de las acciones.
71. Modelo del
Negocio
Cambiar
admitidos
Registrar Curso
Hay alumnos?
no
Cerrar Curso
Aprobar Curso
Preinscripción
Matriculación
Cancelar Curso
Hay alumnos?
no
Avisar
Admitidos
Crear Proyecto
Sistema
Alumno
Servicio PE
Responsable
Diagrama de
actividades
72. Modelamiento de Software
Diagramas UML
Diagrama de Componentes
Los diagramas de componentes describen los elementos físicos
reemplazables del sistema y sus relaciones
Muestran las opciones de realización incluyendo código fuente, binario
y ejecutable
Profesor Rodrigo Cabello S
73. Modelamiento de Software
Diagramas UML
Diagrama de Componentes
¿Que es un componente?
Un componente de software, es una parte fisica de un sistema.
Se encuentran en las computadoras, NO en la mente del analista.
Ej.
Una tabla
Archivo de datos
Un ejecutable
Documentos
Etc…
Profesor Rodrigo Cabello S
74. Modelamiento de Software
Diagramas UML
Diagrama de Componentes
• ¿Cuál es la relación entre un componente y una clase?
• La clase representa la abstracción de un conjunto de atributos y
operaciones.
• El componente es la implementación de una o mas clases
Profesor Rodrigo Cabello S
75. Modelamiento de Software
Diagramas UML
Diagrama de Componentes
• ¿Cuál es la relación entre un componente y una clase?
• La clase representa la abstracción de un conjunto de atributos y
operaciones.
• El componente es la implementación de una o mas clases
Profesor Rodrigo Cabello S
76. COMPONENTE
• Un componente es una parte física de un sistema (modulo, base de datos,
programa ejecutable, etc.). Se puede decir que un componente es la
materialización de una o mas clases, porque una abstracción con atributos
y métodos pueden ser implementados en los componentes.
• En un DC, un componente se representa con un rectángulo en el que se
escribe su nombre y en el se muestran dos pequeños rectángulos al lado
izquierdo. O también los siguientes:
Representación simple de un Componente
77. • Estereotipos de componentes
UML define cinco estereotipos estándar que se aplican en los
componentes
• Executable, componente que se puede ejecutar
• Library, biblioteca de objetos estática o diná
• mica
• Table, Componentes que representa una tabla de base de
datos
• File, componente que representa un documento que contiene
código fuente o datos
• Document, Comp. Que representa un documento.
78. INTERFACES
• Es el lazo de unión entre varios componentes.
Donde C es el nombre de la interfaz.
79. • Las interfases pueden representarse de varias
formas, como vemos en la grafica:
81. ¿En que fase del ciclo de vida se
encuentra?
• Se presenta en el diseño que da paso a la
implementación
El diagrama de Componentes se genera a partir
del diagrama de clases
Dependencias
82. Pasos para la elaboración de un diagrama
de componentes
• previamente al diagrama de componentes debemos de tener hecho el
diagrama de clases.
• Se debe identificar a todos las clases que participaran en el sistema o
subsistema a desarrollar.
• Una vez identificado las clases, se procede a identificar sus métodos.
• Estos métodos pasaran a ser módulos con líneas de código
independientes.
• Estos módulos serán los componentes de nuestro diagrama.
• Estos componentes se relacionan entre si por medio de sus interfaces.
83. ¿Por qué utilizar un Diagrama de
Componentes?
Nos permite ver el modelado de un sistema o
subsistema
permite especificar un componente con
interfaces bien definidas.
84. si los componentes se diseñan de tal
forma que puedan ser tratados tan
independientemente podrán ser
reutilizados
85. Diagrama de Componentes
• Relación con diagrama de clases
• Métodos de la clase pasan a ser módulos
• Módulos pasan a ser componentes.
Nombre
Atributo
Métodos
86. Diagrama de Componentes
• Diferencias:
• Un componente representa un elemento físico (bits). Una clase es una
abstracción lógica.
• El componente se puede representar en nodos físicos, la clase no.
• Las operaciones de un componente solo se alcanzan a través de
interfaces. Las de una clase podrían ser accesibles directamente.
87.
88. Clasificación de procedimientos
• Pedido
• Registro_contrato
• Elaboracion_contartos
• Imprecion_contrato
• Consulta _ productos
• Búsqueda _ producto
• Cobro_deuda_anterior
• Actualización _ registro
• Búsqueda _ cuenta
• Actualización _ registro
91. Modelamiento de Software
Diagramas UML
Diagramas de componentes
RESUMEN
Con este tipo de diagramas se representan entidades reales, esto
es, componentes de software. Un componente de software
puede ser una tabla, un archivo de datos, un ejecutable,
documentos, un applet de Java, etc.
Profesor Rodrigo Cabello S.
93. Modelamiento de Software
Diagramas UML
Diagramas de componentes
RESUMEN
• Al igual que lo que ocurre con las clases, los componentes pueden ofrecer una interfaz, para que otros
componentes puedan realizar las operaciones ofrecidas por dicho interfaz. Podemos hablar ahora de otros
dos conceptos como son la sustitución y la reutilización. Se puede sustituir un componente por otro si este
último contiene las mismas interfaces que el anterior. Se puede reutilizar un componente si se puede
acceder a dicho componente de manera adecuada a través de sus interfaces.
• El símbolo del componente es el siguiente es un rectángulo con otros dos rectángulos sobrepuestos. En
Enterprise Architect, los componentes se muestran como un rectángulo, que contiene el símbolo del
componente en una esquina
Profesor Rodrigo Cabello S.
94. Modelamiento de Software
Diagramas UML
Diagrama de despliegue
Los diagramas de despliegue muestran la disposición física de los distintos nodos que componen
un sistema y el reparto de los componentes sobre dichos nodos
Profesor Rodrigo Cabello S.
95. Diagramas de Despliegue
Diagramas de despliegue
• Describen la arquitectura física del sistema durante la
ejecución, en términos de:
– procesadores
– dispositivos
– componentes de software
• Describen la topología del sistema: la estructura de los
elementos de hardware y el software que ejecuta cada
uno de ellos.
96. • Los nodos son objetos físicos que existen en tiempo de
ejecución, y que representan algún tipo de recurso
computacional (capacidad de memoria y procesamiento):
– Computadores con procesadores
– Otros dispositivos
• impresoras
• lectoras de códigos de barras
• dispositivos de comunicación
Dell Pentium
466 MMX
máquina1:
Dell Pentium
466 MMX
Ventas
Despliega
pos.exe
contactos.exe
Diagramas de Despliegue
97. Dispositivos
• Los dispositivos del sistema también se representan como
nodos.
• Generalmente se usan estereotipos para identificar el tipo de
dispositivo.
HP LaserJet
5MP
<<printer>>
Cisco Router
X2000
<<router>>
Diagramas de Despliegue
98. • Los nodos se conectan mediante asociaciones de
comunicación.
• Estas asociaciones indican:
– Algún tipo de ruta de comunicación entre los nodos
– Los nodos intercambian objetos o envían mensajes a
través de esta ruta
• El tipo de comunicación se identifica con un estereotipo que
indica el protocolo de comunicación o la red.
Diagramas de Despliegue
100. Nodos y componentes
Los nodos son los elementos donde se ejecutan los componentes.
Ventas
pos.exe contactos.exe
Diagramas de Despliegue
101. • Si un tipo de componente puede ejecutarse en un tipo de
nodo, se crea una dependencia con el estereotipo
<<supports>>
– Una instancia de la componente podría localizarse en
una instancia de ese nodo.
UNIX Transaction
Server Program
Silicon
Graphics O2
<<supports>>
Diagramas de Despliegue
102. máquina1:Dell Pentium 466 MMX
<<library>>
CL:Transaction
Client Library
cliente1:Cliente
Instancias ejecutándose en un nodo.
Diagramas de Despliegue
103. Modelamiento de Software
Diagramas UML
Diagrama de Casos de usos
Es una descripción de las acciones de un sistema desde el punto de vista
del usuario. Para los desarrolladores del sistema, esta es una
herramienta valiosa, ya que es una técnica de aciertos y errores para
obtener los requerimientos del sistema desde el punto de vista del
usuario.(NO SOLO POR EXPERTOS EN COMPUTACION)
Profesor Rodrigo Cabello S
105. Modelamiento de Software
Diagramas UML
Diagrama de colaboración
• Un Diagrama de Colaboración muestra una interacción organizada
basándose en los objetos que toman parte en la interacción y los
enlaces entre los mismos (en cuanto a la interacción se refiere).
• UML –Interacciones
Los objetos interactúan entre sí pasándose mensajes.
Los objetos se conectan a través de enlaces.
• Mensaje: especifica transmisión de información entre objetos.
• Enlace: especifica un camino a lo largo del cual un objeto puede enviar
un mensaje a otro objeto
Profesor Rodrigo Cabello S
106.
107. Un diagrama de secuencia representa una interacción como
un gráfico bidimensional.
La dimensión vertical: es el eje del tiempo
La dimensión horizontal muestra los roles de clasificador
que representan objetos individuales en la colaboración
Un rol de clasificador:
Es la descripción de un objeto que desempeña un determinado
papel dentro de una interacción, distinto de los otros objetos de
la misma clase.