ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS UMLCICLO VITAL DEL SOFTWARE IModelo de cascada

Análisis (qué) Diseño (cómo) Codificación (hacerlo) Pruebas (¿funciona?) Mantenimiento

CICLO VITAL DEL SOFTWARE IICiclo evolutivo

Dedfinición de un subsistema (descomposición funcional) Construcción de un modelo (qué clases se requieren) Análisis de clase(s) Diseño de clase(s) Ciclo Codificación de clase(s) Prueba de clase(s)

Diseña un poco, programa un poco, prueba un poco …

OOD es…ModularEfectos laterales mínimos (encapsulamiento)Programación por extensiónOrientado a datosExplota la herencia (jerárquico)Reutilización de clasesFácil de modificar

Encapsulamiento IDesarrollador

Objetivo: 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.

Encapsulamiento IIUsuario de las clases

Objetivo: usar las clases con el mínimo esfuerzo Manera: usar sólo las operaciones provistas Beneficios: interfaz comprensible, bajo coste de programación Coste: pérdida de eficiencia de ejecución (menor si se utiliza un lenguaje como C++)

Descomposición funcional Módulos construidos alrededor de las operaciones Datos globales o distribuidos entre módulos Entrada/proceso/salida Organigama de trabajo y flujo de datos.

OOD Módulos construidos alrededor de las clases. Clases escasamente acopladas, sin datos globales. Encapsulamiento y mensajes

Diagramas jerárquicos de clases.

Ventajas del OOD Módulos con fuerte cohesión interna y escaso acoplamiento externo (sin variables

globales, …) Facilita el funcionamiento en entorno multiporcesador (objetos distribuidos) Correspondencia directa con el mundo real Prototipos rápidos Herramientas y bibliotecas muy amplias Aplicaciones construidas enganchando objetos Mejor comprensión y mantenimiento.

Inconvenientes del OOD Impactos desfavorables sobre espacio y tiempo de ejecución. Forma de pensar diferente: curva de aprendizaje lenta. Peligro de atomización, con dificultad de comprensión global. Herencia y ligadura dinámica dificulta las pruebas.

DEFINICIÓN DE UNA CLASE Identificar y nombrar la clase Identificar sus componentes Identificar sus atributos Identificar los errores Identificar las conexiones funcionales (qué clases sirve/exige) Definir conexiones son superclase y subclases Identificar porpiedades especiales (persistencia, cuncurrencia). Probar la clase en un prototipo.

IDENTIFICACIÓN DE ATRIBUTOSEl 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).

Definición de atributosTipos de atributos.

Atómicos predefinidos (entero, real, carácter, pixel, …) Atómico enumerativo (color, día de la semana, …) Colección Composición (referencias objetos)

Valor del atributo Común a muchos objetos (varible de clase) Propio de un objeto (variable de objeto)

IDENTIFICACIÓN DE MÉTODOS Método: algoritmo que utiliza y modifica los atributos de una clase. Un método es desencadenado por un mensaje. Funcionalidad de la clase: conjunto de sus métodos. El conjunto de métodos debe ser:

o Completo (realizan toda la funcionalidad de la clase)o General (se aplican a todos los objetos de la clase)

o Diferenciado (cada método debe ser simple y realizar una sola función).Definición de método

Tipos de métodoso Modificador (asigna valor a un atributo)o Selector (devuelve el valor de un atributo)o Aplicable a la clase (constructor)o Aplicable al objeto

Parámetros del métodoo ¿qué información necesita? (argumentos de entrada)o ¿qué debe devolver? (resultado y argumentos de salida)

Identificación de los errores ¿Qué puede salir mal durante la ejecución de un método? ¿Qué comprobaciones debe hacer cada método? ¿Cómo interpretar y corregir las condiciones de error?

METODOLOGÍAS DE ANÁLISIS Y DISEÑO (OOA/OOD)

OOAD (Booch) Tipos de relaciones

o Herencia o generalizacióno Agregación o composicióno Asociacióno Metaclaseo Instanciación (plantillas)o Cliente – servidor (acceso)

OOAD (Grady Booch) Tipos de clases

o Clases ordinariaso Metaclaseso Categorías de claseso Clases parametrizadas (plantillas)o Clases instaciadas (plantillas)o Utilidades de clase: subprogramas libres y clases estáticas.

PARTES DE UNL Vistas

o Conjunto de diagramas Diagramas

o 9 tipos de grafoso Combinan los elementos del modelo

Elementos del modeloo Clases, objetos, mensajes, relaciones

Mecanismos generaleso Comentarios, información, semántica, extensión y adaptaciones.

VISTASo Vista de casos de uso

o Funcionalidad externa dl sistemao Vista lógica

o Estructura estática y conducta dinámica del sistema.o Vista de componentes (software9

o Organización de las componenteso Vista de concurrencia

o Comunicaciones y sincronizacióno Vista de despliegue (deployment)

o Arquitectura física

LAS VISTAS EN UML

VISTAS DE CASOS DE USO

o Dirigida al análisis de requisitos (lo que quiere hacer el usuario)o Describe la funcionalidad del sistema, como la perciben los actores externos.o Dirige el desarrollo de las otras vistas.o Define los objetivos finales del sistemao Permite validar el sistemao Actor externo:

o Usuarioo Otro sistema

o Se plasma en diagramaso De casos de usoo De actividad

VISTA LÓGICAo Describe la funcionalidad internao Dirigida a diseñadores y desarrolladoreso Define la estructura estática

o Clases, objetos y relacioneso Define las colaboraciones dinámicas

o Mensajes y funcioneso Propiedades adicionales

o Persistencia y concurrenciao Interfaces y estructura interna de las clases.

VISTA LÓGICA

Vista de componentes