miércoles, 7 de octubre de 2009

Uso de ArgoUML

Uso de UML para poder facilitar el análisis para la creación de algún problema.


Conocer conceptos:
Diagramas de Casos de Uso: Es una descripción generalizada de como será usado el sistema, además de que ofrece una visión desde fuera para poder entender el propósito de la funcionalidad del sistema.

Diagrama de Clases: Muestra una estructura estática del objeto, así como su estructura interna y sus relaciones entre si.




Para comenzar marquemos los requerimientos que nos pide el problema, en este caso haremos el diagrama de casos de uso para un control de carro,y debe tener las siguientes funciones; activar/desactivar alarma, poner/quitar seguros, abrir/cerrar cajuela, y responder al botón de pánico, através de los botones del mismo control.Hay que partir desde saber como es nuestra interfaz, que en este caso sería el control del auto

Requerimientos:

  • Activar/desactivar alarma
  • Poner/quitar seguro
  • Abrir/Cerrar cajuela
  • Activar el panic

Detallamiento:
1 botón: - 1clic; pone seguros- 2 clic; alarma en espera
2 botón:- 1 clic; tiene la función de desactivar la alarma, ya sea que este en espera o haya sido activada (sonido)- 2 clic; quita seguros- 3 clic; un tercer clic en caso de que el botón de panic haya sido activado
3 botón:- 1 clic; abre cajuela- 2 clic; cierra cajuela

4botón:- 1 clic; a este botón sólo se le dará la función de activar panico

El resultado es:



Ahora designamos una clase que se va a llamar "botones" y ya de ahi salen las caracteristicas para un diagrama de clases: De la misma forma podemos desarrrollar otro diagrama de casos de uso pero ahora enfocandolo a el funconamiento de una gasolinera:

Requerimientos:

  • Recarga a gasolinera
  • Cargar gasolina a automóvil
  • Venta de productos extra
    Pago del cliente
    Recarga de máquina una vez por semana


Resulatado





lunes, 5 de octubre de 2009

FUERAS DE SERIE (Outliers)



¿Porque unas personas tienen éxito y otras no? ¿Qué diferencia a quienes hacen algo especial en la vida de quienes no lo hacen?
A través de su viaje por el mundo de los «fueras de serie», los mejores, los más brillantes y famosos, nos convence de que nuestro modo de pensar en el éxito es erróneo.
Prestamos demasiada atención al aspecto de estas personas, y muy poca al lugar de donde vienen, es decir, a su cultura, su familia, su generación y a las singularidades de su educación.
El relato maneja principalmente la idea equivocada de que nacemos con chispa y esto hace que triunfemos pero en realidad esta idea es errónea ya que esta demostrado que todos los grandes de nuestra cultura popular no llegaron a ser lo que son tan solo por su talento inato sino por la extensa practica y arduas horas de devoción y dedicacion para hacer lo que amaban.
Cita el ejemplo de los Beatles que en realidad no era una muy buena banda, o que fueran mui buenos tocando, o que fueran muy amigos o que lo tocaran con el corazon, lo que los hizo trascendentes fue la excelencia con las que aprendieron tocar después de muchas horas de practica gracias a las oportunidades
que recibieron. Lo que distingue a un interprete virtuoso de uno mediocre es el esfuerzo que cada uno dedica a practicar y eso no es todo: los que estan en la misma cumbre no es que trabajen un poco o bastante mas que todos los demás, trabajan mucho, mucho mas.



Otro caso particular es el de Bill Gates que desde pequeño tuvo las posibilidades de estudiar y estar en lugares oportunos donde se abría paso la programacion y las horas de practicas diarias.



La imagen que surge de tales estudios es que se requieren diez mil horas de practica para alcanzar el dominio propio de un experto de categoría mundial en el campo que fuere.
Parece que el cerebro necesitase de ese tiempo para asimilar cuanto necesita conocer para alcanzar un dominio verdadero, esto se cumple hasta en los casos emblemáticos de un prodigio. Diez mil horas es el numero mágico de la grandeza.
La mayoría de la gente solo puede alcanzar esa cifra formando parte de alguna especie de programa especial o accediendo a una especie de oportunidad extraordinaria que les de una posibilidad de invertir tantas horas en una misma cosa.
Esto nos hace preguntarnos ¿la regla de las diez mil horas es una regla general para el éxito? todos los fueras de serie que hemos visto hasta ahora son beneficiarios de alguna especie de oportunidad insólita que disfrutaron y los hicieron practicar las diez mil horas por lo que hace pensar que Si, si es una regla general.

domingo, 4 de octubre de 2009

