You are on page 1of 11

UNIDAD 1

CONCEPTOS BASICOS DEL MODELADO DE OBJETOS
1.1 Reconocimiento de objetos y clases en el mundo real y la interacción entre ellos.
La capacidad de reconocer objetos físicos es una habilidad que los humanos aprenden en edades muy tempranas. Una pelota de colores llamativos atraerá la atención de un niño, pero casi siempre, si se esconde la pelota, el niño no intentará buscarla; cuando el objeto abandona su campo de visión, hasta donde él puede determinar, la pelota ha dejado de existir. Normalmente, hasta la edad de un año un niño no desarrolla lo que se denomina el concepto de objeto, una habilidad de importancia crítica para el desarrollo cognitivo futuro. Muéstrese una pelota a un niño de un año y escóndase a continuación, y normalmente la buscará incluso si no esta visible. A través del concepto de objeto, un niño llega a darse cuenta de que los objetos tienen una permanencia e identidad además de cualesquiera operaciones sobre ellos. Informalmente podemos entender un objeto como una entidad tangible que exhibe algún comportamiento bien definido. Desde la perspectiva de la cognición humana, un objeto es cualquiera de las siguientes cosas: • Una cosa tangible y/o visible • Algo que no puede comprenderse intelectualmente • Algo hacia lo que se dirige un pensamiento o acción Clases Para comprender la naturaleza de una clase, se deberán considerar dos niveles de definición: El abstracto y el de instrumentación. El nivel abstracto de una clase proporciona la esencia de la clase. En seguida se define una clase en el nivel abstracto. En el nivel abstracto, una clase se describe como una interfaz que define el comportamiento de sus objetos. Una clase se puede describir como una interfaz, porque su propósito principal es describir las operaciones, o funciones, que pueden realizar sus objetos. De esta manera, se define el comportamiento común para todos sus objetos. Por comportamiento, se entiende cómo actúa y reacciona un objeto de una clase dada cuando se acceda

1.2 La abstracción y el encapsulamiento.
Las personas normalmente comprenden el mundo construyendo modelos mentales de parte de los mismos; tratan de comprender cosas con las que pueden interactuar: un modelo mental es una vista simplificada de cómo funciona de modo que se pueda interactuar contra ella. En esencia, este proceso de construcción de modelos es lo mismo que el diseño de software, aunque el desarrollo de software es único. El diseño de software produce el modelo que puede se manipulado por una computadora.

La abstracción es esencial para el funcionamiento de una mente humana normal y es una herramienta muy potente para tratar la complejidad. Considerar, por ejemplo, el ejercicio mental de memorizar números. Un total de siete dígitos se puede memorizar con más o menos facilidad. Sin embargo, si se agrupan y se denominan números de teléfono, los dígitos individuales se relegan en sus detalles de más bajo nivel, creándose un nivel abstracto y más alto, en el que los siete números se organizan en una única entidad. Utilizando este mecanismo se puede memorizar algunos números de teléfonos, de modo que la agrupación de diferentes entidades conceptuales es un mecanismo potente al servicio de la abstracción. Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona así fronteras conceptuales nítidamente definidas respecto a la perspectiva del observador. Una abstracción se centra en la visión externa de un objeto y, por tanto, sirve para separar el comportamiento esencial de un objeto de su implantación. Seidewitz y Stara sugieren que «existe una gama de abstracción, desde los objetos que modelan muy de cerca entidades del dominio del problema a objetos que no tienen una verdadera razón para existir». De mayor a menor utilidad, estos tipos de abstracción incluyen: • Abstracción de entidades. Un objeto que representa un modelo útil de una entidad del dominio del problema o del dominio de la solución. • Abstracción de acciones. Un objeto que proporciona un conjunto generalizado de operaciones, y todas ellas desempeñan funciones del mismo tipo. • Abstracción de máquinas. Un objeto que agrupa operaciones, todas ellas virtuales utilizadas por algún nivel superior de control, u operaciones que utilizan todas algún conjunto de operaciones de nivel inferior. • Abstracción de coincidencia. Un objeto que almacena un conjunto de operaciones que no tiene relación entre sí. Se persigue construir abstracciones de entidades, porque imitan directamente el vocabulario de un determinado dominio de problema Encapsulamiento Dicho sencillamente, la abstracción de un objeto debería preceder a las decisiones sobre su implementación. Una vez que se ha seleccionado una implantación, debe tratarse como un secreto de la abstracción, oculto para la mayoría de los clientes. Como sugiere sabiamente Ingalls, «ninguna parte de un sistema complejo debe depender de los detalles internos de otras partes». Mientras que la abstracción «ayuda a las personas a pensar lo que están haciendo», el encapsulamiento «permite que los cambios hechos en los programas sean fiables con el menor esfuerzo». La abstracción y el encapsulamiento son conceptos complementarios: la abstracción se centra en el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la implementación que da lugar a este comportamiento. El encapsulamiento se consigue a menudo mediante la ocultación de información, que es el proceso de ocultar todos los secretos de un

