Introduccin al Anlisis y Diseo Orientado a Objeto utilizando UML'

1
Introducción al Análisis y Diseño Orientado a
Objeto utilizando UML.

• Descripción del curso
• Relator Carlos Concha Saladrigas

2
Objetivos del curso

• Al terminar el curso el alumno estará capacitado
  para
• Dominará los conceptos fundamentales de la OO.
• Conocerá las principales etapas en el Análisis y
  Diseño Orientado a Objeto.
• Conocerá UML y los artefactos principales que
  proporciona para el desarrollo de sistemas
  orientados a Objetos.

3
Temas a tratar durante el curso

• Problemática actual en el desarrollo de software.
• Ciclos de desarrollo de SW.
• Cascada, evolutivo, prototipos.
• Conceptos básicos de orientación a objetos.
• Encapsulación, Herencia, Polimorfismo.
• Conceptos básicos de UML.
• Diagramas básicos, notación, uso.
• Análisis ydiseño Orientado a Objetos utilizando
  UML.

4
Introducción a la Orientación a Objetos
5
Qué es un objeto?

• Definición
• El objeto es uno de los conceptos básicos en la
  programación orientada a objetos.
• Se los puede considerar como una de las
  abstracciones principales que permite estructurar
  un programa en torno a entidades que representen
  parte de la realidad.

6
Qué es un objeto?

• Las características principales de un objeto son
  su identidad, su estado y su comportamiento.
• La primera permite distinguirlo de otros objetos
  y es fácilmente identificable gracias a los
  nombres que éstos poseen.
• El estado, por su parte, describe las propiedades
  (ó datos) del objeto.
• El comportamiento señaliza qué tipo de
  interacción puede comprender el objeto (sus
  métodos).

7
Qué es un objeto?

• Ejemplo del concepto de Orientación a Objetos
• Un objeto del mundo real Perro.
• Perro es un miembro (instancia) de una clase
  mucho más grande de objetos que llamaremos
  Mamíferos.

8
Qué es un objeto?

• Un conjunto de atributos genéricos pueden
  asociarse con cada objeto, en la clase perro.
• Por ejemplo, todo perro tiene patas, peso, color,
  entre otros muchos posibles atributos.
• Estos atributos también son aplicables a un gato,
  ratón, caballo ,etc.
• Como perro es miembro de la clase mamífero, perro
  hereda todos los atributos definidos para la
  clase mamíferos.

9
Qué es un objeto?
10
Qué es el Análisis y Diseño OO?

• Es identificar el dominio del problema y su
  solución lógica dentro de la perspectiva de la
  Orientación a Objetos.
• Análisis Orientado a Objeto Identificar y
  definir los objetos (conceptos) dentro del
  dominio del problema.
• Diseño Orientado a Objetos Definir los objetos
  lógicos de Software (con atributos y métodos) que
  serán programados el un lenguaje de programación
  idóneo.
• Diferencia con el modelo estructurado El
  análisis y diseño estructurado son orientado a
  los procesos.

11
Qué es UML?

• UML Unified Modeling Lenguaje.
• Lenguaje de Modelado de arquitecturas de
  software.
• DEFLa estructura de los componentes de un
  sistema, sus interrelaciones y los principios y
  guías que gobiernan su diseño y evolución a
  través del tiempo IEEE Transaction of Software
  Engineering
• NO es una metodología, es una notación.
• Independiente de la metodología.
• Proporciona herramientas básicas para la
  definición de artefactos (diagramas) que pueden
  ser utilizados en diferentes fases del proceso de
  desarrollo.

12
Qué es UML?

• UML define 12 tipos de diagramas divididos en
  tres categorías.
• Diagramas estructurales.
• Clases, Objetos, Componentes, Despliegue
  (deployment).
• Diagramas de comportamiento.
• Caso de uso, Secuencia, Actividad, Colaboración,
  Estados.
• Diagramas de administración de modelo.
• Paquetes, Sub-sistemas, Modelos

13
Qué necesito para desarrollar un proyecto basado
en UML?

• Seleccione una metodología.
• Seleccione una herramienta de desarrollo.
• En general las herramientas soportan un cierto
  tipo de metodologías.
• Entrénese.

14
Lenguajes y herramientas OO

• Lenguajes de programación más comunes que
  soportan la Orientación a Objetos
