FUNDAMENTOS DE PROGRAMACION POO

1. FUNDAMENTOS DE PROGRAMACIÓN
ITCH II
Carrera: ISC
Materia: Fundamentos de
Programación
Alumna:Yesenia Chaparro
Ochoa
Horario: 5 pm-6pm
Docente: Hernán de la Garza
Gutiérrez

2. 1.1 RECONOCIMIENTO DE CLASES Y OBJETOS Y SUS
RELACIONES EN EL MUNDO REAL.
Un objeto se define como una estructura que encapsula atributos
(características) y comportamientos (procedimientos) de una entidad
con un papel bien definido en una aplicación. Cada objeto tiene:
 - Estado: Conjunto de valores de los atributos en un instante de tiempo
dado. El comportamiento de un objeto puede modificar el estado de
este.
 - Comportamiento: Relacionado con su funcionalidad y determina las
operaciones que este puede realizar o a las que puede responder ante
mensajes enviados por otros objetos.
 - Identidad: Es la propiedad que permite a un objeto diferenciarse de
otros. Generalmente esta propiedad es tal, que da nombre al objeto.
 Clases: Es la definición de un objeto. Cuando se programa un objeto y
se definen sus características y funcionalidades, realmente se programa
una clase

3. 1.2 ABSTRACCIÓN.
 Abstracción:Es un método por el cual abstraemos una
determinada entidad de la realidad de sus características y
funciones que desempeñan. Denota las características esenciales
de un objeto, donde se capturan sus comportamientos.
 Dentro de las características esenciales se encuentran:
 Atributos (o datos).
 Comportamiento (métodos)
 La abstracción es crucial para comprender este complejo mundo,
para el funcionamiento de una mente humana normal y es una
herramienta muy potente para tratar la complejidad, es clave para
diseñar un buen software

4. Ejemplo:
La abstracción de un automóvil.
 - Características: Color, año de fabricación, modelo,
etc.
 - Métodos o Funciones: Frenar, encender, etc.

5. 1.2. ENCAPSULAMIENTO
 Encapsulamiento: Significa reunir a todos los elementos
que pueden considerarse pertenecientes a una misma
entidad, al mismo nivel de abstracción.
 En la OO el encapsulamiento de una entidad se logra
mediante la definición de una clase, que reúne los datos
y comportamiento en una unidad.

6. 1.3 LA POO Y LA COMPLEJIDAD DEL SOFTWARE.
La POO comparada con otros paradigmas de
programación, permite manejar de mejor manera la
complejidad del software. Por lo siguiente:
 Agrupar elementos comunes (objetos) en clases.
 La clase incluye en una unidad los atributos y los
métodos.
 Se pueden construir jerarquías de herencias de clases
que
hereden (reciban) lo que ya esta definido.
 Lo anterior aumenta la modularidad. El programa esta
formado por módulos o partes bien identificadas.
La programación orientada a objetos, un programa es
una colección de una sola entidad básica, el objeto, el
cual combina los datos con los procedimientos que
actúan sobre ellos. Durante la ejecución, los objetos
reciben y envían mensajes a otros objetos para
ejecutar las acciones requeridas.

7. 1.3 LA POO Y LA COMPLEJIDAD DEL SOFTWARE.
 La modularidad implica:
 El programa se puede construir, probar y depurar
por módulos.
 Al agregar nueva funcionalidad, se pueden crear
nuevos módulos o incluir la funcionalidad en
módulos que ya existen.
 Se facilita el localizar errores, el mantenimiento y el
crecimiento del software.
 Si la programación estructurada se interesa primero por los
procedimientos y después por los datos, el diseño orientado
a objetos se interesa en primer lugar por los datos, a los que
se asocian posteriormente procedimientos

8. 1.4 CONCEPTOS DEL CICLO DE VIDA
DEL SOFTWARE.
Las etapas básicas y los principios del modelo OO del ciclo
de vida del software son:
 1. Especificación de requerimientos.
 2. Análisis.
 3. Diseño.
 4. Programación.
 5. Mantenimiento.

9. 1.4.1 ESPECIFICACIONES DE
REQUERIMIENTOS.
 Comprende las tareas relacionadas con la determinación de las
necesidades o de las condiciones a satisfacer para un software
nuevo o modificado, tomando en cuenta los diversos
requerimientos de los clientes.
 El propósito es hacer que los mismos alcancen un estado óptimo