sábado, 26 de septiembre de 2009

Ejemplo de Clases

Ejemplo de control de Auto


Control
Prende el boton de panico.
Activa y desactiva la alarma del carro.
Pone y quita seguros de las puertas.
Abre la cajuela.

Una vez, pone/quita seguros.
Dos veces, Deja la alarma en espera activa.


Clase de usos

Chofer: Presiona los botones del control
Control: Activa y desactiva la alarma del carro.
Control: Quitan y ponen seguros. Abre la puerta.
Control y llave: Abren la cajuela.
Control: Deja la alarma en espera activa.
Llave: Enciende el carro.


UML Tutorial




UML (Lenguaje de modelado unificado) reprenta la unificacion de los conceptos y notaciones que presentaron tres autores en sus libros ( Grandy Booch, Jim Rumbaugh y Ivar Jacobson)

La Objetivo de UML es convertirse en un lenguaje comun para crear modelosde objetos orientados a a softwares.

Esta corriente de UML esta compuesta por dos importantes corrientes; metamodelado y notacion.


Metamodelo: UML es el unico que tiene una representacion de datos estandar, esta es llamada metamodelo, que es una descripcion de UML en UML. Este describe objetos, atributos y relaciones necesarias para representar los conceptos de UML con otras aplicaciones del software. Este proporciona casos estandar e inequivocos.

La Notacion: Esta compuesta de dos subdiviciones:
Divicion para modelados de elementos estaticos de un diseño por ejemplo clases, atributos y relaciones.
Divicion para modelados de elementos dinamicos de un diseño por ejemplo;objetos, mensajes y maquinas de estados finitos.

Diagrama de Clases: El proposito deldiagrama de clases es representar las clases dentro de un modelo, En un objeto orientado a aplicaciones las clases tienen atributos (miembro variables) operaciones (miembro funcion) y relaciones con otras clases

sábado, 19 de septiembre de 2009

Unidad 1 Conceptos básicos del modelo orientado a objetos

1.1 Reconocimiento de Objetos y Clases

Un objeto se delimita como una estructura que encapsula atributos (características) y comportamientos (procedimientos) de una entidad con un papel bien definido. 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.
Los objetos, concretos y abstractos, están a nuestro alrededor, forman nuestro entorno. Podemos distinguir cada objeto en base a sus características y comportamientos.
Por ejemplo; en un aula de clases observamos los siguientes objetos: • Alumno • Profesor • Mesa • Silla • Mesa banco • Pizarrón
Interacción entre objetos: Los objetos no sólo tienen atributos relacionados con su forma física sino que, además, exhiben comportamientos específicos de su clase.
• Alumno: Estudia, aprende.
• Profesor: Enseña, evalúa.
• Mesa: Ordenada, desordenada.
• Silla: Ocupada, desocupada.
• Mesa banco: Ocupado, desocupado.
• Pizarrón: Pintado, borrado
Observamos que en el aula hay varios objetos alumno, por lo que pensamos en el grupo de alumnos, al que denominaremos como la clase alumno. De igual manera, cada materia es impartida por un profesor; el conjunto de profesores forman la clase Profesor. Pudiéramos extender nuestro análisis al pizarrón, la mesa, la silla,, al conjunto de mesa bancos, etc.
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 La Abstraccion y el encapsulamiento como un proceso natural


Abstracción: Es un método por el cual abstraemos valga la redundancia, una determinada entidad de la realidad de sus características y funciones que desempeñan, estos son representados en clases por medio de atributos y métodos de dicha clase.
Procedimientos: Proporcionó la primera posibilidad de ocultación de información.
Módulos: Es una técnica que proporciona la posibilidad de dividir sus datos y procedimientos en una parte privada y una parte pública. Proporcionan un método efectivo de ocultación de la información, pero no permiten realizar instanciación, que es la capacidad de hacer múltiples copias de las zonas de datos.
TADS: Un tipo abstracto de dato (TAD) es un tipo de dato definido por el programador que se puede manipular similarmente a los tipos de datos definidos por el sistema.
Un tipo abstracto de dato corresponde a un conjunto (puede ser de tamaño indefinido) de valores legales de datos y un número de operaciones primitivas que se pueden realizar sobre esos valores. Para construir un tipo abstracto de dato se debe:
1.- Exponer una definición del tipo.
2.- Hacer disponible un conjunto de operaciones.
3.- Proteger los datos asociados con el tipo.
4.-Permitir instancias múltiples del tipo.

1.3 La Poo y la Complejidad del Software