• Java
• C
• Plataforma .net
• Smalltalk
• Herramientas case
• Rational Rose.
• Poseidon (Profesional Edition)
• Herramientas de modelado
• Visio 2002
• Umbrella (Open Source)
• Poseidon (Comunity Edition)

15
Procesos de desarrollo de Software

• Problemática actual el desarrollo de SW
• Breve descripción de la Ing. de SW
• Tipos de procesos de desarrollo de SW

16
La problemática actual en el proceso de
desarrollo de software.

• Causas
• Mitos
• Soluciones

17
Qué es el Software?

• Antiguamente programar se veía como un arte.
• Características del software
• Lógico no físico.
• No se estropea.
• Generalmente es hecho a medida.

18
Problemas actuales en el desarrollo de SW

• El desarrollo de software es un negocio riesgoso.
• Muchas historias de fracaso Larman
• 31 Proyectos no se concluyen
• 53 Rebasa en un 200 el costo estimado
• Carencia de estándares.
• Dificultad en la estimación de costos.
• Poca reutilización de código.
• Proceso no definido.

19
Problemas actuales en el desarrollo de SW

• Curva típica de fallos de Software Pressman.

20
Problemas actuales en el desarrollo de SW

• El impacto del cambio Pressman

21
Mitos del Software PressmanMitos de Gestión

• Mito 1 Tenemos un libro lleno se estándares y
  procedimientos para construir software. Mi gente
  ya tiene todo para hacer lo que tiene que hacer.
• Saben que existe?, lo usan?, es completo?.
  Experiencia es también valiosa.
• Mito 2 Tenemos todo lo que necesitamos, HW y SW
  de última generación.
• El desarrollo implica mucho mas que herramientas.

22
Mitos de Gestión

• Mito 3 Si fallamos en la planificación,
  agregamos más programadores y asunto solucionado.
• En general mas gente agrega más caos no mas
  eficiencia.

23
Mitos del Software PressmanMitos del cliente

• Mito 1 Una declaración general de los objetivos
  es suficiente para comenzar a escribir programas,
  los detalles se dejan para más adelante.
• Una mala definición inicial es la principal causa
  de la pérdida de trabajo en SW.
• Mito 2 Los requisitos del proyecto cambian
  continuamente, pero estos pueden acomodarse fácil
  puesto que el software el flexible.
• El impacto del cambio varía según en el momento
  que se introduzca.

24
Mitos del cliente

• Mito 3 No es necesario involucrarse en el diseño
  del SW. Basta con dar las especificaciones y ver
  los resultados finales.

25
Mitos del Software PressmanMitos del
desarrollador

• Mito 1 Una vez que escribimos el programa y
  hacemos que funcione nuestro trabajo ya está
  hecho.
• -Cuanto más pronto se comience a escribir código,
  más se tardará en terminarlo.
• Mito 2 Hasta que no tengo el programa
  ejecutándose, realmente no tengo forma de
  comprobar su calidad.
• Existen mecanismos efectivos para ser aplicados
  desde el principio del proyecto durante todas las
  fases.

26
Mitos del desarrollador

• Mito 3 Lo único que se entrega al terminar el
  proyecto es el programa funcionando.
• Un parte fundamental para la mantención es la
  documentación.

27
Porque es necesario un proceso formal?

• Tentación clásica Ponerse a programar de
  inmediato.
• Objetivo principal Disminuir el riesgo creando
  un sistema eficiente mediante un diseño formal.
• Es mas barato realizar cambios en las actividades
  de análisis y diseño que en la codificación.

28
Porque es necesario un proceso formal?

• Reducción de complejidad, modelando sistemas y
  realizar abstracciones para detectar solo
  detalles fundamentales.
• Generación de modelos a bajo costo.
• Reutilización de código es una parte fundamental
  en la construcción de SW de alta calidad.

29
Introducción a la Ingeniería de Software

• Breve Descripción

30
Qué es ingeniería de SW?

• La aplicación de un enfoque sistemático,
  disciplinado y cuantificable hacia el desarrollo,
  operación y mantenimiento del Software, es decir,
  la aplicación de la ingeniería al Software
  IEEE

31
Capas de la Ingeniería de Software
Rational Rose, poseidón
OO, Estructurado
Prototipo, cascada
ISO, McCall
32
Capas de la ingeniería de SW.Enfoque de calidad