antes de alcanzar la fase de diseño en el proyecto.
 Los buenos requerimientos deben ser medibles, comprobables, sin
ambigüedades o contradicciones.

10. ESPECIFICACIÓN DE REQUERIMIENTOS.
Los requerimientos para un sistema de software determinan lo que hará el
sistema y definen las restricciones de su operación e implementación.
Para esta actividad se debe:
 IDENTIFICACION DE REQUISITOS: Identificar las necesidades del usuario
(del negocio).
 ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS: Describir los objetivos de la
aplicación.
 ESPECIFICACION DE REQUERIMIENTOS: Definir características y funciones
generales de la aplicación.(requerimientos funcionales y no funcionales)
 VALIDACIÓN DE REQUISITOS:El equipo de Ingeniería de sistemas y los
clientes deben establecer en conjunto las metas y objetivos de la aplicación.
 FACTORES EN LA CALIDAD DEL SOFTWARE: Eficiencia,
Transportabilidad, Verificabilidad, Fácil de utilizar, Corrección, Extensibilidad,
Compatibilidad Reutilización.

11. EJEMPLO DE ESPECIFICACIÓN DE REQUERIMIENTOS.
Giro de la empresa.
La empresa “HogarSeguro.com” se dedica a la venta, configuración e
instalación de equipo de seguridad para hogares y pequeñas empresas.
Identificar la necesidad del negocio.
La empresa requiere de una aplicación Web que permita a los consumidores
configurar y comprar todos los componentes requeridos para instalar un
sistema de administración en su hogar o empresa.
Objetivos de la aplicación.
 Vender directamente a los consumidores, lo que eliminará costos de
intermediación y mejorará márgenes de utilidad.
 Aumentar las ventas en un 25%.
 Penetrar en regiones geográficas donde no se tienen puntos de venta.
 Que el usuario pueda configurar un equipo de seguridad para su hogar,
al proporcionar información sobre habitaciones, dimensiones y
distribución

12. 1.4.2 ANÁLISIS ORIENTADO A OBJETOS
 Definición. Es un método de análisis que examina los
requisitos desde la perspectiva de las clases y objetos que se
encuentran en el vocabulario del dominio del problema.
Documentos de deben tenerse o desarrollarse durante el
análisis:
 Especificación de requisitos o requerimientos.
 Diagramas de casos de uso.
 Escenarios y subescenarios.
 Prototipos y su evaluación.

13. CASO DE USO.
 Es una técnica para la captura de requisitos potenciales de un
nuevo sistema o una actualización de software. Cada caso de uso
proporciona uno o más escenarios que indican cómo debería
interactuar el sistema con el usuario o con otro sistema para
conseguir un objetivo específico. Ejemplo:

14. ESCENARIOS
 Es una descripción parcial y concreta del comportamiento de un
sistema en una determinada situación.

15. PROTOTIPO.
 Es una representación de aquellos aspectos del software que
serán visibles para el cliente (por ejemplo, la configuración de la
interfaz con el usuario y el formato de los despliegues de salida).
 El prototipo, es evaluado por el cliente para una
retroalimentación; gracias a ésta se refinan los requisitos del
software que se desarrollará.

16. 1.4.3 DISEÑO OO
 Es el proceso de dividir una solución en una cantidad
determinada de objetos constituyentes
 Es una fase de la metodología orientada a objetos para el
desarrollo de Software.
 Su uso induce a los programadores a pensar en términos de
objetos, en vez de procedimientos, cuando planifican su código.
Un objeto agrupa datos encapsulados y procedimientos para
representar una entidad.
 La 'interfaz del objeto', esto es, las formas de interactuar con el
objeto, también es definida en esta etapa.
 El diseño orientado a objetos es la disciplina que define los
objetos y sus interacciones para resolver un problema de negocio
que fue identificado y documentado durante el análisis orientado a
objetos.

17. 1.4.4 POO
 Toma las mejores ideas de la programación
estructurada la combina con nuevos y poderosos
conceptos que animan o alientan una nueva visión
de la tarea de la programación, permite
descomponer fácilmente un problema en subgrupos
de partes relacionadas, entonces, puede traducir
estos subgrupos en unidades autocontenidas
llamadas Objetos
 Es un paradigma de programación que usa objetos y
sus interacciones para diseñar aplicaciones y
programas de computadora.
 Está basado en varias técnicas, incluyendo herencia,
