SlideShare una empresa de Scribd logo
Lenguaje de
Modelado
Unificado
Lic. Carlos Villarroel Murga
Arquitectura de software
Es un instrumento cuya
función principal es la de
intervenir en favor del
hombre
James M Fitch.
Necesitamos soluciones para problemas reales, no
inventar problemas para afrontar con nuevas soluciones
Arquitectura de software
Viéndolo de esa forma, en realidad el rol de un
arquitecto de edificaciones y un arquitecto de
software parecen enfrentar los mismos retos
Arquitectura de software
No es lo mismo
construir esto
Arquitectura de software
Que esto!!!
Arquitectura de software
O esto ?
Arquitectura de software
Que esto!!!
Cada escenario plantea retos,
condiciones y necesidades
diferentes!
Arquitectura de software
Que herramientas, personas
presupuesto, conocimiento y tiempo
necesitamos para cada escenario?
Arquitectura de Software
Todas las consideraciones que
se tienen que tomar en
cuenta para definir la
arquitectura de edificaciones ,
deberían ser tomadas en
cuenta también al definir una
Arquitectura de software
Mansión Winchester
 160 Habitaciones
 3 Ascensores
 47 Chimeneas
 Sistema de
Alcantarillado y
calefacción
Todo Adelantado
para su época 1922
La arquitectura de esta
mansión sorprende y
escapa a los limites de
la razón
Mansión Winchester
Se pueden encontrar puertas que dan
a paredes o que están en medio de las
ventanas, etc.
Mansión Winchester
Qué tiene que ver esto con
la arquitectura de software
Esta situación es mas común de lo que
debería en el desarrollo de software
Cuando un desarrollador es asignado a la
tarea de mantener y/o actualizar un sistema
legado, cuya arquitectura tiene fallas o no
esta documentada.
Elegimos reconstruir partes o crear nuestras
propias rutas dentro el código.
“Programar sin una arquitectura en mente es como
explorar una gruta solo con una linterna: no sabes
dónde estás, dónde has estado ni hacia dónde vas”
Danny thorpe
Analogía Arquitectónica
 Tiene sentido poner ladrillos sin hacer
antes los planos?
 El modelo, los planos, ayudan a afrontar
la complejidad del proyecto.
 ¿Cuál es el lenguaje adecuado para
representar los planos?
Comunicación y Representación
del Conocimiento
 Para representar el conocimiento hace falta un
lenguaje adecuado
 El conocimiento bien representado ayuda a hacerse
las preguntas oportunas:
 ¿qué falta aquí?
 ¿qué pasaría si...?
 ¿por qué no se puede...?
¿Qué es un Modelo?
 Abstracción o simplificación de la realidad
 Modelado y lenguaje
 El lenguaje es vehículo del pensamiento: ayuda
a pensar con claridad
 El modelado es un elemento esencial del
proceso de desarrollo de software
 El modelado requiere un lenguaje adecuado
 Modelar no es hacer diagramas sino pensar
con diagramas
Propiedades [Deseables]
de un Modelo
 Comprensible: Expresado de tal forma
que se pueda entender fácilmente.
 Preciso: Representa fielmente el sistema
modelado.
 Predictivo: Se puede utilizar para obtener
conclusiones correctas sobre el sistema.
 Barato: Más económico que construir y
estudiar el propio sistema.
UML
(Unified Modeling Language)
Historia UML
UML
Es un lenguaje para:
 Visualizar
 Especificar
 Construir
 Documentar
Artefactos de sistemas intensivos de software
Lenguajes de modelado,
modelos y diagramas
 Un lenguaje de modelado permite expresar los
distintos modelos que se producen en el
proceso de desarrollo.
 Un modelo es una representación abstracta de
una especificación, un diseño o un sistema
desde un punto de vista particular.
 Un diagrama es una representación de (parte
de) un modelo de diseño
 Un modelo se representa por uno o mas
diagramas
Lenguaje de Modelado UML 2.0
 Elementos primitivos de modelado
(estáticos, dinámicos, agrupamiento, anotaciones)
 Relaciones
 Dependencia
 Asociación
 Generalización
 Realización
 Diagramas UML (13 diagramas)
 Diagramas estáticos
 Diagramas de comportamiento