La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación. Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita ver este tipo de programación.
En la historia de la programación ha habido varias evoluciones sucesivas. Una de las principales fue la programación estructurada, cuyo principio fundamental era dividir un programa en subprogramas más pequeños y fáciles de resolver, hasta llegar a niveles de complejidad elementales, siempre apoyándonos en la idea de ¿qué debe hacer el programa?
Este método de diseño, a pesar de haber dado resultados satisfactorios, tiene limitaciones. Algunas de ellas son:
• No favorece la reutilización del código. Si en la figura anterior f1 y f2 fueran idénticas, este hecho seguramente pasaría desapercibido y no se compartiría una única función fn.
• Si dos subprogramas comparten una misma función fn reutilizando así el código que define la misma, y más adelante queremos modificar fn porque hay un cambio en uno de los subprogramas que la utilizan, la modificación afectará también al otro subprograma, razón por la que ahora tendremos que realizar dos funciones.
La programación orientada a objetos puede llevarse a cabo con lenguajes convencionales, pero esto exige al programador la construcción de los mecanismos de que disponen los lenguajes orientados a objetos. Por ello, lo más apropiado es utilizar directamente un lenguaje orientado a objetos, ya que éstos soportan los mecanismos y las características que anteriormente se han expuesto, tales como objetos, clases, métodos, mensajes, herencia, etc.
La herencia constituye uno de los mecanismos más potentes de la programación orientada a objetos

1.4 Conceptos del Ciclo de Vida del Software
El ciclo de vida del software en el Proceso Unificado
Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición.

La concepción: es definir el alcance del proyecto y definir el caso de uso.
La elaboración: es proyectar un plan, definir las características y cimentar la arquitectura.
La construcción: es crear el producto y la transición es transferir el producto a sus usuarios

Según Microsoft 1997, el diseño de software se realiza a tres niveles: conceptual, lógico y físico.

Diseño Conceptual :El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa.

Diseño Lógico: El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. El diseño lógico comprende las siguientes tareas:
*Identificar y definir los objetos de negocio y sus servicios
*Definir las interfases
*Identificar las dependencias entre objetos
*Validar contra los escenarios de uso
*Comparar con la arquitectura de la empresa
*Revisar y refinar tanto como sea necesario


Diseño físico: El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o económica. El componente es la unidad de construcción elemental del diseño físico.

Las características de un componente son:

*Se define según cómo interactúa con otros
*Encapsula sus funciones y sus datos
*Es reusable a través de las aplicaciones
*Puede verse como una caja negra
*Puede contener otros componentes

El diseño físico debe involucrar:

*El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red.
*El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso)
*El diseño para uso concurrente – el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.
*El diseño con el manejo de errores y prueba de eventos: Validando los parámetros- a la entrada antes de continuar con cualquier proceso. Protegiendo recursos críticos manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.
*Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos.
*Debugging – crear una versión para limpiar errores.
*Protección integral de transacciones de negocios – los errores deben regresarse al componente que llama.

El diseño físico comprende las siguientes tareas:

*Definir los componentes
*Refinar el empaquetamiento y distribución de componentes
*Especificar las interfases de los componentes
*Distribuir los componentes en la red
*Distribuir los repositorios físicos de datos
*Examinar la tolerancia a fallas y la recuperación de errores *
*Validar el diseño físico

De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica.

La Programación Orientada a Objetos



La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented Programming) como paradigma, “es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes.
Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La POO como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes”

1.4.1 Especificaciones de requerimientos

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema

ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS
Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.
Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando que se versión es “esencial por necesidades especiales”.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

*Requerimientos funcionales
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo

*Requerimientos no funcionales.
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento.
De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

REQUERIMIENTOS DEL USUARIO Y DEL SISTEMA

Requerimientos del usuario
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos

LOS REQUERIMIENTOS DEL SISTEMA

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador del software.
Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.
La especificación de requerimientos del sistema incluye diferentes modelos del sistema como el de objetos o el de flujo de datos.

EL DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE: Éste es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema. En algunos casos, los dos tipos de requerimientos se integran en una única descripción. En otros, los del usuario se definen en una introducción de la especificación de los del sistema. Si existe un gran numero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar como documentos separados.
El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los administradores principales de la organización, quienes pagan por el sistema, hasta los ingenieros responsables del software.
Una gran variedad de organizaciones han definido estándares para los documentos de requerimientos.
El IEEE sugiere la siguiente estructura para los documentos de requerimientos.
1. Introducción • propósito del documento de requerimientos • Alcance del producto • Definiciones, acrónimos y abreviaturas • Referencias • Resumen del resto del documento
2. Descripción general • Perspectiva del producto • Funciones del producto • características del usuario • Restricciones generales • Suposiciones y dependencias
3. Requerimientos específicos. Cubren los requerimientos funcionales, no funcionales y de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección. Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeño del sistema, especificar los requerimientos lógicos de la base de datos, las restricciones de diseño, las propiedades emergentes del sistema y las características de calidad.
4. Apéndices
5. Índice

