Download - Introduccion a UML-Mvc
1
Introducción a UMLIntroducción a UML
Marcela VarasIngeniero Civil informático
Mag. en Cs. de la Computación
. Diciembre de 2002
Contenidos
1. Conceptos Básicos [0.5 hora]2. UML: qué es [0.5 hora]3. UML Parte Estática [1 hora]4. Diseño de Bases de Datos con UML [1
hora]5. Caso [1 hora]
2
1. Conceptos Básicos
•Dimensiones de los Sistemas Software•Paradigma de la Orientación a Objetos
Conceptos Básicos:Dimensiones de los Sistemas
SoftwareDimensión 1: Tipo de Componente
Interfaz - Lógica de Procesamiento -Repositorio
Dimensión 2: Tipo de ComportamientoEstático – Dinámico - Funcional
Dimensión 3: Nivel de AbstracciónConceptual – Lógico -Físico
3
Conceptos Básicos:Paradigma Orientación a Objetos
• Paradigma procedural ( hasta fines de los 70s)• Tipo de Componente: Lógica de Procesamiento• Nivel de Abstracción: Físico y Lógico• Tipo de Comportamiento: Funcional
• Paradigma Bases de Datos (aún vigente)• Tipo de Componente: Repositorio• Nivel de Abstracción: alcanza hasta el nivel conceptual• Tipo de Comportamiento: Estático
Conceptos Básicos:Paradigma Orientación a Objetos• Paradigma Orientación a Objetos (desde
principios de los 80s)• Tipo de Componente: Todos• Tipo de Comportamiento: Todos• Nivel de abstracción: Todos
• Ideas Fuerza: • Encapsulamiento (-> cohesión)• Reuso• Bajo Acoplamiento• Mayor Expresividad y Naturalidad
4
2. UML
A continuación ...
2. UML: Qué es
•Lo que implica que sea unificado•Componentes: Vistas y Diagramas•Ejemplos
5
Unified Modeling Language
• Lenguaje de Modelado Visual de Propósito general
• Usos:• 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”
• 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
6
UML: Componentes
• 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áticoVista Diagramas Conceptos Principales
Vista Estática Diagrama de Clases
Clase, Asociación, GeneralizaciónDependencia, 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
Vista del despliegue (deployment)
Diagrama de Componentes
Componente, Interfaz, Dependencia, Realización
Diagrama de Despliegue
Nodo, Componente, Dependencia, Locación
7
Diagrama de Clases
Diagrama de Casos de Uso
8
Diagrama de Componentes
Diagrama de Despliegue
9
UML DinámicoVista 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
Estado, Actividad, Transición de compleción, Juntura (join), Bifurcación (fork)
Vista de Interacción
Diagrama de Secuencia
Interacción, Objeto, Mensaje, Activación
Diagrama de Colaboración
Colaboración, Interacción, Rol de colaboración, Mensaje
Diagrama de Estados
10
Diagrama de Actividades
Diagrama de Secuencia
11
Diagrama de Colaboración
UMLGestión del Modelo
Vista Diagramas Conceptos Principales
Vista de la gestión del modelo
Diagrama de Clases
Paquete, Subsistema, Modelo
Vista Diagramas Conceptos Principales
Todas Todos Restricción, Estereotipo, Valores tagged(etiquetados)
Extensibilidad
12
Vista de la Gestión del Modelo
Extensibilidad
13
3. UML Parte Estática
A continuación ...
3. UML Parte Estática
•Diagrama de Casos de Uso•Diagrama de Clases
14
Diagrama de Casos de Uso
• 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:• rol que juega un
usuario con respecto al sistema.
• un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
Caso de Uso:• Operación o tarea
específica que se realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso
15
Diagrama de Casos de Uso: ElementosRelaciones
Asociación:• Es el tipo de relación
más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso).
Dependencia o Instanciación:• Es una forma muy
particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Diagrama de casos de Uso: Elementos
Relaciones de Generalización
• 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).
• 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.
16
Diagrama de Casos de Uso: EjemploMá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
17
Máquina Recicladora: Diagrama Completo
Diagrama de Clases
• 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: • Clases: atributos, operaciones y visibilidad. • Relaciones: Herencia, Composición,
Agregación, Asociación y Uso. • Responsabilidades
18
Diagrama de Clases: Elementos
Clase• 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: ElementosAtributo
• 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.
• 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)
19
Diagrama de Clases: Elementos
Operaciones (métodos)• 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.
• 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: ElementosRelaciones entre Clases
• Las clases interrelacionadas modelan un sistema en su dimensión estática.
• Existen tres tipos de relaciones básicas:• Dependencia• Generalización• Asociación
20
• Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana)
• 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:Dependencia (instanciación o
uso)
Relaciones entre Clases:Generalización
• 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)
• Una clase sin superclases es una clase raíz
• Una clase sin subclases es una clase hoja
21
Relaciones entre Clases:Generalización - Polimorfismo
• Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones.• 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
22
Relaciones entre clases:Asociación
• 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.
• 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 : uno0..1 : cero o uno3 : tres*: muchos1..*: al menos uno2,6,7: dos, seis o siete2-4, 10-12 : de dos a cuatro y
de diez a doce
Relaciones entre clases:Asociación
23
Relaciones entre ClasesAgregación y Composición
• 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 contruyea partir del objeto incluido, es decir, es "parte/todo“, como un parámetro pasado “por valor”.
• 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”.
Permite modelar objetos complejos, en base a relaciones todo –parte.
Relaciones entre Clases:Agregación y Composición
Agregación(Por referencia)
Composición(Por valor)
24
Diagrama de Clases: ElementosResponsabilidades
La distribución de responsabilidades en un sistema, se realizaidentificando 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
25
4. Diseño de Bases de Datos con UML
A continuación ...
4. Diseño de Bases de Datos con UML
•Consideraciones Generales•Bases de datos OO y Objeto-Relacionales•Consideraciones de Diseño•Patrones
26
Consideraciones Generales
• Persistencia• Restricciones y Reglas del Negocio• Limitaciones de los Productos
Comerciales• Patrones Reusables
Bases de Datos Orientadas a Objetos
• No existe un modelo formal• Primitivas básicas: objeto y literal.• Objetos y literales pertenecen a un tipo.• El estado de un objeto está definido por los valores
actuales de sus propiedades: atributos y relaciones con otros objetos.
• El comportamiento de un objeto está definido por el conjunto de operaciones que pueden aplicarse o ser ejecutadas por el objeto
• Una BDOO almacena objetos, posibilitando que sean compartidos por múltiples usuarios y aplicaciones.
27
Bases de Datos Orientadas a Objetos
• Herencia• Ciclo de vida del objeto• Listas y punteros : no normalización• Operaciones• Diferentes arquitecturas. Aún no hay
estándar.
Bases de Datos Objeto-Relacionales:Extensiones de Tipos Básicos
• Linking Dinámico de funciones definidas por el usuario
• Activación cliente-servidor de funciones definidas por el usuario
• Integración de funciones definidas por el usuario y aplicaciones middleware
• Funciones seguras• Callback en funciones• Métodos de acceso definidos por el usuario• Tipos de datos de largo arbitrario• Manejo de almacenamiento abierto
28
Bases de Datos Objeto-Relacionales:Objetos Complejos
• Constructores de tipos• Conjunto de• Registro de• Referencia
• Funciones definidas por el usuario• Tipos de datos complejos de largo arbitrario• Soporte SQL
Bases de Datos Objeto-Relacionales:Herencia
• Herencia de datos y funciones• Sobrecarga• Herencia de tipos, no tablas• Herencia múltiple
29
Bases de Datos Objeto-Relacionales:Sistema de Reglas
• Eventos y Acciones son recuperadas como actualizaciones
• Integración de reglas con herencia y extensiones de tipos
• Ejecución de reglas semánticas• Control de ciclos infinitos
Consideraciones de Diseño
• OID• Persistencia• Definición del Comportamiento:
• Operaciones: serán métodos persistentes. Se diseñan dejando abierta la implementación (por restricciones de los productos comerciales)
• Triggers:Manejador de eventos. Se declaran en UML con el estereotipo «signal» en el método.
• Procedimientos almacenados: operación que el sistema no asocia explícitamente con una clase.
30
Restricciones y Reglas del Negocio:Identificación
• Identidad de Objeto y Restricción de Unicidad• Identificación implícita (OID) versus• Identificación explicita (value based)
• Se declaran con tagged values:• {OID}• {alternate OID}
• Propiedades de unicidad y minimalidad
Restricciones y Reglas del Negocio:
Identificación
31
Restricciones y Reglas del Negocio:Dominios
• El dominio de un atributo es el conjunto de valores que dicho atributo mapea.
• Los dominios se declaran por extensión o intensión.• Extensión: se declara explícitamente el conjunto de objetos
que pertenecen al dominio• Intensión: predicado lógico.
• UMNL no especifica un modelo para dominios, sólo tipos de datos
Restricciones y Reglas del Negocio:Dominio – Tipos de Datos
• Un tipo de dato es un tipo cuyos valores no tienen identidad, son sólo valores.
• Se deben utilizar los constructores de tipos de datos (primitiva, estructura y enumeración) para definir dominios.
32
Restricciones y Reglas del Negocio:Restricciones Complejas
• OCL: Object Constraint Language• Lenguaje declarativo que se puede utilizar en
clases y operaciones, entre otros.• No soportado por la herramientas.
• Se declaran utilizando notaciones en los diagramas.
Restricciones y Reglas del Negocio: Utilizando Notaciones para Declararlas
33
Patrones de Diseño
• Los patrones de diseño capturan soluciones que han sido desarrolladas y evolucionan en el tiempo. Capturan soluciones probadas y eficientes en forma sucinta y fácilmente aplicable.
• Conflicto: inhibición de la creatividad versus reuso y eficiencia.
Patrones de Diseño
• Patrones Abstractos: describen soluciones genéricas a problemas genéricos.• Patrón singleton: Asegura que una clase tenga
sólo una instancia en la base de datos.• Patrón Composite: Representa una estructura de
árbol hehca de distintos tipos de objetos relacionados. Se utiliza para representar jerarquías parte-todo en la base de datos.
34
Patrón Singleton
Patrones de Diseño
• Patrones de Análisis: Es un modelo de un problema de un dominio específico.• Patrón party: modela personas y organizaciones y
la relación de empleo entre ellos.• Patrón Geographic Location Pattern: Modela redes
de áreas geográficas.• Patrón Process: modela procesos de manufactura
continuos.• Patrón Document : modela documentos, su
estructura y usuarios.
35
Patrón Party
Patrón Document
36
Patrón Land Record
Región
Comuna
Acto
Access Management
37
Gerencia (stewardship)
5. Caso
A continuación ...
38
5. Caso
Para el caso descrito, desarrolle:•Diagrama de Casos de Uso•Diagrama de Clases
Gestión de Proyectos de Informática
El sistema debe manejar lo siguiente:• 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:
• Plan del proyecto• Avance del proyecto
39
Otras cosas Interesantes
• Proceso Unificado de Desarrollo• Modelamiento del negocio con UML• Desarrollo Basado en Componentes• Uso de Patrones• Vistas no Cubiertas • Herramientas de Apoyo
Bibliografía y Referencias: Fundamental
• James Rumbaugh, Ivar Jacobson, GradyBooch, “The Unified Modeling LanguageReference Manual”, Addison Wesley, 1999
• Craig Larman, “UML y Patrones”, Prentice Hall, 1999
• OMG www.omg.org
40
Bibliografía y ReferenciasComplementaria
• Rational www.rational.com• Robert Muller, “Database Design For Smarties: Using
UML for Data Modeling”, Morgan Kaufmann, 1999• Marcela Varas, “Apuntes de Modelamiento de Datos”,
asignaturas.inf.udec.cl/~moddatos/apuntes• Luis Guerrero, “Taller de UML”, DCC, Universidad de
Chile, 2002, www.dcc.uchile.cl/~luguerre/cc61j• Patricio Salinas, “Tutorial de UML”, DCC, Universidad
de Chile, 2000, www.dcc.uchile.cl/~psalinas/uml
Introducción a UMLIntroducción a UMLMarcela Varas
Ingeniero Civil informáticoMag. en Cs. de la Computación