UML y Patrones POO Flashcards
¿Cual seria el proceso de desarrollo de un modelo Orientado a Objetos?
–No muy importante—
Fase1) ANALISIS
DETECCION DE PROBLEMA Y CASOS DE USO
Diagrama de caso de uso (requisitos funcionales)
Diagrama de clases (entidades/relaciones): clases (atriburos y metodos) + relaciones (asociacion/ agregacion/ composicion/ herencia)
Fase2) DISEÑO / ARQUITECTURA
a) Elección de arquitectura:
+ MVC –> Te marca una serie de módulos / subsistemas: presentacion, logica, modelo, persistencia…..:
- PRESENTACION:
- LOGICA –> Classes (ej. En Spring @Service)
- MODELO –> Clases (clases + interfaces+ relaciones de dependencia)
- PERSISTENCIA –> Clases (ej. En Spring @Repository)
+ ….
b) Diseño de bajo nivel
Ej.: Si tengo objetos muy complejos de crear –> Patron tipo “Factory”
Si tengo objetos com mucho ciblo de vida (estados) –> Patron tipo “State”
Fase3) IMPLEMENTACION
Estructura UML 2.x
– No muy importante —
a) INFRAESTRUCTURA –> Metamodelo de soporte
b) SUPERESTRUCTURA –> Notación semantica de los diagramas
c) OCL –> Lenguaje para definir restricciones / reglas. Se puede agregar a muchos diagramas. ej.: clase Meeting inv: self.end > self.start –> obliga a fecha fin mayor que fecha ini
d) UML Data Interchange –> .XMI. Estandard de intercambio de información entre herramientas CASE
Mecanismos de extensión UML
a) Esteriotipo –> Añade semántica a un elemento «_space;UI»_space; que no la tiene por si mismo. Ej.: para definir una interfaz en un diagrama de clases: «interface»
b) Restricciones –> { ordered } Para definir una regla. ej.: que una lista de productos este ordenada
c) Valores Etiquetados –> { procesadores = 3 } Definición de valores fijos. ej.: un atributo con valor fijo
d) Perfiles –> Conjunto de Estereotipos, restricciones, valores etiquetados para una tematica dada
Conceptos de POO. ADOO
a) Clase –> Define una estructura y comportamiento de una entidad dada
b) Objeto –> Elemento donde almacenar info. Estado (contenido o ifo que tiene dentro el obj). Identidad (identificacion univoca)
c) Método –> Implementación de un determnado comportamiento. Sobrecarga
d) Atributo –> Datos de negoio o referencias a otros objetos
c) Mensaje –> Llamada a un método sobre un objeto
Principios de POO
a) Abstracción –> Capturar los detalles de negocio al modelar. 1º Objs 2º Clases
b) Encapsulación –> Ocultación de detalles internos del objeto. Reducir acoplamiento
c) Polimorfismo –> Objetos de distintas clases ‘se hagan pasar’ por el mismo tipo. Ligadura dinámica: técnica con la que se averigua el método real a ejecutar (Late binding)
d) Hereencia –> Capacidad de definir unas clases en terminos (a partir) de otras
Cual es el estandard de UML
ISO/IEC 19505: en 2012
Árbol de diagramas UML
Saberse la foto y encuadrar en los dos grandes grupos: Comportamiento y Estructurales.
Diagrama de clases
*Asociación. Las relaciones de asociación representan un conjunto de enlaces entre objetos o instancias de clases. Es el tipo de relación más general, y denota básicamente una dependencia semántica. Por ejemplo, una Persona trabaja para una Empresa.
Multiplicidad, que describe la cardinalidad de la relación, es decir, especifica cuántas instancias de una clase están asociadas a una instancia de la otra clase. Los tipos de multiplicidad son: Uno a uno, uno a muchos y muchos a muchos.
*Herencia. Las jerarquías de generalización/especialización se conocen como herencia. Herencia es el mecanismo que permite a una clase de objetos incorporar atributos y métodos de otra clase, añadiéndolos a los que ya posee. Con la herencia se refleja una relación “es_un” entre clases. La clase de la cual se hereda se denomina superclase, y la que hereda subclase.
*Agregación. La agregación es un tipo de relación jerárquica entre un objeto que representa la totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento físico de estructuras relacionadas lógicamente. Los objetos “son-parte-de” otro objeto completo. Por ejemplo, motor, ruedas, carrocería son parte de automóvil.
*Composición. La composición es una forma de agregación donde la relación de propiedad es más fuerte, e incluso coinciden los tiempos de vida del objeto completo y las partes que lo componen. Por ejemplo, en un sistema de Máquina de café, las relaciones entre la clase máquina y producto, o entre máquina y depósito de monedas, son de composición.
*Dependencia. Una relación de dependencia se utiliza entre dos clases o entre una clase y una interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus servicios.
«use» –> Marcan tipo de relacion de dependencia
Rombo vacío –> Agregación
Rombo lleno –> Composición
Línea punteada flecha abierta –> Dependencia
Línea punteada flecha cerrada –> Implementacion (interfaz)
Línea flecha cerrada –> Herencia
Flecha en mitad de una relación –> Dirección de una relacion (ej.: Autor |> escribió |> Libro)
* –> Cardinalidad 0..N
1 –> Cardinalidad 0..1
Diagrama de Componentes
Linea cabeza en C –> indica dependencia de un Ciruculo de otro componente
Linea punteada cabeza en > –> indica hacia donde va la dependencia
Circulo –> Interfaces que ofrece (operaciones). Se pueden tener varios en un componente.
Cuadrados –> Ports (puertos) por donde nos comunicamos con otros compoenntes
Diagrama de Casos de Uso
- Existe relación de herencia entre actores
- Existe relación de herencia entre casos de uso
- No todos los casos de uso son de igual “tamaño”
- No existen los casos de uso “abstractos” (ej: Gestionar …)
- Se pueden organizar en paquetes/subsistemas
- Los casos de uso no “explotan” como los DFD’s
- Los casos de uso capturan un nivel de granularidad medio-bajo
- La relación «extend» indica un comportamiento opcional. Se da solo cuando se satisfaga una determinada condicion, no es obligatorio aunque se de el caso de uso base.
- La relación «include» indica un comportamiento obligatorio. Siempre que se da el caso de uso base, se da el incluido. Nace de que se identifica un comportamiento común en el flujo de varios casos de uso y se ‘saca’ a otro caso de uso.
Lo que hay dentro de las pelotitas (caso de uso) se tiene que poder especificar con un Diagrama de Actividad.
***Importante las relaciones «extend» e «include»
Diagrama de Paquetes
Agrupa funcionalidades para que tengamos un orden legible y no todo en una misma ‘hoja’.
Paquete con un triangulo –> Modelo que agrupa otros paquetes
Diagrama de Actividad
- Nos ayudan a definir nuestros procesos de negocio y casos de uso
- Se pueden añadir los objetos sobre los que trabajan ciertas actividades
- Nos ayudan a plantear los casos de prueba (escenarios)
Diagrama de Objetos
- Representan un ejemplo de arbol de objetos en memoria
- Son útiles para analizar ciertas partes del diagrama de clases
- Los objetos están conectados mediante “enlaces”
Diagrama de Perfil
Diagrama de Transición de Estados
- Se realizar para ciertas clases con comportamiento dinamico
- Son la antesala del patrón de diseño State
- Nos ayudan a plantear ciertas pruebas Unitarias
- Tiene que haber una correspondencia con la clase correspondiente
Diagrama de Colaboración / Comunicacion e Interacción-Secuencia
- Son diagramas equivalentes
- Representan un único escenario dentro de un diagrama de actividad
- El de comunicación es algo mas completo porque vemos los enlaces entre objetos
Def M3: El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es describir el comportamiento dinámico del sistema de información haciendo énfasis en la secuencia de los mensajes intercambiados por los objetos.
Escenario: Estos diagramas representan escenarios y son representaciones de uno de los caminos que puede tomar el Diagrama de Actividad o el Caso de Uso (por ‘dentro’)
Interacción-Secuencia VS Comunicacion
SeInteracción-Secuencia: la linea temporal es la ‘vertical’
Interacción-Secuencia: No se ve la relación entre sus elementos
Comunicación: no tiene linea temporal se asignan orden a las asociaciones
Comunicación: SI que se ve la relación entre sus elementos
Diagrama de Timing
—- No es importante —
De Interacción
Que nos suene, es un cronograma de tiempos. Sistemas donde le tiempo sea crítico
Diagrama de Interaction Overview
De Interacción
Es como hacer zoom en una parte del diagrama de actividad y mostrar otros de interaccion
Diagrama de Despliegue
El diagrama anterior representa una parte del nuevo sistema que deberá desarrollarse en JAVA. En ella se muestra un diagrama UML de:
a) Despliegue
b) Componentes
c) Paquetes
d) Clases
b) Componentes