MODELADO DEL SISTEMA: Es importante evaluar los componentes del sistema y sus relaciones entre sí, determinar cómo están reflejados los requisitos, y valorar como se ha concebido la “estética” en el sistema.

VALIDACIÓN DE REQUISITOS: El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidad en la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.

GESTIÓN DE REQUISITOS: Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento.

FACTORES EN LA CALIDAD DEL SOFTWARE: La construcción de software de calidad requiere el cumplimiento de numerosas características:
*Eficiencia: La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula.
*Transportabilidad (portabilidad): La transportabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
*Verificabilidad: La verificabilidad es facilidad de verificación de un software; es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
*Integridad: es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso.
*Fácil de utilizar: Un software es fácil de utilizar si se puede comunicar con él de manera cómoda. *Corrección: Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
*Robustez: Capacidad de los productos software de funcionar incluso en situaciones anormales.
*Extensibilidad: Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esto: diseño simple y descentralización.
*Reutilizació: Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
*Compatibilidad: Facilidad de los productos para ser combinados con otros.

1.4.2 Analisis Orientado a Objetos

Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la información
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa

1.4.3 Diseño Orientado a Objetos
Es el proceso de construir un modelo de objetos para la solución. El diseño orientado a objetos es el proceso de dividir una solución en una cantidad determinada de objetos constituyentes


1.4.4 Programacion Orientada Objetos Conceptos y Caracteristicas
¿Que es la programación orientada a objetos?.
La Programación Orientada a Objetos (POO) es una forma de enfocar la tarea de programación. Los enfoques de la programación han cambiado drásticamente desde la invención de las computadoras, la creciente complejidad de los programas, antes se realizaban mediante una consola las instrucciones máquinas en binario.
Esto funcionaba porque los programas sólo tenían unos pocos cientos de instrucciones. Cuando crecieron los programas, se invento el lenguaje ensamblador para que el programador pudiera manejar programas más largos y complejos usando una representación simbólica de las instrucciones máquina.
Los lenguajes de alto nivel aparecieron para proporcionar al programador más herramientas con las cuales gestionar esa complejidad. En los años sesenta nace la programación estructurada, este es el método alentando por varios lenguajes como pascal, y C. Con los lenguajes estructurados fue posible escribir programas moderadamente complejos de una forma bastante sencilla.
Sin embargo, usando incluso la programación estructurada, cuando los proyectos Alcanzan cierto tamaño, su complejidad se vuelve demasiado difícil para ser controlada por un programador. La Programación Orientada a Objetos 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.
La Programación Orientada a Objetos permite descomponer fácilmente un problema en subgrupos de partes relacionadas. Entonces, puede traducir estos subgrupos en unidades autocontenidas llamadas Objetos

1.5 Elementos Primordiales en el Modelo de Objetos



1.5.1 Abstraccion Objetos
Significa 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. Es la capacidad para encapsular y aislar la información de diseño y ejecución.
La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes características (no esenciales).
Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes.

1.5.2 Encapsulamiento Objetos
El encapsulamiento es una característica de la programación orientada a objetos. 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.
Encapsulamiento Como se puede observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa.
Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento.
Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.

1.5.3 Modularidad Objetos
La Modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.
La modularización consiste en dividir un programa en módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.
La Modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación y abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización de un buen módulo como componente.

1.5.4 Jerarquia y Herencia
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.5 Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, 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.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. También hay situaciones donde un paradigma resulta más apropiado que otro. Los más comunes son el desarrollo en cascada, el desarrollo en espiral, el desarrollo por prototipos, el desarrollo incremental, el desarrollo en V y el desarrollo orientado a objetos. También existen modelo híbridos, los cuales combinan elementos de diferentes modelos según las necesidades existentes.

Espiral

Prototipos




Casacada

Incremental

En v

Orientado a objetos
Hibridos
1.7 Beneficios del Modelo de Objetos y de la Poo sobre otros Paradigmas
En resumen, 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.
Permite mostrar la magnitud de los lenguajes de programacion basada en objetos.

La POO utiliza jerarquia de clases para la elaboracion del diseño. Crea sistemas mas flexibles, que en un futuro son modificables. Se aplica en las bases de datos, analisis matematico, animacion, robotica, composicion de musica, etc