modularidad, polimorfismo y encapsulamiento.
 Su uso se popularizó a principios de la década de
1990.

18. 1.5 ELEMENTOS PRIMORDIALES EN EL
MODELO OO.
 La programación Orientada a Objetos trata de cumplir las
necesidades de los usuarios finales, estás tareas se realizan
mediante la modelización del mundo real, el soporte fundamental
es el modelo objeto.
 Los elementos más importantes de este modelo son:
 Abstracción
 Encapsulamiento
 Modularidad
 Jerarquía y Herencia
 Polimorfismo

19. 1.5.1. ABSTRACCIÓN.
 Extraer las propiedades esenciales de un objeto que lo distinguen de los
demás tipos de Objetos y proporciona fronteras conceptuales definidas
respecto al punto de vista del observador
 Denota las características esenciales de un objeto, donde se capturan sus
comportamientos.
 Es la capacidad para encapsular y aislar la información de diseño y
ejecución
 Una abstracción se centra en la vista externa de un objeto, de modo que
sirva para separar el comportamiento esencial de un objeto de su
implementación. Definir una abstracción significa describir una entidad
del mundo real, no importa lo compleja que pueda ser y, a continuación,
utilizar esta descripción en un programa.

20. 1.5.2. ENCAPSULAMIENTO.
 Significa reunir a todos los elementos que pueden
considerarse pertenecientes a una misma entidad, al
mismo nivel de abstracción.
 Los lenguajes orientados a objetos proporcionan la
Encapsulación. La encapsulación se puede utilizar
para aplicar el concepto de Abstracción.
 Cada objeto está aislado del exterior, es un módulo
natural, y la aplicación entera se reduce a un
agregado o rompecabezas de objetos. El aislamiento
protege a los datos asociados a un objeto contra su
modificación por quien no tenga derecho a acceder a
ellos, eliminando efectos secundarios e interacciones

21. 1.5.3. MODULARIDAD.
 Es la descomposición de un sistema complejo
en piezas mas simples llamadas módulos.
 Es más fácil la solución de “pequeños”
módulos.
 Este procedimiento de descomposición refleja
el principio de “Divide y Vencerás”.
 El código fuente de un objeto puede ser
escrito, así como darle mantenimiento,
independientemente del código fuente de otros
objetos. Así mismo, un objeto puede ser
transferido alrededor del sistema sin alterar su
estado y conducta.

22. 1.5.4. JERARQUÍA Y HERENCIA.
 Herencia: (por ejemplo, la clase D recibe herencia
de la clase C) Es la facilidad mediante la cual la
clase D hereda en ella cada uno de los atributos y
operaciones de C, como si esos atributos y
operaciones hubiesen sido definidos por la misma
D.
 La Jerarquía es una propiedad que permite la
ordenación de las abstracciones. Las dos jerarquías
más importantes de un sistema complejo son:
estructura de clases (jerarquía “es-un” (is-a):
generalización/especialización) y estructura de
objetos (jerarquía “parte-de” (part-of): agregación).
 Las jerarquías de generalización/especialización se
conocen como herencia. Básicamente, la herencia
define una relación entre clases, en donde una clase
comparte la estructura o comportamiento definido
en una o más clases (herencia simple y herencia
múltiple, respectivamente).

23. 1.5.4. JERARQUÍA Y HERENCIA.
 Jerarquía de clases. Las relaciones de herencia
forman una estructura de árbol (jerarquía).
Ejemplo:

24. 1.5.5 POLIMORFISMO
 Comportamientos diferentes, asociados a objetos
distintos, pueden compartir el mismo nombre, al
llamarlos por ese nombre se utilizará el
comportamiento correspondiente al objeto que se
esté usando.
 Es la posibilidad de que una entidad tome muchas
formas. En términos prácticos, el polimorfismo
permite referirse a objetos de clases diferentes
mediante el mismo elemento de programa y
realizar la misma operación de diferentes formas,
según sea el objeto que se referencia en ese
momento.
 El polimorfismo adquiere su máxima expresión
en la derivación o extensión de clases, es decir,
cuando se obtiene una clase a partir de una clase
ya existente, mediante la propiedad de derivación
de clases o herencia.

25. 1.5.5 POLIMORFISMO
 Suponer una jerarquía de clases de
figuras de dos dimensiones. Cada
clase puede tener un método que se
llame igual, por ejemplo “área()” pero
cada clase tendrá una formula de
cálculo de área diferente según la
clase.
 Por ejemplo, la operación comer es
