Introducción al Análisis y Diseño Orientado a Objetos Tema 3
TACC II Curso 2008/09 1
Motivación z Un p proyecto y software no consiste sólo en p programar. g z Necesitamos saber cuáles son las necesidades del cliente. { Identificar Id tifi llos requisitos, i it anotarlos, t l analizarlos, li l validarlos. lid l
z Necesitamos diseñar una solución,, y hacer “los planos” p del software: { Diseño de la arquitectura, detallado, de datos, …
z Hay que asegurarse de que el software funciona: { Pruebas de unidad (a nivel de método y clase), de integración, del sistema de aceptación sistema, aceptación, etc. etc
z Hay que mantener el software. { Documentación (de cada una de las fases), coherencia entre los productos de las distintas fases (ej. código vs. diseños).
2
Indice
zModelos de Ciclo de Vida. zAnálisis y Diseño Orientado a Objetos Objetos. zNotaciones. zMetodologías.
3
Modelos de ciclo de vida z ¿Qué Q é estrategia t t i seguimos i para organizar i l las f fases d de un proyecto?. z Un modelo de ciclo de vida nos guia en las fases que hayy q que realizar, sus entradas y salidas, y los criterios de transición. zL La elección l ió de d uno u otro depende d d de d las l características í i del proyecto. z Con teconologías orientadas a objetos se tiende a ciclos de vida iterativos e incrementales. 4
Modelos de Ciclo de Vida Qué
/ Estudio de Viabilidad. Planificación y Estimación.
Análisis
Desventajas: •No N permite it iteraciones. it i
Cómo
Diseño
Codificación
MCV en Cascada
Pruebas e integración
Operación O ó y Mantenimiento
• Los requisitos se congelan al principio del proyecto. • No existe un proyecto “enseñable” hasta el final del proyecto.
[ ti ] [retiro] 5
Modelos de Ciclo de Vida [más iteraciones]
Iteración de A & D
Planificación
Análisis
Diseño
Incremento Planificación
Análisis
Diseño
Extraer clases reutilizables
Prototipo
Pruebas
Eval. Eval cliente
[más iteraciones]
MCV iterativo e incremental (RUP)
6
Indice zModelos M d l d de Ci Ciclo l d de Vid Vida.
zAnálisis Análisis y Diseño Orientado a Objetos. {Ventajas e inconvenientes inconvenientes. {Análisis. {Diseño. zNotaciones. zNotaciones zMetodologías. 7
Análisis y Diseño Problema vs vs. Solución Análisis (qué)
Diseño (cómo)
Dominio del problema
Dominio de la Solución
Modelo del Dominio del Problema
Modelo del Dominio de la Solución
ControlTrafico VentanaResumen Avión
PlanVuelo
Controlador Trafico Aeropuerto
VentanaMapas p
BDPlanVuelo C t lT fi ControlTrafico 8
Paradigma g de Orientación a Objetos j Características
z Diseños modulares modulares. z Efectos laterales mínimos(encapsulamiento) ( p ) z Extensibilidad. z Fácil de modificar. z Orientado a datos. z Explota la herencia (jerárquico). z Reutilización R ili ió d de clases. l 9
Ventajas z Módulos con fuerte cohesión interna y escaso acoplamiento externo (sin variables globales, …) z Facilita el funcionamiento en entorno multiprocesador (objetos distribuidos) z Correspondencia directa con el mundo real z Prototipos rápidos z Herramientas y bibliotecas muy amplias z Aplicaciones construidas enganchando objetos z Mejor comprensión y mantenimiento z Apropiado para aplicaciones dirigidas por eventos. 10
Inconvenientes z IImpactos t d f desfavorables bl sobre b espacio i y tiempo ti d de ejecución. z Forma de pensar diferente: curva de aprendizaje lenta. z Herencia y ligadura dinámica dificultan las pruebas. z Difícil seguir el flujo de ejecución (e.j. llamádas implicitas a constructores, conversiones implícitas, etc.) z Frameworks grandes y complicados (e.j. MFCs). 11
Análisis Orientado a Objetos z Centrarse en el “qué”. z Identificar los requisitos: documentos de análisis. { Entrevistas. { Identificar requisitos funcionales y no funcionales (ej.: rendimiento, fiabilidad)
z Especificar los requisitos: documento de especificación de requisitos. { Documento D t técnico. té i O Organización i ió y clasificación l ifi ió d de llos requisitos. i it
z Analizar: Modelos de análisis análisis. { Estudio de posibles escenarios: casos de uso. { Otras técnicas: fichas CRC, orientados al flujo, etc.
z Validar.
12
Análisis Orientado a Objetos z La especificación de requisitos i it d describe ib ell sistema, en lenguaje natural.
Obtención de requisitos Especificación de requisitos: Documento Análisis Modelo de Análisis: Modelo Diseño del Sistema
Modelo del Sistema: Modelo
z Sirve de comunicación entre desarrolladores y clientes, “contrato”. z El modelo de análisis usa notación formal (ej.: Z,, Alloy) y) o semi-formal (ej.: UML). z Sirve de comunicación entre desarrolladores. 13
Análisis Orientado a Objetos Modelos de Análisis Modelos basados en Escenarios Casos de uso, texto. Casos de uso, diagramas. Diagramas de actividad. Diagramas de secuencia. …
Modelos orientados al Flujo Diagramas de Flujo de Datos Diagramas de Flujo de Control Diagramas de Transición de Estados …
Modelo de Análisis Modelos basados en Clases Diagramas de Clases. Diagramas de Paquete. Modelos CRC. CRC Diagramas de Interacción. …
Modelos basados en Comportamiento Diagramas de Estado. Diagramas de Secuencia. Secuencia … 14
Análisis Orientado a Objetos Modelos de Análisis. Basado en Escenarios. Modelo de Análisis: Modelo
Modelo Funcional: Modelo
Modelo de Objetos: Modelo
Modelo Dinámico: Modelo
z Modelo funcional: casos de uso y escenarios. z Modelo de Objetos: diagramas de clases y objetos. z Modelo M d l dinámico: di á i di diagramas d de secuencia,… i 15
Casos de uso zD Describen ib qué é hace h ell sistema i t d d ell punto desde t de d vista i t de un observador externo. z Actores: ¿quién interactúa con el sistema?. También pueden ser otros sistemas. p z Un escenario es un ejemplo de lo que ocurre cuando uno o varios i actores interactúan i ú con ell sistema. i zC Caso de d uso: conjunto j t de d escenarios i ( (secuencias i d de interacción de los actores y el sistema) 16
Casos de uso z Pasos: { Identificar los lĂmites (alcance) del sistema. { Identificar los actores principales. { Para cada uno, identificar sus objetivos. { Definir casos de uso que satisfagan sus objetivos. 17
Casos de Uso: Ejemplo CASO DE USO 1: Procesar venta Actor Primario: { Cajero. C j
Interesados y objetivos: { Cajero: Quiere anotaciones precisas y rápidas de precios, sin errores. { Cliente: Cli t Q Quiere i que ell pago sea rápido á id con ell mínimo í i esfuerzo. f Q i Quiere una prueba de compra para justificar devoluciones. { Compañía: Quieren almacenar las transacciones y satisfacer los intereses de los clientes. { Comercial: Quiere que se le actualicen sus comisiones por venta. { Agencias de impuestos gubernamentales: Quieren recolectar impuestos de cada venta. Puede que haya varias agencias (nacionales, regionales, etc.) t ) { Servicios de Autorización de Pagos (por tarjetas de crédito): Quiere recibir peticiones digitales de autorizaciones en el formato y protocolo correcto.
Precondiciones: { El cajero se ha identificado y autentificado.
18
Casos de Uso: Ejemplo Garantía de éxito (Postcondiciones): Se registra la compra en el sistema. Se calcula el impuesto aplicable. Se actualizan los sistemas de inventario y de contabilidad. Se registran las comisiones. Se genera un recibo. Se registran las aprobaciones de pago por tarjeta.
Escenario principal de Exito: 1. Llega un clienta al TPV con bienes o servicios que comprar. 2. El cajero comienza una nueva compra. 3. El cajero introduce un identificador de producto. 4 El sistema 4. i t registra i t ell elemento l t y presenta t una descripción d i ió del d l mismo, i su precio i y total actual. Se calcula el precio de una lista de reglas. El cajero j repite p los p pasos 3-4 hasta q que no hayy más elementos. 5. El sistema presenta el total con los impuestos calculados. 6. El cajero le dice el total al cliente, y le pide que pague. 7 El cliente paga y el sistema procesa el pago. 7. pago 8. El sistema registra la venta completada y manda la información a los sistemas externos de inventario y contabilidad. 9. El sistema genera el recibo. 10. El cliente se va. 19
Casos de Uso: Ejemplo Extensiones (Flujos alternativos): a*. En cualquier momento, el sistema falla. 3a. Identificador inválido. 1. El sistema señala un error y rechaza la entrada. 7a. Pago en efectivo. ... 7b Pago con tarjeta 7b. tarjeta. ... Requisitos especiales: z Pantalla táctil en panel grande y plano. El texto debe ser visible desde un metro. z Respuesta de autorización de crédito en menos de 30 secs, el 90% de las veces. z Recuperación robusta cuando el acceso a sistemas externos (tales como el inventario, impuestos, etc.) falla. z Posibilidades de internazionalización de texto. z Reglas de negocio insertables en los pasos 3 y 7. ... 20
Casos de Uso: Ejemplo Lista de variaciones de tecnología y datos: 3a. Se introduce el identificador del elemento mediante escáner de código de barras o mediante el teclado. 3b. Distintos esquemas de identificadores: UPC, EAN, JAN o SKU. 7a. La información sobre el pago con tarjeta se puede introducir mediante el teclado o lector. 7b. Se pide firma en papel. En dos años, creemos que muchos clientes van a querer captura de firma digital. Frecuencia de ocurrencia: Puede ser casi continua. Temas abiertos: ¿Cuáles son las posibles variaciones en las leyes sobre impuestos? Explorar el tema de recuperación en caso de fallo de sistemas externos. ¿Qué modificaciones se necesitan para negocios distintos? ¿Debe el cajero extraer el cajón con la recaudación al terminar? ¿Puede el cliente usar directamente el lector de tarjetas o es el cajero el que lo hace? 21
Diagrama de Casos de Uso (UML) TPV Procesar Venta caje o cajero Procesar Devoluciones «actor» Analizador de Actividad de Ventas
Administrador del sistema
«actor»
Analizar Actividad
Calculador de Impuestos p
... Gestionar Seguridad Gestionar Usuarios
Servicio de Autorización de Pagos
«actor» Sistema de contabilidad
22
Modelos de Análisis Basados en Clases Identificar las clases
z Analizar los documentos de análisis, análisis o casos de uso. uso z Clases que pertenecen al espacio de la solución vs. espacio p del p problema. z Aislar los sustantivos: { Entidades externas: producen o consumen información que usa el sistema. { Cosas (informes, señales, etc.): información que necesita el sistema. { Sucesos o eventos que ocurren durante la operación del sistema. { Papeles que desempeñan los usuarios. { Unidades organizacionales. { Sitios que establecen el contexto y la función global del sistema. { Estructuras que definen una clase de objetos o clases relacionadas. 23
Diagrama de clases Conceptuales ElementoVenta cantidad
* 0..1
Concepto C t u Objeto del dominio
d descrito-por it
1
registra-ventas-de
1..* 1..
Descripcion Precio ID
1..* 1..
Producto contenido-en 1 * 1..*
fecha hora pagada-p por
1
*
capturada-en
cantidad
Cat谩logo 3 Usado-por
* 3 almacena
1
1
Tienda direcci贸n nombre
Iniciada-por 1 1
3contiene 1
1..* 3 describe
Atributos 1
Cliente
contiene 1..*
1
P Pago
1..* 1
1
Venta
Especific.Producto
1
Cajero
registra-ventas-en 1
Asociaci贸n
R i t Registro 24
1
Clasificación de clases z Tipos de clases: {De entidad (a.k.a. de modelo o de negocio). Son clases que persisten i d durante l la aplicación. li ió R Representan información relevante para la aplicación. {De frontera (a.k.a. de contorno). Clases que crean la interfaz que el usuario ve y con la que interacciona. interacciona {De control. Realizan una “unidad unidad de trabajo trabajo”:: crean o actualizan objetos de entidad, validan datos, etc.
25
Diagrama de clases de análisis Caso de uso Procesar Venta
Cajero
TPV GUI
«actor»
«actor»
«actor»
Sistema Contabilidad
Servicio Autorización Pagos
Calculador Impuestos
Calculo Precio
Registro Venta
Busqueda Elemento
1..* Venta
Elemento26 Venta
Método de Clase-ResponsabilidadColaborador (CRC) z Clases/Responsabilidades/Colaboradores. Clases/Responsabilidades/Colaboradores z Facilitan la colaboración entre desarrolladores. z Una ficha por cada clase relevante. z Se identifican sus responsabilidades. z División de responsabilidades, relaciones de colaboración. z Jerarquías de generalización/especialización. 27
Método de Clase-ResponsabilidadColaborador (CRC) Clase: PlanoDePlanta Descripción:
Responsabilidad
Colaborador
Define el nombre/tipo de plano de planta Maneja la posición del plano de planta Escala el plano de planta Incorpora paredes, puertas y ventanas
Pared
M Muestra t la l posición i ió d de llas cámaras á d de vídeo íd C Camara
28
Del Análisis al Diseño z El modelo d l de d análisis áli i d describe ib ell sistema i t d desde d el punto de vista de los actores. z No N contiene ti iinformación f ió d de lla estructura t t iinterna t del sistema, esto es del cómo. z Diseño Di ñ d dell sistema: i t {Objetivos de diseño que se deben optimizar (derivados de los requisitos no funcionales) funcionales). {Una arquitectura software: descomposición en subsistemas, dependencias entre ellos, etc.
z Diseño detallado (de objetos). {Refinamiento del diseño del sistema. {Diseño de las clases de la solución, interfaces.
29
Dise帽o Orientado a Objetos zConceptos b谩sicos de DOO: { Encapsulamiento. p { Ocultaci贸n de informaci贸n. { Herencia. Herencia { Interfaces. { Polimorfismo. P li fi
30
Diseño Orientado a Objetos j Encapsulamiento
zDesarrollador {Objetivo: j crear clase con interfaz clara y comprensible {Manera: ocultar detalles de implementación {Beneficios: cambio de estructuras/algoritmos sin afectar {Coste: clases reutilizables más caras a corto plazo
31
Diseño Orientado a Objetos j Encapsulamiento
zUsuario de las clases {Objetivo: j usar la clase con el mínimo esfuerzo {Manera: usar sólo las operaciones provistas {Beneficios: interfaz comprensible comprensible, bajo coste de programación {Coste: pérdida de eficiencia de ejecución
32
Descomposici贸n Funcional zM贸dulos construidos alrededor de las p operaciones zDatos globales o distribuidos entre m贸dulos zEntrada/Proceso/Salida zOrganigramas de trabajo y flujo de datos
33
OOD zM贸dulos construidos alrededor de las clases zClases escasamente acopladas, sin datos globales zEncapsulamiento y mensajes zDiagramas jer谩rquicos de clases
34
Definici贸n de una clase z Identificar y nombrar la clase p z Identificar sus componentes z Identificar sus atributos z Identificar los errores z Identificar las conexiones funcionales (qu茅 clases sirve/exige) z Definir conexiones con superclase y subclases z Identificar propiedades especiales (persistencia, concurrencia) z Probar la clase en un prototipo
35
Identificar atributos zEl conjunto de atributos de una clase debe ser: {Completo (contienen toda la informaci贸n pertinente) {General (se aplican a todos los objetos de la clase) {Diferenciado (cada atributo representa un aspecto diferente de la clase)
36
Definir atributos zTipos Ti d de atributos t ib t {Atómicos predefinidos (entero, real, carácter, pixel...) {Atómico enumerativo (color, día de la semana...)) {Colección {Composición (referencias objetos)
zValor del atributo {Común a muchos objetos (variable de clase) {Propio op o de u un objeto ((variable a ab e de objeto) 37
Identificar Métodos z Método: algoritmo que utiliza y modifica los atributos de una clase z Un método es desencadenado por un mensaje z Funcionalidad de la clase: conjunto de sus métodos z El conjunto de métodos debe ser: {Completo (realizan toda la funcionalidad de la clase) {General (se aplican a todos los objetos de la clase) {Diferenciado (cada método debe ser simple y realizar una sola función) 38
Definir Métodos zTipos Ti de d métodos ét d {Modificador (asigna valor a un atributo) {Selector (devuelve el valor de un atributo) {Aplicable p a la clase ((constructor)) {Aplicable al objeto
zParámetros del método {¿Qué información necesita? (argumentos de entrada) {¿Qué debe devolver? (resultado y argumentos de sa salida) da) 39
Ejemplo ElementoVenta C tid d Entero Cantidad: E t
descrito-por *
1
getSubTotal() 1..* contenido-en 1
Venta Fecha: Date hora: Time completa: Logico
captura 1
Completar() * crearElementoVenta(..) crearPago() getTotal() g () 1 pagada-por
1 1
1 Busca-en catalogo
Registro ...
Cantidad: Dinero
Catalogo g ... 1
finalizarVenta() introducirElemento(...) hacerNuevaCompra(...) realizarPago(...)
5usa 1
Tienda
1
tiene
Descripcion: Text Precio: Dinero ID: IDElemento ... 1 * 1..* 5contiene 1
getEspecificacion(...)
Direcci贸n: Direccion nombre: Texto
1
P Pago
EspecificacionProducto
1
anyadirVenta(...) 40
3Registra-completadas
1
Identificar Errores z¿Qué puede salir mal durante la ejecución de un método? z¿Qué comprobaciones debe hacer cada método? z¿Cómo interceptar y corregir las condiciones de error?
41
Patrones de Diseño z Catálogo de soluciones que han probado ser buenas para ciertos problemas comunes de diseño. z Evita “reinventar la rueda” continuamente. zR Reutilización tili ió de d buenas b prácticas, á ti común ú en otras t ingenierías. z Un patrón es una descripción del problema y la esencia de su solución, que se puede reutilizar en casos distintos. distintos z Los estudiaremos en el Tema 8. 42
Indice zModelos de Ciclo de Vida. zAnálisis. zAnálisis zDiseño.
zNotaciones. {UML zMetodologías. zMetodologías
43
UML http://uml.org
z Unified Modeling Language Language. z Combinar y estandarizar una notaci贸n para la descripci贸n de sistemas orientados a objetos a partir de los lenguajes de modelado m谩s conocidos: { Booch - OOD. OOD { Rumbaugh - OMT. { Jacobson - OOSE y Objectory.
z Combina las mejores propiedades de: { { { {
Conceptos de modelos de datos (ERD) Modelos de negocios (workflow) Modelos de Objetos Modelos de Componentes 44
UML z Es un lenguaje gráfico para visualizar visualizar, especificar especificar, construir y documentar las partes de un sistema de software desde distintos puntos de vista. z Ofrece una forma estándar de modelar sistemas software pudiendo utilizarse: software, { Con cualquier proceso de desarrollo. { A lo largo de todo el ciclo de vida. { Con C di distintas ti t ttecnologías l í d de iimplementación l t ió
z Puede usarse también en otras áreas,, como la ingeniería de negocio, modelado de procesos, etc.
45
UML z No es un método, método ni un proceso ni una metodología metodología. z No establece qué modelos construir. z Para un óptimo aprovechamiento, debe ser usado en un proceso: { guiado por casos de uso uso, { centrado en la arquitectura, { iterativo e { incremental. 46
UML zUML es una familia de notaciones, útiles para describir distintos aspectos p p de un sistema: {Estático. Describe los elementos del sistema y {Estático sus relaciones. {Dinámico Describe el comportamiento del {Dinámico. sistema a lo largo del tiempo. zCasos de Uso Uso. Desde el punto de vista del usuario usuario.
47
UML Tipos de Diagramas
UML
Modelos
48
Vistas z Vista Vi t de d C Casos d de U Uso {Funcionalidad externa del sistema
z Vista Vi t Lógica Ló i {Estructura estática y conducta dinámica del sistema
z Vista Vi t de d C Componentes t {Organización de las componentes
z Vista Vi t de d C Concurrencia i {Comunicaciones y sincronización
z Vista Vi t de d D Despliegue li {Arquitectura física 49
Vista de Casos de Uso z Dirigida g al Anรกlisis de Requisitos q ((lo q que q quiere hacer el usuario) z Describe la funcionalidad del sistema, como la perciben los actores externos z Dirige el desarrollo de las otras vistas z Define los objetivos finales del sistema z Permite validar el sistema z Actor externo: { Usuario { Otro sistema
z Se p plasma en diagramas g { de Casos de Uso { de Actividad { de Secuencia 50
Vista de Casos de Uso TPV Procesar Venta caje o cajero Procesar Devoluciones «actor» Analizador de Actividad de Ventas
Administrador del sistema
«actor»
Analizar Actividad
Calculador de Impuestos p
... Gestionar Seguridad Gestionar Usuarios
Servicio de Autorización de Pagos
«actor» Sistema de contabilidad
51
Vista Lógica zDescribe la funcionalidad interna zDirigida a diseñadores y desarrolladores zDefine la estructura estática {Clases, objetos y relaciones
zDefine Define las colaboraciones dinámicas {Mensajes y funciones
zP i d d adicionales zPropiedades di i l {Persistencia y concurrencia {Interfaces y estructura interna de las clases
52
Vista L贸gica zSe plasma en diagramas {Est谩ticos zde Clases j zde Objetos
{Din谩micos zde Estado zde Secuencia de Colaboraci贸n zde zde Actividad 53
Vista Lógica g Diagramas estáticos Elemento
Diagrama ag a a de clases Carbono
Diagrama de Di d objetos
:Hidrógeno
Hidrógeno
:Hidrógeno
:Hidrógeno
:Carbono
:Carbono
:Hidrógeno
:Hidrógeno
:Hidrógeno
54
Vista L贸gica Diagrama g de Estados
endOfSong()/ NumActual+=1 Play()/ Pl ()/ driver.play(actual, 0)
eject ()/ driver.stop(); stop()/ driver.abrir() driver.stop(); NumActual=1 actual= disco.obtenerCancion(NumActual)
C
Play Pause()// Tpausa = driver.stop p()
Abierto
Stop
Play()/ driver.plaay(actual, Tp pausa)
e eject ()/ driver.cerrar () d
Cerrado ejject ()/ driver.abrir ()) d
[driiver.detectarA Abierto()]
[(info=driver.detectarDisco())!=NULL]/ disco=buscaDisco(info) [not driver. detectarAbierto()] NumActual = 1; C actual = disco.obtenerCancion(ordenActual) disco obtenerCancion(ordenActual)
[NumActual<= disco.numCanciones()]/ actual= disco.obtenerCancion (NumActual) driver.play(actual,0)
P Pause
apagar ()/ driver.stop(); driver.apagar()
55
Vista L贸gica g Diagrama de Secuencia
56
Vista L贸gica g Diagrama de Colaboraci贸n (comunicaci贸n)
realizarPago(cantidad)
:Registro
1: realizarPago(cantidad)
:Venta
1.1: crear(cantidad)
:Pago
57
Vista L贸gica g Diagrama de Actividad Put Coffee in Filter
[found coffee] Find Beverage [no coffee]
Put Filter in Machine Turn on Machine
Add Water to Reservoir
Get Cups
/ coffeePot.turnOn Brew coffee light goes out Pour Coffee
[found cola]
Get cans of cola Drink
[no cola] 58
Vista de Componentes zDescribe los m贸dulos del sistema y sus p dependencias. zModelar la arquitectura software. zDirigida Di i id a d desarrolladores. ll d zSe Se p plasma as a e en d diagramas. ag a as {de Componentes
59
Vista de Componentes p Ejemplo
60
http://www.agilemodeling.com/artifacts/componentDiagram.htm
Vista de Concurrencia z Describe la divisiรณn del sistema en procesos y procesadores z Dirigida a desarrolladores e integradores z Resuelve problemas de {uso eficiente de los recursos {ejecuciรณn en paralelo (hilos) {comunicaciรณn y sincronizaciรณn de hilos
z Se plasma en diagramas {dinรกmicos {de Componentes {de Despliegue
61
Vista de Concurrencia Ejemplo :FactoryManager
:FactoryScheduler
job
currentJob:TransferJob
A2,B2/2:completed(job)
1:start(job)
:FactoryJobMgr
<<local>> job
A2:completed
B2:completed 1/B1:start(job)
:Robot
1/A1:start(job)
:Oven
62
Vista de Despliegue zMuestra M t la l di distribución t ib ió fí física i d dell sistema i t (ordenadores, dispositivos) y sus conexiones zDirigida g a desarrolladores,, integradores g y probadores zSe plasma en {el diagrama de Despliegue {el mapa de asignación de componentes a la arquitectura física 63
Vista de Despliegue p g Diagrama de Despliegue
64
Tipos de Diagramas
65
Tipos de Diagramas
Análisis
Diseño
D. Casos de Uso.
D. Clases y Objetos.
D. Secuencia del Sistema.
D. Colaboración.
D Clases Conceptuales D. Conceptuales.
D Secuencia D. Secuencia.
D. Clases Análisis.
D. Estados. 66
Indice zModelos de Ciclo de Vida. zAnálisis. zAnálisis zDiseño. zNotaciones.
zMetodologías. zMetodologías
67
Metodologías zUna notación no es suficiente. z¿Cómo se organiza el proyecto? (MCV) z¿Qué documentación se genera? z¿Qué técnicas se utilizan en cada fase? z¿Quién las realiza? z¿Herramientas de soporte?
68
Metodologías ÎBooch
( (OOAD) ) ÊCASEIode (CCM) ÊCoad-YourdonNi l (OOA,OOD) Nicola (OOA OOD) ÊNE University (Demeter) ÊObject Engin. (Fresco) ÊHewlett-Packard (Fusion) ÊGraham (SOMA) ÊTexas Instruments (IE\O) ÊICL (MTD) ÊParcPlace (OBA)
ÎJacobson
(OOSE) ÊOlivetti (OGROUP) ÎMartin-Odell (OOIE) ÊTASKON ((OORAM)) ÊWinter (OSMOSYS) ÎRumbaugh (OMT) ÊLBMS (SE/OT) ÎShlaer/Mellor (OOSA) ÊCCTA (SSADM) ÎW Wirfs-Brock s oc (RDD) ( ) ÊLloyds Register (Z++)
69
Rational Unified Process (RUP) z Es un p proceso iterativo e incremental. z Dirigido por los casos de uso. z Centrado en la arquitectura. arquitectura z Fases: { Comienzo Comienzo. Definir el alcance del proyecto. proyecto { Elaboración. Plan de proyecto, especificar características, esbozar la arquitectura. { Construcción. Construir el producto. { Transición. Entrega a los usuarios.
Comienzo
Elaboración tiempo
Construcción
Transición 70
Rational Unified Process (RUP) ( ) Hitos e Iteraciones Comienzo
Elaboración
Visión
Comienzo
Esbozo de arqu.
Elaboración …
Iteraciones preliminares
Release
Construcción
funcionalidad inicial
Construcción
Release del producto
Transición
…
…
Iteraciones de arquitectura
Transición
Iteraciones de desarrollo
Release Release Release Rel.
…
Iteraciones de transición
Release ReleaseRel.
Release Release
71
Rational Unified Process (RUP) Fases workflows e iteraciones Fases,
72
Rational Unified Process (RUP) workflows y modelos
Requisitos
Análisis
Diseño
Implementación
Prueba
Uso de diagramas UML
Modelo de Casos de Uso
Modelo de Análisis
Modelo de Diseño
Modelo de Despliegue g
Modelo de I l Implementación t ió
Modelo de Pruebas 73
Modelo de Casos de Uso Diagramas de Casos de Uso Modelo de Casos de Uso
Diagramas de Clases
Modelo de An谩lisis
Diagramas de Componentes
Modelo De Dise帽o
Diagramas d Di de Despliegue
Modelo de D Despliegue li
Diagramas g de Secuencia
Modelo de Implementaci贸n
Diagramas de Colaboraci贸n
Modelo de Pruebas
Diagramas de Estado Diagramas de Actividad
Diagramas de Objetos
Diagramas de Paquetes
74
Modelo de Análisis Diagramas de Casos de Uso Modelo de Casos de Uso
Diagramas de Clases
Modelo de Análisis
Diagramas de Componentes
Modelo De Diseño
Diagramas d Di de Despliegue
Modelo de D Despliegue li
Diagramas g de Secuencia
Modelo de Implementación
Diagramas de Colaboración
Modelo de Pruebas
Diagramas de Estado Diagramas de Actividad
Diagramas de Objetos
Diagramas de Paquetes
75
Modelo de Diseño Diagramas de Casos de Uso Modelo de Casos de Uso
Diagramas de Clases
Modelo de Análisis
Diagramas de Componentes
Modelo De Diseño
Diagramas d Di de Despliegue
Modelo de D Despliegue li
Diagramas g de Secuencia
Modelo de Implementación
Diagramas de Colaboración
Modelo de Pruebas
Diagramas de Estado Diagramas de Actividad
Diagramas de Objetos
Diagramas de Paquetes
76
Modelo de Despliegue Diagramas de Casos de Uso Modelo de Casos de Uso
Diagramas de Clases
Modelo de An谩lisis
Diagramas de Componentes
Modelo De Dise帽o
Diagramas d Di de Despliegue
Modelo de D Despliegue li
Diagramas g de Secuencia
Modelo de Implementaci贸n
Diagramas de Colaboraci贸n
Modelo de Pruebas
Diagramas de Estado Diagramas de Actividad
Diagramas de Objetos
Diagramas de Paquetes
77
Modelo de Implementación Diagramas de Casos de Uso Modelo de Casos de Uso
Diagramas de Clases
Modelo de Análisis
Diagramas de Componentes
Modelo De Diseño
Diagramas d Di de Despliegue
Modelo de D Despliegue li
Diagramas g de Secuencia
Modelo de Implementación
Diagramas de Colaboración
Modelo de Pruebas
Diagramas de Estado Diagramas de Actividad
Diagramas de Objetos
Diagramas de Paquetes
78
Proceso dirigido por casos de uso workflows Requisitos
Análisis
Diseño
Implementación
Prueba
Los casos de uso dirigen y relacionan estos workflows
z Los casos de uso dirigen las iteraciones: { Creación y validación de la arquitectura. { Definición de los casos y procedimientos de prueba. { Planificación de las iteraciones. { Creación de la documentación de usuario. { Entrega del sistema
z Sincronización del contenido de los distintos modelos 79
Proceso centrado en la arquitectura z Los modelos son el medio para visualizar, especificar, construir, generar y documentar la arquitectura del sistema. z RUP prescribe el refinamiento sucesivo de la arquitectura. arquitectura C i Comienzo
El b Elaboración ió
C Construcción t ió
T Transición i ió
tiempo Arquitectura
80
Bibliografía z “Applying “A l i UML and d Patterns. P tt 2 d Edition 2nd Editi ”. ” Craig C i Larman, Prentice Hall, 2002. z “Applying “A l i UML in i the th Unified U ifi d Process”. P ” Ivar I Jacobson, Rational Software. z “Ingeniería “I i í del d l Software. S ft U enfoque Un f práctico á ti 6ª Edición”. R.S. Pressman, McGraw Hill. 2005. z “Ingeniería “I i í del d l Software S ft O i t d a Objetos”, Orientado Obj t ” Bruegge, Dutoit, Prentice Hall. 2002. z “Análisis “A áli i y Diseño Di ñ Orientado O i t d a Objetos Obj t con UML y el Proceso Unificado”. Schach. McGraw Hill. 2005 2005. 81