objeto que no contribuye a sus características esenciales; típicamente, la estructura de un objeto esta oculta, así como la implantación de sus métodos. El encapsulamiento proporciona barreras explícitas entre abstracciones diferentes y por tanto conduce a una clara separación de intereses. Por ejemplo considérese la estructura de una planta. Para comprender como funciona la fotosíntesis a un nivel alto de abstracción, se pueden ignorar detalles como los cometidos de las raíces de la planta o la química de las paredes de las células. Análogamente, al diseñar una aplicación de bases de datos, es práctica común el escribir programa de forma que no se preocupen de la representación física de los datos, sin que dependan solo de un esquema que denota la vista lógica de los mismos. Los objetos a un nivel de abstracción están protegidos de los detalles de implementación a niveles más bajos de abstracción. Para resumir, se define el encapsulamiento como sigue: El encapsulamiento es el proceso de almacenar en un mismo compartimento de los elementos de una de una abstracción que constituye su estructura y su comportamiento; sirve para separar el interfaz contractual de una abstracción y su implantación.

1.3 La POO y la complejidad del software.
La abstracción es la clave para diseñar buen software. En los primeros días de la informática, los programadores enviaban instrucciones binaras a una computadora, manipulando directamente interrupciones en sus partes frontales. Los nemotécnicos del lenguaje ensamblador eran abstracciones diseñadas para evitar que los programadores tuvieran que recordar las secuencias de bits que componen las instrucciones de un programa. El siguiente nivel de abstracción se consigue agrupando instrucciones primitivas para formar macroinstrucciones. Por ejemplo, un conjunto se puede definir por abstracción como una colección no ordenada de elementos en el que no existen duplicados. Utilizando esta definición, se puede especificar si sus elementos se almacenan en un array, una lista enlazada o cualquier otra estructura de datos. Un conjunto de instrucciones realizadas por un usuario se pueden invocar por un macroinstrucción; un macroinstrucción instruye a la máquina para que realice muchas cosas. Tras los lenguajes de programación ensambladores aparecieron los lenguajes de programación de alto nivel, que supusieron un nuevo nivel de abstracción. Los lenguajes de programación de alto nivel permitieron a los programadores distanciarse de las interioridades arquitectónicas específicas de una máquina dada. Cada instrucción en un lenguaje de alto nivel puede invocar varias instrucciones máquina, dependiendo de la máquina específica donde se compila el programa. Esta abstracción permitía a los programadores escribir software para propósito genérico, sin preocuparse sobre que máquina corre el programa. El proceso de abstracción fue evolucionando desde la aparición de los primeros lenguajes de programación. El método más idóneo para controlar la complejidad fue aumentar los niveles de abstracción. En esencia la abstracción supone la capacidad de encapsular y aislar la información del diseño y ejecución. En un determinado sentido, las técnicas orientadas a objetos pueden verse

como un producto natural de una larga progresión histórica que va desde las estructuras de control, pasando por los procedimientos, los módulos, los tipos abstractos de datos y los objetos

1.4 Conceptos del ciclo de vida del software.
El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios. La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al software, a continuación dos conceptos: “Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software” IEEE 10744 “Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” ISO 12207-15