RELACIONES
Dependencia
Una relación semántica entre dos elementos, tal que
un cambio en una de ellos (el independiente) puede
afectar al otro (el dependiente).
A B
“B depende de A”
RELACIONES
Asociación
Es una relación estructural que describe un
conjunto de links, siendo un link una conexión
entre objetos
0..1 *
empleador empleado
RELACIONES
Generalización
Una relación de generalización/especialización
en la que el elemento especializado
(descendiente) se construye sobre la
especificación del elemento generalizado
(ancestro)
RELACIONES
Realización
Es una relación semántica en la que un clasificador,
tal como una interfaz o un caso de uso, especifica
un “contrato” que otro clasificador, tal como una
clase o una colaboración, garantiza llevar a cabo.
DIAGRAMAS UML
Diagramas estáticos
Diagrama de clases
Diagrama de componentes
Diagrama de distribución
Diagramas UML
Diagramas de comportamiento
 Diagramas de casos de uso
 Diagrama de secuencia
 Diagrama de colaboración
 Diagrama de estados
 Diagrama de actividades
Diagrama de Casos de Uso
 Parte desde el punto de
vista del usuario final.
 Da una buena pauta
para conocer más a
fondo los requisitos que
deberá tener el sistema
a desarrollar.
 Muestra la manera en la
que un usuario final va a
interactuar con el
sistema sin tomar en
cuenta los mecanismos
que se van a utilizar
para crear o hacer
funcionar el sistema.
Diagrama de Estados
 Conforme un sistema
interactúa con los
usuarios y otros sistemas,
sus objetos pasan por
cambios que ajustan las
interacciones.
 Un cambio en un sistema
se da debido a que los
objetos que componen
dicho sistema
modificaron su estado
como respuesta a los
sucesos y al tiempo.
 Un diagrama de estados
también se conoce
como un "motor de
estado."
Diagrama de Secuencias
 Muestra una interacción ordenada según la
secuencia de eventos vista a la luz de una
línea de tiempo.
 Muestra los objetos participantes en la
interacción y los mensajes que intercambian.
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.
 A diferencia de los diagramas de secuencia, los
diagramas de colaboración muestran las relaciones
entre los roles de los objetos.
Diagrama de Actividades
 Es en cierta medida, un diagrama de flujo reforzado.
 Muestra los pasos (conocidos como actividades) así
como puntos de decisión y bifurcaciones
 Muestran una visión simplificada de lo que ocurre
durante una operación o proceso.
Diagrama de Componentes
 Un componente de
software es una parte
física de un sistema, y se
encuentra en la
computadora, no en la
mente del analista.
 Ejemplos de
componentes son tablas,
archivos de datos,
ejecutables, bibliotecas
de vínculos dinámicos,
documentos y cosas por
el estilo.
 Contiene componentes,
interfaces y relaciones.
Diagrama de Distribución
 Se enfoca
específicamente al
hardware de un sistema
determinado.
 El elemento primordial
del hardware es un
nodo, que es un
nombre genérico para
todo tipo de recurso de
cómputo.
 Cada uno de los nodos
puede contener otros
componentes,
incluyendo software,
Diagrama de Clases
 Describe la estructura de un sistema mostrando las
clases del sistema, sus atributos, operaciones (o
métodos), y las relaciones entre los objetos.
 Se utiliza para
que la atención
se centre en los
aspectos lógicos
de las clases en
lugar de en su
implementación
.
Herramientas de Modelado
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Presentacion de uml (2)
Conclusiones
A diferencia de los
arquitectos de
edificaciones, los
arquitectos de
software son los
encargados de
construir la base de
la arquitectura de los
proyectos
Conclusiones
En desarrollo de software
servirá de guía para el
desarrollo de un sistema
Planos y maquetas
en arquitectura
Conclusiones
A través de los
diagramas se
representa el diseño
y distribución del
software, pueden
mostrar diferentes
vistas de un mismo
sistema y de las
condiciones que
existen en el
entorno donde se
despliega
Conclusiones
Es la herramienta por
excelencia que
utilizan los arquitectos
de software.

Más contenido relacionado

PPT
Objeto de Aprendizaje : Introducción a UML
PPTX
Lenguaje Unificado de Modelado (UML)
PDF
Modelado de requisitos
PPT
MODELAMIENTO VISUAL Y UML
PPTX
Diagrama de secuencia. soruco
PPT
Modelos de dominio
PPT
UML: CASOS DE USO
Objeto de Aprendizaje : Introducción a UML
Lenguaje Unificado de Modelado (UML)
Modelado de requisitos
MODELAMIENTO VISUAL Y UML
Diagrama de secuencia. soruco
Modelos de dominio
UML: CASOS DE USO

La actualidad más candente (20)

