FUNDAMENTOS DE PROGRAMACIÓN

ITCH IICarrera: ISCMateria: Fundamentos de Programación Alumna: Yesenia Chaparro OchoaHorario: 5 pm-6pmDocente: Hernán de la Garza Gutiérrez

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

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

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.

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.

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.

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

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.

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.

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.

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

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.

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:

ESCENARIOS Es una descripción parcial y concreta del

comportamiento de un sistema en una determinada situación.

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á.

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.

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.

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

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.

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

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.

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).

1.5.4. JERARQUÍA Y HERENCIA.

Jerarquía de clases. Las relaciones de herencia forman una estructura de árbol (jerarquía). Ejemplo:

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.

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).

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

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.

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.

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.

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.

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).