• Se aplica a lo largo de todo el proceso de
  ingeniería de Software. Define las metodologías
  para todas las otras áreas.
• Incluye
• Enfoques de gestión de calidad.
• Tecnología de Ing. SW. Efectiva (métodos y
  herramientas).
• Revisiones técnicas formales que se aplican
  durante todo el proceso de software.
• Control de cambios y documentación.
• Procedimientos que aseguren un ajuste a los
  estándares de desarrollo de SW.
• Mecanismos de medición y generación de informes.

33
Capas de la ingeniería de SW.Procesos

• Un proceso de desarrollo de software es un marco
  de trabajo de las tareas que se requieren para
  construir de Software alta de calidad.
• El proceso define el contexto en el que se
  aplican los métodos técnicos, se producen los
  resultados de trabajo (modelos, documentos,
  datos, informes, formularios) y se establecen
  hitos.

34
Capas de la ingeniería de SW.Métodos

• El método indica como construir técnicamente el
  SW.
• Se puede utilizar el mismo proceso pero utilizar
  un método distinto
• E.g Se puede utilizar el proceso de desarrollo
  de software en cascada y escoger entre una
  metodología Orientada a Objetos o una
  Estructurada.

35
Capas de la ingeniería de SW.Herramientas

• Proporcionan un soporte semi-automático o
  automático para el proceso y para los métodos.
• Necesitan de una notación formal para introducir
  los procesos y los métodos (e.g Rational Rose usa
  UML)

36
Tipos de procesos de software

• Ciclos de vida del Software

37
Procesos de desarrollo de SW.

• Ciclo de vida Sucesión de etapas por las que
  atraviesa un producto software a lo largo de su
  desarrollo y existencia.
• Existen distintas formas o paradigmas de ciclo de
  vida
• Secuencial, cascada.
• Orientado a prototipos
• Evolutivo
• Incremental
• Espiral
• Componente

38
Procesos de desarrollo de SW.Secuencial

• Aplicación secuencial de una serie de pasos.
• Cada paso genera entradas y documentación para la
  siguiente.
• Puede ser usada dentro de otros modelos.
• Muy utilizado en la actualidad.

• Comprender la naturaleza del dominio.
• Especificación de los requisitos

• Estructura de datos
• Arquitectura de SW
• Representaciones de la Interfaz
• Algoritmos

• Construcción del SW. En base al diseño

• Prueba de procesos lógicos internos.
• Pruebas funcionales

39
Procesos de desarrollo de SW.Cascada

• Propuesto por W. Royce a principios de los años
  70.

Análisis
Diseño
Codificación y pruebas unitarias
Operación y mantenimiento
Integración del sistema
40
Procesos de desarrollo de SW.Cascada

• Críticas al ciclo de vida clásico
• Proyectos raramente siguen el flujo secuencial.
• Se deben saber todos los requerimientos desde el
  inicio.
• Dificultad para establecer los requerimientos al
  principio del proceso.
• El producto se puede mostrar al cliente en fases
  muy tardías del proceso.
• Errores detectados tardíamente. Aumenta el costo.

41
Procesos de desarrollo de SW.Prototipos

• Mecanismo de especificación de requisitos.
• Cuando solo se tienen requisitos muy generales
  por parte del cliente, es práctico utilizar este
  paradigma.
• Sistemas muy complejos de entender.
• Prototipear consiste en construir una versión
  inicial de un producto, en la cual se describe la
  interacción hombre-máquina sin implementar
  completamente la funcionalidad del sistema
  (prototipo sin funcionalidad).

42
Procesos de desarrollo de SW. Prototipos

• Utilidad
• Ayuda a los analistas a establecer las
  necesidades del cliente.
• Ayuda a los desarrolladores a mejorar los
  productos.
• Ciclo que primero, revisa los requerimientos del
  cliente. Luego, se construye un prototipo y
  finalemnte el cliente lo prueba, para iniciar
  nuevamente el ciclo.

43
Procesos de desarrollo de SW. Prototipos

• Clases de prototipos
• Vertical desarrolla completamente algunas de las
  facetas del producto.
• Horizontal desarrolla parcialmente todas las
  facetas del producto.
• Evolutivo La versión final es el producto ya
  construido.
• Desechable Se usa sola para la captación de
  requerimientos y funcionalidad.