1.4.1 Especificaciones de requerimientos.
Expresión de necesidades. Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). Especificaciones. Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).

Lo más normal será que no resulte posible obtener una buena especificación del sistema a la primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados).

Análisis. Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, ...que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes: • Funcional. • Estático. • Dinámico. • Diseño Diseño Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.). Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirán justificadas en simple política de empresa y por mantener "compatibilidad" en lo que respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte de los casos no serán rumores con fundamento o estudios previos realizados al efecto, sino más bien debidos a la propia publicidad como consejera). Implementación. Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos. Lamentablemente en la actualidad, quedan bastantes empresas en las que, tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de

implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto. Pruebas. El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.e. de rendimiento). Validación. Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos). Mantenimiento y Evolución. Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.e. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.e. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

1.4.2 Análisis 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 El análisis orientado a objetos 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.3 Diseño Orientado a Objetos.
El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico del sistema que diseña.

El diseño de software orientado a objeto anima a pensar en el software como un modelo muy próximo a la forma en que pensamos, e interaccionamos con él, en el mundo real. En edad temprana, aprendemos acerca de los objetos y de cómo se manipulan. Los bebés, aprende que si mueven un sonajero hará ruido. Más tarde, a medida que se desarrollan las capacidades cognitivas, somos consientes de que los objetos tienen propiedades y empezamos a pensar en ellos de forma abstracta. Por ejemplo, un bebé crecido pronto se da cuenta de que hacer ruido es una capacidad de todos los sonajeros

1.4.4 Programación Orientada a Objetos, conceptos y características.
La orientación a objetos puede describirse como el conjunto de disciplinas (ingeniería) que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes. La programación orientada a objetos permite una representación más directa del modelo de mundo real en el código. El resultado es que la transformación radical normal de los requisitos de sistema (definido en términos de usuario) se reduce considerablemente. La programación orientada a objetos es un método de implementación en que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia. Hay tres características importantes: 1. Utiliza objetos, no algoritmos, como sus bloques lógicos de construcción fundamentales. 2. Cada objeto es una instancia de alguna clase 3. Las clases están relacionadas con otras clases por medio de relaciones de herencia

1.5 Elementos primordiales en el modelo de objetos.
Los elementos más importantes que deben tener los objetos de software que sirven como base sobre las cuales se fundamenta la programación orientada a objetos, para cumplir con el paradigma de orientación a objetos son: • Abstracción • Encapsulamiento • Modularidad. • Herencia y Jerarquía. • Polimorfismo. Cada uno de estos puntos requiere de una actitud mental diferente, una forma distinta de pensar en el problema. Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de objetos.

1.5.1 Abstracció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 el proceso de simplificar un problema complejo. Al abordar la solución de un problema, uno no se abruma con cada uno de los detalles, mas bien, lo simplifica enfocándose tan sólo en los aspectos relevantes para la solución. Una abstracción se centra en la vista externa de un objeto, de un 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. El elemento clave de la programación orientada a objetos es la clase. Una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado específico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, un pluma estilográfica es un objeto que tienen un estado (llena de tinta o vacía) y sobre la cual se pueden realizar algunas operaciones (por ejemplo escribir, poner o quitar el capuchón, llenar de tinta si está vacía). La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de clases para gestionar dichas abstracciones en lenguajes de programación ha facilitado considerablemente su aplicación.

1.5.2 Encapsulamiento.
La encapsulación o encapsulamiento es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en esencia, es el proceso de ocultar todos los objetos de un objeto que no contribuyen a sus características esenciales. La encapsulación permite la división de un programa en módulos. Estos módulos se implementan mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la práctica, esto significa que cada clase debe tener dos partes una interfaz y una implementación. El interfaz de una clase captura solo su vista externa y la implementación contiene la representación de la abstracción, así como los mecanismos que realizan el comportamiento deseado.

1.5.3 Modularidad.
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 si 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. Por ejemplo, en C++ los módulos son archivos compilados por separado. La práctica usual es situar los interfaces de los módulos en archivos con nombres con extensión .h (archivos de cabecera) y las implementaciones de los módulos se sitúa en archivos con nombre con extensión .cpp.

La modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módulos cohesivos y débilmente acoplados

1.5.4 Jerarquía y herencia.
Una de las propiedades más importantes de la programación orientada a objetos es la herencia. De hecho, algunos piensan que un programa que no emplea herencia no es un programa orientado a objetos. La herencia es aquella propiedad de la programación orientada a objetos que le permite a una clase, llamada clase derivada, compartir la estructura y el comportamiento de otra clase, llamada clase base. La naturaleza está llena de herencia. Todas las cosas vivas heredan las características o rasgos de sus antepasados. Aunque usted es diferente de sus padres en muchos sentidos, también es igual en muchas formas debido a los rasgos genéticos que ha heredado de ellos. En la programación orientada a objetos, la herencia permite que las clases recién creadas hereden miembros de clases existentes. Estas nuevas clases derivadas o hijos, incluirán sus propios miembros y miembros heredados de las clases base o padres. De esta manera, es posible ver una colección de clases con miembros heredados comunes como una familia de clases, como aquélla a la que usted pertenece. Las clases se relacionan una con otra a través de la herencia. Tal herencia crea una jerarquía de clase. La jerarquía es una propiedad que permite una ordenación de las abstracciones. Las dos jerarquías mas importantes de un sistema complejo son: estructura de clases (jerarquía «es–un» (is–a): generalización/especialización) y una 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 mas clases (herencia simple y herencia múltiple, respectivamente). La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación y ruedas, motor, transmisión y chasis son agregados de camión.

1.5.5 Polimorfismo.
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Característica fundamental de la POO, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esta propiedad no suele ser considerada como

fundamental en los diferentes modelos de los objetos propuestos, pero, dada su importancia, no tiene sentido considerar un objeto modelo que no soporte esta propiedad. Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite 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.

1.6 Historia de los paradigmas en el desarrollo del software.
El significado de paradigma (paradigma en latín; paradeigma en griego) en su origen significaba un Ejemplo ilustrativo, en particular enunciado modelo que mostraba todas las inflexiones de una palabra. 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 La programación orientada a objetos (POO) se suele conocer como un nuevo paradigma de programación. Otros paradigmas conocidos son: el paradigma de la programación imperativa (con lenguajes tales como Pascal o C), el paradigma de la programación lógica (PROLOG) y el paradigma de la programación funcional (Lisp). En este sentido, la programación orientada a objetos es un nuevo paradigma. La orientación a objetos fuerza a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa realizar computación y sobre como se estructura la información dentro del computador.

1.7 Beneficios del modelo de objetos y de la POO sobre otros paradigmas
La programación orientada a objetos es una técnica para programar: un paradigma para escribir “buenos” programas para un conjunto de problemas. El apoyo para un paradigma no viene solo en la forma obvia de los recursos del lenguaje que permiten emplear directamente el paradigma, sino también en la forma más sutil de verificaciones en los tiempos de compilación o ejecución, o ambos, contra desviaciones no intencionales respecto al paradigma. La verificación de tipos es el ejemplo mas obvio de esto; la detección de ambigüedades y las verificaciones durante la ejecución pude servir para ampliar el apoyo lingüístico de los paradigmas. Los recursos extra lingüísticos, como las bibliotecas estándar y los ambientes de programación, pueden proporcionar también un apoyo importante para los paradigmas. Un lenguaje no es por fuerza mejor que otro por poseer una característica de la que carece el otro. Existen muchos ejemplos de lo contrario. Lo importante no es tanto que características posee un lenguaje, sino que estas sean suficientes para apoyar los estilos de programación deseados en las áreas de aplicaciones deseadas: • Todas las características deben estar integradas al lenguaje en forma muy limpia y elegante.

• Debe ser posible utilizar una combinación de características distintivas para lograr soluciones que de otra manera habrían requerido características independientes adicionales. • El numero de características espurias y de aplicación especial debe ser lo mas bajo posible. • La realización de un rasgo distintivo no debe implicar un gasto extra significativo para los programas que no lo requieran. • Un usuario solo necesita saber acerca del subconjunto del lenguaje empleado explícitamente para escribir un programa.