01 Introduccion Programación Orientaeda a Objetos

  • 1,239 views
Uploaded on

Clase de Introducción al Curso de Programación Orientada a Objetos de la carrera de Ciencias Computacionales de la ESPOL

Clase de Introducción al Curso de Programación Orientada a Objetos de la carrera de Ciencias Computacionales de la ESPOL

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,239
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
40
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
  • Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
  • Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

Transcript

  • 1. Programación Orientada a Objetos Orientada a Objetos
    • Introducción
  • 2. Instructor
    • Xavier Ochoa Chehab
      • Estudios
        • Ingeniero en Computación (ESPOL, 2000)
        • M.Sc. Computación Aplicada (VUB, 2002)
        • Ph.D. en Ingeniería (KULeuven, 2008)
      • Trabajo
        • Profesor Principal de la FIEC (7 años)
        • Investigador en el CTI (11 años)
  • 3. Instructor
    • Areas de Interes Profesional
      • E-Learning 2.0
      • Multimedia
      • Métricas
    • Areas de Interes Personal
      • Ciencia Ficción (Libros, Peliculas)
      • Astronomía
      • Viajar
  • 4. Instructor
      • Presencia Digital:
        • http://ariadne.cti.espol.edu.ec/xavier
        • Bookmarks: http://delicious.com/xaoch
        • Twitter: http://www.twitter.com/xaoch
        • Web log: http://xaoch.tumblr.com
        • Pres.: http://www.slideshare.com/xaoch
  • 5. Estudiantes
  • 6. Estudiantes
    • Entrevista Cruzada
      • ¿Quién es?
      • ¿Porque estudia CC?
      • Origen de su Nombre
  • 7. Las Reglas
    • Asistencia:
      • La asistencia es obligatoria
      • Se toma lista a los 15 minutos de empezada la clase. Se puede ingresar a la clase más tarde, pero no se marca la asistencia
      • Si el instructor no llegase dentro de los 15 primeros minutos no habrá clase ese día.
  • 8. Las Reglas
    • Evaluación:
      • Primera Evaluación
        • Examen escrito: 50 puntos
        • Investigación: 10 puntos
        • Deberes: 10 puntos
        • Proyecto: 25 puntos
  • 9. Las Reglas
    • Evaluación:
      • Segunda Evaluación
        • Examen escrito: 50 puntos
        • Investigación: 10 puntos
        • Deberes: 10 puntos
        • Proyecto: 30 puntos
  • 10. Las Reglas
    • Evaluación:
      • Mejoramiento
        • Examen escrito: 50 puntos
        • Proyecto: 50 puntos
  • 11. Las Reglas
    • Investigación
      • Cada semana deberán inlcuir un contenido nuevo para la materia encontrado en Internet
      • No se contará contenido repetido
      • Se utilizará el sistema Delicious.com
      • Se utilizará el tag pooespol
      • Se contará hasta las 23:59 del Domingo
  • 12. Las Reglas
    • Proyectos
      • Los proyectos se realizarán en grupos de 2
      • Los proyectos deberán ser sustentados
      • Se calificará:
        • funcionalidad, diseño, estilo y robustés
  • 13. Introducción a Orientación a Objetos Orientación a Objetos
  • 14. Paradigma Procedimental
    • El paradigma procedimental ve a un sistema de computo como un “procesador de datos”
    • Los datos ingresan al programa y se van transformando al pasar por una serie de funciones
  • 15. Paradigma Procedimental
    • Sistema de Rol de Pagos :
      • Obtener la lista de empleados
      • Obtener el registro de horas de trabajo
      • Obtener las tablas de remuneración y descuentos
      • Para cada empleado:
        • Calcular la cantidad a pagar
        • Calcular las retenciones e impuestos
        • Calcular la paga neta
        • Preparar el cheque
        • Anotar el cheque en el sistema de contabilidad
        • Enviar el cheque al empleado
      • Devolver todos los documentos a su respectivo lugar
  • 16. Paradigma Procedimental
    • Esas operaciones pueden llevarse a cabo con un computador
    • Los pasos necesarios para llegar a cabo una tarea se conocen como “proceso”
    • Cada uno de los pasos se conoce como “procedimiento”
  • 17. Paradigma Procedimental
    • Cada procedimiento recibe datos de entrada, los procesa y luego los transmite a otro procedimiento y finalmente a un humano.
    • Los datos son dados a los procedimientos de una manera similar a la que la materia prima es alimentada una línea de ensamblaje.
  • 18. Paradigma Procedimental
    • El diseñador trata de descomponer los problemas en pequeños procedimientos que siendo ejecutados en el orden correcto hacen que el sistema llegue a una respuesta.
    • Esto funciona muy bien para problemas pequeños. ¿Pero que pasa con sistemas grandes y donde lo que gobierna al sistema no son los datos sino los eventos?
  • 19. Paradigma Procedimental
    • Ejemplos de este tipo de problema son los sistemas interactivos
    • En ellos el flujo del programa ya no es lineal, sino que dependerá de la respuesta del usuario
    • El orden en que los procedimientos son llamados no se conoce de antemano
  • 20. Construcción de una casa para “fido” Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples
  • 21. Construcción de una casa Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas
  • 22. Construcción de un rascacielos
  • 23. ¿Un nuevo paradigma?
    • Paradigma = conjunto de teorías, estándares y métodos que juntos representan maneras de organizar el conocimiento y ver el mundo.
    • En la ciencia una revolución ocurre cuando un paradigma viejo es reexaminado, rechazado y remplazado por uno nuevo
    • Paradigma de Programación = una manera de conceptuar que significa computar y como estructurar y organizar las tareas que deben ser llevadas a cabo por una computadora
  • 24. Paradigma Orientado a Objetos Orientado a Objetos
    • En el paradigma orientado a objetos, el diseñador trata de resolver un problema modelando los diferentes objetos presentes y sus diferentes interacciones
    • En este paradigma los datos no son algo externo al programa, sino que está embebido dentro de los “objetos”
  • 25. Paradigma Orientado a Objetos Orientado a Objetos
    • El paradigma orientado a objetos permite al programador concentrarse en el la solución al problema y no en cómo implementarla en un computador
    • Brinda tres claras ventajas sobre el paradigma procedimental:
      • Fácil Mantenimiento
      • Reusable
      • Escalable
  • 26. ¿Por qué la POO es Popular?
    • Similaridad con la forma de pensar acerca de los problemas en la vida real
    • Es muy escalable, desde problemas triviales hasta sistemas muy complejos
  • 27. POO: Una nueva manera de ver el mundo
    • “ Juan quiere mandar flores a su amiga Ana que vive en otra ciudad. Debido a la distancia Juan no puede llevar las flores directamente a Ana. Juan acude a Pedro, un florista local, y le da el número y tipo de flores que quiere enviarle a Ana y su dirección. Juan puede estar seguro que las flores serán entregadas a Ana. ”
  • 28. Agentes, Responsabilidad, Mensajes y Métodos
    • Juan encuentra un agente apropiado (Pedro)
    • Y le envía un mensaje que contiene una petición.
    • Es la responsabilidad de Pedro el satisfacer esa petición.
    • Existe algún método (conjunto de operaciones) usadas por Pedro para entregar las flores.
    • Juan no necesita conocer el método particular que Pedro utilizará, esa información esta oculta .
  • 29. POO: el Principio General
    • Un programa orientado a objetos esta estructurado como una comunidad de agentes que interactúan entre si llamados objetos.
    • Las acciones son iniciadas por la transmisión de mensajes a un agente (un objeto).
    • El mensaje codifica un requerimiento de acción y es acompañado por información adicional (argumentos) necesaria para llevar a cabo el requerimiento.
    • El receptor es el agente al cual el mensajes es enviado. Si el receptor acepta el mensaje, acepta la responsabilidad de llevar a cabo la acción solicitada.
    • En respuesta a un mensajes el receptor ejecutará algún método para satisfacer el requerimiento.
  • 30. ¿Qué es un objeto?
      • Así como los procedimientos son la base para construir programas estructurados, los objetos son usados para construir programas orientados a objetos
      • Un programa orientado a objetos es una colección de objetos que están organizados para, y cooperan para, lograr un objetivo.
  • 31. Objeto
    • Cada objeto:
      • Contiene datos: Los datos guardan información que describe el estado del objeto.
      • Tiene un conjunto de comportamientos: Estos comportamientos son cosas que el objeto sabe como hacer y que son disparadas por mensajes enviados al objeto.
      • Tiene identidad individual: Esto hace posible distinguir un objeto de otro así como es posible distinguir una variable de otra
  • 32. Objeto
    • Objeto empleado:
    Datos: Nombre: Juan Perez Horas que trabaja a la semana: 40 Afiliado al seguro: si Comportamiento: Calcular Sueldo Calcular Retenciones Cambiar horario de trabajo Empleado # 03123
  • 33. Objeto
  • 34. Objeto Bicicleta
  • 35. Objeto
    • Un objeto es una abstracción de una entidad del mundo real.
    • Los datos de un objeto son conocidos como los atributos
    • Los comportamientos de un objeto son conocidos como métodos.
  • 36. Ejemplos de Objetos
    • Cuenta Bancaria
      • Estado: número de cuenta, dueño, balance, tasa interés, etc
      • Operaciones: depositar, retirar, transferir, etc
    • Estudiante
      • Estado: nombre, matrícula, fecha de nacimiento, carrera
      • Operaciones: calcular edad, calcular pago, buscar notas
    • String
      • Estado: secuencia de caracteres
      • Operaciones: calcular largo, probar si es igual, concatenar, etc.
  • 37. Lenguajes OO
    • Smalltalk (Squeak)
    • C++
    • Java
    • C#
    • Python
    • Ruby
  • 38. Terminología
    • JRE – Java Runtime Environment
      • JVM que ejecuta el código
    • JDK – Java Development Kit
      • JRE + tools (compiler, debugger) para desarrollo de applets y de aplicaciones
    • J2SE – Java 2 Platform, Standard Edition
      • JRE y JDK “family”
    • J2EE - Java 2 Platform, Enterprise Edition
      • Incluye frameworks para trabajo Web
    • http://java.sun.com/javase/technologies/index.jsp
  • 39. Entorno de Desarrollo
  • 40. Tarea
    • Instalar JDK 6
    • Instalar Eclipse (JEE-Galileo)
    • Enviar captura de pantalla en SIDWeb