una operación fundamental en la vida
de los mamíferos, de modo que cada
tipo de mamífero debe poder realizar
la operación o función comer. Por otra
parte, una cabra o una vaca que pastan
en un campo, un niño que se come un
caramelo y un animal que devora a
otro animal, son diferentes formas que
utilizan diferentes mamíferos para
realizar la misma función (comer).

26. 1.6 HISTORIA DE LOS PARADIGMAS EN EL DESARROLLO DEL SOFTWARE.
Paradigmas: Representan un enfoque particular o filosofía para la
construcción del software. No es mejor uno que otro sino que cada
uno tiene ventajas y desventajas. Los más comunes son el desarrollo
en cascada(metodología de desarrollo en cascada es: Análisis de
requisitos, Diseño, Programación, Prueba, Implantación,
Mantenimiento),.
Los enfoques generales para la escritura del código han sido:
 Programación “espagueti”. Sin una secuencia de ejecución definida.
Sin módulos.
 Programación estructurada. Se usan los módulos (basados en
procedimientos) y las sentencias de programación estructuradas.
 POO. Se afina el concepto de módulo al incluir datos y
procedimientos (en una “clase”). Incluye nuevos conceptos como
herencia, polimorfismo, etc.
Ventajas El análisis del riesgo se hace de forma explícita y clara.
Une los mejores elementos de los restantes modelos.
Inconvenientes Genera mucho trabajo adicional. Exige una cierta
habilidad en los analistas (es bastante difícil

27. 1.6 HISTORIA DE LOS PARADIGMAS EN EL DESARROLLO
DEL SOFTWARE.
Algunos paradigmas de programación específicos (procedimientos
computacionales para resolver un problema), son:
 Demostrativo.
 El desarrollo en espira
 El desarrollo por prototipos
 El desarrollo incremental,
 El desarrollo en V
 Declarativo.
 Imperativo.
 Funcional.
 Lógico.
 Orientado a Objetos.

28. 1.6 HISTORIA DE LOS PARADIGMAS EN
EL DESARROLLO DEL SOFTWARE.
Los LP según su nivel de acercamiento con el
“hardware” se clasifican en:
 Lenguaje máquina (0, 1).
 Lenguaje ensamblador.
 Lenguajes de tercer nivel (palabras en inglés).
 Lenguajes declarativo (indicar que hacer y no como
hacerlo).
Desde el punto de vistas de las metodologías que se
aplican para el ciclo de vida del software, algunas son:
 Ciclo vida clásico o cascada.
 Modelo en espiral.
 Prototipos.

29. 1.7 BENEFICIOS DEL MODELO DE OBJETOS Y DE LA
POO SOBRE OTROS PARADIGMAS.
La programación orientada a objetos beneficia a los desarrolladores debido a que:
 Los programas son fáciles de diseñar debido a que los objetos reflejan elementos
del mundo real.
 Las aplicaciones son más sencillas para los usuarios debido a que los datos
innecesarios están ocultos.
 Los objetos son unidades autocontenidas.
 La productividad se incrementa debido a que puede reutilizar el código.
 Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades
de negocios.
 Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
 Simplifica los datos complejos.
 Reduce la complejidad de la transacción.
 Confiabilidad.
 Robustez.
 Capacidad de ampliación.
 La OO permite una modelación más natural de los sistemas, parecido a como un
humano los visualiza. El modelo refleja mejor la realidad.
 La OO proporciona soporte para todas las etapas del ciclo de vida del software.

30. 1.7 BENEFICIOS DEL MODELO DE OBJETOS Y DE
LA POO SOBRE OTROS PARADIGMAS.
 La LPOO permite crear TDA (tipos de datos
abstractos). Es decir nuevos tipos de datos que no
están predefinidos en el LP pero son necesarios
para el usuario.
 Los LPOO proporcionan un rico conjunto de clases
predefinidas que se pueden usar en las
aplicaciones.
 Reutilización. Las clases se construyen a partir de
otras clases.

31. 1.7 BENEFICIOS DEL MODELO DE OBJETOS Y DE
LA POO SOBRE OTROS PARADIGMAS.
 Fiabilidad.
 Productividad del desarrollador.
 Calidad.
 Mantenimiento.
 Costo.
 Escalabilidad.
 Adaptabilidad (mejor independencia e
interoperabilidad).