PPTX
UML - Analisis de Sistemas
PDF
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
PPS
Modelo conceptual
DOCX
Aplicaciones del modelo y especificaciones
PDF
El lenguaje de modelado unificado
PPT
Vista lógica
DOCX
Arquitectura del software
DOCX
13 tipos de diagramas uml, la metodología de desarrollo ágil de software y la...
PPTX
Enfoque estructurado y Enfoque OO - Ingenieria de software
PPTX
Diseño detallado
PDF
10.el diseño en el nivel de componentes
PPTX
2 2 estilos arquitectonicos
PPTX
Diseño Estructurado
PPT
Introducción a UML
DOC
Deber analisis
PPT
Lenguaje Unificado de Modelado
PPT
Modelado del AnáLisis
DOCX
La arquitectura de 41 vistas
PPTX
Diseño de-la-arquitectura-de-software
DOCX
Desarrollo estructurado
UML - Analisis de Sistemas
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
Modelo conceptual
Aplicaciones del modelo y especificaciones
El lenguaje de modelado unificado
Vista lógica
Arquitectura del software
13 tipos de diagramas uml, la metodología de desarrollo ágil de software y la...
Enfoque estructurado y Enfoque OO - Ingenieria de software
Diseño detallado
10.el diseño en el nivel de componentes
2 2 estilos arquitectonicos
Diseño Estructurado
Introducción a UML
Deber analisis
Lenguaje Unificado de Modelado
Modelado del AnáLisis
La arquitectura de 41 vistas
Diseño de-la-arquitectura-de-software
Desarrollo estructurado
Publicidad

Similar a Presentacion de uml (2) (20)

PPT
ADS - Sesion2
PPT
Modelamiento visual-y-uml346
ODP
PPT
9. introducción a uml
DOCX
Glosario de terminos
PPTX
Lenguaje de modelado unificado uml
PDF
MetodoMadesi_3_03.pdf
PDF
UML - Diagramas de Actividades, componentes y clases
PPT
Tema 2.UML parte 1.ppt
DOCX
Arquitectura de software.docx
PPTX
PPTX
Diagramas uml
PPTX
PPTX
DOCX
Diagramas de flujo
PPTX
PPTX
UML(Lenguaje Unificado de Modelado)
ODP
PDF
Diccionario
DOCX
Patrones
ADS - Sesion2
Modelamiento visual-y-uml346
9. introducción a uml
Glosario de terminos
Lenguaje de modelado unificado uml
MetodoMadesi_3_03.pdf
UML - Diagramas de Actividades, componentes y clases
Tema 2.UML parte 1.ppt
Arquitectura de software.docx
Diagramas uml
Diagramas de flujo
UML(Lenguaje Unificado de Modelado)
Diccionario
Patrones
Publicidad

Último (20)

PDF
Conecta con la Motivacion - Brian Tracy Ccesa007.pdf
PDF
Gasista de unidades unifuncionales - pagina 23 en adelante.pdf
PDF
La Evaluacion Formativa en Nuevos Escenarios de Aprendizaje UGEL03 Ccesa007.pdf
PDF
SESION 12 INMUNIZACIONES - CADENA DE FRÍO- SALUD FAMILIAR - PUEBLOS INDIGENAS...
PDF
Fundamentos_Educacion_a_Distancia_ABC.pdf
PDF
Crear o Morir - Andres Oppenheimer Ccesa007.pdf
DOCX
III Ciclo _ Plan Anual 2025.docx PARA ESTUDIANTES DE PRIMARIA
PDF
Escuelas Desarmando una mirada subjetiva a la educación
DOCX
V UNIDAD - PRIMER GRADO. del mes de agosto
PDF
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
PDF
IDH_Guatemala_2.pdfnjjjkeioooe ,l dkdldp ekooe
PPTX
AGENTES PATÓGENOS Y LAS PRINCIPAL ENFERMEAD.pptx
PDF
Metodologías Activas con herramientas IAG
PDF
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
PDF
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
PDF
Lección 6 Escuela Sab. A través del mar rojo.pdf
PDF
OK OK UNIDAD DE APRENDIZAJE 5TO Y 6TO CORRESPONDIENTE AL MES DE AGOSTO 2025.pdf
PDF
Unidad de Aprendizaje 5 de Matematica 1ro Secundaria Ccesa007.pdf
PDF
Unidad de Aprendizaje 5 de Educacion para el Trabajo EPT Ccesa007.pdf
PDF
COMUNICACION EFECTIVA PARA LA EDUCACION .pdf
Conecta con la Motivacion - Brian Tracy Ccesa007.pdf
Gasista de unidades unifuncionales - pagina 23 en adelante.pdf
La Evaluacion Formativa en Nuevos Escenarios de Aprendizaje UGEL03 Ccesa007.pdf
SESION 12 INMUNIZACIONES - CADENA DE FRÍO- SALUD FAMILIAR - PUEBLOS INDIGENAS...
Fundamentos_Educacion_a_Distancia_ABC.pdf
Crear o Morir - Andres Oppenheimer Ccesa007.pdf
III Ciclo _ Plan Anual 2025.docx PARA ESTUDIANTES DE PRIMARIA
Escuelas Desarmando una mirada subjetiva a la educación
V UNIDAD - PRIMER GRADO. del mes de agosto
Salvese Quien Pueda - Andres Oppenheimer Ccesa007.pdf
IDH_Guatemala_2.pdfnjjjkeioooe ,l dkdldp ekooe
AGENTES PATÓGENOS Y LAS PRINCIPAL ENFERMEAD.pptx
Metodologías Activas con herramientas IAG
Didactica de la Investigacion Educativa SUE Ccesa007.pdf
Educación Artística y Desarrollo Humano - Howard Gardner Ccesa007.pdf
Lección 6 Escuela Sab. A través del mar rojo.pdf
OK OK UNIDAD DE APRENDIZAJE 5TO Y 6TO CORRESPONDIENTE AL MES DE AGOSTO 2025.pdf
Unidad de Aprendizaje 5 de Matematica 1ro Secundaria Ccesa007.pdf
Unidad de Aprendizaje 5 de Educacion para el Trabajo EPT Ccesa007.pdf
COMUNICACION EFECTIVA PARA LA EDUCACION .pdf