44
Procesos de desarrollo de SW. Prototipos

• Observaciones sobre los prototipos
• A menudo el primer prototipo se desecha Brooks
• El primer modelo es demasiado genérico.
• Reduce el riesgo de parcheado del producto
  final.
• La construcción del prototipo supone una
  inversión adicional.

45
Prototipos

• Observaciones sobre los prototipos
• El cliente ve funcionando una versión de lo que
  será su programa sin asumir que dicha versión no
  es robusta ni completa.
• Se puede mezclar con otros paradigmas (Cascada,
  evolutivo, etc.)

46
Procesos de desarrollo de SW.Modelos evolutivos

• Los requisitos de gestión y productos cambian a
  lo largo del desarrollo de un proyecto.
• Modelo de cascada y prototipos no consideran
  evolución del SW.

47
Procesos de desarrollo de SW.Modelos evolutivos

• Modelos evolutivos son iterativos.
• Permite al equipo de desarrollo generar
  versiones mas completas del software.
• Tipos de modelos
• Incremental
• Espiral
• Ensamblaje de componentes

48
Procesos de desarrollo de SW.Modelos evolutivos
Incremental

• Los riesgos asociados en el desarrollo de grandes
  sistemas son altos.
• Construir solo una parte del sistema, dejando
  otras funciones para futuras versiones.

49
Procesos de desarrollo de SW.Modelos evolutivos
Incremental

• Consideraciones
• Útil cuando no se dispone de todo el personal
  para el desarrollo completo.
• Diferencia con prototipo, entrega de producto
  operacional con cada entrega.
• Construir un sistema pequeño es menos riesgoso
  que construir un sistema grande.

50
Modelos evolutivos Incremental

• Si se comete un error grave, basta con volver a
  la versión anterior.
• Reducir los ciclos de desarrollo disminuye la
  probabilidad que los requerimientos del cliente
  cambien.
• Mejor control de errores.

51
Procesos de desarrollo de SW.Modelos evolutivos
Espiral

• Propuesto por Boehm en 1988.
• El SW. Se desarrolla en versiones incrementales.
• Por cada vuelta del ciclo se producen versiones
  más completas.

52
Modelos evolutivos Espiral

• Espiral se divide en 6 regiones, llamadas
  regiones de tarea.
• Comunicación con el cliente
• Planificación
• Análisis de riesgo
• Ingeniería
• Construcción y adaptación
• Evaluación del cliente

53
Procesos de desarrollo de SW.Modelos evolutivos
Espiral
54
Procesos de desarrollo de SW.Modelos evolutivos
Espiral

• El modelo no termina hasta que el SW. Es
  desechado.
• Se puede mezclar con otros modelos incremental,
  cascada.
• El prototipo agrega un loop extra en el espiral.
• Diferencia, incorpora el análisis de riesgo.

55
Procesos de desarrollo de SW.Modelos evolutivos
Componentes

• Más adecuado para la construcción de SW orientado
  a objeto.
• Orientación a objetos encapsula datos y métodos.
• Centrado a la construcción de componentes que no
  están en una biblioteca de clases.
• Si el componente no existe se sigue un paradigma
  de desarrollo.

56
Procesos de desarrollo de SW. Modelos
evolutivos Componentes
57
Procesos de desarrollo de SW.RUP Rational
Unified Process

• Proceso de desarrollo propuesto por Rational
  basado en buenas prácticas.
• Consiste en un conjunto de templates, blueprints
  y documentación que cubren todo el proceso de
  desarrollo.

58
RUP Rational Unified Process

• Adaptable según las necesidades de la
  organización.
• Pensado para proyectos grandes pero se puede
  utilizar para proyectos pequeños.

59
Procesos de desarrollo de SW.Como elegir un
modelo?

• Algunos criterios
• Complejidad del problema y solución.
• Frecuencia esperada en el cambio de requisitos
  por parte del cliente.
• Acceso al cliente por parte de los
  desarrolladores.
• Grado de exactitud en los requisitos.
• Tolerancia al riesgo.
• Presupuesto.

60
Ejercicio

• Describa el proceso de desarrollo actual que
  sigue en su empresa.
• Describa el proceso de desarrollo ideal que
  debería seguir su empresa.
• Compárelo con el proceso diseñado por otra
  persona de su equipo o empresa.