Introduccin al Anlisis y Diseo Orientado a Objeto utilizando UML' - PowerPoint PPT Presentation

1 / 60
About This Presentation
Title:

Introduccin al Anlisis y Diseo Orientado a Objeto utilizando UML'

Description:

Dominar los conceptos fundamentales de la OO. ... Es mas barato realizar cambios en las actividades de an lisis y dise o que en la ... – PowerPoint PPT presentation

Number of Views:507
Avg rating:3.0/5.0
Slides: 61
Provided by: carlosc3
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com