Presentacion de uml (2)

  • 2. Arquitectura de software Es un instrumento cuya función principal es la de intervenir en favor del hombre James M Fitch. Necesitamos soluciones para problemas reales, no inventar problemas para afrontar con nuevas soluciones
  • 3. Arquitectura de software Viéndolo de esa forma, en realidad el rol de un arquitecto de edificaciones y un arquitecto de software parecen enfrentar los mismos retos
  • 4. Arquitectura de software No es lo mismo construir esto
  • 7. Arquitectura de software Que esto!!! Cada escenario plantea retos, condiciones y necesidades diferentes!
  • 8. Arquitectura de software Que herramientas, personas presupuesto, conocimiento y tiempo necesitamos para cada escenario?
  • 9. Arquitectura de Software Todas las consideraciones que se tienen que tomar en cuenta para definir la arquitectura de edificaciones , deberían ser tomadas en cuenta también al definir una Arquitectura de software
  • 10. Mansión Winchester  160 Habitaciones  3 Ascensores  47 Chimeneas  Sistema de Alcantarillado y calefacción Todo Adelantado para su época 1922 La arquitectura de esta mansión sorprende y escapa a los limites de la razón
  • 11. Mansión Winchester Se pueden encontrar puertas que dan a paredes o que están en medio de las ventanas, etc.
  • 12. Mansión Winchester Qué tiene que ver esto con la arquitectura de software
  • 13. Esta situación es mas común de lo que debería en el desarrollo de software Cuando un desarrollador es asignado a la tarea de mantener y/o actualizar un sistema legado, cuya arquitectura tiene fallas o no esta documentada. Elegimos reconstruir partes o crear nuestras propias rutas dentro el código. “Programar sin una arquitectura en mente es como explorar una gruta solo con una linterna: no sabes dónde estás, dónde has estado ni hacia dónde vas” Danny thorpe
  • 14. Analogía Arquitectónica  Tiene sentido poner ladrillos sin hacer antes los planos?  El modelo, los planos, ayudan a afrontar la complejidad del proyecto.  ¿Cuál es el lenguaje adecuado para representar los planos?
  • 15. Comunicación y Representación del Conocimiento  Para representar el conocimiento hace falta un lenguaje adecuado  El conocimiento bien representado ayuda a hacerse las preguntas oportunas:  ¿qué falta aquí?  ¿qué pasaría si...?  ¿por qué no se puede...?
  • 16. ¿Qué es un Modelo?  Abstracción o simplificación de la realidad  Modelado y lenguaje  El lenguaje es vehículo del pensamiento: ayuda a pensar con claridad  El modelado es un elemento esencial del proceso de desarrollo de software  El modelado requiere un lenguaje adecuado  Modelar no es hacer diagramas sino pensar con diagramas
  • 17. Propiedades [Deseables] de un Modelo  Comprensible: Expresado de tal forma que se pueda entender fácilmente.  Preciso: Representa fielmente el sistema modelado.  Predictivo: Se puede utilizar para obtener conclusiones correctas sobre el sistema.  Barato: Más económico que construir y estudiar el propio sistema.
  • 20. UML Es un lenguaje para:  Visualizar  Especificar  Construir  Documentar Artefactos de sistemas intensivos de software
  • 21. Lenguajes de modelado, modelos y diagramas  Un lenguaje de modelado permite expresar los distintos modelos que se producen en el proceso de desarrollo.  Un modelo es una representación abstracta de una especificación, un diseño o un sistema desde un punto de vista particular.  Un diagrama es una representación de (parte de) un modelo de diseño  Un modelo se representa por uno o mas diagramas
  • 22. Lenguaje de Modelado UML 2.0  Elementos primitivos de modelado (estáticos, dinámicos, agrupamiento, anotaciones)  Relaciones  Dependencia  Asociación  Generalización  Realización  Diagramas UML (13 diagramas)  Diagramas estáticos  Diagramas de comportamiento
  • 23. RELACIONES Dependencia Una relación semántica entre dos elementos, tal que un cambio en una de ellos (el independiente) puede afectar al otro (el dependiente). A B “B depende de A”
  • 24. RELACIONES Asociación Es una relación estructural que describe un conjunto de links, siendo un link una conexión entre objetos 0..1 * empleador empleado
  • 25. RELACIONES Generalización Una relación de generalización/especialización en la que el elemento especializado (descendiente) se construye sobre la especificación del elemento generalizado (ancestro)
  • 26. RELACIONES Realización Es una relación semántica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o una colaboración, garantiza llevar a cabo.
  • 27. DIAGRAMAS UML Diagramas estáticos Diagrama de clases Diagrama de componentes Diagrama de distribución
  • 28. Diagramas UML Diagramas de comportamiento  Diagramas de casos de uso  Diagrama de secuencia  Diagrama de colaboración  Diagrama de estados  Diagrama de actividades
  • 29. Diagrama de Casos de Uso  Parte desde el punto de vista del usuario final.  Da una buena pauta para conocer más a fondo los requisitos que deberá tener el sistema a desarrollar.  Muestra la manera en la que un usuario final va a interactuar con el sistema sin tomar en cuenta los mecanismos que se van a utilizar para crear o hacer funcionar el sistema.
  • 30. Diagrama de Estados  Conforme un sistema interactúa con los usuarios y otros sistemas, sus objetos pasan por cambios que ajustan las interacciones.  Un cambio en un sistema se da debido a que los objetos que componen dicho sistema modificaron su estado como respuesta a los sucesos y al tiempo.  Un diagrama de estados también se conoce como un "motor de estado."
  • 31. Diagrama de Secuencias  Muestra una interacción ordenada según la secuencia de eventos vista a la luz de una línea de tiempo.  Muestra los objetos participantes en la interacción y los mensajes que intercambian.
  • 32. 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.  A diferencia de los diagramas de secuencia, los diagramas de colaboración muestran las relaciones entre los roles de los objetos.
  • 33. Diagrama de Actividades  Es en cierta medida, un diagrama de flujo reforzado.  Muestra los pasos (conocidos como actividades) así como puntos de decisión y bifurcaciones  Muestran una visión simplificada de lo que ocurre durante una operación o proceso.
  • 34. Diagrama de Componentes  Un componente de software es una parte física de un sistema, y se encuentra en la computadora, no en la mente del analista.  Ejemplos de componentes son tablas, archivos de datos, ejecutables, bibliotecas de vínculos dinámicos, documentos y cosas por el estilo.  Contiene componentes, interfaces y relaciones.
  • 35. Diagrama de Distribución  Se enfoca específicamente al hardware de un sistema determinado.  El elemento primordial del hardware es un nodo, que es un nombre genérico para todo tipo de recurso de cómputo.  Cada uno de los nodos puede contener otros componentes, incluyendo software,
  • 36. Diagrama de Clases  Describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.  Se utiliza para que la atención se centre en los aspectos lógicos de las clases en lugar de en su implementación .
  • 48. Conclusiones A diferencia de los arquitectos de edificaciones, los arquitectos de software son los encargados de construir la base de la arquitectura de los proyectos
  • 49. Conclusiones En desarrollo de software servirá de guía para el desarrollo de un sistema Planos y maquetas en arquitectura
  • 50. Conclusiones A través de los diagramas se representa el diseño y distribución del software, pueden mostrar diferentes vistas de un mismo sistema y de las condiciones que existen en el entorno donde se despliega
  • 51. Conclusiones Es la herramienta por excelencia que utilizan los arquitectos de software.