Fundamentos de Programación

1.1 Reconocimiento de clases y objetos y sus relaciones en el mundo real. Identificar objetos y relaciones en los siguientes sistemas: Escuela, Sesión de Internet, Pago de predial, Bosque, Río, Inscripción.

1.2 Abstracción. Abstracción: 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)

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

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.

1.4 Conceptos del ciclo de vida del software. Las etapas básicas 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. Para esta actividad se debe: Identificar las necesidades del usuario (del negocio). Describir los objetivos de la aplicación. Definir características y funciones generales de la aplicación. El equipo de Ingeniería de sistemas y los clientes deben establecer en conjunto las metas y objetivos de la aplicació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.

Ejemplo de especificación de requerimientos. 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.

Ejemplo de especificación de requerimientos. 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.

1.4.2 Análisis Orientado a Objetos 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 de diagrama de caso de uso.

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

1.5.1. Abstracción. Denota las características esenciales de un objeto, donde se capturan sus comportamientos.

1.5.2. Encapsulamiento. Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción.

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

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.

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.

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 “area()” pero cada clase tendrá una formula de cálculo de área diferente según la clase.

1.5.5 Polimorfismo El método se llama igual, por tener el mismo significado lógico. Las llamadas a cada método serían parecidas a la forma: Cuadrado.area() Rectángulo.area() Círculo.area()

1.6 Historia de los paradigmas en el desarrollo del software. Los enfoques generales para la escritura del código han sido: Programación “espaguetti”. 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.

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

1.6 Historia de los paradigmas en el desarrollo del software. 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 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 interoperatividad).