Introduccin a UML Marcela Varas Contenidos 1 2
- Slides: 46
Introducción a UML Marcela Varas
Contenidos 1. 2. 3. UML: qué es UML Parte Estática Taller
1. UML: Qué es Lo que implica que sea unificado Componentes: Vistas y Diagramas Ejemplos
Unified Modeling Language l l Lenguaje de Modelado Visual de Propósito general Usos: l l Especificar, visualizar, construir y documentar artefactos de un sistema software. Se diseñó de manera de independizarlo del método de desarrollo, y se intenta que sea aplicable a todas las etapas del ciclo de vida del software
UML: “Unificado” l l l Cruza los métodos y notaciones anteriores Cruza los ciclos de desarrollo Cruza los dominios de aplicación Cruza las plataformas y lenguajes de implantación Cruza los procesos de desarrollo Cruza los conceptos internos
UML: Componentes l l l l l Vista Estática Vista de Casos de Uso Vista de Interacción Diagrama de Secuencia Diagrama de Colaboración Vista de la Máquina de Estados Vista de Actividades Vista Física Vista de la Gestión del Modelo Constructores de Extensibilidad
UML Estático Vista Diagramas Conceptos Principales Vista Estática Diagrama de Clases Clase, Asociación, Generalización Dependencia, Realización, Interfase Vista de Casos de Uso Diagrama de Casos de Uso Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso Vista de Implementación Diagrama de Componentes Componente, Interfaz, Dependencia, Realización Vista del despliegue (deployment) Diagrama de Despliegue Nodo, Componente, Dependencia, Locación
Diagrama de Clases
Diagrama de Casos de Uso
Diagrama de Componentes
Diagrama de Despliegue
UML Dinámico Vista Diagramas Conceptos Principales Vista de Máquina de Estados Diagrama de Estados (statechart) Estado, Evento, Transición, Acción Vista de actividades Diagrama de Actividades Vista de Interacción Diagrama de Secuencia Estado, Actividad, Transición de compleción, Juntura (join), Bifurcación (fork) Interacción, Objeto, Mensaje, Activación Diagrama de Colaboración, Interacción, Rol de colaboración, Mensaje
Diagrama de Estados
Diagrama de Actividades
Diagrama de Secuencia
Diagrama de Colaboración
UML Gestión del Modelo Vista Diagramas Conceptos Principales Vista de la gestión del modelo Diagrama de Clases Paquete, Subsistema, Modelo Extensibilidad Vista Diagramas Conceptos Principales Todas Todos Restricción, Estereotipo, Valores tagged (etiquetados)
Vista de la Gestión del Modelo
Extensibilidad
2. UML Parte Estática l. Diagrama de Casos de Uso l. Diagrama de Clases
Diagrama de Casos de Uso l l Modela la funcionalidad de un sistema percibido desde el usuario externo (actor). Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema. Pueden describirse en varios niveles de detalle. Un caso de uso se implementa como una colaboración en la vista de interacción.
Diagrama de Casos de Uso: Elementos Actor: Caso de Uso: l rol que juega un usuario con respecto al sistema. l Operación o tarea específica que se l un Actor no realiza tras una orden necesariamente de algún agente representa a una externo, originada por persona en particular, una petición de un sino más bien la labor actor o bien desde la que realiza frente al invocación desde otro sistema. caso de uso
Diagrama de Casos de Uso: Relaciones Asociación: Dependencia o Instanciación: l Es el tipo de relación más básica que indica l Es una forma muy particular de relación la invocación desde un entre clases, en la cual actor o caso de uso a una clase depende de otra operación (caso de otra, es decir, se uso). instancia (se crea).
Diagrama de casos de Uso: Relaciones de Generalización l l l Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). Se diferencian por el estereotipo <<uses>> (uso) o (<<extends>>) (herencia). l extends: Se recomienda utilizar cuando un caso de uso es similar a otro (en sus características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
Diagrama de Casos de Uso: Ejemplo Máquina Recicladora El sistema debe : 1. Registrar el número de ítemes ingresados. 2. Imprimir un recibo cuando el usuario lo solicita, que incluye (a) una descripción de lo depositado, (b) el valor de cada item y (c) el total 3. El usuario/cliente presiona el botón de comienzo 4. Existe un operador que desea saber lo siguiente: (a) Cuántos ítemes han sido retornados en el día y (b) al final de cada día, un resumen de todo lo depositado. 5. El operador debe además poder cambiar información asociada a ítemes y dar una alarma en el caso de que (a) un item se atore o (b) no hay más papel.
Máquina Recicladora: Identificación de Actores
Máquina Recicladora: Diagrama Completo
Diagrama de Clases l l l Modela los conceptos del dominio de la aplicación. Permite visualizar las relaciones entre las clases que involucran el sistema Un diagrama de clases está compuesto por los siguientes elementos: l l l Clases: atributos, operaciones y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Responsabilidades
Diagrama de Clases: Elementos Clase l Es la unidad básica que encapsula toda la información de un Tipo de Objeto (un objeto es una instancia de una clase).
Diagrama de Clases: Elementos Atributo l l Los atributos describen a una clase. Pueden ser Públicos, Privados o Protegidos. public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. l l private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia)
Diagrama de Clases: Elementos Operaciones (métodos) l l Las operaciones o métodos de una clase describen la forma en la cual ésta interactúa con su entorno. Pueden ser Públicas, Privadas o Protegidas. public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. l l private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la misma clase lo pueden acceder). protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia)
Diagrama de Clases: Elementos Relaciones entre Clases l l Las clases interrelacionadas modelan un sistema en su dimensión estática. Existen tres tipos de relaciones básicas: l l l Dependencia Generalización Asociación
Relaciones entre Clases: Dependencia (instanciación o uso) l Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana) l l La interpretación más frecuente es la de uso: una clase usa a otra como argumento de una operación. El objeto creado no se almacena en el objeto que lo crea.
Relaciones entre Clases: Generalización l l Relaciona una abstracción general (superclase) con una más concreta del mismo tipo (subclase) Una clase puede tener cero, una (herencia simple) o más superclases (herencia múltiple) l l Una clase sin superclases es una clase raíz Una clase sin subclases es una clase hoja
Relaciones entre Clases: Generalización - Polimorfismo l Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones. l l l Un objeto de una subclase puede sustituir a un objeto de la superclase en cualquier contexto. Lo inverso no es cierto Una operación de la subclase con igual signatura que una operación de la superclase la anula y sustituye. El polimorfismo es muy útil en la programación.
Relaciones entre Clases: Generalización
Relaciones entre clases: Asociación l l Relación estructural entre las clases. En general es simétrica Tiene un nombre, que la describe (verbo, con dirección de lectura) Puede tener un rol que describe el papel específico que una clase juega en una asociación. l Tiene multiplicidad, que especifica por cada clase el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación: 1 : uno 0. . 1 : cero o uno 3 : tres *: muchos 1. . *: al menos uno 2, 6, 7: dos, seis o siete 2 -4, 10 -12 : de dos a cuatro y de diez a doce
Relaciones entre clases: Asociación
Relaciones entre Clases Agregación y Composición Permite modelar objetos complejos, en base a relaciones todo –parte. l l l Composición Relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. El Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo“, como un parámetro pasado “por valor”. l l l Agregación Relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. El objeto base utiliza al incluido para su funcionamiento, como un parámetro pasado “por referencia”.
Relaciones entre Clases: Agregación y Composición Agregación (Por referencia) Composición (Por valor)
Diagrama de Clases: Elementos Responsabilidades La distribución de responsabilidades en un sistema, se realiza identificando un conjunto de clases que colaboran entre sí para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase
Diagrama de Clases
3. Caso Para el caso descrito, desarrolle: l. Diagrama de Casos de Uso l. Diagrama de Clases
Gestión de Proyectos de Informática El sistema debe manejar lo siguiente: l l l Unidad organizacional que solicita el proyecto Nombre del proyecto Organización del proyecto Planificación del proyecto (actividades, responsables, plazos, recursos asignados) Control del proyecto (nivel de avance, productos entregados) Se debe, además, manejar información de los recursos humanos involucrados ( nombre, perfil, filiación ). El sistema debe entregar: l l Plan del proyecto Avance del proyecto
Bibliografía y Referencias: Fundamental l James Rumbaugh, Ivar Jacobson, Grady Booch, “The Unified Modeling Language Reference Manual”, Addison Wesley, 1999 Craig Larman, “UML y Patrones”, Prentice Hall, 1999 OMG www. omg. org
Bibliografía y Referencias Complementaria l l Rational www. rational. com Robert Muller, “Database Design For Smarties: Using UML for Data Modeling”, Morgan Kaufmann, 1999 Luis Guerrero, “Taller de UML”, DCC, Universidad de Chile, 2002, www. dcc. uchile. cl/~luguerre/cc 61 j Patricio Salinas, “Tutorial de UML”, DCC, Universidad de Chile, 2000, www. dcc. uchile. cl/~psalinas/uml
- Introduccin
- Introduccin
- Introduccin
- Introduccin
- Que diferencia hay entre filosofia y ciencia
- Introducción de enzimas
- Mda uml
- Alejandra varas oftalmologa
- Marcela boni evangelista
- Marcela bernal
- Excavacion papilar aumentada
- Marcela fejtová
- Marcela sarmiento
- Dcl
- Dra alejandra varas
- Ing. marcela pavlová
- Altas cumbres puerto varas
- Marcela saeb lima
- Marcela boni evangelista
- Altas cumbres puerto varas
- Vara verde de alamo
- Marcela ruz
- Pistola haga forestal
- Marcela donoso
- Higgs singlet
- Medida de varas
- Marcela botero
- Varas feiten
- Los planetas exteriores
- 20 varas de lienzo
- Leggi di de morgan logica
- Esttico
- Marcela pulido
- Marcela saeb lima
- Marcela palominos
- Casa donoso wine
- Marcela veselkova
- Marcela boni evangelista
- Tapato
- Personajes de la espada en la piedra
- Muerte de yenny marcela
- Altas cumbres puerto varas
- Contenidos conceptuales procedimentales y actitudinales
- Contenidos de aprendizaje.
- Contenidos desarrollados
- S-nhyzk-bvg -site:youtube.com
- Contenidos interdisciplinares